LynuxWorks Webinar on REUSABLE SOFTWARE COMPONENTS June 13, 2007

Transcription

1 LynuxWorks Webinar on REUSABLE SOFTWARE COMPONENTS June 13, 2007

2 Agenda Introductions & Housekeeping Historical overview of Software in the Airborne Environment Software Certification standard: RTCA/DO- 178B Reusable Software Components: Advisory Circular LynuxWorks LynxOS-178 Operating System Benefits

3 Introductions Presenter: Joe Wlad,, Director of Product Management at LynuxWorks Federal Aviation Administration Designated Engineering Representative Post Q&A at anytime Answers at the end Presentation available for download later Instructions to be provided

4 Historical Review of Software use in aircraft

5 First Generation Commercial Aircraft Characteristics Few Digital Systems outside of Inertial Navigation Systems Minimal integration Human interface with every computer or its input/output Analog computers that communicate using discretes and signals Autopilot System: 20 separate computers to handle pitch, roll, yaw, trim, throttles and landing!

6 The B747 Flight Deck 1960 s technology > 1000 switches Dozens of unique indicators akin to a boiler room 3-person crew to control, navigate and manage flight Operating and maintenance costs are very high

7 Software Use on Aircraft Software use on aircraft is now pervasive Lowers costs, Reliability Improved Crew workload reduced Modern Flight Decks are becoming totally automated Millions of lines of code now running inside a modern airliner FAA software certification to DO-178

8 Typical Federated Architecture Boeing 757 Flight Management System Typical FMS interacts with subsystems on an aircraft Advantage: Failures can usually be localized to a single system or computer Disadvantages: Integration also controlled by vendor Separate LRU s for each system using different processors FCC ADC CDU GPS ILS/MLS DME/ADF IDS Flight Management Computer OMC MCP VOR EEC FDR FQIS IRS CLOCK

9 Integrated Modular Avionics (IMA) Modern processors can support more than a single application Memory Management Units assist with providing application separation along with a partitioned operating system IMA allows for consolidation and portability of applications thereby reducing program lifecycle costs

10 Reduce the number of LRU s IMA Advantages Lower maintenance costs Reduce weight and size Improve portability Reduce upgrade costs Flexibility and fault tolerance Improved dispatch reliability Boeing claims that IMA design can save 1000 pounds of weight on the 787

11 RTCA/DO-178B Background

12 DO-178B Background DO-178B: Software Considerations in Airborne Systems and Equipment Certification, circa 1992 Evolved from DO-178A, circa 1985 DO-178B is a guidance document only and focuses on software processes and objectives to comply with these processes Developed by RTCA, Inc (a not for profit company) and its members to ensure that software meets airworthiness requirements Called out in many certification requirements documents as the recommended method to obtain approval of airborne software Design Approvals through FAA Technical Standard Orders and Supplemental Type Certificates Many other standards exists: SEI-CMM, DEF STAN 00-55, ISO, DOD-2167, IEC 61508

13 DO-178B Background DO-178B is not prescriptive Vendors are allowed to decide how objectives are satisfied DO-178B objectives vary, depending upon how software failures can affect system safety Consider two aircraft examples 1) Software controlling the coffeemakers in the aft galley fails Outcome: passenger safety not compromised 2) Software controlling the aircraft during an automatic landing in zero visibility conditions fails Outcome: Possibly catastrophic and lives lost Obviously these two software applications need not be developed to the same rigor

14 DO-178B Background For this reason, DO-178B defines five software levels Each level is defined by the failure condition that can result from anomalous software behavior Failure Condition Catastrophic Hazardous/Severe - Major Major Minor No Effect Software Level Level A Level B Level C Level D Level E

15 DO-178B Background Once a system safety assessment is done and the safety impact of software on is known then the level is defined Level A has 66 objectives Level B 65 objectives Level C 57 objectives Level D 28 objectives Level E: None

