1 / 10

SE or C for ES? Discussion Group

SE or C for ES? Discussion Group. Olaf Spinczyk / Bernd Fischer Embedded System Software Group Computer Science 12 TU Dortmund olaf.spinczyk@tu-dortmund.de http://ess.cs.tu-dortmund.de/~os/. Why C?. Fear of performance issues Lack of tool support Matlab/Simulink ok

katima
Download Presentation

SE or C for ES? Discussion Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SE or C for ES? Discussion Group Olaf Spinczyk / Bernd Fischer Embedded System Software Group Computer Science 12 TU Dortmund olaf.spinczyk@tu-dortmund.de http://ess.cs.tu-dortmund.de/~os/

  2. Why C? • Fear of performance issues • Lack of tool support • Matlab/Simulink ok • Certification is very difficult with dynamic dispatch, etc. • predictability is critical • Safety critical applications are common in ES

  3. Tailoring Embedded DBMS Today? • Not at all? Not really. • Berkeley DB a little (11 features, #ifdefs, runtime checks)‏ • Ctree (C, multiple variants)‏ • 2 -3 commercial embedded databases • Flash DB • Models? Models for variability? • No. At least we don't know better.

  4. SE Techniques of Interest • Various techniques that support Product Line Enginering • CPP++ • OO • AOP • FOP • SOA • MDSD

  5. How to do better? • With CPP++ • Benefits • same level of configurability • better views, navigation, documentation (statistics)‏ • checking consistency • maintenance costs are reduced • could be coupled with variant management tools • Open Issues • how to use it? • what is the right feature granularity? • depending on the feature granularity #ifdef hell could be replacedby a color hell

  6. How to do better? • With OO (and Components)‏ • Benefits • modularization, ... • Open Issues • crosscutting concerns • granularity vs overhead • dynamic binding vs. resource constraints

  7. How to do better? • With AOP or FOP • Benefits • Better modularity • -ilities • feature tracability (mapping of features to modules better)‏ • Generating variants is easier • Pluggability of modules • Development easier • Open Issues • unexpected results with aspects (wrong pointcuts)‏ • with FOP combining layer in mind is difficult • tools support for visualization and reasoning etc. crucial • aspect interaction... • no commercial support, yet

  8. How to do better? • With MDSD • Benefits • ultimate generative power • arbitrary domain-specific abstraction • e.g. a language for locking mechanism • Open Issues • abstraction gap between feature model and MDSD model low or even not existing • how many DB-specific abstraction do exist?

  9. How to do better? • With SOA • Benefits • easy to integrate and flexible architecture • loosely coupled components • distributed components • high autonomy • reduced complexity • Open Issues • communication overhead • SOA and embedded devices don’t really match • SOA is designed for large enterprises • are small scale applications • can’t be fast and reliable at the same time

  10. So what can we do? • Can we take just the benefits? • Is there a migration path from the current state of the art to more advance SE techniques? • start thinking in product lines • use CPP++: very close to #ifdef, but visualization etc. • use simple objects or components: clearly defined interfaces; higher level of abstraction; be aware of costs! • use AOP and/or FOP: better modularization of feature implementations in the solution space (homogeneously crosscutting/inhomogeneously crosscutting concerns)‏ • use MDSD: more “generative power” and arbitrary domain-specific models • use SOA: decoupling and distribution of components • Tool support for each migration step would be needed

More Related