1、 AN DOCUMENT Prepared by AIRLINES ELECTRONIC ENGINEERING COMMITTEE Published by AERONAUTICAL RADIO, INC. 2551 RIVA ROAD, ANNAPOLIS, MARYLAND 21401-7435 AIRCRAFT DATA NETWORK PART 1 SYSTEMS CONCEPTS AND OVERVIEW ARINC SPECIFICATION 664P1-1 PUBLISHED: June 30, 2006 DISCLAIMER THIS DOCUMENT IS BASED ON
2、 MATERIAL SUBMITTED BY VARIOUS PARTICIPANTS DURING THE DRAFTING PROCESS. NEITHER AEEC NOR ARINC HAS MADE ANY DETERMINATION WHETHER THESE MATERIALS COULD BE SUBJECT TO VALID CLAIMS OF PATENT, COPYRIGHT OR OTHER PROPRIETARY RIGHTS BY THIRD PARTIES, AND NO REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED
3、, IS MADE IN THIS REGARD. AEEC USES REASONABLE EFFORTS TO DEVELOP AND MAINTAIN THESE DOCUMENTS. HOWEVER, NO CERTIFICATION OR WARRANTY IS MADE AS TO THE TECHNICAL ACCURACY OR SUFFICIENCY OF THE DOCUMENTS, THE ADEQUACY, MERCHANTABILITY, FITNESS FOR INTENDED PURPOSE OR SAFETY OF ANY PRODUCTS, COMPONENT
4、S, OR SYSTEMS DESIGNED, TESTED, RATED, INSTALLED OR OPERATED IN ACCORDANCE WITH ANY ASPECT OF THIS DOCUMENT OR THE ABSENCE OF RISK OR HAZARD ASSOCIATED WITH SUCH PRODUCTS, COMPONENTS, OR SYSTEMS. THE USER OF THIS DOCUMENT ACKNOWLEDGES THAT IT SHALL BE SOLELY RESPONSIBLE FOR ANY LOSS, CLAIM OR DAMAGE
5、 THAT IT MAY INCUR IN CONNECTION WITH ITS USE OF OR RELIANCE ON THIS DOCUMENT, AND SHALL HOLD ARINC, AEEC, AND ANY PARTY THAT PARTICIPATED IN THE DRAFTING OF THE DOCUMENT HARMLESS AGAINST ANY CLAIM ARISING FROM ITS USE OF THE STANDARD. THE USE IN THIS DOCUMENT OF ANY TERM, SUCH AS SHALL OR MUST, IS
6、NOT INTENDED TO AFFECT THE STATUS OF THIS DOCUMENT AS A VOLUNTARY STANDARD OR IN ANY WAY TO MODIFY THE ABOVE DISCLAIMER. NOTHING HEREIN SHALL BE DEEMED TO REQUIRE ANY PROVIDER OF EQUIPMENT TO INCORPORATE ANY ELEMENT OF THIS STANDARD IN ITS PRODUCT. HOWEVER, VENDORS WHICH REPRESENT THAT THEIR PRODUCT
7、S ARE COMPLIANT WITH THIS STANDARD SHALL BE DEEMED ALSO TO HAVE REPRESENTED THAT THEIR PRODUCTS CONTAIN OR CONFORM TO THE FEATURES THAT ARE DESCRIBED AS MUST OR SHALL IN THE STANDARD. ANY USE OF OR RELIANCE ON THIS DOCUMENT SHALL CONSTITUTE AN ACCEPTANCE THEREOF “AS IS” AND BE SUBJECT TO THIS DISCLA
8、IMER. 2006 BY AERONAUTICAL RADIO, INC. 2551 RIVA ROAD ANNAPOLIS, MARYLAND 21401-7435 USA Prepared by the Airlines Electronic Engineering Committee Specification 664P1 Adopted by the Airlines Electronic Engineering Committee October 24, 2001 Summary of Document Supplements Supplement Adoption Date Pu
9、blished Specification 664P1-1 April 4, 2006 June 30, 2006 A description of the changes introduced by each supplement is included on Goldenrod paper at the end of this document. ARINC SPECIFICATION 664P1 AIRCRAFT DATA NETWORK PART 1 SYSTEMS CONCEPTS AND OVERVIEW Published: June 30, 2006ii FOREWORD Ae
10、ronautical Radio, Inc., the AEEC, and ARINC Standards Aeronautical Radio, Inc. (ARINC) was incorporated in 1929 by four fledgling airlines in the United States as a privately-owned company dedicated to serving the communications needs of the air transport industry. Today, the major U.S. airlines rem
11、ain the Companys principal shareholders. Other shareholders include a number of non-U.S. airlines and other aircraft operators. ARINC sponsors aviation industry committees and participates in related industry activities that benefit aviation at large by providing technical leadership and guidance an
12、d frequency management. These activities directly support airline goals: promote safety, efficiency, regularity, and cost-effectiveness in aircraft operations. The Airlines Electronic Engineering Committee (AEEC) is an international body of airline technical professionals that leads the development
13、of technical standards for airborne electronic equipment-including avionics and in-flight entertainment equipment-used in commercial, military, and business aviation. The AEEC establishes consensus-based, voluntary form, fit, function, and interface standards that are published by ARINC and are know
14、n as ARINC Standards. The use of ARINC Standards results in substantial benefits to airlines by allowing avionics interchangeability and commonality and reducing avionics cost by promoting competition. There are three classes of ARINC Standards: a) ARINC Characteristics Define the form, fit, functio
15、n, and interfaces of avionics and other airline electronic equipment. ARINC Characteristics indicate to prospective manufacturers of airline electronic equipment the considered and coordinated opinion of the airline technical community concerning the requisites of new equipment including standardize
16、d physical and electrical characteristics to foster interchangeability and competition. b) ARINC Specifications Are principally used to define either the physical packaging or mounting of avionics equipment, data communication standards, or a high-level computer language. c) ARINC Reports Provide gu
17、idelines or general information found by the airlines to be good practices, often related to avionics maintenance and support. The release of an ARINC Standard does not obligate any airline or ARINC to purchase equipment so described, nor does it establish or indicate recognition or the existence of
18、 an operational requirement for such equipment, nor does it constitute endorsement of any manufacturers product designed or built to meet the ARINC Standard. In order to facilitate the continuous product improvement of this ARINC Standard, two items are included in the back of this volume: An Errata
19、 Report solicits any corrections to the text or diagrams in this ARINC Standard. An ARINC IA Project Initiation/Modification (APIM) form solicits any recommendations for addition of substantive material to this volume which would be the subject of a new Supplement. ARINC SPECIFICATION 664 PART 1 TAB
20、LE OF CONTENTS iii 1.0 INTRODUCTION .1 1.1 Purpose of this Document1 1.2 Scope 2 1.3 Aircraft Data Network Document Organization.3 1.3.1 Aircraft Data Network Original Parts3 1.3.2 Aircraft Data Network New Parts and Supplements of Original Parts 3 1.3.3 Part 1, Systems Concepts and Overview 4 1.4 R
21、elated Documents .4 1.4.1 Relationship of this Document to Other ARINC Standards 4 1.4.2 Relationship to Industry Standards4 1.4.3 RTCA and EUROCAE Documents4 1.4.4 IEEE and ANSI Documents.5 1.4.5 ISO and IEC Documents .5 1.5 Document Precedence 5 1.6 Regulatory Approval 5 2.0 INTRODUCTION TO NETWOR
22、K CONCEPTS6 2.1 Fundamental Concepts6 2.1.1 The OSI Reference Model.6 2.1.2 A Comparison of OSI Compliant and Internet-Based Data Networks 7 2.1.3 Network Topology .8 2.1.3.1 Logical Networks 8 2.1.3.2 Physical End System Networks 9 2.1.4 Switches and Routers .12 2.1.5 Information Flow through a Ref
23、erence Network.14 2.1.6 Address Mapping in a Compliant System17 2.1.7 Address Resolution in a Profiled Aircraft Data Network System 19 2.1.8 Protocol Layering and the Resulting Frame.20 2.2 Aircraft Domains and Related Concepts 21 3.0 INTRODUCTION TO NETWORK CONCEPTS24 3.1 Aircraft Data Network Type
24、s 24 3.1.1 Compliant and Profiled Networks 24 3.1.1.1 Compliant Network is Compliant with IEEE 802.3 and IETF 1122.24 3.1.1.2 Specification of a Compliant Network .25 3.1.2 Profiled Networks 25 3.1.2.1 Specification Principles.25 3.1.2.2 Conformance Statement.26 3.1.2.3 Profiled Network Features and
25、 Properties 26 ARINC SPECIFICATION 664 PART 1 TABLE OF CONTENTS iv 3.1.2.4 Profiled Network Parameters27 3.2 Network Type Selection.27 3.2.1 Compliant Network Specification 27 3.2.2 Profiled Network Specification 27 3.3 Interoperability Considerations.28 3.4 Interaction Between Networks .29 APPENDIC
26、ES A Network Performance and Concepts Tutorial 30 B Glossary and Acronyms List35 ARINC Standard Errata Report ARINC Industry Activities Project Initiation/Modification (APIM) ARINC SPECIFICATION 664 PART 1 Page 1 1.0 INTRODUCTION 1.1 Purpose of this Document ARINC Specification 664 has been develope
27、d in several parts and written with a view that commercially available Commercial Information Technology Standards can be applied to aviation with minimal changes. Further, where there are selections among the commercial standards or deviations for aviation requirements, there is provision to record
28、 and disclose those selections and deviations in the form of Protocol Implementation Conformance Statements (PICS) and Services Implementation Conformance Statements (SICS), PICS End Systems and Intermediate Systems. An End System is a device that serves as a source or receptor of data on a network.
29、 Technically, an End System has both user and network Applications that are instantiated above the network components, that is, layer 4 (Transport) or above. An Intermediate System is a device (or set of devices) which actually implements the network by allowing the packets or frames to take differe
30、nt paths through a network according to where they are intended to go. A fundamental concept of all networks is the notion of peer-to-peer communications. For example, layer 2 (L2) communicates with layer 2, layer 4 (L4) communicates with layer 4, and applications communicate with peer applications.
31、 This concept is fundamental to the OSIRM, where each layer understands the interfaces on either side, but has no knowledge of what is occurring in the other layers. From an application perspective, a User Protocol Data Unit is inserted into the “top” of the network into layer 4, transferred to the
32、destination End System, and then delivered to the destination Application by the peer layer 4 service. Figure 2.1.3-1 shows two End Systems communicating through an Intermediate System. The figure shows three types of Intermediate System. Intermediate System operating at layer 3 (Routers) are discus
33、sed later in detail in Part 5 of this specification. ARINC SPECIFICATION 664 PART 1 - Page 9 2.0 INTRODUCTION TO NETWORK CONCEPTS APPLICATIONSTRANSPORTNETWORKMACPHYAPPLICATIONSTRANSPORTNETWORKMACPHYPHY PHYNETWORKMAC MACPHY PHYMACPHYPHYREPEATER SWITCH ROUTER END SYSTEM INTERMEDIATE SYSTEMS END SYSTEM
34、 Figure 2.1.3-1 Peer-to-Peer Communications through Intermediate Systems Note: The arrows of the above diagram indicates logical peer-to-peer relationships of the OSI model and are not intended to imply a physical connection. In a peer-to-peer system, each layer of the network has its own address, a
35、llowing a peer to communicate with one or more peers. The addresses used for an Internet based network (as in the Aircraft Data Network) have the following addresses: Layer Address Name Size 4 Port 4 bytes (2 Source, 2 Destination) 3 IP (Internet Protocol) v4 8 bytes (4 Source, 4 Destination) 2 MAC
36、(Media Access Control) 12 bytes (6 Source, 6 Destination) 1 Not applicable The layer 2 Address allows selection of one or more physical End Systems. The layer 3 IP Address allows selection of one or more logical End Systems, and the layer 4 Port Addresses allows selection of one and only one attach
37、point into an application. An End System always has one or more IP and Port address assigned to it. An Intermediate System has either one or more MAC addresses, or one or more IP addresses assigned to it. COMMENTARY An Intermediate System may have End System functionality in it as well for the purpo
38、ses of management or maintenance. However these are secondary to the intended function of the Intermediate System and are transparent to the operation of the Intermediate System except in special circumstances. 2.1.3.2 Physical End System Networks Physically End Systems can be interconnected in thre
39、e basic ways: 1. Point-to-point 2. Common Bus ARINC SPECIFICATION 664 PART 1 - Page 10 2.0 INTRODUCTION TO NETWORK CONCEPTS 3. Hub and Spoke In a point-to-point interconnection scheme, each End System has a direct connection to all other End Systems. This is also referred to as “n-way.” In a common
40、bus interconnection, all End Systems are connected by means of one or more common buses. ARINC 429 and ARINC 629 are examples of avionics data buses. 10Base-2 and 10Base-5 are examples of IEEE 802.3 Ethernet. In a “Hub and Spoke” interconnection, all data flows through one or more common hubs. This
41、could also be considered a variant of the point-to-point interconnection scheme as all End Systems are connected point-to-point to a common hub. This is also called a Star topology. The “point-to-point” scheme is interface intensive, requiring network connections where (n-1)! is the number of End Sy
42、stems to be interconnected. On a common bus a common resource is managed so that only one transmitter can be enabled on the bus at any one time. That is, the common bus forms a common “collision domain” which is managed to minimize collisions. ARINC Specification 429 manages this by only allowing on
43、e transmitter to be connected to a bus. ARINC Specification 629 defines timing so that each transmitter can have the bus at a predefined time. IEEE Classic Ethernet uses Carrier Sense Multiple Access/Collision Detection to manage the common resource. Multiple transmitters listen to the bus when they
44、 have data to send. If the bus is quiet, then these transmitters can all start to transmit at the same time. Each transmitter monitors the bus and if a collision (multiple transmitters) condition is detected, then all the transmitters cease transmitting and start a random (but bounded) timer which p
45、revents them for transmitting until the timer expires. A hub (either layer 2 devices in Figure 2.1.3-1) can have multiple (but mutually exclusive) functions depending on the underlying technology. In Classic Ethernet (common bus) for example (10Base-2 and 10Base-5) the hub functions as a repeater (l
46、ayer 1 to layer 1), allowing a Ethernet system to extend beyond the physical limitations of a single segment. In a pure system, the hub acts as a repeater such that all information appears on all segments to all End Systems. Thus the term “Repeater Hub.” However, connecting multiple Ethernet segment
47、s into a single collision domain is inefficient. Consider two networks, each with multiple terminals. Between the networks is a Repeater Hub. This is shown in Figure 2.1.3-2. The Repeater Hub connects both Segment 1 and Segment 2 together into a single collision domain (common logical bus) so that e
48、ven if T11 wants to send a message to T12, it waits until the traffic between T22 and T23 is finished before it can transmit. A more efficient approach is that the Hub be aware of what traffic is on each segment and only move frames from one segment to another, if necessary. When this is implemented
49、 the Repeater Hub becomes a Bridge Hub and the two segments are logically separated into two collision domains by using the MAC address at Layer 2. This is shown in Figure 2.1.3-3 (and also in Figure 2.1.3-1). The use of a Bridge Hub provides an immediate improvement in apparent bandwidth. Within a single collision domain the apparent bandwidth is the line bandwidth divided by the number of End Systems connected to that collision domain. Assuming the network is implemented using a 10 Mbps medium, then with a Repeater Hub the apparent bandwidth is 10 Mbps or approxim
