ARINC 652-1993 Guidance for Avionics Software Management《航空电子设备管理指南》.pdf

《ARINC 652-1993 Guidance for Avionics Software Management《航空电子设备管理指南》.pdf》由会员分享，可在线阅读，更多相关《ARINC 652-1993 Guidance for Avionics Software Management《航空电子设备管理指南》.pdf（73页珍藏版）》请在麦多课文档分享上搜索。

1、 GUIDANCE FORAVIONICS SOFTWARE MANAGEMENTARINC REPORT 652PUBLISHED: JANUARY 15, 1993AN DOCUMENTPrepared byAIRLINES ELECTRONIC ENGINEERING COMMITTEEPublished byAERONAUTICAL RADIO, INC.2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401Copyright 1993 byAERONAUTICAL RADIO, INC.2551 Riva RoadAnnapolis, Maryland 2

2、1401-7465 USAARINC REPORT 652GUIDANCE FOR AVIONICS SOFTWARE MANAGEMENTPublished: January 15, 1993Prepared by the Airlines Electronic Engineering CommitteeReport 652 Adopted by the Airlines Electronic Engineering Committee: November 5, 1992Report 652 Adopted by the Industry: January 15, 1993REPORT 65

3、2TABLE OF CONTENTSITEM SUBJECT PAGE1.0 INTRODUCTION 11.1 Purpose of this Document 11.2 Background 11.3 Airline Objectives 11.4 ARINC 652 Overview 11.5 Relationship to Other Documents 11.5.1 Relationship to RTCA DO-178B/EUROCAE ED-12B 21.5.2 Relationship to ARINC Report 651 21.6 Use of “Specification

4、 Language“ 21.7 Other Considerations 22.0 SOFTWARE COST DRIVERS 32.1 Overview of Costs Drivers 32.2 Airline Related Costs 32.2.1 Operational Costs Due to Low MTBF/MTBR 32.2.2 Post Delivery Changes 32.2.3 Modification Due to Lack of Hardware 32.2.4 Selection Of Customer Options 32.2.5 Tolerant Design

5、 42.2.6 Post Delivery Support-Customer Relationship 42.2.7 Cost of Configurable Software 42.2.8 Cost of Interfacing to Flight Simulators 42.3 Equipment Supplier-Development Costs 42.3.1 Project Management 42.3.1.1 Development Schedules 42.3.1.2 Stability of Requirements 42.3.1.3 Customer/Supplier Re

6、lationship 42.3.2 Product Related Factors 42.3.2.1 Complexity and Size 42.3.2.2 Target Hardware Design 42.3.2.3 Memory and Throughput Constraints 52.3.2.4 Re-Use of Existing Software 52.3.2.5 Use of Commercial Off-The-Shelf (COTS) Software 52.3.2.6 Software Criticality Level 52.3.3 Use of Developmen

7、t Tools 52.3.3.1 Requirement, Analysis and Design 52.3.3.2 Verification 52.3.3.3 Documentation Tools 62.3.3.4 Software Configuration Management 62.3.3.5 Host Computers 62.3.3.6 Software Test and Integration Facility 62.3.3.7 Introduction of Tools 62.3.3.8 Tool Qualification 62.3.4 Personnel Factors

8、62.3.4.1 Staff Capability 62.3.4.2 Multi-Site Development 72.3.4.3 Staff Continuity 62.3.4.4 Use of Sub-Contract Engineers 72.4 Aircraft Integrator Costs 72.4.1 Functional Specification Elaboration 72.4.2 Supplier Monitoring 72.4.2.1 Project Management 72.4.2.2 Software Quality Assurance 72.4.3 Syst

9、em Integration Costs 72.4.3.1 Ground Tests 82.4.3.2 Flight Tests 82.4.4 Certification Process 82.5 Cost Distribution 83.0 SOFTWARE MANAGEMENT 93.1 The Software Development Process 93.1.1 Integral Processes 93.1.1.1 Software Management Process 93.1.1.2 Certification Liaison 9iiiREPORT 652TABLE OF CON

