IV&V on Orion’s ARINC 653 Flight Software Architecture Adelbert Lagoy and Todd A. Gauer Agenda • ARINC 653/DO 178 background • Advantages to a 653 FSW architecture – Development – V&V – Maintenance • Available COTS 653 systems • The impact of the selection of a ARINC 653 approach on baseline documentation – Alignment and misalignment of ARINC 653 to NASA documentation • IV&V impacts from application of 653 approach – Architecture verification impacts – Requirements validation impacts – FSW code verification impacts – Potential recertification impacts • Other impacts (adverse impacts) – “overhead” from 653 – Static partition definitions – COTS OS opacity • Orion IV&V Experience ARINC 653/DO 178 background ARINC 653 • The Aeronautical Radio, Incorporated (ARINC) specification ARINC 653 is a software time and space partitioning standard for Real Time Operating Systems (RTOSs). • The ARINC 653 standard supports Integrated Modular Avionics (IMA) architecture allowing appropriate integration of avionics software of differing levels within a single hardware device. • ARINC 653 provides a level of fault protected operation. – Faults within a partition should not stop other partitions from executing. • Metaphor – ARINC 653 compliant system’s partitions are like “virtual flight computers” within the flight computer. Metaphor – ARINC 653 Conventional Monolithic System ARINC 653 System with 4 Partitions Memory Memory Time Time • ARINC 653 splits the available processor time and space into partitions (partitions do not need to be the same size). • When we talk “partition” in this discussion you can substitute “virtual flight computer” if that is helpful. ARINC 653/DO 178 background ARINC 653 • Each partition is assured of its allocated processing time and memory – Lockup, freeze, endless loop, overrun, etc within one partition will not prevent another partition from operating. – “Data starvation” of running partitions from faulted partitions ceasing to deliver necessary data is possible. • ARINC partitioning allows: – Safer mixing of multiple software criticality levels in a single flight computer. – Highly structured interface controls – Assured access to processor time and memory by each partition. Advantages to an ARINC 653 FSW architecture • Development – Formalized partitions should ease development of highly complex systems – Abstracted from HW, should support increased processor portability – COTS OS SW presents reduced cost/schedule risk • V&V – Verification of Partitions should be less complex as greater verification credit can be taken from unit level testing (less integrated testing should needed) – Less regression testing for bug fixes if properly architected • Maintenance – Less regression testing for bug fixes NASA and ARINC • NPR 7150.2A does not incorporate ARINC 653 partition thinking into its practices. – “For a given system or subsystem, software is expected to be uniquely defined within a single class.” DO 178 background • DO 178B Software Considerations in Airborne Systems and Equipment Certification from RTCA • DO 178B processes are an accepted path to FAA certification • DO-178 Software levels set by HA results – Software Levels establish process objectives – Similar to NPR 7150.2 Classes Failure RTCA Hazard Software Process Condition Analysis Level Objectives DO-178 Category Mission / Software Applicable NASA NPR 7150.2 Application Class SWEs Type Comparison of DO 178 and NPR 7150.2A Class Class Descriptions SWEs A Human Rated Space Software Systems - needed to perform a primary mission objective of 132 human space flight and directly interacts with human space flight systems B Non-Human Space Rated Software Systems or Large Scale Aeronautics Vehicles – software must 132 perform reliably to accomplish primary mission objectives, or major function(s) C Mission Support Software or Aeronautic Vehicles, or Major Engineering/Research Facility 118 Software - software necessary for the science return from a (non-primary) instrument D Basic Science/Engineering Design and Research and Technology Software Ground software that 74 performs secondary science data analysis, E Small Light Weight Design Concept and Research and Technology Software Software developed 34 to explore a design concept/hypothesis, not used to make decisions for a Class A, B, or C system Level Software Level Objectives Objectives with Independence A Software whose anomalous behavior could cause/contribute to a 66 25 catastrophic failure condition for the aircraft B Software whose anomalous behavior could cause/contribute to a 65 14 hazardous/severe-major failure condition for the aircraft C Software whose anomalous behavior could cause/contribute to a 57 2 major failure condition for the aircraft D Software whose anomalous behavior could cause/contribute to a 28 2 minor failure condition for the aircraft E No Impact to safety, aircraft operation or crew workload 0 0 ARINC 653/DO 178 background (cont.) • DO 178B is a process specification, as such it is not inspectable but depends on application in development (similar to some NASA practices) • DO 178 verification data packages (showing conformance to the necessary processes) are sold separately – Orion has elected to not purchase the DO 178 verification data package Available COTS ARINC 653 systems • Green Hills Integrity 178B – Used by Orion • Wind River VX Works 653 Platform – Flight and command computers in the Ares I • LynuxWorksOS-178 – Commercial avionics – UAV avionics Document Structure SW Architecture Logical Document Structure Partition X Partition Y Partition Z CSCI X CSCI Y CSCI Z IRDIRD IRD Integrity-178B API/ARINC 653 APEX API COTS CSCI IRD Integrity-178B Kernel COTS CSCI Embedded Processor Embedded Processor • ARINC 653 partitions provide a Orion Document Structure (examples) natural division for CSCI definitions • Alignment of partitions to CSCIs CSCIs X & Y CSCI Z CSCI Z supports effective documentation development, regression testing, IRD IRD No IRD V&V, structured integration, and eases development Partial COTS CSCI • Orion does not follow the logical approach resulting in undocumented Partial COTS CSCI CSCI to CSCI interfaces and more Embedded Processor complex regression analysis FCM FSW Partitions and Domains S I N GNCP I C C H T V E E B I F K O V O D M S M M P C M O D P P A P H T M G G S L P P O C G G S P 1 2 H 3 N C D A D S S C I E C H M B I N C C N I H V P E E E B I F S O V N N H O G A P W H W T M O D P P A S L M P C B M T M M C P P O T D D D G G C D C D R C P T V S E E E D D D D P P P D D N P L M W S E O A S P A P P P R P U U U U C U U U O A P M C T A U S M C C C C D D D C C G D C C A T D E D V V P P E E D D D I I I H N H I S M V L I P P R C W C W A I I I U U U M E M U M P M M U M U M M M T D S U U U M M M G N N M D D D D M D M D D D D D D M M M T T T M V V T P I I P T I T I P I P I P T T T H H H P E R H U U U U H U H U U U U U U H H H F F F F F F F F F F F D D M M M M M M S S I P T S T S T S S S T S T S T S S A A U U H A H A H A A A H A H A H A A CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW APX APX APX APX APX APX APX APX APX APX APX APX APX APX APX RES NRB OSD OSS BSP BMP Boot, APEX and OS “under layer” not addressed by IIRD (Not really a “partition” just drawn here that way) DCM FSW Partitions CWA & B EL inconsistently represented S D C C C C B S B F I I K A D M S W E S M D O O P C H T A A L T P O P P F B 1 D C H C C B O B 2 D S A L G S W E B M C C A L L C O P M P I I M M D C R M V M M M O M T O T R W M T T T T T H P H P H C A T H D H H H H M M D D C M T A D M D D D D T T P P S T L V P T P P P P H H U U M H M M U H U U U U D D D C D D M D D D D D D D D I P I M P P T I P I I I I P I U U U P U U H U U U U U U U U D F F D D F F F F F F D F I S S I I S S S S S S I S U A A U U A A A A A A U A CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW CSW APX APX APX APX APX APX APX APX APX APX APX APX RES NRB OSD OSS BSP BMP Boot, APEX and OS “under layer” not addressed by IIRD (Not really one “partition” just drawn here that way) Software Rqmnts Spec.