Embedded Systems and Software
Engineering
Gary Hafen
USC CSSE Executive Workshop
March 10, 2010
Situation
• Software is providing an increasing
percentage of functionality in our
embedded systems
–
–
–
–
–
–
Space Craft
Aircraft
Ships
Automobiles
Cell Phones
Appliances
Issue
• Software is an abstract, logic based product that
invites latent errors to persist
– The errors may be nearly invisible to inspection or detection
• Embedded System Software is the most glaring
example of this attribute
– Lack of visible observation of software interaction
– Intrusive test probes change the operational conditions
– Real-time, asynchronous dynamics make errors hard to
reproduce
This Issue must be Acknowledged and Dealt with
in the System and Software Architecture Design
Premise
• Real time embedded software has special challenges
• Difficulties stem from the combination of technically
challenging problems
– Solutions are founded in physical sciences
– Limited computing resources severely constrain
the solution space
– Highly complex verification environments
• These problems manifest themselves in a wide
variety of important implementation factors
ISO 15288 System Engineering V
ISO 12207 Software V
Life Cycle Processes Harmonized with 15288
Plan for
Qualification Test
Requirements Analysis
Plan for
Integration
Architectural Design
Plan for
Unit Test
Detailed Design
Construction
Change is Needed
• The V-model presupposes that a system can be
deterministically decomposed and integrated
• Complexity and network system interoperability make this
impossible
• System Functionality is 80-90% Software Enabled
• System Engineering approaches need to emulate current
Software Engineering approaches
– Model based design
– Agile practices
– Logical as well as physical analysis and definition
methods
– Data/Information focused (e.g. Object Oriented) as well
as control flow focused
Implementation Issues
•
•
•
•
Unclear organizational responsibilities
Requirements inadequacy
Execution resource constraints
Concurrent hardware development
– Leads to late discovery of hardware/software interface
functionality and incompatibility
– Results in unplanned software growth
• Software engineer domain knowledge inadequacy
• Verification of embedded systems
– Requires complex test labs with hardware in the loop,
environment simulators, etc.
Unclear Organizational
Responsibilities
• System Engineering allocates functionality to an
embedded computer system
– With or without software or hardware domain expertise
• Management awareness is problematic
– Software is not always on the radar until too late
– Incomplete understanding of the priorities and risks with
respect to software
• The software team is often fragmented on a program
– Inadequate communication between groups
– Role of the System Engineering Integration
Team (SEIT) with respect to software
Requirements Inadequacy
• Late maturity of the Operational Concept
– User/operator does not get a feel for how the system really
works until it’s done
– Seeing actual operational scenarios results in discovery of
new software requirements
• Complex control laws, complex hardware interfaces,
high accuracy requirements
• Parallel, asynchronous processing creates nondeterministic behavior
• Autonomy requires complex second order
requirements that will be derived late
Execution Resource Constraints
• Computing resources for embedded systems are
constrained by physical size
• Environmental Qualification testing requirements for
hardware prevent hardware upgrades
• Systems Engineers must be extraordinarily conscious
of the resources consumed by the implementations
they choose
• Implementations are driven more by
performance than by clarity of the design
or maintenance concerns
Concurrent Hardware Development
• Late discovery of hardware/software interface
incompatibility
– results in unplanned software growth and workarounds
• Constraints associated with modifying qualified
hardware results in a “we’ll fix it in the software”
decision
• These discoveries are made when the resources
to fix the problem are least available
Domain Knowledge Inadequacy
• Software integrates our embedded systems
• Software engineers play a key role in the integration
• Effective embedded software engineers must have
domain knowledge
• An embedded software engineer must understand the
physics and mathematics of our complex systems.
This domain knowledge of software engineers is critical
to the success of our complex programs
Complex Verification Requirements
• Driven by the potential for catastrophic failure
• Must be performed on hardware that is as identical to
the operational hardware as possible
– In the actual operational environment or one that is simulated and
certified
• Non-deterministic behavior is difficult to exhaustively
verify
• Test Environment must have
dynamic tools to provide
comprehensive stimulation and
observation of embedded systems
• Lab must be configuration managed
to assure valid, repeatable results
Summary
• Embedded Systems Engineers must have
Software Engineering understanding and skill
– 80% of the capability that they are designing
for are software enabled
• Embedded Software Engineers must have
Domain Systems Engineering understanding and
skill
– Success of the software product is dependent
on their knowledge of the physical
environment that it interacts with
The Systems Engineer must be a Software Engineer
The Software Engineer must be a Systems Engineer