d1.2: state of the art in software engineering for embedded systems in flanders
Post on 09-Jan-2016
23 Views
Preview:
DESCRIPTION
TRANSCRIPT
21 April 2023
S
E
E
S
C
O
A STWW - Programma
D1.2: State of the Art in Software Engineering for Embedded Systems in Flanders
Prof. Koen De Bosschere
S
E
E
S
C
O
A
Outline
Visit summary
Reported problem areas
Conclusion
S
E
E
S
C
O
A
Visits
Barco
Agfa-Gevaert
Philips
Imec
Siemens-Atea
Alcatel
S
E
E
S
C
O
A
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
S
E
E
S
C
O
A
Hard real-time applications
Soft Real-time appsNot Real-time apps
Hard Real-time apps• power down• mechanical• incoming signals• protocols
33 %
Hard real-time code
S
E
E
S
C
O
A
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
S
E
E
S
C
O
A
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
S
E
E
S
C
O
A
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
S
E
E
S
C
O
A
Waterfall V-model HPM (Hatley Pirbhay and Meilir Page-Jones) SASD PEPP Rational Unified Process Octopus ROOM
CMM
Development process
S
E
E
S
C
O
A
Design tools
Rational Rose
Rose Real-Time
Together/J
Word/Excel/Interleaf
Flowcharter/Visio/StP
Intranet
S
E
E
S
C
O
A
Models, Diagrams
State charts
Message sequence charts
Block diagrams
Use cases
Scenarios
Data flow diagrams
Class diagrams
Collaboration diagrams
Text
S
E
E
S
C
O
A
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
S
E
E
S
C
O
A
Programming languages
C++ (large projects)
C
Assembler (small projects)
Java
Ada
Visual Basic
VHDL
S
E
E
S
C
O
A
Development Environments CodeWright DevStudio Visual Basic Visual Studio JBuilder, Visual J++ Apex CAD-UL Emacs/Textedit/vi DDTS Visual Age (Envy)
S
E
E
S
C
O
A
Versioning
ClearCase
Continuus
PVCS
CVS
WebCVS
S
E
E
S
C
O
A
Debugging/testing
ICE (microcontrollers)
Logic State Analysers
Platform dependent debugging tools
Lint
Purify
Purecov
Teaser
DDTS
S
E
E
S
C
O
A
Reported components
Visited companies do not deploy a component based software development methodology
Current componentsReal-time kernelTCP/IP stackSTL/ATL librariesGUI-libraryJVMFile systems(design patterns)
Exception: IOCM ORB
S
E
E
S
C
O
A
Reported problems with reuse
Technical
Hardware varies all the timeSometimes 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
S
E
E
S
C
O
A
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
S
E
E
S
C
O
A
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)
S
E
E
S
C
O
A
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
S
E
E
S
C
O
A
Conclusions
Spectrum of embedded systems is huge
The constraints can differ significantly
Great variety in methodologies and tools
S
E
E
S
C
O
A
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
top related