ARINC-429 to ARINC-664P7

Excalibur Systems

The MACC 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

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 MACCs 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 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.

 

contact us
Your message was sent successfully
 
Home Login