The MACC family of products currently supports Ethernet to and from ARINC-429 conversion. This paper discusses the necessary steps to turn the MACC into an ARINC-429 to ARINC-664 Part 7 (hereinafter: "ARINC-664P7") converter.
Review of ARINC-664 Part 7
First we should review the basic differences between standard Ethernet and ARINC-664P7.
Addressing
Ethernet addressing generally assigns a single source and destination MAC and IP address to each end point in a network. ARINC-664P7 assigns addresses based on content, similar to the labels in ARINC-429. Ethernet does support multicast addressing which is the basis for the ARINC-664P7 addressing mechanism. In ARINC-664P7 the MAC and IP destination addresses contain a 16 bit Virtual Link Identifier (VLID.)
Sequence Number
ARINC-664P7 adds an additional byte to each message that is not included in the IP and UDP message lengths that is incremented for each message transmitted to a particular VLID. The receiver checks this byte to make sure no messages have been lost between messages received.
Timing
ARINC-664P7 defines a mechanism for guaranteeing delivery of messages. It divides the total bandwidth on the network between the End Systems that share the network. Each type of data is assigned a Bandwidth Allocation Gap which limits the frequency with which that type of data can be sent.
Sampling vs. Queuing
Since ARINC-664P7 is designed for Avionics applications it recognizes that there are different types of data that need to be transmitted on aircraft. Sampling data is data sent periodically such as Altitude, Air Speed, and Longitude etc. Queuing data is similar to standard Ethernet data such as files. Data bases, videos, etc. There are several differences in the handling of each data type as, for example, Sampling data may be sent repeatedly without change whereas Queuing data should only be sent if new data is available.
Dual Redundancy
ARINC-664P7 transmits and receives on two busses simultaneously. The receiver looks at the data for whichever bus is received first – possibly by only a few nanoseconds – and if the data is error free the receiver will use it and ignore the data on the other bus. If the error contains an error, the receiver will check the other bus and, if the second busses data is correct, will use that data.
Tables used for a MACC ARINC-429 to ARINC-664P7 System
Let us assume that the MACC is being used to receive incoming 429 labels and retransmit them over an ARINC-664P7 bus to an End System such as a Multifunction Display Unit.
A table would be set up in which each ARINC-429 Label would be associated with an ARINC-664P7 packet. Multiple labels could be associated with the same ARINC-664P7 packet. As follows:
ARINC-429 to ARINC-664P7 table – 429 data extraction section
|
429 Label
|
Label type
|
Significant bits
|
Units
|
|
100
|
BNR
|
12 through 27
|
Feet
|
|
212
|
BNR
|
12 through 22
|
N.M
|
|
372
|
BCD
|
14 through 28
|
degrees
|
ARINC-429 to ARINC-664P7 table continued – ARINC-664P7 insertion section
|
664 Message ID
|
664 start byte
|
length
|
Data type
|
Units to convert to
|
|
1
|
0
|
4
|
binary
|
meters
|
|
1
|
4
|
2
|
binary
|
N.M
|
|
2
|
0
|
4
|
binary
|
SemiCircles
|
ARINC-664P7 Schedule Table
|
Message ID
|
VLID
|
Schedule type
|
milliseconds
|
|
1
|
123
|
On demand lbl 212
|
|
|
2
|
345
|
periodic
|
100
|
The ARINC-429 to ARINC-664P7 table is used to effect the translation of ARINC-429 data to ARINC-664P7 data. Each label is defined in terms of format and size of its data for both incoming 429 data and outgoing ARINC-664P7 data. Outgoing data is placed in separate messages where a single ARINC-664P7 message can contain data from several ARINC-429 labels. In the example, labels 100 and 212 are both placed in a single ARINC-664P7 message (Msg ID1) and label 372 is placed in a second ARINC-664P7 message (Msg ID2).
The second table determines when each ARINC-664P7 message is transmitted. Message 1 is transmitted whenever label 212 is received, Message 2 is transmitted every 100 milliseconds.
Please note that the tables are presented for explanatory purposes and fields not necessary for understanding the underlying concepts have been left out for clarity.
Implementation of a MACC within an ARINC-664P7 System
Let us look at the MACC’s capabilities in terms of the above differences.
Addressing
The VLID label in the ARINC-664P7 schedule Table contains an entry for the VLID. This is used to fill in the MAC and IP destination addresses of the transmitted packets. The remaining address data is filled in with the fixed values assigned in a separate configuration table described in the MACC User’s Manual.
Sequence Number
The MACC will internally maintain a sequence number for each Message ID and add it to the end of packet of that type sent. Each time a packet is sent the Sequence number will be incremented in accordance with the ARINC-664P7 specification.
Timing
The timing is handled by the schedule type field of the AFDX schedule Table. Scheduling is not so critical for this application since only a single ARINC-664P7 device is being transmitted to so there is no issue of overusing bandwidth.
Sampling vs. Queuing
The use of on demand scheduling is appropriate to Queuing data which will cuse an ARINC-664P7 packet to be sent only if a new label comes in. Periodic scheduling is appropriate for Sample data.
Dual Redundancy
The MACC only has a single Ethernet line so it cannot transmit with dual redundancy. If dual redundancy is an absolute requirement a new version of the MACC supporting two Ethernet busses will be necessary.
However, let us look at the situation from a system point of view.
ARINC-429 does not inherently support dual redundancy. Therefore a number of possibilities are available from a system standpoint
- We may have only a single 429 input.
- We may be dealing with two devices each of which sends the same data over a single 429 bus. One device will be connected to the MACC’s channel 0 429 port and the other to the MACC’s channel 1 429 port.
- We may be dealing with an ARINC-429 device that sends the same data over two ARINC-429 busses.
For the first possibility, there is little advantage to transmitting the ARINC-664P7 over a dual redundant bus. The system as a whole lacks dual redundancy so adding it to a small part of the system will not significantly improve safety. An ARINC-664P7 receiver is perfectly capable of working with only a single bus connected.
For the second possibility, the ideal solution would involve using a separate MACC for each device. This will remove a single point of failure (i.e., the MACC) from an otherwise completely dual redundant system.
For the third possibility, where redundancy is used only for the communication lines but not the devices, the MACC as currently implemented may not be the ideal solution. Two MACC's could be used for this configuration but that would add more redundancy and therefore cost than the system may need. Alternatively a single MACC could be used with a loss of dual redundancy on the ARINC-664P7 side of the system.
Conclusion
The MACC family of products as currently designed can handle most situations where a translator is needed to translate between ARINC-429 and ARINC-664P7 devices. Due to the specific environment in which a translator is used, many of the normal requirements for ARINC-664P7 are not relevant. The specific needs of a given program must be analyzed to see if the MACC is appropriate without modification; with minor firmware modifications; or would require a new hardware revision.