04/11/23 1

Embedded System Development Processes

W. T. TsaiDepartment of Computer Science and Engineering

Arizona State UniversityTempe, AZ 85255

wtsai@asu.edu

04/11/23 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 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)

04/11/23 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

04/11/23 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)

04/11/23 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

04/11/23 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

04/11/23 7

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

04/11/23 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.

04/11/23 9

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.

04/11/23 10

The Ideal Scenario: Dream On

Release Time

Time

Requirement Change Rate

04/11/23 11

Actual Scenario: Reality

Release Time

Time

Requirement Change Rate

04/11/23 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.

04/11/23 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.

04/11/23 14

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.

04/11/23 15

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 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.nsf/Publish/570

04/11/23 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.

04/11/23 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

04/11/23 18

Recent Trends

• Rapid development and V&V– Rapid system design– Rapid code development– Rapid real-time V&V