Embedded System
Development Processes
W. T. Tsai
Department of Computer Science and Engineering
Arizona State University
Tempe, AZ 85255
wtsai@asu.edu
6/28/2016
1
Different kinds of Embedded
Systems
• Mission-critical systems – most embedded systems are missioncritical systems because the failure to perform the mission can
cause significant damages. Examples of such systems may include
PDA, cellular phones and communication processors (5 9’s or 6 9’s).
• Safety-critical systems – most embedded systems are related to
safety, but only some are safety-critical, i.e., the failure of the system
can cause significant damage to the people involved. Examples of
such safety-critical systems include most medical devices such as
pacemakers.
• In other words, most embedded systems must be very reliable but
some requires additional safety issues (which require safety
analysis – a very complicated and expensive process)
6/28/2016
2
Traditional Development Process
• Waterfall model
• Requirement
– Talking to customers (patients, doctors and nurses), regulators
(FDA), marketing people (sales people and in-house doctors)
• Design
– Multiple-level of design including high-level design and low-level
design
• Coding including debugging
• Testing
– Inspection, walk through and code reading
– Multiple levels of testing including module or unit testing,
integration testing, system testing, acceptance testing and field
testing
6/28/2016
3
Embedded System Development
Processes
• Add one more process before the software development
process
– System requirement engineering
– System design (breaking into mechanical/electrical/software)
• Scenarios, timing constraints and physical constraints such as
memory, reliability, safety, processor speed, fault tolerance
–
–
–
–
–
Then follow by the software requirements
Software design
Software coding
Software testing
System integration testing (with mechanical/electrical/software
together)
6/28/2016
4
Operation/Environment Modeling for
Safety-Critical Applications
• We need a operational/environment profile for
the entire lifecycle of the embedded system
–
–
–
–
–
–
–
–
From requirements to design
From design to implementation
From implementation to manufacturing
From manufacturing to transportation
From transportation to installation
From installation to operation
From operation to removal
From removal to disposal
6/28/2016
5
Why?
• For safety-critical embedded systems, it is
necessary to address the complete lifecycle and
all the possible environment the devices that will
be used.
• Factors such as temperature (too hot or too cold,
and the rate of change), pressure, humidity,
operators must be taken into considerations. Is
the embedded system to be used in
– Air, marine, land, desert, space or controlled
environment
6/28/2016
6
Is V&V the best defense?
• No
• Design out is the best defense.
– Thing will NOT happen by design out.
– Thus intelligent design is the best design. Not V&V.
• The pacemaker’s lead is one such example. You
may find information about pacemaker lead at
http://www.bairdindustries.com/
• You may also find information about pacemaker
failures (including those caused by lead) at
http://www.emedicine.com/med/topic1704.htm
6/28/2016
7
Love/Hate of the Process
• This is the commonly practiced process for
safety-critical embedded systems and with
huge experience.
• This is also expensive.
• Some people are critical of this process
saying that the process does not take care
of the changes.
6/28/2016
8
Changes in Development
• Changes keep on coming.
• Poston’s law: The rate of changes
increases exponentially as the deadline
approaches.
• Ideally this rate should decrease rather
than increase as the deadline approaches.
• This phenomenon is very common and
has been observed in almost all
embedded system development.
6/28/2016
9
The Ideal Scenario: Dream On
Requirement
Change Rate
Time
Release Time
6/28/2016
10
Actual Scenario: Reality
Requirement
Change Rate
Time
Release Time
6/28/2016
11
Why?
• People actually do NOT practice requirementdriven system/software development, instead
they practice code-based requirement
engineering.
– Just before the deadline, they change the
requirement so that the requirement will be consistent
with the code, and thus they can turn in both
documents consistent. Thus immediately after the
deadline the rate of requirement changes dropped
significantly.
– This is also called faking waterfall model by D.
Parnas.
6/28/2016
12
Extreme Programming (XP)
• Every 6 weeks they produce a working prototype
to demonstrate.
• Involve users all the time to get constant
feedback.
• This is getting acceptance and popular as
everywhere I go people are telling me that they
use extreme programming even for safetycritical mission-critical embedded applications.
• There is significant time and peer pressure to
practice this. If you are junior, you may feel that
you are insulted during the process.
6/28/2016
13
Verification and Validation
• Should be performed at each stage, not
just at the end.
• Should be performed by independent
groups, this is called IV&V.
6/28/2016
14
Some Common V&V Techniques at the
Requirement Stage
• Completeness and consistency – ensures that
things are complete and consistent.
• Modeling and Simulation
– Both the system and environment (often by captureand-replay)
• Feedback with users/customers using the actual
system or just GUI aspect
• UCD – User centered design
– This can be an expensive exercise
– IBM UCD http://www-306.ibm.com/ibm/easy/eou_ext.nsf/Publish/570
6/28/2016
15
Requirement Modeling and
Simulation
• Develop use case or scenarios (use
scenarios are different from system
scenarios)
– A use scenario describe how a user will use
and operate the system
– The user may have his/her own process
according to a pre-defined process or not.
– It is necessary to validate these scenarios.
6/28/2016
16
Recent Trends
• More formal models used in the
development process
– More modeling and simulation
– More environment capture-and-replay or
simulation
– UML
• Better process such model-based
architecture
– At each step, formal models will be used
6/28/2016
17
Recent Trends
• Rapid development and V&V
– Rapid system design
– Rapid code development
– Rapid real-time V&V
6/28/2016
18