Embedded System Development Processes

1
Embedded System Development Processes

• W. T. Tsai
• Department of Computer Science and Engineering
• Arizona State University
• Tempe, AZ 85255
• wtsai_at_asu.edu

2
Different kinds of Embedded Systems

• Mission-critical systems most embedded systems
  are mission-critical 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 9s or 6 9s).
• 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)

3
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

4
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)

5
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
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

7
Is VV 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
  VV.
• The pacemakers 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

8
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.

9
Changes in Development

• Changes keep on coming.
• Postons 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.

10
The Ideal Scenario Dream On
11
Actual Scenario Reality
12
Why?

• People actually do NOT practice
  requirement-driven 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.

13
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 safety-critical
  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.

14
Verification and Validation

• Should be performed at each stage, not just at
  the end.
• Should be performed by independent groups, this
  is called IVV.

15
Some Common VV 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
  capture-and-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.ns
  f/Publish/570

16
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.

17
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

18
Recent Trends

• Rapid development and VV
• Rapid system design
• Rapid code development
• Rapid real-time VV