Safety & Security for the Connected World Reaping the benefits of Reusable Software Components The Significance of FAA Reusable Software Component Certification Mark Pitchford
The conflicting demands on development The project triangle shows how conflicting demands on a project have the scope to compromise quality Process standards are primarily concerned with Quality and Functionality But Time and Cost are also critical to the viability of the development team (c) Lynx Software Technologies, 2016 2
Software Reuse Software Reuse is an attractive weapon to use in balancing the demands of the project triangle But history shows us that what is proven in one system, may not be quite so appropriate in other circumstances There are examples both outside the realms of aerospace, and much closer to home (c) Lynx Software Technologies, 2016 3
Therac 25 Later model replaced hardware interlocks with software, exposing existing software flaws elsewhere Therac 25 involved in at least 6 accidents in which 100 times the correct dose was applied Standards such as IEC 62304 designed to ensure that quality is not compromised And yet cost and time pressures don t go away! (c) Lynx Software Technologies, 2016
Ariane 5 Software exception raised in the Inertial Reference System (SRI). Design was almost exactly the same as that used successfully on the Ariane 4, particularly in the case of the software. Standards such as DO-178 are designed to ensure that quality is not compromised And yet cost and time pressures don t go away! (c) Lynx Software Technologies, 2016
The overheads of compliance DO-178 focuses on establishing quality software design and development practices. It describes the standard to which the definition of and tracing to requirements, design phases, software development and testing needs to be applied. It describe the artifacts which need to be collated to provide evidence of each completed step (c) Lynx Software Technologies, 2016
The principle of risk Risk = Probability of hazardous event occurring x Severity of event (c) Lynx Software Technologies, 2016 7
EFFORT Design Assurance Level The greater the risk, the higher the DAL, the more compliance overhead increases (c) Lynx Software Technologies, 2016
Safety Objectives: DO-178C Design Assurance Level Objectives Objectives that must be verified with independence A - Catastrophic 71 30 B - Hazardous 69 18 C - Major 62 5 D - Minor 26 2 E No Effect - - (c) Lynx Software Technologies, 2016 9
Safety Objectives: DO-178C (c) Lynx Software Technologies, 2016 10
How much Testing is Enough? For example: Structural Coverage: Statement Coverage Branch Coverage MCDC (Modified Condition / Decision Coverage) Object Code Coverage DO-178B/C level A: 100% coverage of the Object Code (c) Lynx Software Technologies, 2016
The conundrum Therac 25 is an early example of the dangers of replacing hardware safety systems with inadequately proven software Ariane 5 shows the dangers of assuming that software proven in one circumstance is necessarily acceptable for another. But showing that a system is not flawed is both expensive and time consuming (c) Lynx Software Technologies, 2016
Reusable Software Components The FAA Advisory Circular AC 20-148 was written in recognition of this conundrum. Because of economic incentives and advances in software component technology, software developers want to develop an RSC that can be integrated into many systems target computers and environments with other system software applications, as determined by the integrator or applicant. In these cases, an RSC developer may partially satisfy the applicable RTCA/DO-178B objectives, while the integrator or applicant completes and shows the compliance for the integrated software package, systems aspects, and aircraft certification. Examples of potential RSCs include software libraries, operating systems, and communication protocols. (c) Lynx Software Technologies, 2016
Reusable Software Component What is an RSC? A previously developed software component intended for reuse in follow-on systems in DO-178 projects What is AC 20-148? Provides a means of compliance for RSC developers to take full/partial certification credit for RSC usage in follow-on programs. Motivation Advances in system design & software component technology Trend towards common/reusable components (eg, RTOS & middleware) Build/certify once, deploy often (c) Lynx Software Technologies, 2016 14
Re-use Certification Without RSC Reuse of COTS Product or In-House Solution Suppose it has been certified previously It is incorporated into your DO-178 system & submit for certification The lessons learned from such as Ariane 5 mean that the FAA looks for justification that the software component is appropriate for this application. Without an RSC, that requires all certification artifacts to be regenerated, resubmitted and re-reviewed Result: Time and Money are spent on certifying the same components over and over again. (c) Lynx Software Technologies, 2016 15
RSC RTOS: Modularity is key Application Software System Software Hardware Development Team 1 Development Team 2 Partition 0, Level A/B Partition 1, Level B Partition 2, Level D VCT Cinit POSIX User Mode Health Monitor Supervisor Mode TCP/IP/UDP LynxOS-178 Partitioning Kernel CPU Support Package Microprocessor ARINC POSIX Board Support Package FTP/TFTP ARINC POSIX Static Device Drivers POSIX ARP/ICMP/IGMP PCI DRM SNMPv3 SOCKETS SOCKETS SOCKETS SNTP Hardware Partition N, Level E Process1 PCI Controller Process2 Dynamic Device Drivers Optional Hardware multiple development groups mixed criticalities and increased integration modular architecture (c) Lynx Software Technologies, 2016 16
RSC RTOS: What is the difference? RSC Documentation doesn t stop with the provision of artifacts It includes guidelines to ensure that every interface to the RTOS is clearly specified (c) Lynx Software Technologies, 2016 17
RSC RTOS: What is the difference? This highly specified modularity means that the RTOS can be treated as a black box FAA is satisfied that the application code cannot then cause a problem as long as the instructions are adhered to Adherence to those instructions is then the only required evidence. (c) Lynx Software Technologies, 2016 18
RSC RTOS: What is the difference? In practical terms: The Certifying Authority will not re-examine the RSC component artifacts Modifications / Variations only require a Change Impact Analysis not a full recertification Protects against hardware and software modifications means greater re-use and repeatability (c) Lynx Software Technologies, 2016 19
RSC RTOS: What is the difference? For the Integrator The RSC artifacts provide educational value to the integrator Written guidance and tests help the integrator to assimilate their applications Yields significant savings in labour compared to conventional DO-178 artifacts. (c) Lynx Software Technologies, 2016 20
RSC RTOS: What is the difference? (c) Lynx Software Technologies, 2016 21
What if certification is not mandated? For some systems, it is enough to know that a system is capable of certification For any RSC, the FAA is satisfied that the component will ALWAYS behave as expected. For alternative non-rsc components, they require evidence of that. Whatever your application, that provides evidence of an additional level of quality (c) Lynx Software Technologies, 2016 22
Summary Standards such as DO-178 seek to apply best practice to avoid repeating the mistakes of the past Applying best practice requires time & money the project triangle For aviation projects, specifying an FAA designated RSC RTOS will reduce that effort with no compromise on quality Projects outside the scope of DO-178 certification can also benefit from that thoroughness of engineering, in terms of Presentation of evidence A sound engineering case (c) Lynx Software Technologies, 2016 23
Safety & Security for the Connected World For further information visit www.lynx.com or the Lynx stand