Net2Plan-AFDX: An open-source tool for
optimization and performance evaluation of AFDX
networks
Laureano Fernandez-Olmos
Francesc Burrull, Pablo Pavon-Marino
Science and Applied Techniques Department
Spanish Air Force Officer Academy
San Javier, Spain
lferolm@ea.mde.es
Telecommunications Network Engineering Group
Technical University of Cartagena
Cartagena, Spain
{francesc.burrull, pablo.pavon}@upct.es
Abstract— In this paper we present the AFDX (Avionics FullDupleX switched Ethernet) extension for the open-source
networking tool Net2Plan [1][2]. The Net2Plan-AFDX extension
is also open-source, with no cost. This software will provide
integrators, researchers and students with a set of tools to
calculate, given an AFDX network design, an exhaustive set of
AFDX parameters and performance merits. Net2Plan-AFDX can
also be used for developing additional tools to evaluate and
research alternatives related to AFDX. The implemented AFDX
modules offer a Network Calculus and a Trajectory Approach
algorithms’ implementation for the theoretical worst-case delay
calculation, given a configuration table. It also implements a
simulation tool that produces realistic end-to-end latency values
expected in an operational environment, as well as other
performance merits. Avionics System Integrators can improve
their designs using the obtained results.
Keywords – AFDX, Net2Plan, Open-source Optimization, Java,
Avionics, Network Calculus
I.
INTRODUCTION
Standard ARINC 664 describes the Avionics Full Duplex
Switched Ethernet (AFDX)[3]. Modern aircraft, like Airbus
A400M and A350, use by design such networks. The main
reason for using an AFDX network instead of the traditional
full-wired solution is weight savings and increased network
capacity. The number of systems deployed in modern aircraft
would result in a large number of dedicated cables, thus an
important weight. The solution is a network, but this solution
has to provide certain guaranties of performance. AFDX
networks offer high capacity and easy reconfiguration. They
also provide easy extension of new Line Replaceable Units
(LRU) -adding new equipment-, resulting at the end in a
lighter infrastructure.
An AFDX network requires a strict certification, ensuring
a deterministic behavior. The certification requirements for
this technology are obtained using the Network Calculus [4]
model, although there are other techniques that offer valid
results for obtaining such requirements, like the so-called
Trajectory Approach [5]. The maximum delay, or worst-case
end-to-end latency, can be obtained using these models due to
the deterministic nature of the avionics network. Finding that
worst-case delay is a key certification requirement.
In this paper we present Net2Plan-AFDX, an open-source
tool developed as an extension of the open-source and free to
use network optimization software Net2Plan [1][2]. Similarly
to Net2Plan, Net2Plan-AFDX extension is shipped under the
LGPL (Lesser General Public License). Net2Plan is targeted
to practitioners, researchers and students interested in the
design and optimization of AFDX networks.
Net2Plan-AFDX permits modeling AFDX networks,
consisting of topologies interconnecting AFDX switches,
LRUs, and the definition of unicast and multicast Virtual
Links (VLs) carrying the traffic. This is stored in a network
object representing a full network design. Then, a common use
case in Avionics System Integrators is calculating the
parameters of the AFDX design. For this situation, Net2Plan is
able to calculate the per-VL performances, and generate
reports, data tables and draw graphics showing them. For
instance, Net2Plan-AFDX provides the calculation of the
worst-case end-to-end latencies in AFDX networks, thanks to
its implementation of a Network Calculus-based estimation
model, the model used for certification purposes, and through
an implementation of the Trajectory Approach model, which
tends to produce more accurate (less pessimistic) results.
Using these calculations e.g. an Avionics System Integrator
can adjust its configuration tables until obtaining the delay
values that pass certification requirements.
Net2Plan-AFDX can also assist the users in simulating the
behavior under realistic conditions of the AFDX designs
created. For instance, in this use case, given a configuration
table that would pass a certification (worst-case values within
required bounds), we are able to simulate the realistic
observed values that would arise once implemented into an
aircraft, under varying operation conditions. The Net2PlanAFDX tool can obtain such values through an event-driven
simulator. The simulation results provide the Avionics System
Integrators with a realistic view of their solutions, allowing
fine-tuning of their configuration tables. Naturally, theoretical
worst-case values are pessimistic respect to these observed
values. However, simulation results provide interesting
insights, like seeing how far the average values are from the
pessimistic bounds, and computing performance merits too
complex to be estimated from theoretical analysis.
The Net2Plan tool has been developed in the Java
programming language. The tool has been designed to be
extended, inheriting the modular capabilities of Net2Plan tool.
For instance, a researcher could add new worst-case
estimations, or add new performance merits to compute by
creating new Net2Plan algorithms and reports, using the
standard Net2Plan API [1]. To assist this process, Net2Plan
has an extensive documentation consisting of user guides, API
Javadoc, video-tutorials and examples. All together implies a
reduction of the learning curve time, and thus of operational
costs for an AFDX project.
In this paper, we present a case study example of a realistic
size, for a better understanding of the tool. From the topology
of an aircraft's network and a configuration table, a collection
of network designs are created to show the capabilities of the
Net2Plan-AFDX extension. LRUs and Switches are
represented by Nodes and Virtual Links by Demands.
Relevant design performances are calculated, like the latency,
jitter and feasibility of the configuration table bearing in mind
the link capacity, Virtual Link (VL) demands and integrator
constraints stated in the configuration table.
The rest of the paper is organized as follows. Section II
describes the offline network design tool for creating and
estimating performances of AFDX networks. Section III
illustrates the use of the simulation tool. Finally, Section IV
concludes the paper.
II.
switches, end systems, links and unicast or multicast virtual
links. These elements can be added to the tool in the graphical
user interface in a manual form. In addition, the tool can read
this information from a CSV file (Comma Separated Values, a
popular format for data representation). In this way a
configuration table can be easily adapted to be loaded into the
tool: The only task required is to adapt a CSV file to the
specific System Integrator format. After being loaded in
Net2Plan-AFDX, the design can be saved and loaded using
the regular Net2Plan XML-based format (.n2p extension).
Figure 1 shows the graphical user interface for the offline
network design module, in the use case used along this paper.
The chosen AFDX design is a relatively complex scenario to
illustrate the strengths of the software, in a realistic aircraft
network topology consisting of 8 switches and 74 LRUs. The
left panel of the user interface shows the network topology
(left side of Figure 1). Switches are interconnected as depicted
in the figure, and LRUs are connected to only one switch, so
every route has to cross at least one switch.
The logical plane of our AFDX scenario builds over the
network topology and is specified in a configuration table. It
consists of 445 VLs, These VLs can be classified into unicast
VLs and multicast VLs: 265 unicast and 178 multicast. Each
multicast VL has a certain number of LRU destinations.
The number of LRU destinations of the multicast VLs
varies between 2 and 70 LRUs. The maximum size of a VL
data packet is obtained assuming payload values between 1
and 200 bytes. Finally, the Bandwidth Allocation Gap (BAG),
according to ARINC 664 part 7 Standard, has been chosen
with a value of a power of 2. However, it is possible to use
any intermediate value of BAG if desired.
OFFLINE DESIGN OF AFDX NETWORKS
The Net2Plan-AFDX offline design tool permits the
creation of AFDX networks, by placing elements like
Figure 1: Switch connections
The information mentioned above can be easily observed
by visiting the tables in the right panel in Figure 1:
•
sequence of links traversed, the average carried traffic
(which should be the 100% of the traffic of the offered
Nodes table: These objects represent both the switches
and the LRUs. The specific AFDX values
characterizing the node are included in Net2PlanAFDX as so-called attributes. Attributes are just
arbitrary defined key-value associations, which can be
attached to Net2Plan nodes, and that Net2Plan-AFDX
uses to carry AFDX specific information of the
designs. Figure 2 shows an example.
Figure 4: Multicast trees table
demand traffic in valid designs), and some AFDXspecific information.
•
Figure 2: Nodes table
•
Links table: These objects represent the connection
between Switches and LRUs. No specific AFDX
attributes are attached to the links. Figure 3 shows an
Multicast trees table: While unicast demands are
carried through routes, multicast demands are carried
by means of multicast trees. A multicast tree defines
the tree of links traversed by the multicast VL traffic,
the average carried traffic (again, it should be the
100% of the multicast demand offered traffic in valid
designs), and some AFDX-specific information in the
form of key-value attributes. Naturally, the multicast
tree associated to a given multicast demand, is
initiated in the associated demand origin node, and
ends in its set of end nodes. Fig. 4 shows an example.
A. Validator
The validator is one of the first tools available for
assessing an AFDX design. The purpose of this tool is
checking that the network is fulfilling some basic fundamental
AFDX static design limits, with two parts:
•
First, the Validator ascertains that the introduced
configuration table is valid according to part 7 of the
ARINC 664 standard. This part of the standard
specifies limits and parameters of an AFDX network.
It is applied by default at the moment of loading the
configuration into Net2Plan. This static validation
warns about standard violations like e.g., exceeding
the maximum number on VLs on an Ethernet link.
These errors can be corrected adjusting the
configuration table.
•
After the static validation has been successfully
passed, the second objective is to make sure that the
implicit configuration parameters derived from the
Avionics System Integrator requirements are fulfilled.
Hence, there is a second runtime validation at the
moment of applying any of the theoretical network
calculation algorithms. This validation avoids
dynamic violations, e.g., exceeding the maximum
capacity of an Ethernet link. These errors can be
corrected reducing the number of VLs of the
overloaded link in the configuration table.
Figure 3: Links table
example.
•
Demands table: The Demands table stores the unicast
demand information. In Net2Plan-AFDX, a demand
is the intention to transmit a flow (unicast VL). It is
characterized by the demand end nodes, the average
offered traffic, and some AFDX specific parameters
stored as demand attributes.
•
Multicast demands table: This table stores the
information of the multicast demands, which are the
intention to transmit in the network a multicast VL.
The main parameters characterizing a multicast
demands are the origin node, the set of (one or more)
end nodes, and the offered traffic.
•
Routes table: While demands are the intention of
carrying traffic, a route is the actual form in which the
traffic is carried. A route is characterized mainly by
the associated demand it is carrying traffic of, the
Figure 5: Off-line tool
B. Worst-case latency estimation models
The Offline tool checks the static design parameters and
the theoretical parameters through the implementation of
different theoretical models: Network Calculus and
Trajectory Approach. These algorithms provide the
theoretical worst-case end-to-end latency scenario for each
VL.
In order to obtain the theoretical boundary values of the
latency of the AFDX network no simplifications have been
made. All the calculations take into account the maximum
packet size of each VL, the header size of the transport
protocol being used (UDP in all cases) and the Inter Frame
Gap (IFG) of 20 bytes.
1) The Network Calculus algorithm
The Network Calculus algorithm has been implemented
calculating the latency in each node assuming that all the
nodes use FIFO queues[6]. According to Network Calculus
a FIFO queue can be modeled by the boundaries of the
offered traffic and the carried traffic. Hence, in the case of
the arrival curve, the curve is modeled by the expression:
Figure 6 depicts the modeling of both curves.
The maximum latency and maximum queue size per
node can be obtained from these 2 curves. Maximum
latency corresponds to the biggest horizontal distance
between curves. Figure 7 denotes this distance as:
d = Τ + b/R
We can neglect the propagation time of each link, since
cabling distances in an aircraft are of the order of few tens
of meters. We can then obtain the latency of a VL by adding
the latency of each node traversed. To take into account the
IFG latency each packet size (except the one from the VL
under analysis) has been increased in 20 bytes.
γ = r·t + b
In the case of the service curve the expression is:
β = R [t − Τ]
Figure 7: Maximum latency per node.
This expression has been implemented into a Java class,
NCFunction. In order to obtain the latency with the
algorithm Network Calculus we call the method
getMaxDelayInMs(), wich returns the latency.
Figure 6. Model of the arrival and service curves.
2) The Trajectory Approach algorithm
The Trajectory Approach algorithm accounts all packets
that coexist in each node with the analyzed VL. Hence, a
VL will be delayed the amount of time associated to the
busy period of the packets with equal or more priority than
the analyzed VL. Using FIFO queues means that all packets
have the same priority and in this case the busy period
corresponds to the time needed for processing the packets of
the VL. This way, the worst-case corresponds to when the
node processes all the packets before the one from the VL
under analysis. The following pseudo-code in figure 8
illustrates the process.
Foreach (packetsPerLinks : hops) {
Foreach (lmax : packetsPerLinks) {
latency += 1000 * 8 * (UDPHeader + lmax +IFG)/linkCapacity;
}
hopNumber==0?latency+=LTx:latency+=LSw;
latencyInMs+=1000*8* (UDPHeaderBytes+VL_LMAX)/linkCapacity;
hopNumber ++;
}
latencyInMs+=LRx;
be synthetically created according to different statistical
models. The cycle of a packet is described below:
•
A packet arriving at the AFDX network is
considered not regulated until it traverses the I/O
interface of the Traffic Regulator, an artifact defined
in the AFDX standards. The Traffic Regulator
knows the output time of the last regulated packet,
t’. If the difference is less than the Bandwidth
Allocation Gap (BAG) of the VL the packet is
postponed for output at the instant t’+BAG. The
latency is calculated assuming that the arrival time
to the network is the Traffic Regulator output time.
•
Latency increases when a packet arrives to a switch
or an I/O port. The frame has to wait a certain time
depending on its VL corresponding output queue.
Other factor to consider is the technological latency
limits introduced by the standard ARINC 664.
When a packet arrives at a node we calculate the
time t in which it will reach the appropriate queue.
If this time is less than the next service time t' of the
corresponding VL output queue, the output time of
the packet will be increased to t' + ttx.
•
To simulate the packet through the whole network
we use an event for each time interval. All the
arrival times at each node are stored in an object
called Packet. Latency statistics are updated once
the packet reaches its destination node.
Figure 8: Pseudo-code Trajectory Approach max. delay
III. ON-LINE AFDX SIMULATION TOOL
The On-Line tool consists of an event-driven simulator
of an AFDX network design, previously loaded from a
configuration table. The simulator creates AFDX frames in
the design VLs, and tracks the path of the packets from their
input to their output end systems, and the time spent in the
different queues. The traffic generated in the simulation can
The following pseudo-code in figure 10 illustrates the
process.
Figure 9: AFDX Simulator GUI
if (!regulated){
RegulatorQueue.get(routeIndex).add(packet);
if (simTime < nextRegulatorServiceTime) {
timeLeavingRegulator = nextRegulatorServiceTime;
nextRegulatorServiceTime +=BAG;
}else{
timeLeavingRegulator = simTime;
nextRegulatorServiceTime = simTime + BAG;
}
// event for the packet leaving the regulator
// event for generation next packet of this VL
}else{
if (isTechnologyLatencyWaiting){
// event for the packet after Technology Latency Waiting
}else{
if (!destinationNode){
sendPacketThroughLink(simTime, packet, link);
}else{
// packet arrives destination, perform calculations
statsRoute.addValue(packetLatency);
}
Figure 10: Pseudo-code simulator max. delay
Since Net2Plan-AFDX stores the full information of the
delays of each packet in each traversed element, it is able to
compute a rich set of statistics from that, including e.g. the
maximum, minimum and average per-VL latency as well as
other statistical data that might be of interest.
A. Reports
Net2Plan-AFDX is able to produce a number of reports,
describing several aspects of an AFDX design. In short, a
report is a module that produces a web page, having an AFDX
design as an input.
One of the reports generated, visualizes information about
the loaded configuration table, its validation result and the
static values obtained from the NC and TA algorithms. It also
contains information about the occupation of all the elements
of the AFDX network. If any value exceeds the occupation
limits, it is shown in red.
The report functionality can be also used to display the results
of a simulation. In this case, the report will contain the results
of the simulation, that will be also compared to the theoretical
worst-case latency results of the implemented algorithms NC
and TA. The VLs are represented in two blocks: unicast block
and multicast block. The report is generated in HTML format
and can be exported to PDF. Figure 11 shows the different
parts contained in a report in the case study developed.
B. Graphics
The simulation results can be represented using graphics to
ease the data visualization. Fig. 12 illustrates an example for
our case study. The graphic contains the minimum, average
and maximum observed values in the simulation for each VL.
The worst-case theoretical values (for NC and TA) are plotted
in the same graph (blue and red lines in Fig. 12). VL latencies
are sorted to provide the analyst with a visual effect of the
variation of the simulated latency respect to the calculated
latency.
Figure 11: AFDX network configuration report
Figure 12: Graphical simulation result
IV.
CONCLUSIONS
In this paper, we present Net2Plan-AFDX extension, an
open-source and free to use tool for supporting the design of
AFDX networks. The tool permits estimating worst-case
end-to-end latencies from an AFDX network topology and
configuration table. This is provided by two
implementations: Network Calculus approach, and a
technique called Trajectory Approach. Net2Plan-AFDX tool
also provides a simulation environment to obtain the actual
operating values of an AFDX network under user-defined
operating conditions and compare them with the theoretical
worst-case values. A realistic case study has been created
and evaluated to show the strengths and merits of Net2PlanAFDX.
Net2Plan-AFDX is being used in an ongoing research,
consisting of the design of rerouting algorithms that
optimize the reconfiguration of an AFDX network during
short maintenance periods, and the design of AFDX
networks with improved failure tolerance.
ACKNOWLEDGMENT
This work was partially supported by the Spanish project
grant TEC2014-53071-C3-1-P (ONOFRE) and TEC201571932-REDT (ELASTIC).
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
http://www.net2plan.com
P. Pavon-Marino, J.L. Izquierdo-Zaragoza, “Net2Plan: An opensource network planning tool for bridging the gap between academia
and industry”, IEEE Networks Magazine, Vol. 29 (5), pp. 90-96,
Sept-Oct. 2015.
ARINCSpecification664:AircraftDataNetwork,Parts1,2,7Aeronoutica
l Radio Inc., Tech. Rep., 2002–2005.
J.-Y. Le Boudec and P. Thiran, Network Calculus: A Theory of
Deterministic Queuing Systems for the Internet. Online Version of the
Book Springer Verlag - LNCS 2050 Version April 26, 2012.
H. Bauer, J.-L. Scharbarg, and C. Fraboul, “Applying trajectory approach to AFDX avionics network,” in Proc. 14th Int. Conf.
Emerging Technol. Factory Autom., Mallorca, Sep. 2009, pp. 1– 8.
Steven Martin, Pascale Minet, “Schedulability analysis of flows
scheduled with FIFO: Application to the Expedited Forwarding
class”, 2006 IEEE