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 systemsSoftware 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 persistSoftware 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 attributeEmbedded 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 challengesReal time embedded software has special challenges Difficulties stem from the combination of technically challenging problemsDifficulties 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 factorsThese problems manifest themselves in a wide variety of important implementation factors

ISO System Engineering V

ISO Software V Life Cycle Processes Harmonized with Requirements Analysis Architectural Design Detailed Design Construction Integration Qualification Test Unit Test Plan for

Change is Needed The V-model presupposes that a system can be deterministically decomposed and integratedThe V-model presupposes that a system can be deterministically decomposed and integrated Complexity and network system interoperability make this impossibleComplexity and network system interoperability make this impossible System Functionality is 80-90% Software EnabledSystem Functionality is 80-90% Software Enabled System Engineering approaches need to emulate current Software Engineering approachesSystem 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 responsibilitiesUnclear organizational responsibilities Requirements inadequacyRequirements inadequacy Execution resource constraintsExecution resource constraints Concurrent hardware developmentConcurrent hardware development –Leads to late discovery of hardware/software interface functionality and incompatibility –Results in unplanned software growth Software engineer domain knowledge inadequacySoftware engineer domain knowledge inadequacy Verification of embedded systemsVerification 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 systemSystem Engineering allocates functionality to an embedded computer system –With or without software or hardware domain expertise Management awareness is problematicManagement 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 programThe 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 ConceptLate 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 requirementsComplex control laws, complex hardware interfaces, high accuracy requirements Parallel, asynchronous processing creates non- deterministic behaviorParallel, asynchronous processing creates non- deterministic behavior Autonomy requires complex second order requirements that will be derived lateAutonomy requires complex second order requirements that will be derived late

Execution Resource Constraints Computing resources for embedded systems are constrained by physical sizeComputing resources for embedded systems are constrained by physical size Environmental Qualification testing requirements for hardware prevent hardware upgradesEnvironmental Qualification testing requirements for hardware prevent hardware upgrades Systems Engineers must be extraordinarily conscious of the resources consumed by the implementations they chooseSystems 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 concernsImplementations are driven more by performance than by clarity of the design or maintenance concerns

Concurrent Hardware Development Late discovery of hardware/software interface incompatibilityLate 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” decisionConstraints 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 availableThese discoveries are made when the resources to fix the problem are least available

Domain Knowledge Inadequacy Software integrates our embedded systemsSoftware integrates our embedded systems Software engineers play a key role in the integrationSoftware engineers play a key role in the integration Effective embedded software engineers must have domain knowledgeEffective embedded software engineers must have domain knowledge An embedded software engineer must understand the physics and mathematics of our complex systems.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 failureDriven by the potential for catastrophic failure Must be performed on hardware that is as identical to the operational hardware as possibleMust 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 verifyNon-deterministic behavior is difficult to exhaustively verify Test Environment must have dynamic tools to provide comprehensive stimulation and observation of embedded systemsTest Environment must have dynamic tools to provide comprehensive stimulation and observation of embedded systems Lab must be configuration managed to assure valid, repeatable resultsLab must be configuration managed to assure valid, repeatable results

Summary Embedded Systems Engineers must have Software Engineering understanding and skillEmbedded 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 skillEmbedded 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