Past, Present and Future of Safety-Critical Real-time Embedded Software Development

1. Past, Present and Future of Safety-Critical Real-time Embedded SoftwareDevelopment Capital Science 2008 Presented by: Haik Biglari Fairchild Control Corporation March 29, 2008

2. Outline Introduction Definitions - Embedded System - Critical Applications - Safety- Critical Embedded System - Achieving the objective Past - The Earliest Usage of Embedded Systems - The Need For Certification Present - Examples of Present day Safety-Critical Systems - Software Development Life Cycle - Capability Maturity Levels - Current System Development Issues - Current Software Development Issues Future - Domain Specific Languages and Tools - Model Based Design Conclusion

3. Introduction Safety-Critical systems are those systems whose failure could result in loss of life, cause significant property damage or cause damage to the environment. These complex systems tend to have sufficient kinetic or potential energy which can become uncontrollable and thus pose a hazardous condition. Therefore, these systems must be designed in such a way as to guarantee system stability during all of the system operational modes. Furthermore, when a fatal fault occurs, the system safely shuts down.

4. Definition of Real-time Embedded System Real-time Embedded System in its simplest form is depicted below: Micro-Controller(s) System Under Control

5. Definition of Critical Applications • Computer based systems used in avionics, chemical process and nuclear power plants. • A failure in the system endangers human lives directly or through environment pollution and Influence is on a large economic scale.

6. Definition • Safety: Safety is a property of a system that it will not endanger human life or the environment. • Safety-Critical System: A system that is intended to achieve, on its own, the necessary level of safety integrity for the implementation of the required safety functions.

7. Developing Safety-Critical Systems • To achieve the safety objective: - well-defined system safety requirements (hazards & risks analyzed) - quality management (auditing process) - design / system architecture (reliability analysis) - defined design/manufacture processes - certification and approval processes - known behaviour of the system in all conditions

8. Software Development • To achieve the safety objective: - Safety requirements which address all system specifications - Quality Control Processes for Validation & Verification - Software Design Description - Certification and approval (according to a guideline) - Extensive software development testing (functional and code coverage) - Extensive system integration testing (control laws, software and hardware) - Complete set of documentation which supports the software development life cycle.

9. Risk Analysis • Severity : - Catastrophic – multiple deaths >10 - Critical – a death or severe injuries - Marginal – a severe injury - Insignificant – a minor injury • Frequency Categories: Frequent 0,1 events/year Probable 0,01 Occasional 0,001 Remote 0,0001 Improbable 0,00001 Incredible 0,000001

10. Risk acceptability Tolerable Hazard Rate (THR) – A hazard rate which guarantees that the resulting risk does not exceed a target individual risk. SIL 4 = 10-9 < THR < 10-8 SIL 3 = 10-8 < THR < 10-7 SIL 2 = 10-7 < THR < 10-6 SIL 1 = 10-6 < THR < 10-5 SIL = Safety Integrity Level

11. Safety-Critical Systems - Past According to Wikipedia – One of the first recognizably modern embedded system was the Apollo Guidance Computer, developed by Charles Stark Draper at the MIT Instrumentation Laboratory. At the project's inception, the Apollo guidance computer was considered the riskiest item in the Apollo project as it employed the then newly developed monolithic integrated circuits to reduce the size and weight. An early mass-produced embedded system was the Autonetics D-17 guidance computer for the Minuteman missile, released in 1961.

12. The Need For Certification As the Embedded systems began to be used for the consumer market, several certification standards for different industries were developed: IEC 880 - Nuclear Safety - 1986 IEC 601 - Medical Safety – 1996 MISRA - Motor Industry Safety – UK 1994 IEC 61508 - Programmable Electronic Safety – Geneva 1998 RTCA DO-178B – Airborne Systems Safety - 1992

