slide1 n.
Skip this Video
Download Presentation
SE or C for ES? Discussion Group

Loading in 2 Seconds...

play fullscreen
1 / 10

SE or C for ES? Discussion Group - PowerPoint PPT Presentation

  • Uploaded on

SE or C for ES? Discussion Group. Olaf Spinczyk / Bernd Fischer Embedded System Software Group Computer Science 12 TU Dortmund Why C?. Fear of performance issues Lack of tool support Matlab/Simulink ok

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'SE or C for ES? Discussion Group' - katima

Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

SE or C for ES?

Discussion Group

Olaf Spinczyk / Bernd Fischer

Embedded System Software Group

Computer Science 12

TU Dortmund

why c
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
tailoring embedded dbms today
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.
se techniques of interest
SE Techniques of Interest
  • Various techniques that support Product Line Enginering
    • CPP++
    • OO
    • AOP
    • FOP
    • SOA
    • MDSD
how to do better
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
how to do better1
How to do better?
          • With OO (and Components)‏
  • Benefits
    • modularization, ...
  • Open Issues
    • crosscutting concerns
    • granularity vs overhead
    • dynamic binding vs. resource constraints
how to do better2
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
how to do better3
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?

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
so what can we do
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