3.1 Computer-based Flight and Mission Planning Systems (hereafter referred to as MPS) provide substantial efficiencies for aviation flight and mission planning over traditional approaches. MPS consist of software applications that allow maps, charts, weather, intelligence and aircraft performance data to be used in developing navigation solutions (eg routes, approaches, terminal procedures), communication settings, flight and mission calculations (eg fuel, leg times), and other pertinent aeronautical data. MPS may include visual software tools optimised for specific aircraft roles, and automate the computations associated with aircraft specific flight/mission planning. Once the mission information has been generated, it is printed (eg kneeboards, strip charts), or alternatively written onto a data storage device (eg PCMCIA flash disk, or proprietary data transfer module) for transfer to aircraft systems (eg FMS, navigation system, EFB). Some modern MPS also include functions to transmit and receive flight/mission information via datalink, either at the commencement of a flight/mission, or as real time updates throughout a flight/mission. MPS may also be used for post-flight/mission debriefing.
3.2 With the advancement of performance based navigation, and the aircraft equipment that supports these types of navigation, MPS are being used in more challenging and potentially hazardous ways (eg aeronautical data supporting required navigation performance). Therefore, any MPS applications transferring, translating, manipulating or generating aeronautical information in this context should be designed and assured commensurate with the integrity requirements for the data they process.
3.3 This chapter presents the Authority prescribed airworthiness design requirements for MPS.
3.4 Design Requirement (Essential). The worst credible failure condition and the associated data criticality level for the aeronautical data produced by MPS must be established using formal System Safety tools and techniques.
3.5 The above design requirement can be satisfied by following a defined systematic approach, as detailed in a system safety program, for identifying, analysing and evaluating hazards to determine the worst credible failure condition associated with the use of the MPS. The Authority prescribed system safety airworthiness design requirements are presented in:
DASDRM Section 2 Chapter 2 – System Safety.
3.6 The worst credible failure condition of the MPS can be used to determine the data criticality of the aeronautical data. The following data criticality levels are defined by the International Civil Aviation Organisation (ICAO) in Annex 15 (Chapter 3) to the Convention on International Aviation:
Critical data (Assurance Level 1). The data if erroneous, would prevent continued safe flight and landing or would reduce the ability to cope with adverse operating conditions to the extent that there is a large reduction in safety margins or functional capabilities. There is a high probability when trying to use corrupted critical data that an aircraft would be placed in a life threatening situation.
Essential Data (Assurance Level 2). The data if erroneous, would reduce the ability to cope with adverse operating conditions to the extent that there is a significant reduction in safety margins. There is a low probability when trying to use corrupted essential data that an aircraft would be placed in a life threatening situation; and
Routine Data (Assurance Level 3). The data if erroneous, would not significantly affect aircraft safety. There is a very low probability when trying to use corrupted routine data that an aircraft would be placed in a life threatening situation.
3.7 The failure condition definitions for aeronautical data are intended to be compatible with the existing aircraft safety assessment process of MIL-STD-882 and ARP4754/4761, these correlate to the design assurance requirements of RTCA/DO-178C, as presented in Table 3–1. ICAO data criticality and data process assurance level are aligned to the existing failure condition definitions as shown in Table 3–1.
Table 3-1: Relationship between Failure Condition Categories and Data Process Assurance Levels
|
MIL-STD-882 and |
RTCA/DO-178C |
|
ICAO Annex 15 |
RTCA/DO-200B |
||
|
Failure Condition Category |
Effect |
Design Assurance Level |
|
Data Criticality |
Definition |
Data Process Assurance Level |
|
Catastrophic |
Failure conditions that would prevent continued safe flight and landing. |
A |
|
Critical |
The data if erroneous, would prevent continued safe flight and landing or would reduce the ability to cope with adverse operating conditions to the extent that there is a large reduction in safety margins or functional capabilities. There is a high probability when trying to use corrupted critical data that an aircraft would be placed in a life threatening situation. |
1 |
|
Hazardous / Severe Major |
Failure conditions that would reduce the capability of the aircraft or the ability of the crew to cope with adverse operating conditions to the extent that there would be: |
B |
|
|||
|
Major |
Failure conditions that would reduce the capability of the aircraft or the ability of the crew to cope with adverse operating conditions to the extent that there would be, for example, a significant reduction in safety margins or functional capabilities, a significant increase in crew workload or in conditions Impairing crew efficiency, or discomfort to occupants, possibly including injuries. |
C |
|
Essential |
The data if erroneous, would reduce the ability to cope with adverse operating conditions to the extent that there is a significant reduction in safety margins. There is a low probability when trying to use corrupted essential data that an aircraft would be placed in a life-threatening situation. |
2 |
|
Minor |
Failure conditions that would not significantly reduce aircraft safety, and that would involve crew actions that are well within their capabilities. Minor failure conditions may include, for example, a slight reduction in safety margins or functional capabilities, a slight increase in crew workload, such as routine flight plan changes, or some inconvenience to occupants. |
D |
|
|||
|
No Safety Effect |
Failure conditions that do not affect the operational capability of the aircraft or increase crew workload. |
E |
|
Routine |
The data if erroneous, would not significantly affect aircraft safety. There is a very low probability when trying to use corrupted routine data that an aircraft would be placed in a life threatening situation. |
3 |
3.8 Design Requirement (Essential). The MPS must be assured to a level commensurate with the worst credible failure condition and data criticality level.
3.9 The above requirement can be satisfied by applying appropriate validation and/or verification techniques along with the required level of software assurance as presented in Table 3-2. To allow an application of the relevant validation and verification design features and assurance requirements with MPS functional components, it is necessary to define a means of categorising MPS functions. In RTCA/DO-200B this is done using the data processing phases of receive, assemble, translate, select, format and distribute. However these terms are defined in the context of the whole aeronautical data process, and not just MPS components. Therefore, the ADF approach to MPS functions is to use the guidewords of Transfer, Format, Manipulation, and Generation for MPS components (defined in paragraph 13).
3.10 The guidewords, in conjunction with the data assurance level of the aeronautical data element in question, are used to determine which validation and verification techniques and assurance requirements need to be implemented by the MPS (refer Table 3–2). The alternative to validation and verification techniques identified in Table 3–2 is to assure that design faults that could introduce errors are absent. Of course, the absence of design faults cannot be conclusively demonstrated. Software assurance techniques are used to provide confidence, commensurate with the severity of failure, that design faults are absent.
Table 3-2: Design and Assurance Requirements for MPS Functions
|
MPS Functional Guideword |
Data Assurance Level |
Validation and Verification Techniques |
OR |
Absence of Verification and Validation |
|
Transfer |
1 (Critical) |
Digital Error Detection1 OR Feedback / Readback Verify2 |
OR |
MPS Components that perform the Transfer function are qualified commensurate with RTCA/DO-178C Level A or B |
|
2 (Essential) |
Digital Error Detection3 OR Feedback / Readback Verify4 |
OR |
MPS Components that perform the Transfer function are qualified commensurate with RTCA/DO-178C Level C or D* |
|
|
3 (Routine) |
No detection and handling required |
|||
|
Formatting |
1 (Critical) |
Feedback / Reversibility Check2 OR Independent Redundancy5 |
OR |
MPS Components that perform the Formatting function are qualified commensurate with RTCA/DO-178C Level A or B |
|
2 (Essential) |
Feedback / Reversibility Check4 OR Independent Redundancy5 |
OR |
MPS Components that perform the Formatting function are qualified commensurate with RTCA/DO-178C Level C or D* |
|
|
3 (Routine) |
No detection and handling required |
|||
|
Manipulation / Generation |
1 (Critical) |
Feedback / Reversibility Check2 OR Independent Redundancy5 |
OR |
MPS Components that perform the Manipulation / Generation function are qualified commensurate with RTCA/DO-178C Level A or B |
|
AND |
||||
|
Logical Consistency Checks OR Semantic Consistency Checks |
||||
|
2 (Essential) |
Feedback / Reversibility Check4 OR Independent Redundancy6 |
OR |
MPS Components that perform the Manipulation / Generation function are qualified commensurate with RTCA/DO-178C Level C or D* |
|
|
AND |
||||
|
Logical Consistency Checks OR Semantic Consistency Checks |
||||
|
3 (Routine) |
No detection and handling required |
|||
|
Notes:
* Note the difference between RTCA/DO-178C Level C and D is notable, and therefore the safety assessment process must make it explicit which severity failure condition the data element relates to. It also means there may be limitations to the extent to which tools used for Essential data in one context may be used in an alternative context. Note that the Digital Error Detection qualification requirements (e.g., generate and check) are more onerous than the other verification techniques as the generated Digital Error Detection code is typically used by other downstream data processing tools/steps for error detection. |
||||
3.11 The various validation and verification techniques that can be implemented are defined in:
RTCA/DO-200B – Standards for Processing Aeronautical Data – Appendix C.
3.12 Software assurance levels and associated objectives are prescribed in:
RTCA/DO-178C – Software Considerations in Airborne Systems and Equipment
3.13 The MPS functional guidewords used in Table 3-2 are defined below along with the suitable validation and/or verification techniques that can be applied:
Transfer. The MPS directly transfers the source data to the data transfer device, in the same format, without change. This type of MPS function is suitable for protection using digital error detection mechanisms as described in RTCA/DO-200B Appendix C.
Format. The MPS takes static source data, and through a set of pre-defined formatting requirements, reformats the source data into a new format for writing to the data transfer device. The extent of changes to the source data is confined to format changes (eg DAFIF to ARINC424), including the unit changes, word data type, and frame packing strategy. The unit changes (eg meters to feet) will involve some form of calculation. The MPS does not generate any new information as a result of dynamic source data or user input. Feedback and independent redundancy are the most suitable means of MPS components determining if errors have been introduced into the data, as described in RTCA/DO-200B Appendix C.
Manipulation. The MPS takes a combination of static and dynamic source data, and through a set of pre-defined requirements, manipulates (or translates) the source data for writing to the data transfer device. Manipulation may include the production of new information as a result of calculations based on static source data, but does not include the provision of data input by the user. Feedback and independent redundancy are the most suitable means of MPS components determining if errors have been introduced into the data, as described in RTCA/DO-200B Appendix C.
Generation. Through a combination of static and dynamic source data, and keyboard input from the user, the MPS generates new data to be loaded onto the data transfer device. The validation methods described in RTCA/DO-200B Appendix C are the most suitable methods of ensuring the resultant generated data is valid.
3.14 Design Requirement (Essential). Aeronautical data produced by the MPS, with a data criticality of Critical or Essential, must meet the established data quality requirements prescribed in:
RTCA/DO-200B - Standards for Processing Aeronautical Data.
3.15 The aeronautical data quality requirements should be established by the user and supplier of the aeronautical data and be clearly documented. Aeronautical data quality is defined as the degree or level of confidence that the data provided meets the requirements of the user. Aeronautical data quality requirements include levels of accuracy, resolution, assurance, traceability, timeliness, completeness, and format. Data quality requirements are defined in RTCA/DO-200B.
3.16 Further guidance on MPS acquisition/modification projects and in-service engineering support agencies can be provided by the chapter sponsor.