S E E S C D 1. 2: State of the Art in Software Engineering for Embedded Systems in Flanders Prof. Koen De Bosschere O A STWW - Programma *
Outline S E E S C O A u. Visit summary u. Reported problem areas u. Conclusion
Visits S u. Barco E u. Agfa-Gevaert E u. Philips S u. Imec C u. Siemens-Atea O u. Alcatel A
Application domains S E E S C O A u. Modems u. Network devices u. Telephone switches u. Digital video + audio u. Remote controls u. TVs; set-top boxes u. High-end printers; printer servers u. Display systems u. GPS u. Hearing devices u. Battery management systems
Hard real-time applications S E E Hard realtime code 33 % S C O A Soft Real-time apps Not Real-time apps Hard Real-time apps • power down • mechanical • incoming signals • protocols
Hardware S E E u. One 4 -bit microcontroller vs. network of high-end 32 -bit processors S u 16 bytes vs. 64 MB of RAM (500 kstats) C u. Hard disks O u. Battery-powered A u. Custom or off-the-shelf
Development cost S E u Teams: 1 -20 people E u Development effort: 3 -1318 py S u Time to market: 0. 5 -5 years C u 10% vs. 70% software effort O u Manufacturing cost vs. development cost A
Development process S E E S u. Each company has more than one type of software development process u. The bigger the projects/company, the better formalized the software development process and methodology C O A u. Move towards: spiral or incremental model
Development process S E E u. Waterfall u. V-model u. HPM (Hatley Pirbhay and Meilir Page-Jones) u. SASD S u. PEPP C u. Rational Unified Process O u. Octopus u. ROOM A u. CMM
Design tools S u. Rational Rose E u. Rose Real-Time E u. Together/J S C u. Word/Excel/Interleaf O u. Flowcharter/Visio/St. P A u. Intranet
Models, Diagrams S u. State charts E u. Message sequence charts E S u. Block diagrams u. Use cases u. Scenarios C u. Data flow diagrams O u. Class diagrams A u. Collaboration diagrams u. Text
Reported problems with design tools S E E S C O A u. Current design tools are too complex and offer too little, they are not worth the effort for small to medium projects u. Real-time constraints cannot be tracked
Programming languages S u. C++ (large projects) E u. C E u. Assembler (small projects) S u. Java C u. Ada O u. Visual Basic A u. VHDL
Development Environments S E E u. Code. Wright u. Dev. Studio u. Visual Basic u. Visual Studio S u. JBuilder, Visual J++ C u. Apex O A u. CAD-UL u. Emacs/Textedit/vi u. DDTS u. Visual Age (Envy)
Versioning S u. Clear. Case E u. Continuus E u. PVCS S u. CVS C u. Web. CVS O A
Debugging/testing S u. ICE (microcontrollers) E u. Logic State Analysers E u. Platform dependent debugging tools S u. Lint C u. Purify O u. Purecov A u. Teaser u. DDTS
Reported components S E E S C O A u. Visited companies do not deploy a component based software development methodology u. Current components w. Real-time kernel w. TCP/IP stack w. STL/ATL libraries w. GUI-library w. JVM w. File systems w(design patterns) u. Exception: IOCM ORB
Reported problems with reuse S E E S C O A u. Technical w. Hardware varies all the time w. Sometimes unexpected resource allocations by components u. Management w. The output of a project is a system, not a component w. The use of components requires additional resources w. Not enough interaction between development teams
Reported problem areas S E u. Integration of third party software E u. Changing requirements (also: research during development) S u. Deadlines C u. Generation and maintenance of documentation O A u. Debugging: memory leaks, ISRs u. Serviceability
Reported problem areas S u. Lack of multiplatform IDE, tools in general E u. Effort estimation techniques (metrics) E u. Performance estimation techniques S u. Hardware problems C u. Lack of qualified personnel, multi-site development O A u. Growing complexity of software u. Low software productivity (2 kloc/py)
Reported problem areas S E u. Testing is time-consuming (white, black box, glass box) E u. Versioning of the design S u. Need for rapid prototyping C u. User interface specification is difficult O A
Conclusions S E u. Spectrum of embedded systems is huge E u. The constraints can differ significantly S u. Great variety in methodologies and tools C O A
Conclusions S E E S C O A u. Software complexity in embedded systems is rapidly growing; this trend will continue in the future (networking) u. Each company is using more than one design methodology, and is experimenting with tools u. There is no “typical embedded system”; there won’t be a “unified methodology” for all embedded systems