10、TENTSITEM SUBJECT PAGE3.1.1.3 Software Quality Assurance Process 103.1.1.4 Software Configuration Management Process 103.1.1.5 Software Verification Process 113.1.2 Term Processes 113.1.2.1 System Definition Process 113.1.2.2 Software Planning Process 113.1.2.3 Software Requirements Process 113.1.2.

11、4 Software Design Process 123.1.2.5 Code Process 123.1.2.6 Combined Integration Proccess 133.1.2.6.1 Software Integration 133.1.2.6.2 Hardware/Software Integration 133.1.3 Post Development Software Related Activities 133.2 Enhancements of Models for Field Performance 133.3 The User and Supplier Rela

12、tionship 143.4 Managing Software Development 143.4.1 Software Design Tradeoffs 153.4.2 Relationship between Complexity and Cost 153.4.3 Value of Software Development Tools 153.4.4 Software Personnel 153.4.5 Schedule 153.4.6 Managing Small Projects 163.4.6.1 Architecture Tradeoffs 163.4.6.2 Reviews a

13、nd Assurances 163.4.6.3 Testing 173.5 Software Documentation 173.6 Managing User-Modifiable Software 183.6.1 Management Goals 183.6.2 Availability of Tools 183.6.3 Integrity of the Changed Software 183.6.4 User Training 183.7 Software Security 193.7.1 Computer Security 193.7.1.1 Vulnerabilities 193.

14、7.1.2 Causes of Preventable Losses 193.7.1.3 Frequency and Cost of Losses 203.7.1.4 Defense Mechanisms 203.7.1.5 Government Security Standards 203.7.2 Methodology 203.7.2.1 Threat Assessment 203.7.2.2 External Threats 203.7.3 Dealing with External Threats 203.7.3.1 Software Protection 203.7.3.2 Data

15、 Protection 203.7.3.3 Other Protection 213.7.3.4 Computer Virus Defense Mechanisms 213.7.4 Software Security Recommendations 213.7.4.1 Unauthorized Access 213.7.4.2 Input Tape Tampering 213.7.4.3 Software Security Verification at Run-Time 213.7.4.4 Recovery Provisions 213.7.4.5 Security Management 2

16、13.7.4.5.1 Never-Alone Principle 213.7.4.5.2 Limited-Tenure Principle 213.7.4.5.3 Separation-of-Duties Principle 213.7.4.6 Detection and Surveillance 223.7.5 Fault Tolerance and Security 223.7.5.1 Fault Tolerance Techniques 224.0 SOFTWARE DEVELOPMENT 234.1 Software Development Environment 234.2 Cons

17、iderations for Software Design 234.2.1 General Considerations 234.2.1.1 Use of Ada High-Order Language 23ivREPORT 652TABLE OF CONTENTSITEM SUBJECT PAGE4.2.1.2 Modularity 244.2.1.3 Consistency of Design 244.2.1.4 Design for Software Criticality Level 244.2.1.5 Throughput 244.2.1.6 Memory Size 244.2.1

18、.7 Documentation 244.2.1.8 Verification Considerations 244.2.1.9 Expandability for Future Applications 244.2.2 Special Considerations 254.2.2.1 Partitioning for Convenience 254.2.2.2 Partitioning for Criticality 254.2.3 Design for Change 254.2.4 Design for Re-Use 254.2.5 Design for Portability 264.2

19、.5.1 Why Transport Software? 274.2.6 Design for Robustness 274.2.6.1 Defensive Programming 274.2.6.2 Design of Built-In Test (BIT) Software 274.2.7 Design for Compatibility with Flight Simulator 274.3 Customer/Supplier Relationships 284.3.1 Life Cycle Model 284.3.2 Customer Participation in Defining

20、 Requirements 284.3.3 Schedule Implications 284.4 Software Certification 285.0 USER-MODIFIABLE SOFTWARE 305.1 User-Modifiable Software Goals 305.2 Software Modification Environment 305.2.1 Change Within Limits 305.2.2 Configuration Control 305.2.3 Documentation 305.2.4 Other Considerations 305.2.5 E

21、xample of User-Modifiable Software 305.2.5.1 Characteristics of this Example 315.2.5.2 Tool Related Issues 325.3 Managing User-Modifiable Software 325.3.1 Selection of Preprogrammed Options 325.3.1.1 Responsibility 325.3.1.2 Tools 325.3.1.3 Training 325.3.1.4 User Requirements 325.3.1.5 Installation