16 DO-178B Processes Use of standard processes and compliance with pre-determined objectives help avoid the common pitfalls of software development DO-178B defines the following processes (as well as objectives for each): Planning Process Development Process Requirements Process Design Process Coding and Integration Process Testing and Verification Process Configuration Management Process Quality Assurance Process

17 DO-178B Software Certification FAA Software Certification standard = RTCA/DO-178B For every line of Code there will be 5-10 lines of tests For every 2 lines of code there will be one signature on some review form One requirement for every lines of code Verification of execution coverage for all decisions and conditions that impact decisions Address compiler added functions too

18 Historical Certification Process Operating System cannot be certified unless System is installed, tested and certified System Target System User Code C or Ada Code Operating System LynxOS-178

19 New FAA Policy: Reusable Software Components Advisory Circular AC , Dec 2004 Allows for certification of components such as math libraries, operating systems and communication protocols See faa.gov/regulations_policies/ S/W accepted by the FAA as meeting DO- 178B objectives across hardware platforms Allows for portability of certification effort to other products without re-verification of the software component

20 Our Customer Needs Reduce cost, risk and time to market when deploying safety critical devices Cost of change is an area that heretofore has been ignored in the embedded market Consider that in the 1980 s a one-line change to the OFP on the Space Shuttle cost nearly $1M Today, cost of software changes for safety critical products is still too high

21 RSC Certification Process FAA Accepted OS is deployed without requiring recertification System Target System FAA ACCEPTED Operating System Component User Code LynxOS-178

22 LynxOS-178 Reusable Software Components Display System PPC 750 Target Hardware User Code Flight Management System PPC 7447 Target Hardware User Code Flight Control System PPC 440 Target Hardware User Code LynxOS-178B RSC Acceptance Letter FAA acceptance of LynxOS-178 is grandfathered across platforms, reducing cost of change

23 RSC Development Cycle Supports Multiple Architectures Develop, Debug, Tune Application 1 Application 2 PPC 440 CSP Unadulterated LynxOS-178 PPC 603 BSP DO-178B Verification, Code coverage Application1 LynxOS Application 2 LynxOS-178 Certified applications using LynxOS-178

24 How much credit applies? Level A calls out 66 explicit objectives Because of the way RTCA/DO-178 is structured, one can not take full credit for all DO-178B objectives with a RSC Remaining objectives are partially satisfied but required input from integrator to be complete E.g., S/W load control, traceability to System level requirements, compatibility with target computer, certification liaison Requires that a RSC guidance package provide clear instructions on how to use the RSC, integrate it and retain DO-178B credit

25 What makes a good RSC? Ideally, the software should be hardware independent Changes to hardware should not result in modifications Network stacks and services, file systems and operating system services Very challenging to make a Time/Space Partitioned operating system achieve FAA acceptance as a reusable software component Requires detailed testing and analysis of time, space and resource partitioning to support fault containment of multiple applications at different levels of DO-178B

26 Reusable Software Component - Credit RSC is initially approved through a TSO or STC/TC process Mechanism is through a PSAC and AC Results in FAA RSC Acceptance Letter RSC Developer provides RSC Data Package to RSC Integrator, includes: Acceptance Letter & Data Sheet RSC Functions Limitations & Assumptions Partitioning and RSC Analysis data Reqs,, Design, SCI, SAS Other RSC Integrators use unadulterated binary files to build and certify its application

27 RSC Compliance Matrix example 178 B Obj # Obj Description Resp. Org. RSC Credit Assumption Original Integrator Assumptio n Follow-o integrator Means of Complianc e for the Objective Activities Remaining For Integrator Applicant 1-1 Software development and integral processes activities are defined. 4.1 a, 4.3 LW Full None None LynxOS- 178 (RSC) PSAC [7] LynxOS- 178 (RSC) SDP [8] LynxOS- 178 (RSC) SCMP [9] LynxOS- 178 (RSC) SVP [10] LynxOS- 178 (RSC) SQAP [11] Follow on Integrator: the integrator s PSAC will need to obtain approval to use AC and reference the LynxOS- 178 (RSC) FAA RSC approval letter and demonstrate identicality of configuratio n.

