Manufacturers should carefully consider the internal structure of software in partitioning sub-functions within an overall function. In an integrated architecture the FMF may be a partition within a system which provides all CNS/ATM airborne functions. The flight management function itself may consist of several subfunctions such as Navigation, Flight Planning, Crew Interface, I/O, etc. which may be separate partitions. As the objectives of software partitioning are efficient design and effective functional allocation, as well as reduced software change costs and lead times, manufacturers must ensure that the software structure eliminates the need to revalidate software partitions and modules that have not been affected by a particular change. In some configurations, the system may be a mixed criticality unit. In other words, this unit may house software of more than one DO-178B level. In these configurations, manufacturers must ensure that partitioning is robust enough to accommodate changes in any lower level software (i.e., less critical software) without mandating the rigors of the more critical software validation, certification, and maintenance.
Operational Functional Independence
While the system makes extensive use of shared resources as a multi-function system (e.g., power supplies, processors), manufacturers may provide for some system functions to be retained during failure conditions.
Airlines strongly desire to continue to operate the system even if one or more functions or external interfaces have failed, as long as the aircraft operation is not predicated on the use of the failed sensor or function(s). Therefore, a failure condition unique to one function or sensor should not adversely impact normal operation of any other system functions.
Unit Identification Considerations
Avionics and airframe manufacturers are strongly encouraged to implement an FMS unit identification methodology that does not correlate the software version with the basic face plate part number of the unit. The objective is that a software revision should not result in the re-identification - part number roll - of the unit. A further objective is that a common FMS platform (i.e., a single face plate part number) could be used across multiple fleets and airframe manufacturers without re-identification of the unit, even if fleet specific software is required for each fleet type.
With this approach an individual manufacturer’s part numbers are assigned and maintained for (1) the FMC hardware, (2) the FMC software, and (3) the overall unit (i.e., face plate part number). In this case, the face plate part number is referred to as the generic or system part number and is not affected by normal revisions to the FMS software (e.g., all software or data that can be loaded into the unit via a data loader will not require a re-identification of the unit).
For this scenario, the operator may stock a given FMC under its system part number. This unit could be effective across multiple fleet types, each with fleet specific software requirements. When an FMC is replaced on an aircraft, the software configuration can be verified from the MCDU. If necessary, the FMC may be loaded with the applicable certified software for that fleet via data loader or system crossload.
This scheme allows the operator to minimize sparing when a given FMC is used on multiple fleet types, even when unique software is required for each fleet. It will also enable new FMC software loads on the aircraft without requiring a revision to the FMC ID plates or the aircraft Illustrated Parts Catalog (IPC).
FMC Accuracy and Performance
Accuracy requirements for the lateral navigation function are defined by the RTCA/DO-236 : Minimum Aviation System Performance Standards (MASPS) Required Navigation Performance for Area Navigation. RTCA/DO-236 also addresses accuracy requirements for the vertical navigation and trajectory prediction functions.
Response Time Standards
Specification of precise response time standards is dependent on the detailed system operational design. This section provides general guidelines that should be considered by system designers in determining computer processing requirements and software architecture.
Requirements and Measurements:
|Task Description||Max. Response Time|
|Direct to a Waypoint in the Flight Plan - Lateral Data Display||2 seconds|
|Direct to a Waypoint in the Flight Plan - Vertical Data Display||3 seconds|
|Direct to a Waypoint Not in the Flight Plan - Lateral Data Display||3 seconds|
|Direct to a Waypoint Not in the Flight Plan - Vertical Data Display||3 seconds|
|Steering Command Output following flight plan change||3 seconds|
|Revise Speed or Altitude Restriction at Descent Waypoint (Time to display of the predicted altitude at the next waypoint)||5 seconds|
|Revise RTA target speed||5 seconds|
|Full Flight Plan Prediction - Vertical Data (performance depends on factors such as flight plan length and number of waypoints)||15 seconds typical|
|Background data update in response to a Mode, scale, or option change on the EFIS||1 second|
|Software and Data base loading (ref. Section 10.3.3) Note: may be limited by file size, media or loader interface||goal: less than 15 minutes|
|ATS Uplink Messages||Note|
|ATS Downlink Messages||Note|
Note: The International Civil Aviation Organization (ICAO) CNS/ATM-1 SARPS allocate part of the total system end to end response time to the avionics. Further allocation to individual avionics subsystems (e.g., FMS, CMU, EFIS) is system architecture dependent and beyond the scope of this document.