International Journal of Engineering Trends and Technology (IJETT) – Volume 21 Number 8 – March 2015
Data Transfer at Transmitter end of AVIONICS
System
N. Ravi Chandra1, K. Narendra2
1
M. Tech student, Embedded systems& Department of E I E & GITAM University, Visakhapatnam, Andhra Pradesh, INDIA
2
Asst. Professor & Department of E I E & GITAM University, Visakhapatnam, Andhra Pradesh, INDIA
Abstract— This paper deals with the transfer of data frames at
transmitter end system for AFDX (Avionics full duplex switched
Ethernet/ Avionics system). Usually the end system deals with the
traffic shaping and policing. The transmitter end system is
concentrate on scheduling of the data frames to eliminate the
traffic. The techniques used in this paper are jitter and round
robin scheduling algorithm. These new concepts improve the
security and quality of service of the transmitter end system and
capable of handling AFDX related protocols.
Keywords—AFDX Frame management, AFDX communication
ports, dual port ram (DPRAM), jitter, scheduler.
I. INTRODUCTION
An Avionics computer system connects to the AFDX
network through an End System. In general, an Avionics
computer system is capable of supporting multiple Avionics
subsystems. Partitions provide isolation between Avionics
subsystems within the same Avionics computer system. This
isolation is achieved by restricting the address space of each
partition and by placing limits on the amount of CPU time
allotted to each partition. The objective is to ensure that an
errant Avionics subsystem running in one partition will not
affect subsystems running in other partitions. Avionics
applications communicate with each other by sending
messages using communication ports. The specification of an
operating system API for writing portable avionics
applications can be found in ARINC 653. In particular,
ARINC 653 defines two types of communications ports –
sampling and queuing ports. Accordingly, it is necessary that
End Systems provide a suitable communications interface for
supporting sampling and queuing ports. The AFDX ports,
defined in ARINC 664, Part 7, include sampling, queuing and
SAP ports. The AFDX sampling and queuing ports
correspond to ARINC 653 sampling and queuing ports,
respectively. AFDX introduces a third port type called a
Service Access Point (SAP) port. SAP ports are used for
communications between AFDX system components and nonAFDX systems.
End Systems are identified using two 8-bit
quantities: a Network ID and an Equipment ID. These may be
combined into a single 16-bit quantity. As we shall see, the
End System identification is used in forming source MAC
addresses and unicast IP addresses.
DESIGN OVERVIEW
The entire design and development of the AFDX
network is done using XILINX software for signals of data
frames transmission. The design of the network is shown in
below figure. The block diagram for the system is as follows.
The data which is present in the CPU interface is
send to the scheduler which uses the concept of Jitter and
BAG and schedules the respective data in round robin
algorithm and then sends to the packetization module which
converts the data in to packets obtained from the scheduler
module. The data which sent to scheduler is stored in the
synchronous dual port RAM. After packetization the
respective packets is sent to the EMAC layers which check
with the data present in the DPRAM. All these transfer is done
using virtual links, these are very reliable and secure.
A. Dual Port RAM (DPRAM):
Synchronous dual-port RAM devices are memory devices
with clocked inputs and outputs for data, address, and control
functions. These SDPRAM’s provide simultaneous access to a
single static RAM memory location from two buses with full
synchronous operation on both ports.
DPRAM increases bandwidth (~2x SRAM)
ISSN: 2231-5381
http://www.ijettjournal.org
Page 388
International Journal of Engineering Trends and Technology (IJETT) – Volume 21 Number 8 – March 2015
DPRAM offers shorter time-to-market
DPRAM reduces design complexity
The sequence numbers are one octet long with a
range from 0 to 255 and are incremented on each
successive frame. After 255, the sequence number is
wrapped around to 1. The sequence number 0 is reserved
for communicating reset. In the default mode, each frame
is sent across both of the channels and the redundancy is
taken care at the receiving end-system.
Reliable frame delivery in the AFDX design is ensured by
utilizing redundant links. End-systems communicate over
multiple communication channels with the effect that
communication is protected against loss of one complete
network.
B. AFDX Communication ports:
Avionics subsystems use communications ports to send
messages to each other. Communication ports, which are
typically part of the operating system API, provide a
programming mechanism for sending and receiving messages.
Two types of communications ports play a role in Avionics
subsystems: sampling and queuing ports.
AFDX End Systems must provide both sampling and
queuing port services, as described in ARINC 653. Sampling
and queuing ports differ mainly in reception. A sampling port
has buffer storage for a single message; arriving messages
overwrite the message currently stored in the buffer. Reading
a message from a sampling port does not remove the message
from the buffer, and therefore it can be read repeatedly.
Each sampling port must provide an indication of the
freshness of the message contained in the port buffer. Without
this indication, it would be impossible to tell whether the
transmitting Avionics subsystem has stopped transmitting or
is repeatedly sending the same message. A queuing port has
sufficient storage for a fixed number of messages (a
configuration parameter), and new messages are appended to
the queue. Reading from a queuing port removes the message
from the queue (FIFO). Typical programming interfaces for
sending and receiving messages are as follows:
i) Send_Msg( port_ID, message)
ii) Recv_Msg( port_ID, message)
The port_ID identifies the communication port, and the
message argument points to a buffer that either contains the
message to be sent or is available to receive a new message
from the port.
D. Jitter:
Virtual Link scheduling consists of two components:
packet regulation and multiplexing. Below figure shows
the role of the Virtual Link Regulators in pacing the
frames from the virtual link queues to create zero-jitter
output streams. The Virtual Link Scheduler is also
responsible for multiplexing the regulator outputs into the
Redundancy Management Unit for replication and
transmission on the physical links.
The outputs of the Regulator consist of regulated streams of
Ethernet frames. Jitter is introduced when the Regulator
outputs are combined by the Virtual Link Scheduler MUX;
Ethernet frames arriving at input to the MUX at the same time
will experience queuing delay (jitter).
Preamble
C. AFDX Frame Management:
7
Start
Delimiter
Header
MAC
IP
Header
UDP
Header
AFDX
Payload
Seq.
Number
FCS
1
12
22
8
17-1471
1
4
A transmitting end-system prepares some data and
passes it to the communication protocol stack. Here, a
sequence number is added to each frame to enable the
receive function to reconstruct a single ordered stream of
frames without duplication before delivery to the receiving
partition.
ISSN: 2231-5381
http://www.ijettjournal.org
Page 389
International Journal of Engineering Trends and Technology (IJETT) – Volume 21 Number 8 – March 2015
E. Scheduler:
Each sending AFDX communication port is
associated with a virtual link. Messages sent to the
communication port are encapsulated within UDP, IP, and
Ethernet headers and placed in the appropriate virtual link
queue for transmission. The transmission of Ethernet
frames in a virtual link queue is scheduled by the End
System’s Virtual Link Scheduler.
The Virtual Link Scheduler is responsible for
scheduling transmissions of all the virtual links originating
with this End System. Figure 20 summarizes the Virtual
Link Scheduling scenario. The Virtual Link Scheduler is
responsible for ensuring that each virtual link conforms to
its assigned bandwidth limitation. Not only must the
Virtual Link Scheduler ensure the BAG and Lmax
limitations for each virtual link, but it is also responsible
for multiplexing all of the virtual link transmissions so that
the amount of jitter introduced by the multiplexing is
within acceptable bounds.
At the output of the scheduler, for a given Virtual
Link, frames can appear in a bounded time interval. This
interval is defined as the maximum admissible jitter. This
jitter is introduced by the scheduler and not by the traffic flow
itself. The End System should regulate transmitted data on a
per VL basis, since this Traffic Shaping Function (exact
knowledge of flow characteristics) is the basis of the
determinism analysis.
G. Waveforms:
The waveforms for dual port ram is
The timing of messages sent to an AFDX communications
port is controlled by the Avionics subsystems and
requirements of various attached devices. For example, a
sensor may be sending readings at a 10 Hz rate. Jitter may be
introduced if the message arrives at a non-empty virtual link
queue. Similarly, multiplexing all the virtual link queues into
the Redundancy Management Unit and subsequent
transmission on the physical links can introduce additional
jitter.
The waveforms for scheduler is
F. Scheduling:
In a transmitting end system with multiple VLs, the
Scheduler multiplexes the different flows coming from the
regulators.
ISSN: 2231-5381
http://www.ijettjournal.org
Page 390
International Journal of Engineering Trends and Technology (IJETT) – Volume 21 Number 8 – March 2015
E. SOFTWARE DESIGN
The program for this system is written by using the
VERILOG in XILINX software.
III. CONCLUSION AND FUTURE SCOPE
The Avionics network transfer data with high security,
reliable and without any collisions between the two data
packets. The reliability of the system increases, reducing the
total life costs and air borne system performance increases.
This technique is used for the communication in aircrafts and
railways; even in tough terrain conditions the data
communication takes place without loss of information. This
concept can be implemented in FPGA to improve the
reliability of system performance practically. As the speed of
Ethernet is high the speed of communication is high. Hence,
in real time systems this technique improves speed to transfer
the data.
REFERENCES
[1] K. Bisson & T. Troshynski, Switched Ethernet testing for
Avionics Applications
[2] K. Wang, S. Wang, J. Shi, Integrated reliability theory and
evaluation methodology of AFDX
[3] ―AFDX/ARINC 664 Protocol Tutorial‖, GE FANUC
Embedded Systems.
[4] Ian Land, Jeff Elliott, ―Architecting ARINC 664‖, Part 7
(AFDX) Solutions.
[5] ―ARINC Tutorial‖, Condor Engineering.
[6] ―AFDX /ARINC 664 Protocol Tutorials‖, TECHSAT
Germany.
[7] http://www.arinc.com
ISSN: 2231-5381
http://www.ijettjournal.org
Page 391