28 LynxOS-178 RSC Data Package Example RSC Documents RSC BUILD PROCEDURE RSC TIMING MARGIN ANALYSIS RSC PARTITIONING & RSC INTERFACE ANALYSIS RSC S/W ACCOMPLISHMENT SUMMARY (SAS) RSC S/W CONFIGURATION INDEX RSC VERIFICATION ENVIRONMENT CONFIGURATION INDEX RSC DATASHEET

29 LynuxWorks RSC Data Sheet Data Sheet gives integrator a top-level view of LynxOS certification pedigree Covers functions of the time/space/resource partitioned OS Gives overview of design and how time/space and resource partitioning are maintained Provides assumptions and required activities of integrator to retain reuse credit Summary of Safety Issues and Limitations

30 RSC Value to Integrators FAA acceptance of RSC means reduced certification risk for integrators Integrators no longer have to wait for the OS supplier to complete its certification work before submitting certification artifacts RSC documentation is structured around providing guidance on RSC integration as well as demonstrating RTCA/DO-178B credit Thousands of labor hours are saved by using accepted certification techniques

31 RSC vs standard 178 Artifacts Source Code DO-178 Artifacts PSAC, SQAP, SCMP, SDP SRS, SDS, SW Coding Stds SVP Design reviews Code reviews Tool qualification docs SW Vulnerability Analysis Partitioning Documents? Reqmts Design SAS SCI Test Procedures Test Results Coverage Analysis Build Procedure RSC Artifacts T/S/R Partitioning Analyses Test Proxies RSC Interface Analysis Timing Margin Analysis Device Driver Interface Standard CSP/BSP API HM Requirements RSC Letter of approval DOORS traceability KEY DIFFERENCE: RSC ARTIFACTS CONTAIN GUIDANCE TO HELP CUSTOMER ACHIEVE CERTIFICATION OF THEIR APPLICATION

32 RSC Value Proposition Some vendors provide a full set of artifacts that include CM, QA, Reviews, etc. >10000 files on a CD ROM Information overload How does customer digest this? Other vendors may take customers hardware in-house, runs the tests and certifies the BSP and OS together We preach that the RSC is better. All you need is the letter and our RSC guidance No need for source code or full 178 artifacts Saves you time, money and reduces risk

33 The RSC vs. Plain DO-178 Artifacts Strict RTCA/DO-178B artifacts DO-178B Artifacts Mountain Confused Customer LYNUXWORKS RSC RSC Interface Analysis, Device Driver Interface standard, CSP/BSP API RSC Artifacts Guidance Application FAA Delays/Denial Customer Project LynxOS-178 Successful Customer Project FAA Approval

34 RSC Value: Reduced Cost and Risk Operating System certification effort is reusable and portable RSC Artifacts provide Guidance on Integration and Certification; saves months in labor over conventional mountain of Certification Evidence Certification packages Certification results are re-usable and portable to minimize cost of change Reduce Risk: Auditors do not review what has already been approved RSC has been proven to meet DO-178B Level A Saves months of certification review

35 What the LynxOS-178 RSC covers Kernel Time/Space Partitioning, Resource Partitioning (I/O, shared resources), Task, Interrupt, Device and File Management System Services POSIX , 1.b,.1c Scheduling, MQ, Pipes, Socket, signals, SEMS, Clocks/Timers, Shared Memory Family of PPC including 74xx, 750, 603, 4xx, and 970 Results in portable DO-178B approval on more than one processor without added engineering effort

36 Key Takeaways Standard Guidance exists on how to retain certification credit for software components Reusable Software Component acceptance results in: Reduced Cost and time to market Portability of Certification Artifacts Increased Productivity LynuxWorks is the first COTS RTOS vendor to deliver a reusable software component (RSC) package

37 Questions

38 Thank-you