Critical Avionics Software

1、Critical Avionics SoftwareChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin2OutlineA viewpoint from production military systems David Sharp, Boeing Phantom WorksSystem development and certificationDO 178 B and CHigh level design examples:Collision avoidance systemsOperating envelope p

2、rotectionTools for modeling, design, and code generationNITRD HCSS National Workshop on Software for Critical Aviation SystemsChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin3Technology Trends in Avionics Systems Are Driving Exponential Growth in Software ComplexityAutonomous systems

3、, adaptive systemsTraditional Approaches and Processes Are Already StressedProgram-specific architectures, languages, toolsUnaligned with commercial practicesCurrent Technology, Practices and Culture of the Industry Cannot Meet Emerging System NeedsDavid Sharp, Boeing Phantom Works, HSCC Plenary Tal

4、k, Stanford, March 2002A Viewpoint from Production Military AircraftChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin4Example: Fighter Avionics DomainsRadarWeaponsNavSensorsWeaponMgmtData LinksStick,ThrottleActuatorsMissionComputingVehicleMgmtDavid Sharp, Boeing Phantom Works, HSCC Pl

5、enary Talk, Stanford, March 2002Chess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin5Mission Computing: Example FunctionalityRelease WeaponsFuse Targets From Data LinksUpdate Navigation StatePredict Selected Weapon TrajectoriesUpdate Steering CuesUpdate DisplaysFuse Targets From SensorsM

6、odify Display Suite Via Pilot PushbuttonPerform Built-In-TestActivate Backup ModeSelect WeaponsAperiodicPeriodicMissionComputingDavid Sharp, Boeing Phantom Works, HSCC Plenary Talk, Stanford, March 2002Chess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin6Vehicle Management: Example Funct

7、ionalityManage Control ModesUpdate Navigation StateCompute Inner Loop ControlsCompute Outer Loop ControlsPerform Periodic Built-In-TestManage RedundancyAperiodicPeriodicVehicleMgmtPerform Initiated Built-In-TestPerform Input Signal MgmtPerform Actuator Signal MgmtDavid Sharp, Boeing Phantom Works, H

8、SCC Plenary Talk, Stanford, March 2002Chess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin7Typical Mission Computing Legacy Characteristics10-100 Hz Update RatesUp To 10-100 Processors1M Lines of CodeO(103) ComponentsProprietary HardwareSlow CPU, small memoryFast I/OTest-Based Verificati

9、onMil-Std Assembly LanguageHighly Optimized For Throughput and MemoryFunctional ArchitecturesFlowchart designsFrequently No Maintained Requirements or DesignAd-hoc models used by algorithm developersHardcoded Hardware Specific Single System DesignsIsolated Use OfMulti-processingSchedulability analys

10、isFrequently overly pessimistic to be usedDavid Sharp, Boeing Phantom Works, HSCC Plenary Talk, Stanford, March 2002Chess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin8Typical Vehicle Management Legacy Characteristics80/160 Hz Update RatesSingle CPU System/ Quad RedundantDual/Quad Redun

11、dant Sensors and Actuators50% of codeExtensive TestingVery conservative development culture50% of effortControl System Models Carefully Developed And UsedHome grownMatlab/MatrixX with auto code generationAdditional CharacteristicsDavid Sharp, Boeing Phantom Works, HSCC Plenary Talk, Stanford, March

12、2002Chess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin9System CertificationSystem and Software TestingDesign/ImplementationRequirements DevelopmentModel V&V Control Power V&V Control Law V&VFunctional V&VSoftware V&VUnit/Component TestHardware/Software Integration (HSI)Hardware V&VQual

13、ification Test (Safety of Flight)Aircraft IntegrationSystem V&VStandalone (Static)Integrated (Dynamic)Failure Modes and Effects Test (FMET)Source: Jim Buffington, LM AeroSystem Development and CertificationChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin10FAA regulatory standard: RTC

14、A DO-178BProject management, risk mitigation, design and testing activities for embedded software developed for the commercial avionics industry are based on the FAA standard:RTCA (Radio Technical Commission for Aeronautics) DO-178B: “Software Considerations in Airborne Systems and Equipment Certifi

15、cation” “Process-based” certificationInteresting points:Certification applies to the end product (ie. airframe), encompassing all systemsIt applies to a given application of a given product (other applications of the same product require further certification)It requires that all code MUST be there