13. Safety-Critical Systems - Present • Transportation systems from flight to automobiles • New airplanes contain advanced avionics such as inertial guidance systems and GPS receivers that also have considerable safety requirements. • Various electric motors: Brushless DC motors, induction motors and DC motors are using electric/electronic motor controllers. • Automobiles, electric vehicles. and hybrid vehicles are increasingly using embedded systems to maximize efficiency and reduce pollution. • Other automotive safety systems such as anti-lock braking system, Electronic Stability Control, and automatic four-wheel drive. • Medical equipment is continuing to advance with more embedded systems • Vital signs monitoring • Electronic stethoscopes for amplifying sounds • Various medical imaging for non-invasive internal inspections.

14. SW Development Life Cycle Models • Waterfall model • Spiral model • Model driven development • User experience • Top-down and bottom-up design • Chaos model • Evolutionary prototyping • Prototyping • ICONIX Process • Unified Process • V-model • Extreme Programming • Software Development Rhythms • Incremental funding methodology

15. V - Lifecycle model * K N O W L E D G E B A S E Systems Level Test Systems Analysis Systems Engineering Systems Design Systems Integration Testing Software Requirement Analysis High Level RBT Software Systems Engineering Software PDR Integration Testing * Configuration controlled knowledge which increases in understanding until system is completed. - Requirements Management. - Requirements Traceability - Model Data/Parameters - Test Definition/Vectors Software CDR Low Level RBT Software Engineering Software Unit Test Software Implementation (Coding)

