
Understanding ARINC 429 Data Bus in Avionics
Learn about ARINC 429, a common avionics data bus standard used in aviation electronics. Explore its physical standard, signaling methods, and framing structure. Discover how ARINC 429 facilitates communication between avionics systems in aircraft.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
14-760: ADVANCED REAL-WORLD NETWORKS AVIONICS DATA BUSES LECTURE 20 * SPRING 2020 * KESDEN
AERONAUTICAL RADIO, INC (ARINC) Aeronautical Services Company Standardization activities Commercial activities Publishes various standards But standards committees are, in some ways, separate from commercial activities
ARINC 429 Unless otherwise noted, slides based upon and using figures from: https://en.wikipedia.org/wiki/ARINC_429
ARINC 429: INTRODUCTION Developed in 1977 Common avionics data bus Avionics = Aviation electronics ARINC 429 defines a data bus for avionics Physical standard, including mechanical and electronic Link layer Data definitions
ARINC 429: MEDIUM 2-wire, twisted-pair One transmitter, Up to 20 receivers Star or bus topology
ARINC 429: SIGNALING Self-clocking Self-synchronizing Balanced differential signaling 12.5kbps or 100kbps
ARINC 429: BPRZ SIGNALLING Complementary Differential bipolar return-to-zero (BPRZ) Bipolar Two poles, +10 and -10 Differential Signal is driven between wires Return-to-zero Guaranteed transition between +10 and -10 or vice-versa Complementary 0 and 1 are mirror opposites
ARINC 429: BPRZ SIGNALING The signal has three states 'HI', 'NULL' and 'LOW' represented by the differential voltage between the two wires of the cable. A logical 1 is signaled by transmission of a +10 1V pulse followed by a 0 0.5V null period. A logical 0 is signaled by transmission of a 10 1V pulse also followed by a 0 0.5V null period. Slide credit: https://www.slideshare.net/yasir2761/avionics-buses-70416230
ARINC 429: FRAMING 32-bit frame is known as a word P SSM SDI Parity (odd parity is used) Sign/Status Matrix. Indicates the sign of a number or a status, depending upon word s Label Source Data Indicator. Indicates the source of the message or its destination, depending upon Label Only 2 bits = 4 identifiers (Not 20). Can represent subsystem vs station Label Some type of identifier associated with the message. Some are standard. Some are not. Thus some are interpreted the same way across aircraft, and some are not.
ARINC 429: DATA Binary Coded Decimal (BCD) SSM may also indicate the Sign (+/-) of the data or some information analogous to sign, like an orientation (North/South; East/West). When so indicating sign, the SSM is also considered to be indicating Normal Operation. Twos Compliment representation of signed binary numbers (BNR) Bit 29 represents the number's sign; that is, sign indication is delegated to Bit 29 in this case. Discrete data representation (e.g., bit-fields) The SSM has a different, signless encoding.
ARINC 429: SSM EXAMPLES Normal Operation (NO) - Functional Test (FT) - Failure Warning (FW) - No Computed Data (NCD) - Indicates that the data is missing or inaccurate for some reason other than a failure. For example, autopilot commands will show as NCD when the autopilot is not turned on Indicates the data in this word is considered to be correct data. Indicates that the data is being provided by a test source. Indicates a failure which causes the data to be suspect or missing.
ARINC 629 Sources: https://pdfs.semanticscholar.org/84c1/c4d2e6a975446585d88cb7e0455b112df584.pdf https://web.archive.org/web/20160123042337/http://nafi.yolasite.com/resources/ARINC %20429_629_FINAL.pdf https://www.maxt.com/mxf/arinc_629_spec.html
ARINC 629: INTRODUCTION Introduced in May 1995 Originally developed for Boeing 777 Now also used in Airbus 330 and Airbus 340 Designed as success for ARINC 429 But was never really intended for use beyond Boeing 777
ARCINC 629: KEY CHARACTERISTICS Bus topology Each bus is a redundant, dual bus ( hot standby ) Multiple independent (dual redundant) buses are possible in same aircraft Unshielded twisted pair Up to 100M long CSMA/CA, TDM Manchester encoding 2 Mbps 128 terminals
AFDX Unless otherwise noted, slides based upon and using figures from: https://www.xilinx.com/support/documentation/application_notes/xapp1130.pdf
AFDX: INTRODUCTION Avionics Full Duplex Switched Ethernet (AFDX) Introduced in 2005 Developed for Airbus 380 Variations used on other aircraft, including Boeing 787 Based upon Ethernet 802.3 protocols Citation: Multiple sources, other than or in addition to xilinc document
AFDX: KEY CONCEPTS Virtual Link Mimics single source, single drop or single source multi drop ARINC 424 connections Addressing and bandwidth requirements for each virtual link are defined in advance Known, predictable quality of service Switch hierarchy is known in advance, so switch delays and capacities are known in advance Virtual links have reserved bandwidth, so load isn t a question All routes, addresses, etc, are known in advance Latency, jitter, etc, can all be shaped and guaranteed
AFDX: REDUNDANCY The entire network is parallel, with data sent and received in parallel. Copies sent within 0.5ms of each other End system manages redundancy, ensures ordered delivery, etc Avionics system gets single copy of data in order
AFDX: TOPOLOGY AND ROUTING Up to 24 end systems per switch Switches can be cascaded No more than 4096 virtual links Remember these are one way Bidirectional requires one for transmit and one to receive Virtual links can be routed through switches All static based upon routing tables No routing protocol
AFDX: FRAME IEEE 802.3 compliant frame Notice Sequence Number (SN) in what otherwise would be payload Used to ensure ordering, detect missing etc Starts at 0, but wraps around 255->1 0 indicates a reset of the transmitting end system
AFDX: MAC SOURCE ADDRESS Note: Source address 32-bit Constant field Assigned by integrator Same for all devices in network 16-bit VL identifier
AFDX: MAC DESTINATION ADDRESS Note: MAC Destination Addresses 24-bit constant field, same as for source addresses 16-bit user defined identifier Controller identifier 3-bit interface identifier Identified which of two networks 001 for A, 010 for B Note: Two bit distances apart 5-bits of 0s
AFDX: VIRTUAL LINKS AT SWITCHES Emulate/Replace the point-to-point connections of ARINC 429 Assigned bandwidth is defined by system and enforced by switch Ports are shared, ports have quotas Each VL also has a maximum frame size Needed to ensure buffering capacity VLs are all predefined to ensure system has required capacity
AFDX: SUB VLS AT SWITCHES Each VL can have up to 4 sub-VLs Individual bandwidth guarantees aren t policed by switch Handled round-robin by switch IP layer has to reassemble fragmentation from round-robin Option by standard Standard does not define how sub-VLs are identified Possibly just by using VL identifiers
AFDX: VIRTUAL LINKS AT END SYSTEMS Each end system is responsible for sending and receiving data via VLs Maximum of 128 VLs per end system Can be any combination of send and receiver Each VL and sub-VL requires its own FIFO queue Sub-VL FIFO ques fill VL FIFO queue round-robin
AFDX: VIRTUAL LINKS AT END SYSTEMS Transmit responsibilities: Reading each VL queue. Incrementing the VL frame sequence number. Scheduling each frame for transmission to maintain the bandwidth guarantee within the allowed jitter. Transmitting redundant frames on both controllers A and B Receive responsibilities: Deleting redundant frames and policing ordinal integrity. Separating data by VL and writing received frames to the appropriate queue Pass one or both copies of redundant data, as configured
AFDX: BANDWIDTH CONTROL Each VL can transmit at an assigned interval, within an assigned gap A VL can transmit a frame within a bandwidth allocation gap Minimum interval between beginning of consecutive frames from a VL Frames can be longer, within limits Frames over predefined max length are dropped as errors If nothing to send, no need to send 1ms to 128 ms 2k, where k is from 1-7
AFDX: BANDWIDTH CONTROL Jitter is time padding at the beginning of the bandwidth allocation gap It allows the end system some time if juggling VLs Maximum jitter is limited in advance Up to 40ms due to transmission technology Plus more depending upon bandwidth of medium, to keep bounds proportional
ARDX: LATENCY LIMITS Less than 150 uS at an end system Switch less than 100uS
AFDX: REDUNDANCY MANAGEMNT End system checks integrity of each frame Checksum + expected sequence number based upon prior sequence number Discard and send error message on error Resets are important Sequence numbers are counted even for discarded frames Resets can force recovery 0 frame indicates reset Anything after 0 is a valid starting point When passed up, compared to make sure same (not just internally consistent as by MAC) One discarded, one sent along Frames with same sequence number Duplicates within skew amount of time Skew set according to topology, max 5ms Considered new frames with bogus sequence number after that
AFDX: FRAME FILTERING AT SWITCHES Special feature of AFDX switches vs Ethernet Verify: Frame size is within limits Integer number of bytes (alignment check) Checksum verified Incoming switch port VL is verified Desitination MAC reachable
AFDX: TRAFFIC POLICING AT SWITCHES After frame filtering discards invalid frames Discarded frames don t count against bandwidth Any frame in excess of VLs bandwidth quota is discarded Byte-based or frame-based policing Token bucket accounting
ASIDE: TOKEN BUCKET ALGORITHM A mechanism for enforcing bandwidth quotas The token bucket algorithm can be conceptually understood as follows: A token is added to the bucket every 1/r seconds. The bucket can hold at the most b tokens. If a token arrives when the bucket is full, it is discarded. When a packet (network layer PDU) of n bytes arrives, if at least n tokens are in the bucket, n tokens are removed from the bucket, and the packet is sent to the network. if fewer than n tokens are available, no tokens are removed from the bucket, and the packet is considered to be non-conformant. Algorithm description taken directly from: https://en.wikipedia.org/wiki/Token_bucket