22、 on Aircraft 325.3.1.6 Cost Impact 325.3.1.7 Password Protection 325.3.2 Tables, Configurable via Resident Table Manager 325.3.2.1 Responsibility 325.3.2.2 Tools 325.3.2.3 Training 325.3.2.4 User Requirements 325.3.2.5 Documentation 325.3.2.6 Problem Reports 335.3.2.7 Relation to Ground Based System

23、s 335.3.2.8 Software Labeling 335.3.2.9 Configuration Control and Verification 335.3.2.10 Installation on Aircraft 335.3.2.11 Cost Impact 335.3.2.12 Password Protection 335.3.3 Tables, Configurable via Ground Support Equipment 335.3.3.1 Responsibility 335.3.3.2 Tools 335.3.3.3 Training 335.3.3.4 Use

24、r Requirements 335.3.3.5 Documentation 335.3.3.6 Problem Reports 33vREPORT 652TABLE OF CONTENTSITEM SUBJECT PAGE5.3.3.7 Interfaces with Ground Based Systems 335.3.3.8 Software Labeling 335.3.3.9 Evaluation on Aircraft 335.3.3.10 Installation on Aircraft 335.3.3.11 Software Installation Procedure 335

25、.3.3.12 Disk Labeling 345.3.3.13 Duplication of Software 345.3.3.14 Cost Impact 345.3.3.15 Password Protection 345.3.3.16 Airline Concerns 345.3.4 Tables and Application Software, Configurable via GSE 345.3.4.1 Responsibility 345.3.4.2 Tools 345.3.4.3 Training 345.3.4.4 User Requirements 345.3.4.5 P

26、lanning 355.3.4.6 Documentation 355.3.4.7 Problem Reports 355.3.4.8 Relation to Ground-Based Systems 355.3.4.9 Software Labeling 355.3.4.10 Software Changes Due to External Factors 355.3.4.11 Configuration Control and Verification 355.3.4.12 Bench Testing 355.3.4.13 Evaluation on the Aircraft 355.3.

27、4.14 Installation on Aircraft 355.3.4.15 Software Installation Procedure 355.3.4.16 Disk Labeling 365.3.4.17 Duplication of Software 365.3.4.18 Cost Impact 365.3.4.19 Password Protection 365.3.4.20 Airline Concerns 365.4 Configuration Management 366.0 POST-CERTIFICATION SOFTWARE CHANGES 376.1 Introd

28、uction 376.2 Software Maintenance Process 376.3 Re-Certification of Modified Systems 376.4 Approach to Certification 376.5 Change Within Limits 376.6 Change Process 37ATTACHMENTS1 Glossary 39-451 Acronyms and Abbreviations 462 System Life Cycle 473 System/Software Development Process 48APPENDICESA R

29、eference Documents 49B Software Life Cycle Models 50-65FIGURESB-1 An Example of System Development Reviews and Audits 55B-2 Detailed Waterfall Representation 56B-3 Software Development and Verification Activities 57B-4 Starts V-Diagram 58B-5 The Two-Leg Process Model 59B-6 Incremental Development 60

30、B-7 Domain Dependent Software Life Cycle 61B-8 Third Generation 62B-9 System Development Life Cycle 63viREPORT 652TABLE OF CONTENTSITEM SUBJECT PAGEFIGURESB-10 Spiral Model of the Software Process 64B-11 New Model 65B-12 Object-Oriented Model 66viiARINC REPORT 652 - Page 11.0 INTRODUCTION1.1 Purpose

31、 of this DocumentThis document is intended as a top-level design guide formanaging the development and maintenance of avionicssoftware. It provides guidance for the design andimplementation of avionics software for traditional ARINC700-Series equipment and Integrated Modular Avionics(IMA). This docu

32、ment emphasizes the airline desire foruser-modifiable software.ARINC Report 652 represents the consensus of theairlines, airframe manufacturers and avionics suppliers. Itis conceptual in nature and covers broad subjects of costobjectives, software management, software design,software modification, s

33、oftware re-use, documentation andcertification. In doing so, the document attempts to be asinclusive as possible, while remaining general enough tobe applicable to new and developing technologies. Itincludes both software management philosophy andrecommended practices. It establishes a starting poin