16. Requirements • Requirements are stakeholder`s (customer) demands – what they want the system to do and not the how! • Safety requirements are defining what the system must do and must not do in order to ensure safety. • Specified Safety requirements and Derived Safety Requirements must be identified early in the Software Development Life Cycle to reduce development cost.

17. RequirementEngineeringRight Requirements • Ways to refine Requirements - complete – linking to hazards (possible dangerous events) - correct – testing & modelling - consistent – semi/formal language - unambiguous – text in real English

18. Requirement Engineering Tools: Doors (Telelogic) • Data base and configuration management • History, traceability and linking • Compatibility with Modelling tools such as MATLAB REQTIFY (Chiastic) • Graphical • Traceability and linking • Compatibility with Modelling tools such as MATLAB

19. Software Design Description • The Supplier System Specifications gives rise to Software Requirements (R). The Requirements combined with Domain Knowledge gives rise to System Design Description (SDD) R + D => SDD Where: R = Requirements D = Domain Knowledge SDD = Software Design Description

20. Software Implementation(Coding) • Currently there are two ways to implement • design. 1) Manual Coding 2) Automatic Code Generation • Most Automatic Code Generators support embedding the manually developed code

21. High Level Testing • High level requirements are captured in the Software Requirement Specification. • Currently Requirement Based Testing (RBT) is used to test the High level functionality. • The most laborious and the most documentation intensive phase is testing. • Software Testing is an NP-Complete problem, that means its complexity is equivalent to the Travelling Salesman Problem.

22. Low Level Testing • Low level requirements are captured in the Software Design Description (SDD). • For certification purpose, the implemented code must be traceable to SDD and the design specs must trace to the code. • For low level testing, one must prove that the implemented code is capable of performing what is in SDD • If RBT is performed with Structural coverage then the Low level testing is satisfied. • Structural coverage includes dynamic overage and static coverage. Currently, there are tools which automate this process.

23. Capability Assessment Software Engineering Institute has developed a method to assess the capability of organizations to develop SW. In this assessment there are five levels: Level 1 – Initial Level 2 – Repeatable Level 3 – Defined Level 4 – Managed Level 5 – Optimizing

24. Initial Level Organizations at this entry level carry out their work on an ad hoc basis. A handful of formal processes are defined properly while project management discipline is, at best, unclear. As such success and failures have little impact on future undertakings. Results therefore become unpredictable, processes are poorly controlled and the ultimate success depends on the dedicated effort of a few enterprising individuals instead of the entire organization as a whole.

25. Repeatable Level At this second level, organizations depend mainly on policies for managing a software project and measures to apply those policies are established. These measures help the organizations to repeat successfully the previously mastered tasks and avoid the repetition of failures. The major chunk of an organization's processes at this level stays institutionalized, through staff experience instead of detailed documentation procedures.

26. Defined Level The various engineering activities and the processes of management at this level is formally defined, documented and integrated. In the process of development and maintenance of software, the organization's staff follows this defined standard process. At this third level, newer methods and tools can be added, and it becomes easier to train new staff to adapt according to the requirement of the organization.

27. Managed Level • At this level, organizations stress the importance of quantitatively measuring the quality of the products delivered by each process. Detailed measures of the software process and product quality are collected and used to identify and correct issues with process performances. Organizations set quantitative goals for both software products as well as processes. • As part of the organization's measurement program, productivity and quality of all software process activities and its supporting activities are measured. As new sets of tools or processes are added, or adjustments are made to already existing processes, measurement data enables the organization to access the success of the adjustment as well as prevent the recurrence of defects.

28. Optimizing Level At level 5, focus is on the continuous process improvement. The organization proactively identifies strengths and weakness in process, with the aim of preventing the occurrence of defects. Here continuous improvement becomes institutionalized into the development process. Instead of merely correcting defects as they are found, the main aim at this highest level is to stall future defects and address the key to those defects by planning in advance.

29. Current Situation – Systems Issues • Failures become more and more distributed and often nation-wide (e.g. air traffic control and commercial systems like credit card denial of authorisation) • The source of failure is more rarely in hardware (physical faults), and more frequently in system design or end-user operation / interaction (system implementation in software). • The harm caused by failures is mostly economical, but sometimes health and safety concerns are also involved. • Failures can impact many different aspects of dependability (dependability = ability to deliver service that can justifiably be trusted).

30. Current Situation – Software Issues • There is a gap between software engineering and systems engineering which gives rise to the high cost of implementation. • Software projects are frequently too late, too expensive and unable to meet the customer’s needs. In the three-way trade-off between time, cost and functionality, software often fails to deliver any of the three. • The industry no longer believes that it is possible to deliver adequate software on time and within budget. • Most embedded projects fail (i.e. cancelled) because problems which should have been detected in the early stages (requirement phase) were detected too late (mostly in system integration and testing phase). • It is possible to go through the certification process and certify the system with defective software.

31. Current Situation – Remedies It is well known that if an organization adopts an established standard for SW development process and is assessed CMMI level of three or higher then the chances of successfully completing safety-critical Software projects increases substantially. It is equally important to bridge the gap between Software Engineering and System Engineering disciplines by leveraging Software System Engineering skills. Software System Engineering is a multi-disciplinary field.

32. Safety-Critical Systems - Future • Software System Engineering will be an established discipline where the curriculum will include multiple disciplines. This will help to narrow the gap between Software Engineering and Systems Engineering. • We will see greater use of Model-Based Design and use of simulation throughout all phases of development. This will minimize the software life cycle cost. • Tools will play a bigger role in the development of safety-critical systems. Specifically we will see greater usage of: • Domain Specific Languages • Automatic Code Generators • Test Vector Generators (High Level Testing • Structural Analysis Tools (Low Level Testing) • Configuration Management Tools • Certification Assisting Tools • For Airborne systems, DO-178C to be released in 2009 addresses some of the above items.

33. Conclusion Software development for Safety-Critical systems have evolved substantially from the earlier days. However, the crisis remains. One reason for this is that the embedded SW for these type of systems are becoming more complex due to allocation of more requirements to SW rather than HW. To cope with this situation, Safety-Critical System developers are streamlining their processes and procedure. In addition, attention is being paid to utilizing more automated tools. It is also becoming evident that the gap between Software Engineering and Systems Engineering can be substantially reduced by qualified Software Systems Engineers.