16、as a direct result of a requirementIt requires full testing of the system and all component parts (including the software) on the target platform and in the target environment in which it is to be deployed Chess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin11DO-178 HistoryTimeline Histo

17、ryNov. 1981- DO-178-SC145Mar. 1985- DO-178A SC152 (4 years)Software Levels 1,2,3 Crit, Essential, NonEssSoftware Develop Steps D1-D5Software Verification Steps V1-V7Dec. 1992- DO-178B SC167 (7 years)Objectives Based TablesWhat, not howCriticality Categories (A,B,C,D) / Objectives Matrix12 years Sinc

18、e DO-178B (15 years)SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICAIONRTCADOCUMENT NO. RTCA/DO-178BDecember 1, 1992Prepared by: SC-167“Requirements and Technical Concepts for Aviation”source: Jim Krodel, Pratt & WhitneyChess Review, Nov. 21, 2005Critical Avionics Software, C. Tom

19、lin12Issues Under Consideration for SC205 Sub-groupsTechnology/Domains Under ConsiderationFormal Methods Model Based Design & VerificationModel Verification and Level of PedigreeCertification of Proof by ModelsSoftware Tools And our reliance on them from a certification perspectiveObject Oriented Te

20、chnologyComms-Nav-Sur/Air-Traffic-Managementsource: Jim Krodel, Pratt & WhitneyChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin135uvdvDifferential game formulation:Compute the set of states for which, for all possible maneuvers (d) of the red aircraft, there is a control action (u) o

21、f the blue aircraft which keeps the two aircraft separated. yxyyhttp:/www.cs.ubc.ca/mitchell/ToolboxLS/Tomlin lab, 2002Example 1: Collision Avoidance SystemsChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin14User Interaction with Aerospace Systems:Interaction betweenSystems dynamicsMo

22、de logicUsers actionsInterface is a reduced representation of a more complex systemToo much information overwhelms the userToo little can cause confusionAutomation surprisesNondeterminisimFor complex, highly automated, safety-critical systems, in which provably safe operation is paramount, What info

23、rmation does the user need to safely interact with the automated system?Example 2: Operating Envelope ProtectionChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin15Controllable flight envelopes for landing and Take Off / Go Around (TOGA) maneuvers may not be the samePilots cockpit disp

24、lay may not contain sufficient information to distinguish whether TOGA can be initiatedflareflaps extendedminimum thrustrolloutflaps extendedreverse thrustslow TOGAflaps extendedmaximum thrustTOGAflaps retractedmaximum thrustflareflaps extendedminimum thrustrolloutflaps extendedreverse thrustTOGAfla

25、ps retractedmaximum thrustrevised interfaceexisting interfacecontrollable flare envelopecontrollable TOGA envelopeintersectionTomlin lab, 2003http:/www.cs.ubc.ca/mitchell/ToolboxLS/Example 2: Operating Envelope ProtectionChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin16Designing saf

26、ety critical control systems requires a seamless cooperation of tools:Modeling and design at the control levelDevelopment tools at the software levelImplementation tools at the platform levelCorresponding research needed:Development of algorithms and tools to verify and validate the high level desig

27、n currently tools such as reachability analysis tools for hybrid systems are limited to work in up to 4-5 continuous state dimensionsDevelopment of code generation tools (ideally, verified to produce correct code)Tools to check the correctness of the resulting codeAlgorithms and tools to automatical

28、ly generate test suitesTools for modeling, design, and code generationChess Review, Nov. 21, 2005Critical Avionics Software, C. Tomlin17Static Program Analysis ToolsStatic program analysis is used at compile time to automatically determine run-time information and properties which are extractable fr

29、om the source code. These include:Ensuring that the allowable range of array indexes is not violatedEnsuring simple correctness properties: functional (such as dependencies between aspects of variables or invariants on the shape of data structures) or nonfunctional (such as confidentiality or integr

30、ity for security-critical applications)Identifying potential errors in memory accessType checkingInterval analysis Checking for illegal operations, like division by zeroCurrently, properties such as absence of run time errors and worst case execution time have been tackled: more research is needed to address problems arising from a distributed, embedded setting, such as checking for safety conditions, and for the absence of deadlocksChess Review, Nov. 21, 2005Critical Avionics Software,