34、t forthe implementation of avionics software.1.2 BackgroundAvionics containing embedded software are wellestablished in the industry. Advancements in electronicssystem integration and software engineering have resultedin avionics of increasing versatility and capability.Current aircraft development

35、programs indicate that thetrend toward a higher degree of equipment integration willcontinue. Likewise, it is expected that this trend will, bynecessity, affect the way that software is designed andpartitioned.The emergence of software-based avionics has alsoenabled the avionics industry to develop

36、new designconcepts for highly-integrated digital avionics undersoftware control. These concepts, collectively referred toas Integrated Modular Avionics (IMA), introduce methodswhich will result in substantial cost savings compared toearlier avionics implementations. It is a modular systemwith common

37、 fault tolerant processing, centralized powersupplies, and a flexible aircraft interface. High-throughputmicroprocessors, the Ada programming language and re-usable software are the key components and technologiesavailable to design, develop and integrate these advancedavionics systems.1.3 Airline O

38、bjectivesThe advent of on-board and portable data loaders hasprovided the airlines with cost effective methods ofimplementing software upgrades and changes.Consequently, the airlines are becoming increasinglyinterested in avionics with user-modifiable software. Suchcapabilities afford them the oppor

39、tunity to customize andtailor certain avionics functions in response to operationalpreferences, marketing strategies and varying geographicalrequirements. The airlines, therefore, advocate techniquesin software design, development and management thatalleviate the need for costly re-certification.Adv

40、ances in software techniques and system architecturehave improved the safety aspects of segregating functionsand preventing undesirable interactions. The airlines havean interest in predetermined options, and segregatedprogrammable code areas, which are determined at thetime of certification to be m

41、odifiable with no impact onsafe aircraft operation. Airline users may elect to obtainthe necessary tools and documentation to make suchlimited changes themselves. It is understood that thenumber of functions to which this is possible is limited.The airlines are much less inclined to modify software

42、thatrequires costly re-certification.The airlines recognize there are two general steps in re-certification:a. The software implementation aspects - confidencethat the software will operate properly with themodification and will not disturb other areas of thesoftware and system.b. The operational ap

43、propriateness aspects - confidencethat the modification is safe in terms of overallcockpit and system operational safety.The goal is to use current software segregation andpartitioning techniques to minimize the re-certificationeffort associated with the software maintained andmodified by the airlin

44、es.1.4 ARINC 652 OverviewThis document is organized into six sections which discusseconomic, technical and administrative issues associatedwith the design of avionics software.Section 1 introduces the document and providesbackground information leading to its development.Section 2 presents the key e

45、conomic and operationalobjectives for avionics software. Avionics software costdrivers are discussed.Section 3 addresses software management. User andsupplier relationships are described. Recommendationsconcerning software development schedules, application ofresources and software security are desc

46、ribed.Section 4 provides design guidance for softwaredevelopment. It addresses issues of software partitioning,modularity and robustness.Section 5 describes the airlines desires for softwaremodification. It describes the software modificationenvironment and recommends methods for implementingsoftwar

47、e changes.Section 6 describes post-certification software changes.1.5 Relationship to Other DocumentsThe material in this Report is intended to complement allARINC Characteristics and Specifications written foravionics. In order to avoid inconsistencies anddiscrepancies, some subjects have intention

48、ally beenomitted since ARINC documents or other specificationsare known to exist. It recognizes that text books andother generic reference materials on software engineeringexists. It is the intent of this Report to encourage the useof any standards of good practice which have beendeveloped by the Go

49、vernment, the Military, and otherARINC REPORT 652 - Page 11.0 INTRODUCTION (contd)1.5 Relationship to Other Standards (contd)industry groups, so long as they are applicable to airlineavionics equipment.1.5.1 Relationship to RTCA DO-178B/EUROCAE ED-12BRTCA DO-178B and EUROCAE ED-12B, “SoftwareConsiderations in Airborne Systems and EquipmentCertification“ are identical documents that containguidelines for software development and certification.The certification requirements used in conjunction withDO-178B/ED-12B are defined by the respectivecertification authority.ARINC Report 652, howe