1 / 23

D1.2: State of the Art in Software Engineering for Embedded Systems in Flanders

D1.2: State of the Art in Software Engineering for Embedded Systems in Flanders. Prof. Koen De Bosschere. Outline. Visit summary Reported problem areas Conclusion. Visits. Barco Agfa-Gevaert Philips Imec Siemens-Atea Alcatel. Application domains. Modems Network devices

dragon
Download Presentation

D1.2: State of the Art in Software Engineering for Embedded Systems in Flanders

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. D1.2: State of the Art in Software Engineering for Embedded Systems in Flanders Prof. Koen De Bosschere

  2. Outline • Visit summary • Reported problem areas • Conclusion

  3. Visits • Barco • Agfa-Gevaert • Philips • Imec • Siemens-Atea • Alcatel

  4. Application domains • Modems • Network devices • Telephone switches • Digital video + audio • Remote controls • TVs; set-top boxes • High-end printers; printer servers • Display systems • GPS • Hearing devices • Battery management systems

  5. Hard real-time applications Hard real-time code • Hard Real-time apps • power down • mechanical • incoming signals • protocols 33 % Soft Real-time apps Not Real-time apps

  6. Hardware • One 4-bit microcontroller vs. network of high-end 32-bit processors • 16 bytes vs. 64 MB of RAM (500 kstats) • Hard disks • Battery-powered • Custom or off-the-shelf

  7. Development cost • Teams: 1-20 people • Development effort: 3-1318 py • Time to market: 0.5-5 years • 10% vs. 70% software effort • Manufacturing cost vs. development cost

  8. Development process • Each company has more than one type of software development process • The bigger the projects/company, the better formalized the software development process and methodology • Move towards: spiral or incremental model

  9. Development process • Waterfall • V-model • HPM (HatleyPirbhay and Meilir Page-Jones) • SASD • PEPP • Rational Unified Process • Octopus • ROOM • CMM

  10. Design tools • Rational Rose • Rose Real-Time • Together/J • Word/Excel/Interleaf • Flowcharter/Visio/StP • Intranet

  11. Models, Diagrams • State charts • Message sequence charts • Block diagrams • Use cases • Scenarios • Data flow diagrams • Class diagrams • Collaboration diagrams • Text

  12. Reported problems with design tools • Current design tools are too complex and offer too little, they are not worth the effort for small to medium projects • Real-time constraints cannot be tracked

  13. Programming languages • C++ (large projects) • C • Assembler (small projects) • Java • Ada • Visual Basic • VHDL

  14. Development Environments • CodeWright • DevStudio • Visual Basic • Visual Studio • JBuilder, Visual J++ • Apex • CAD-UL • Emacs/Textedit/vi • DDTS • Visual Age (Envy)

  15. Versioning • ClearCase • Continuus • PVCS • CVS • WebCVS

  16. Debugging/testing • ICE (microcontrollers) • Logic State Analysers • Platform dependent debugging tools • Lint • Purify • Purecov • Teaser • DDTS

  17. Reported components • Visited companies do not deploy a component based software development methodology • Current components • Real-time kernel • TCP/IP stack • STL/ATL libraries • GUI-library • JVM • File systems • (design patterns) • Exception: IOCM ORB

  18. Reported problems with reuse • Technical • Hardware varies all the time • Sometimes unexpected resource allocations by components • Management • The output of a project is a system, not a component • The use of components requires additional resources • Not enough interaction between development teams

  19. Reported problem areas • Integration of third party software • Changing requirements (also: research during development) • Deadlines • Generation and maintenance of documentation • Debugging: memory leaks, ISRs • Serviceability

  20. Reported problem areas • Lack of multiplatform IDE, tools in general • Effort estimation techniques (metrics) • Performance estimation techniques • Hardware problems • Lack of qualified personnel, multi-site development • Growing complexity of software • Low software productivity (2 kloc/py)

  21. Reported problem areas • Testing is time-consuming (white, black box, glass box) • Versioning of the design • Need for rapid prototyping • User interface specification is difficult

  22. Conclusions • Spectrum of embedded systems is huge • The constraints can differ significantly • Great variety in methodologies and tools

  23. Conclusions • Software complexity in embedded systems is rapidly growing; this trend will continue in the future (networking) • Each company is using more than one design methodology, and is experimenting with tools • There is no “typical embedded system”; there won’t be a “unified methodology” for all embedded systems

More Related