Embedded Systems and Software Engineering

1. Embedded Systems and Software Engineering Gary Hafen USC CSSE Executive Workshop March 10, 2010

2. Situation • Software is providing an increasing percentage of functionality in our embedded systems • Space Craft • Aircraft • Ships • Automobiles • Cell Phones • Appliances

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

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

5. ISO 15288 System Engineering V

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

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

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

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

10. 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 non-deterministic behavior • Autonomy requires complex second order requirements that will be derived late

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

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

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

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

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