Standardization

This section briefly highlights the standardization requirements for the vision state avionics architecture. This is not intended to be a comprehensive discussion of the aviation standards and certification process, which are presented in the MCNA Certification Report19

as a standalone deliverable. The intent of this section is to identify some of the deficiencies in the existing aviation standards such that remedial actions can be undertaken.

4.5.1 Compatibility with ARINC 664

ARINC Specification 664 is primarily a guidance document that establishes the architecture framework for IP-based aircraft. It contains detailed implementation specification for AFDX, and the Ethernet physical layer. ARINC 664 also provides aeronautical profiles for IPv4 and an IP address allocation scheme using private IP address space. Except for AFDX and the Ethernet physical connectivity standards, ARINC 664 is intended to be referenced by other Airline Electronic Engineering Committee (AEEC) standards bodies as they develop ARINC implementation specifications.

The proposed vision state avionics architecture conforms to the ARINC 664 domain model. It also capitalizes on the ARINC 763 characteristics for the Network/Cabin File Server. However, none of the existing ARINC standards reflect the SWIM concept simply because these standards predate SWIM. Therefore, it would be necessary to update the relevant ARINC standards to incorporate SWIM requirements. As the

NFS/CFS entities host the SWIM Server (S3), Native Application, and Adapter functions in the vision state architecture, the ARINC Characteristic 763 must be revised.

The CMU/CMF/router function within the ACD manages all air/ground network communications in the vision state architecture. The form, fit and functionality of the CMU is specified in ARINC Characteristic 758, whereas the air/ground communication protocols for ACD are defined in ARINC Specifications 637, and 618. These standards should also be amended to incorporate the required IP capabilities.

19

The MCNA Certification Report [CDRL A047] describes FAA’s avionics certification process and contains recommendations for amending the process for the vision state.

REV A 96

4.5.2 Additional Standardization effort required

The ICAO is updating the ATN SARPs to permit the use of IP as a subnetwork protocol. Once the ICAO requirements are completed, the private IPv4 addressing scheme specified in ARINC 664 may be used to provide point-to-point subnetwork connections for ATM provided Network Address Translation (NAT) function is approved by ICAO. The IPv6 addressing scheme accommodates ATN Network Service Access Point (NSAP) addresses through appropriate selection of the defined Format Prefixes. Therefore, IPv6 will permit transparent tunneling of ATN network layer protocols for mobility management and is desirable for MCNA. ARINC 664 has limited coverage of the IPv6 addressing mechanisms. This standard should be expanded to describe how IPv6 addresses will be used to support both ATN and non-ATN MCNA communications. Additional standards may also be required to deal with co-existence of IPv4 and IPv6 during the transition period.

Edition 3 of the ICAO ATN SARPs specifies cryptographic mechanisms to ensure information security. In addition to general firewall provisions, the ICAO security algorithms have been included in ARINC 664 for guidance. The AEEC Security (SEC) Working Group is currently undertaking the task of developing a Concept of Operations (ConOps) for secure aeronautical communications. The ConOps will provide the overall security framework for AOC communications. Subsequently, the AEEC sub-committees have to update their respective ARINC standards to incorporate security implementation specifications. It is anticipated that several ARINC standards, such as 618, 637, 702A, 763, 746, etc. will require modifications.

Although avionics implementations are driven by the ARINC standards, airworthiness certification of avionics is governed by the RTCA documents. As the current RTCA documents do not cover the Internet protocols, a complete suite of RTCA standards (MASPs and MOPS) may have to be developed. Alternatively, the RCP specifications may be adequate if it is used as the only criteria for approving communication systems and networks. It will not be possible to clearly identify all standardization requirements for MCNA and the vision state avionics architecture without an established certification guideline from the FAA.

REV A 97

This section discusses how the architecture defined in the previous sections addresses the requirements defined in the MCNA Requirements Report [26].

5.1 Functional Requirements

5.1.1 Relationship between Functions and Communication Services

The MCNA Requirements Report [26] captured the product of functional analysis that defined the first three levels of MCNA functions as summarized in Figure 28.

Provide MCNA

Provide Data Transport Manage Data TransportManage Data Transport

Register Names Allocate Network Addresses Resolve Address from Names Authenticate User Authorize Access Establish Connection /Session Maintain Connection /Session Terminate Connection /Session Allocate Flows to A- G/A-A Subnetworks Move Flows between A- G/A-A Subnetworks Create A- G/A-A Subnetwork Connection Terminate A-G/A-A Subnetwork Connection Authenticate Data Encrypt Data Assure Data Integrity Deliver Packets to Single User Deliver Packets to Group of Users Deliver Packets to All Users Prioritize Packet Delivery Pre-empt lower priority communications Shape Traffic (ingress & egress) Police Traffic Provide Naming and Addressing Transport Data Maintain QoS Manage A-G/ A-A Connections/ Sessions Manage A-G/ A-A Routing Policy & Mobility Manage Network Faults Manage Network Config. Manage Network Accounting Manage Network Security Manage Network Performance

Figure 28 MCNA Functional Analysis

Also documented within this report is a set of communications services which are an extension of the RCP concept intended to comprehensively represent the aggregate of communication services required in the aviation industry. As part of the architecture analysis effort, a table was produced that maps the interaction between these MCNA functions and the MCNA communication services (Figure 29). As would typically be expected, the mapping between functions and communication services is often uneventful since most communication services require most or all of the MCNA functions.