An Evaluation of Ethernet as Data Transport System in Avionics

INOM

EXAMENSARBETE TEKNIK, GRUNDNIVÅ, 15 HP

STOCKHOLM SVERIGE 2020 ,

An Evaluation of Ethernet as Data Transport System in Avionics

RICKARD DOVERFELT

KTH

SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP

Avionics

RICKARD DOVERFELT

Degree Programme in Information and Communication Technology Date: 7th October 2020

Supervisor: Markus Hidell Examiner: Peter Sjödin

School of Electrical Engineering and Computer Science Host company: ÅF Digital Solutions AB

Swedish title: En utvärdering av Ethernet som

datatransportssystem inom avionik

An Evaluation of Ethernet as Data Transport System in Avionics / En utvärdering av Ethernet som datatransportssystem inom avionik

© 2020 Rickard Doverfelt

Abstract

ÅF Digital Solutions AB are looking to replace their current legacy system for audio transmissions within aircrafts with a new system based on Ethernet.

They also want the system to be as closely matching the current Audio Integration System as possible as well as preferably using commercial off the shelf components. The issue evaluated in this thesis is whether it is feasible to port the legacy protocol over to an Ethernet based solution with as few modifications as possible, what performance requirements are present on the Ethernet solution as well as what remaining capacity is available in the network. Furthermore is ÅF Digital Solutions AB interested in what avionics related Ethernet based protocols and standards are already present on the market.

The work is conducted in two tracks - one track of experimental measurements and statistical analysis of the latency present in the proposed solutions and one track with a survey regarding the integration of the present Audio Integration System protocol into the propesed Ethernet based solutions. The study finds two standards present on the market: Avionics Full-Duplex Ethernet (AFDX) and Time-Triggered Ethernet (TTEthernet). Two prototype implementations are built, one implementing AFDX and one custom built upon Ethernet and UDP. The latency of these are measured and found to be largely similar at ideal conditions. Ethernet is found to be more flexible, whilst AFDX allow for interoperation with other manufacturers and TTEthernet facilitates strict timing requirements at the cost of specialised hardware. The bandwidth utilisation of AFDX at ideal conditions is found to be 0.980% per stream and for the Ethernet solution 0.979% per stream.

It is proposed that ÅF Digital Solutions AB pursue a custom Ethernet based solution unless they require interoperability on the same network with other manufacturers as a custom solution with full control over the network allows the largest flexibility in regards to timings and load. If interoperability is required is AFDX proposed instead as it is a standardised protocol and without the, for ÅF Digital Solutions AB, unnecessary overhead of TTEthernet.

Keywords

AFDX, Avionics, Bandwidth utilisation, Ethernet, Latency, Legacy systems

ii | Abstract

Sammanfattning

Åf Digital Solutions AB vill undersöka möjligheterna att byta sitt nuvarande legacysystem för kommunikation inom flygplan till ett Ethernet-baserat system.

Detta på ett sätt som håller implementationen så nära deras nuvarande Audio Integration System som möjligt. Problemet som undersöks är huruvida det är rimligt att flytta legacyprotokollet till Ethernet med så lite modifikationer som möjligt. Utöver detta vill ÅF Digital Solutions AB veta prestandakraven som blir på en Ethernet-lösning samt hur mycket resterande kapacitet som eventuellt finns kvar för framtida användning. Vidare vill de veta vilka standarder som redan finns på marknaden.

Arbetet genomförs genom två spår - ett med experimentella mätningar och statistisk analys och en med ett case-study av integrationen av Audio Integration System och Ethernet. Undersökningen finner två standarder på marknaden relaterat till avionik; Avionics Full-Duplex Ethernet (AFDX) samt Time-Triggered Ethernet (TTEthernet).

Två prototyper byggs, en baserad på AFDX och en baserad på UDP och Ethernet. Latencyn för dessa två mäts och finns vara snarlika vid deras respektive ideala scenarion. Ethernet finns vara mer flexibelt, AFDX mer

interoperabel och TTEthernet mer lämplig vid strikta tidskrav. Bandbreddsutnyttjandet för AFDX finns vara 0.980% vid ideala förhållanden och 0.979% för Ethernet

vid ideala förhållanden.

Det rekommenderas att ÅF Digital Solutions använder sig av en egenutformad Ethernetbaserad lösning om de inte har krav på interoperabilitet ty det ger mer flexibilietet gällande tidskrav, protokoll och dataflödet.

Nyckelord

AFDX, Avionik, Bandbreddsutyttjande, Ethernet, Latency, Legacysystem

iv | Sammanfattning

Acknowledgments

I would like to thank Alexander Pukhanov at AFRY for his supervision of this thesis work and his willingness to help and find information on how the present optical system works. I would also like to thank Kenneth Fornstål for providing ideas on how to measure the latency of the present optical system and help performing said measurements. AFRY should also have a thank you for letting me do this thesis and providing the documents, standards, materials and equipment that I needed.

Stockholm, October 2020

Rickard Doverfelt

vi | Acknowledgments

Contents

1 Introduction 1

1.1 Background . . . . 1

1.2 Problem . . . . 2

1.2.1 Original problem and definition . . . . 2

1.2.2 Scientific and engineering issues . . . . 2

1.3 Purpose . . . . 3

1.4 Goals . . . . 3

1.5 Work Structure . . . . 4

1.6 Delimitations . . . . 4

1.7 Structure of the Thesis . . . . 5

2 Background 7 2.1 Avionics and Aircraft Audio System and Equipment . . . . 7

2.1.1 Avionics and Aerospace Industry . . . . 7

2.1.2 European Technical Standard Order . . . . 8

2.1.3 Aircraft Audio System and Equipment . . . . 8

2.2 IEEE 802.3 Ethernet . . . . 9

2.2.1 Network Layer . . . . 11

2.2.2 Transport Layer . . . . 12

2.3 Current System at ÅFDS . . . . 12

2.4 Related Work . . . . 13

2.4.1 Airbus’ Ethernet Implementation AFDX . . . . 14

2.4.2 Time-Triggered Ethernet . . . . 15

2.5 Summary . . . . 15

3 Method 17 3.1 Survey Process . . . . 17

3.2 Prototype Development . . . . 18

viii | Contents

3.3 Experimental Design and

Planned Measurements . . . . 19

3.3.1 Test Environment . . . . 19

3.3.2 Hardware/Software . . . . 21

4 Prototype Design 23 4.1 Study of present solutions . . . . 23

4.1.1 ARINC 664p7 . . . . 23

4.1.2 AS6802 . . . . 23

4.2 System Design . . . . 24

4.2.1 AFDX Packet Structure . . . . 25

4.2.2 Ethernet Packet Structure . . . . 26

4.3 Implementation . . . . 27

4.3.1 Addressing Scheme . . . . 27

4.3.2 Hardware . . . . 28

4.3.3 Software . . . . 29

5 Results and Analysis 33 5.1 The Ethernet System . . . . 33

5.2 The AFDX Solution . . . . 36

5.3 AIS . . . . 40

5.4 Literature . . . . 40

5.4.1 Functional Aspects . . . . 41

5.5 Bandwidth utilisation . . . . 42

6 Discussion 45 6.1 AFDX and Ethernet . . . . 46

6.2 Stability of the AIS . . . . 47

6.3 TTEthernet . . . . 47

6.4 Comparison of Systems . . . . 48

6.5 Bandwidth Utilisation . . . . 49

7 Conclusions and Future work 51 7.1 Conclusions . . . . 51

7.2 Limitations . . . . 52

7.3 Future work . . . . 53

7.4 Reflections . . . . 53

References 55

List of Figures

2.1 Structure of MAC packet . . . . 10

2.2 Structure of IPv4 header [9] . . . . 11

2.3 Structure of UDP header [12] . . . . 12

2.4 Structure of a packet in AIS . . . . 13

3.1 Survey Process . . . . 18

3.2 Test setup, calibration . . . . 19

3.3 Test setup, latency . . . . 19

3.4 Visualisation of timestamp placement during send . . . . 20

3.5 Visualisation of timestamp placement during receive . . . . . 20

3.6 Structure of a log entry for both solutions . . . . 21

3.7 Test setup, latency (AIS) . . . . 22

4.1 Layout without central hub . . . . 24

4.2 Layout with central hub . . . . 25

4.3 Structure of an AFDX packet, based on [13] . . . . 26

4.4 Structure of AFDX Payload for AFDS’s data streams . . . . . 27

4.5 Structure of Multicast IP for AFDX . . . . 28

4.6 Structure of Unicast IP for AFDX . . . . 28

4.7 Structure of Multicast MAC for AFDX . . . . 28

4.8 Structure of Source MAC for AFDX . . . . 28

4.9 ÅFDS payload as struct . . . . 29

5.1 Ethernet Calibration . . . . 33

5.2 Ethernet Latency . . . . 34

5.3 Ethernet Latency (Compensated) . . . . 34

5.4 Ethernet Latency Distribution . . . . 35

5.5 AFDX Calibration . . . . 36

5.6 AFDX Latency (Crowded) . . . . 37

5.7 AFDX Latency (Compensated, Crowded) . . . . 37

x | LIST OF FIGURES

5.8 AFDX Latency Distribution (Crowded) . . . . 38

5.9 AFDX Latency (Ideal) . . . . 39

5.10 AFDX Latency (Compensated, Ideal) . . . . 39

5.11 AFDX Latency Distribution (Ideal) . . . . 40

6.1 Illustration of queue size over time (Crowded) . . . . 46

List of Tables

2.1 Diagram of layers in OSI model (based on figure 1 in [8]) with

examples of implementations . . . . 10

2.2 Diagram of approximate mapping for AIS into OSI . . . . 14

5.1 Comparison of Systems Found . . . . 41

5.2 Ethernet packet size (bytes) . . . . 42

5.3 AFDX packet size (bytes) . . . . 42

xii | LIST OF TABLES

List of acronyms and abbreviations

A/V Audio/Video

ADC Analog/Digital Converter AFDX Avionics Full Duplex Ethernet AIS Audio Integration System

ARINC Aeronautical Radio, Incorporated ASIC Application-Specific Integration Circuit BAG Bandwidth Allocation Gap

CAT-5e Category 5e CAT-6 Category 6

CDR Clock and Data Recovery COTS Commercial Off-The-Shelf CRC Cyclic Redundancy Check

CSMA/CD Carrier Sense Multiple Access with Collision Detection DAC Digital/Analog Converter

DEC Digital Equipment Corporation DUT Device Under Test

EASA European Union Aerospace Security Agency EC European Council

EP European Parliament ES End System

Ethernet IEEE 802.3 Ethernet

ETSO European Technical Standard Order

xiv | List of acronyms and abbreviations

ETSO-C139 ETSO-C139 Aircraft Audio System and Equipment EU European Union

FCC Federal Communications Commission FPGA Field-Programmable Gate Array GPIO General Purpose Input/Output HAL Hardware Abstraction Layer

IEEE Institute of Electrical and Electronics Engineers IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

LVDS Low-Voltage Differential Signaling MAC Media Access Control

MCU Microcontroller Unit NUCLEO NUCLEO-F767ZI OSI Open Systems Interconnection PAL Programmable Array Logic PCB Printed Circuit Board PCF Protocol Control Frames QoS Quality of Service

RAM Random Access Memory

RTCA Radio Technical Comission for Aeronautics RTOS Real-Time Operating System

SAE Society of Automobile Engineers

SDG Sustainable Development Goal STM ST Microelectronics

TCP Transport Control Protocol TFTP Trivial File Transfer Protocol TTEthernet Time-Triggered Ethernet UDP User Datagram Protocol

UN United Nations

VL Virtual Link

WWI First World War

WWII Second World War

ÅFDS ÅF Digital Solutions AB

xvi | List of acronyms and abbreviations

Chapter 1 Introduction

This chapter describes the specific problem that this thesis addresses, the context of the problem, the goals of this thesis project, and outlines the structure of the thesis.

1.1 Background

This thesis will evaluate a solution for replacing the present physical layer for intercom systems in aerospace with a system based on IEEE 802.3 Ethernet.

This will be performed by analysing the systems currently in use by AFRY, specifically their subsidiary ÅF Digital Solutions AB (ÅFDS). AFRY is a company specializing in consulting in engineering, either as embedded engineers or with design commissions and small scale production. ÅFDS is AFRYs subsidiary focused on development of embedded systems. They also offer small scale production and prototyping.

The system currently in use by ÅFDS, the Audio Integration System (AIS), is based on fibre-optics as the physical medium utilising a proprietary protocol on top of as the remaining layers in the Open Systems Interconnection (OSI) stack. This system has been in use since 2006, and is limited in bandwidth and expandability.

The Institute of Electrical and Electronics Engineers (IEEE) specified Ethernet in their standard IEEE 802.3 in June 1986. That version allowed for a theoretical maximum of 10 Mb/s whilst the current revision, released in June 2018, allow a theoretical maximum of 400 Gb/s. IEEE 802.3 Ethernet (Ethernet) is a switchable packet-based network with both half- and full- duplex operation.[1]

Ethernet was later, in the early 1990’s, adapted to fit for avionic use with the

2 | Introduction

Avionics Full Duplex Ethernet (AFDX) specification by Airbus. This allows communication between units using Ethernet and switches in a statistically deterministic manner. Time-Triggered Ethernet (TTEthernet) is an additional specification built on top of AFDX to allow time-triggered communication over Ethernet.

1.2 Problem

ÅFDS currently uses a legacy system, the AIS, for communication between radio and intercom units that is lacking in potential for extensions as well as being locked down to a specification only used by ÅFDS’s systems. Due to this is ÅFDS looking to find a replacement system using a more widely used standard; a system that allows for extensions and upgrades further down the road as well as backwards compatibility. Furthermore, is it preferable if the system uses Commercial Off-The-Shelf (COTS) parts as far as possible to minimize costs.

1.2.1 Original problem and definition

Is it feasible to replace the present AIS with a system based on Ethernet while still meeting the throughput and latency demands that the aviation environment necessitates? This while maintaining backwards compatibility with the current protocol used by the AIS. What are the limitations of a system based on Ethernet?

1.2.2 Scientific and engineering issues

This thesis evaluates whether it is possible to implement ÅFDS’s current protocol on top of Ethernet using COTS parts and how such an implementation could be designed. The amount of remaining bandwidth capacity in the network is also measured. This aids in evaluating what possibilities exist for future development. Remaining capacity refers to factors such as timeslots if a timeslotted approach is used and unused bandwidth.

Implementing the current protocol on top of Ethernet refers to allowing

the same dataflow as the AIS – allowing the same timing of packets, the same

distribution order and system. The structure of the data packets is to be as

closely the same as possible, potentially with some additional control fields if

necessary. The data fields, however, are a requirement and may not be left out.

Some flow control fields may be substituted or removed if required or already facilitated by Ethernet.

1.3 Purpose

The purpose of the thesis is to evaluate and develop a way to enable more efficient and economical physical layers for audio equipment in aerospace; to develop a system to replace present solutions in older systems already in place using standard components and open platforms. This will likely allow for a longer life-cycle for the equipment already present. At the same time as it enables development and expansion of with new equipment in already present systems, thus allowing for a more sustainable development and production of aircrafts.

The development of a system based on standardised components and standards is to the benefit of ÅFDS, thus also their customers, as they will likely be able to offer a less expensive system. It would also prolong the life of the systems already installed. This will in turn, as SAAB Aerospace AB and the Gripen project is one of their customers, allow for a prolonged life of the Swedish air force’s Gripen aircrafts and a lower cost for the public sector. The prolonged life is also to the benefit of the environment as it reduces the waste produced by the necessity for upgrades as time goes on.

The Swedish air force being one of the potential benefactors may provide an ethical issue as they are a military force. As the aircrafts may be used in combat is there a potential of enabling unethical behaviour in war zones as well as harm, lethal or not, to other humans.

From a sustainability aspect, the potential prolonged life of equipment from the added upgrade path from the new Ethernet-based system a potential positive outcome. The prolonged life decreases the need of replacing the whole audio equipment system, ÅFDS and the customer may just replace and upgrade parts of it.

1.4 Goals

The goal of this project is to evaluate the suitability of an Ethernet-based system to replace the current fibre-based version. This has been divided into the following two sub-goals:

1. Present a starting point for a Ethernet based system.

4 | Introduction

2. Evaluate the performance and find potential remaining capacity in the network; remaining capacity being the bandwidth available for other future usages.

Furthermore should the following deliverables be presented:

1. A test environment to set a basis for future system development.

2. Measurements of performance of the old and proposed systems.

3. A survey of available standards and solutions on the market.

1.5 Work Structure

The work is split up into four phases; an initial phase consisting of a study of relevant systems and standards already present on the market. The initial phase is followed by a prototype development phase. The development is based on the findings in the previous phase and results in a prototype system to use in further measurements. The development phase is followed by an experimental or measurements phase where four sets of measurements are performed. These measurements are then analysed and presented in the results. Finally are conclusions regarding the suitability of an Ethernet based solution for the use case presented by ÅFDS made.

The four sets of measurements performed are a measurement of latency in the Ethernet system, the AFDX system in an ideal scenario, the AFDX system in a crowded scenario and a measurement of latency in the AIS. Measuring the latency allows for checking the stability of the system along with its throughput. It will also show whether the timing requirements are met.

1.6 Delimitations

The study will not focus on the reliability of the network. Potential packet

loss is not something that will be measured and considered in this thesis even

though it is of great importance in the world of avionics. It is related to the

reliability of the system rather than the timings and throughput and thus outside

the scope of this thesis. Furthermore, the prototype will not be tested in a real

environment with real-world workloads as it is outside the scope of this study

and not a relevant test to do at this stage of development. The hardware will

also not be designed according to mechanical performance requirements that

is present in the world of avionics. Therefore will the hardware not be able to

withstand the stresses that is put on such hardware in an actual flight scenario.

1.7 Structure of the Thesis

Chapter 2 presents relevant background information about current standards and technologies used in aerospace industry. Chapter 3 presents the methodology and method used to solve the problem. Furthermore Chapter 4 presents the conduct of the development and research. Chapter 5 presents results from the measurements presented along with an analysis of the findings. Discussion regarding the findings and their potential effects is performed in Chapter 6.

Chapter 7 finally presents a conclusion of the findings in this thesis as well as

potential future work in the field.

6 | Introduction

Chapter 2 Background

This chapter provides a basic background to the area of avionics in section 2.1.

The Ethernet standard is introduced in section 2.2. Furthermore is the current system implemented by ÅFDS, AIS, described in section 2.3. Related work such as Airbus’ AFDX presented in section 2.4 together with other works.

Finally a summary is made in section 2.5.

2.1 Avionics and Aircraft Audio System and Equipment

This section presents a background on the origins of avionics and some of the standardising bodies in regards to the world of aerospace industry. Section 2.1.1 presents some of the historical background leading up to present day regulating bodies and section 2.1.2 presents the current regulatory body in the European Union (EU) and its regulation framework. Section 2.1.3 presents the regulation related to the work covered in this thesis.

2.1.1 Avionics and Aerospace Industry

Avionics is a combination of the words aviation and electronics and was

introduced somewhere around the 1950’s for military electronics. It has since

then become a word that loosely identify electronics in aviation. Avionics

begun with radio communications around the First World War (WWI) and was

closely followed by the introduction of radio navigation in the 1920’s. These

technologies were developed further through the Second World War (WWII)

and beyond until the present day to become the critical part of air flight that it

is today. [2]

8 | Background

Around 1910 was the first form of radio communication, wireless telegraphy, introduced as air to ground communication. These radios utilising a spark- gap transmitter were bulky and noisy, and were substantially improved when electron tubes came along, allowing for amplification. These tubes also paved way for a narrower carrier signal generating less interference. Further improvements to the signal was found by introducing shielding of cables, thus protecting against the noisy environment provided by the ignition system used by the engine. During the 1930’s was the basis of modern aviation intercom introduced by Bell Labs; a system that allowed internal communications within the air plane, two way plane-to-plane communication as well as receive radio-beacon signals and weather broadcasts. This definition begun the standardisation of equipment in aviation. [3]

The Aerospace Industry became more standardised during the 1920’s and 30’s with centralised standards organisations such as Federal Communications Commission (FCC), Aeronautical Radio, Incorporated (ARINC) and Radio Technical Comission for Aeronautics (RTCA). [3]

2.1.2 European Technical Standard Order

European Union Aerospace Security Agency (EASA) is the regulatory body responsible for compiling the regulation in the EU and the certification of manufacturers of aviation equipment. EASA was founded in 2018 by the European Parliament (EP) and European Council (EC) to oversee aviation and aerospace industry within the EU, as well as uphold regulation from the EP, among other goals stated in Regulation (EU) 2018/1139. [4]

The regulation for equipment manufacturers is defined as in the European Technical Standard Order (ETSO) documents. These documents specify the standards which all the different categories of equipments must adhere to.

The documents rarely define the standards themselves, but rather refer to international standards such as those published by RTCA. [5] The ETSO’s are based on the directives provided by Regulation (EU) 748/2012 [6].

2.1.3 Aircraft Audio System and Equipment

ETSO-C139 Aircraft Audio System and Equipment (ETSO-C139) outlines

the required standards compliance necessary in different areas of the audio

systems to be granted certification to use the equipment in aircrafts. The

standards on performance requirements are specified as following RTCA DO-

214A. Regarding other parts such as environment, software and electronic

hardware is specified as the general standards compliances defined in chapter 2, subpart A. [7]

Subpart A §2.1 specifies the environmental standards as RTCA DO-160D change 3. The software standards is specified in §2.2 as RTCA DO-178B. The standard specifies five different levels of software and the standard requires the specification of level or, if several are present in different parts, levels.

Furthermore is sufficient separation of parts with different levels required.

The hardware standards are specified in §2.3 as following RTCA DO-254.

This is required if the design contains Application-Specific Integration Circuit (ASIC) or complex logic devices such as Field-Programmable Gate Array (FPGA) or Programmable Array Logic (PAL). [5]

2.2 IEEE 802.3 Ethernet

Ethernet is a data-link layer protocol for networks initially published by IEEE in 1985. This initial version was half duplex and used Carrier Sense Multiple Access with Collision Detection (CSMA/CD) as its Media Access Control (MAC) protocol. This MAC protocol was instrumental for the development on an experimental first version of Ethernet at Xerox Palo Alto Research Center which allowed for a 2.94 Mb/s data rate. This was further developed together with Digital Equipment Corporation (DEC) and Intel into the 10 Mb/s Ethernet that was approved as an IEEE standard in 1983 and later, in 1985, published as IEEE Std 802.3-1985. This initial version is the basis of the present day Ethernet specification, although expanded. Full duplex MAC protocol is one such addition made in 1997. [1]

As MAC sits in the Data-link layer of the OSI model, seen in table 2.1, is it independent of the medium and can therefore sit on top of any physical media. The Ethernet standard does however also specify a physical layer as well with both optical and copper-based versions supporting different data rates up to 400 Gb/s. While this physical layer implementation differs between data rates and mediums is the MAC protocol consistent through all of them, and is still based on the same protocol that was used in the initial 10 Mb/s version published in 1985.

The MAC protocol utilises a packet as seen in figure 2.1. A MAC packet begin with a preamble to allow the endpoints to reach a steady-state synchronised with the timing of the received packet. After the first 7 bytes of preamble is the start field delimiter, consisting of the sequence 10101011, which mark that the following byte is the start of a MAC frame.

The frame begin with a 48-bit destination address, a MAC address, which

10 | Background

Application HTTP Presentation

Session

Transport TCP, UDP

Network IP

Data-link MAC

Physical Ethernet

Table 2.1: Diagram of layers in OSI model (based on figure 1 in [8]) with examples of implementations

0 7 8 15 16 23 24 31

Preamble

10101011 Dest. Address

Src. Address

Length / Type Data

hhhhhhhhh

hhhhhh

hhhhhh

hhhh hh hh hh hh hh hh hh hh hh hh hh hh h

Frame Check Seq.



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  Frame

Figure 2.1: Structure of MAC packet

identify the recipient of the frame. After that follows the source address, also

a MAC address, identifying who to respond to. The next field is a length

and type field which is 16-bit long. If the value of the field is less than or

equal to 0x05DC, 1500 decimal, then the field should be interpreted as the

length in bytes of the following data field. If the field is greater than or equal

to 0x0600, 1536 decimal, it should instead be interpreted as an Ethertype

which is specified in clause 2 of [1]. Following that is the data field which,

on a regular basic frame, has a maximum size of 1500 bytes. There are two

exceptions to the maximum size where the size may be 1504 and 1982 bytes long. These exceptions are Q-tagged frames at 1504 bytes and envelope frames at 1982 bytes. The minimum size of a MAC frame is 64 bytes which gives a minimum data field size of 46 bytes. If the data to be sent is less than 46 bytes is a pad field added to fill up 46 bytes of data field. The actual data size is presented in the length field of the frame to allow the recipient to know which portion of the data field that is actual data. The last field in the frame is a frame check sequence field consisting of a CRC32 checksum based on all the fields in the frame except the frame check sequence. [1]

2.2.1 Network Layer

0 7 8 15 16 23 24 31

Ver. IHL ToS Total Length

Identification Flags Fragment Offset Time to Live Protocol Header Checksum

Source Address Destination Address

Options

hhhhhh

hhhhhh

hhhhhh

hhhhhhh hh hh hh hh hh hh hh hh hh hh hh hh h

Padding

Figure 2.2: Structure of IPv4 header [9]

The two major protocols of the network layer of the OSI stack is Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). The network layer handles the routing of packets across a network, immediatly connected to the same switch or through routers to remote networks. IPv4 acheives that through the usage of IPv4-addresses which consists of four octets, 32 bits.

IPv4 also supports fragmetation of packets larger than the maximum frame length of the physical layer. See figure 2.2 for the layout of an IPv4 header. [9]

IPv6 is similar to IPv4 in functionality but uses and update 128-bit

addressing and a revised header structure. [10]

12 | Background

2.2.2 Transport Layer

The transport layer of the OSI stack control the data flow of the traffic. The two major transport layer protocols are Transport Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is a connection-based protocol, it set up a communication sequence where a connection is established before the data transfer is perfromed. This ensures that the recipient is live and ready to receive. TCP also, through its frequent handshaking, ensure that a packet is delivered to the recipient unless the number of retries is exceeded. It also handles flowrate limiting to ensure that the buffers of the receiving party is not exceeded nor the network infrastructure. [11]

0 7 8 15 16 23 24 31

Src Port Dest. Port

Length Checksum

Figure 2.3: Structure of UDP header [12]

UDP is in contrast to TCP a connection-less protocol and thus have no guarantees in regard to the recipient actually receiving the packets. UDP does not establish a connection before transmission nor does it specify any acknowledgement of reception thus having less overhead than TCP. UDP uses a simple 8 byte header to specify ports, packet length and an optional checksum, see figure 2.3 for layout. By being connection-less does UDP allow broad- and multi-cast transmission as no connection is required to be setup and thus no state regarding flow control and acknowledgements nor retransmissions. This is in contrast to TCP which does not support broad- nor multi-casts. [12] [11]

2.3 Current System at ÅFDS

The current system implementation at ÅFDS, the AIS, is based on a star-

topology network using optical fibre as medium. The physical interface

utilises a FPGA solution to handle the communication over the fibre link

via Low-Voltage Differential Signaling (LVDS) communication. The signals

on the Printed Circuit Board (PCB) are LVDS up to just before the optical

transmitter and receiver. The FPGA is connected to the rest of the system using

a 16-bit data and address bus. The bus utilises the External Memory Interface

of the Microcontroller Unit (MCU) in the connected system thus allowing for reading and writing of data.

The LVDS is used between the opto-electric parts and the FPGA and uses 2.5V signalling. As the data is encoded using 8b/10b is there no special timing requirements on the signal so long as the FPGA can derive and lock on to the clock embedded in the 8b/10b signal using its Clock and Data Recovery (CDR) function. The external signals is transmitted and received through an optical interface using a data rate of 120 Mb/s.

Sync Ch 0 Ch 1 Ch 2

hhhhhh

hhhhhhh hh hh hh hh hh hh h

Ch n CRC32

Figure 2.4: Structure of a packet in AIS

The link layer consists of a structure as seen in figure 2.4. The sync field is a K.28.5 sync-word, and the data in the channels is encoded with 8b/10b. Each channel has a size of 6 bytes and includes information on channel number, mode, audio samples and status of General Purpose Input/Output (GPIO) signals. A maximum of 192 channels are supported. The CRC32 field is a checksum of all the data in the packet. The hub in the star-topology broadcast all data to all units at a system frame sync interval of 96 µs, giving a frequency of ∼10.416 kHz.

Table 2.2 shows where in the OSI stack the different parts of the AIS would approximately fit in.

2.4 Related Work

In this section is some related works presented. In section 2.4.1 is Airbus’

implementation of Ethernet for avionics presented. After that is a solution for

14 | Background

Application Data in Channels Presentation

Session

Transport Channels

Network

Data-link K.28.5

Physical 8b/10b

Table 2.2: Diagram of approximate mapping for AIS into OSI

Audio/Video (A/V) streaming over Ethernet made by Society of Automobile Engineers (SAE) presented in section 2.4.2

2.4.1 Airbus’ Ethernet Implementation AFDX

AFDX is a layer 2 extension to Ethernet developed by Airbus for use in aircrafts for avionics. The extension is specified in ARINC 664 P7 [13]. Airbus saw a need for a digital communication network for avionics during the end of the 1990’s and turned towards Ethernet to satisfy that need. Ethernet was found to satisfy the need of bidirectional communication between units which could support complex protocols such as Trivial File Transfer Protocol (TFTP) and ARINC 615. Furthermore could Ethernet satisfy the need for openness and extensibility of the communication system. [14] [15]

The AFDX extension provides a deterministic network where each unit has free access to the network. The network is partitioned with the help of Virtual Link (VL) which is a channel of communication between two or more units providing a guaranteed latency, limited latency and jitter as well as static path through the network. [14]

Airbus began development of the AFDX standard due to their need of bidirectional communication, flexibility and wish to use open standards.

Furthermore was the available bandwidth of interest. The standards available

at the time, ARINC 429 and MIL-STD 1553, were both lacking in bandwidth

and ability to support more complex protocols such as TFTP. [14]

2.4.2 Time-Triggered Ethernet

TTEthernet is a QoS extension, published by SAE, for Ethernet layer 2 allowing for hard real-time applications of Ethernet. TTEthernet was developed to allow A/V data to be streamed through a AFDX network despite the sometimes high latency that comes as a consequence of the statistical approach to latency determination, as well as the uneven jitter. TTEthernet, as defined in SAE AS6802 [16], is designed to provide emulate a circuit switching behaviour on a packet switched network as Ethernet and thus enabling real time communication as if a dedicated serial wire connection was present between the end points. [15]

AFDX is, according to [15], not well suited on its own to handle A/V communication due to its asynchronicity and bandwidth trade-offs. TTEthernet is in contrast a synchronous system allowing for synchronisation of end systems, and optionally switches. Synchronising switches allows for scheduling of traffic thus assuring a fixed latency and jitter in the µs ranges. The communication is therefore deterministic allowing for distributed hard real- time function in a fault-tolerant environment. SAE AS6802 work with all bandwidths of of Ethernet from 10 Mb/s up to 10 Gb/s and higher, and with no regard to distance. As SAE AS6802 sit on top of the regular Ethernet specification is it able to co-exist with standard Ethernet traffic as well as other layer 2 extensions such as AFDX. The system time is based on a fault tolerant distributed clock synchronisation algorithm as specified in SAE AS6802. This algorithm mitigates the need for a central master-clock, ”wall-clock”, as the local clocks are used instead and regularly are synchronised via continuous adjustments. [16]

2.5 Summary

The field of avionics was born in the wake of WWI with the introduction of radio in aircrafts. During WWII were avionics further established as a central part of aviation with further advancements in radio communications.

As a result of the rise of avionics and aviation was several standards organs and regulatory bodies established to maintain interoperability and safety, one such organisation is the EASA which is responsible for regulation within the EU. The EASA regulation relevant to the audio equipment ÅFDS produces is ETSO-C139.

Ethernet was standardised in 1983 as 10Mb/s half duplex and has continued

development since and is now capable of 400Gb/s full duplex. It is based

16 | Background

around the MAC frame consisting of a pair of 6 byte addresses, a length and a Cyclic Redundancy Check (CRC) checksum. Along with the frame comes a specification of prelude and inter frame gap to ensure avoidance of collisions.

On top of Ethernet is IPv4 as a network protocol as well as TCP and UDP as transport protocols.

The AIS is the system currently used by ÅFDS. It is based on 8b/10b encoding of bytes sent over an optical interface. The data is structured as channels of 6 bytes and is followed by a CRC checksum.

Airbus developed AFDX as a replacement for the old ARINC 429 and MIL-STD 1553 standards to enable use of bidirectional communication. This enabled the implementation of more complex protocols such as TFTP. It is based around the concept of VLs and time-slotting to enforce a rate limit.

TTEthernet is an extension of AFDX and Ethernet that delivers time-triggered

transmission of packets within an Ethernet network which otherwise is event-

triggered. This to enable real-time data flows using a time synchronisation

protocol.

Chapter 3 Method

The purpose of this chapter is to provide an overview of the method used in this thesis. Section 3.1 describes the survey process. Section 3.2 describes the prototype development method. Section 3.3 describes the experimental design.

3.1 Survey Process

Figure 3.1 shows the steps conducted in order to carry out this study. The

investigation begin with a literature survey to find Ethernet based solutions

already present on the market and the standards associated. Documentation on

how the AIS is constructed is also compiled. This also allows for collection of

relevant standards and regulations which apply to the system in an aviation

scenario. The next step is to develop a prototype using the standards and

documentation collected in the previous step. This will result in a prototype

of the system suggested to ÅFDS which can be used in the following steps

for measurements. After the development of a prototype is the work split

into two tracks – one conducting experiments and statistical analysis and one

performing a case study. The experimental step is favoured and has more

emphasis, while the case study is secondary and is there to help concluding

whether the solution if an acceptable replacement of the AIS in regards to the

functional demands from ÅFDS. The final step is the conclusion of the results

where the raw and analysed data from the previous steps is compiled and put

into context producing an answer to the questions presented by ÅFDS.

18 | Method

Litterature Study

Develop Prototype

Experiments/

Measurements

Statistical Analysis

Case Study

Analysis of Study

Conclusion of Results

Figure 3.1: Survey Process

3.2 Prototype Development

A prototype is to be developed for measurements as well as a base for ÅFDS to develop further upon. This will be achieved by initially surveying Ethernet based solutions already available at the market. The AIS is also to be analysed.

These solutions and their protocols will either be used as inspiration or as a basis for the system developed. After this initial research is concluded is a proposed protocol layout presented which adapts the present protocol to Ethernet. The physical network layout is also developed and a proposed layout is presented.

Once the theoretical design of the solution is done is a physical

implementation of the solution to be constructed. That is a Ethernet interface,

a COTS switch as determined during the theoretical design as well as potential

control units needed; this using a processor evaluation board based on an ARM

processor. This prototype is then available for the measurements presented in

upcoming sections.

3.3 Experimental Design and Planned Measurements

To measure the latency is a random packet following the specification sent from a Device Under Test (DUT) and received at the same DUT. The time passed from the start of the transmission until the decoding the received packet is done is recorded.

3.3.1 Test Environment

Switch Hub

DUT 1

Oscilloscope Logger

Figure 3.2: Test setup, calibration

Switch Hub

DUT 1 Logger

Figure 3.3: Test setup, latency

To measure the latency of the Ethernet and AFDX solutions is a timestamp used. This timestamp is put as a uint32_t embedded in the ÅFDS packet structure.

This timestamp is calibrated using two test points on the NUCLEO-F767ZI

(NUCLEO), see figure 3.2 for setup. When the packet is sent is one test point

20 | Method

Create Packet Call Send Add Timestamp

Serialise AFDX/UDP

Figure 3.4: Visualisation of timestamp placement during send

AFDX/UDP Deserialise

Read Timestamp Handle Payload

Figure 3.5: Visualisation of timestamp placement during receive pulsed and when the response is received is the other pin pulsed. The delta between the pins is measured using an oscilloscope and compared to the delta calculated using the timestamp. The delta based on the timestamp is calculated using the timestamp recorded in the packet and the current timestamp using the formula ∆t = t

− t

. The timestamp is retrieved using the us_ticker from MbedOS on the NUCLEO. The calibration is performed by sending 10 single-fire packets where the delta of both the timestamp method and the oscilloscope is recorded. The difference of the deltas is plotted and the standard deviation is calculated. This gives a baseline for the accuracy of the timestamp method. The point in the execution where the timestamp is added to the packet and read can be seen in figure 3.4 and 3.5 respectively.

The timestamp method allows for more rapid logging of latencies and thus for tests using large number of packets in a rapid succession similar to the real- world scenario. The timestamps are logged via serial communication from the NUCLEO to a computer that records and save the logs for further processing in accordance to the calculations and analysis defined in each test.

The setup presented in Figure 3.3 is used to measure the latency of the

Ethernet soloution. DUT 1 transmits a packet with a random number of

channels in the range [0; 192]. The time delta is calculated and logged together

with the packet number, time of transmission and time of reception once the

P N ∆t t

t

Figure 3.6: Structure of a log entry for both solutions

last bit of the broadcast is received. See figure 3.6 for format. The test is to be run with 500 packets sent at 10 ms intervals.

The AFDX solutions latency, measurement A

is measured using the same setup as in measurement A

, see figure 3.3. The difference is the software used now utilises an AFDX based protocol rather than a base Ethernet as well as the tests being performed in two scenarios; one simulating a crowded situation and one in ideal conditions. The measurement is performed in the same manner as A

to ensure that comparison is possible in as close conditions as possible, that is 500 timestamped packets logged over serial and sent at 10 ms intervals. The logging is performed with a similar structure, as seen in figure 3.6. An interval of 10 ms is chosen so that the effect of the performance of the evaluation board is kept at a minimum. By having a larger interval between transmissions than the latency is the board allowed some margins to execute the overhead of a Real-Time Operating System (RTOS).

The correctness of the AFDX solution, that is whether the order of the packets is correct and all packets arrive, is measured by the packet number, P N in figure 3.6. The log entries are printed in the order the packets are received and thus is it possible to detect out of order packets. Furthermore is gaps in the packet number sequence detectable as dropped packets.

Finally is a reference made by measuring the latency in the AIS, measurement B, using a setup similar to that in figure 3.3 which is presented in figure 3.7.

The signal generator, Sig. Gen. in figure 3.7, outputs a sine wave of an audible frequency into both the input of DUT 1 and the oscilloscope. The oscilloscope is set to trigger on the 0-transition of the input sine wave. The output of DUT 1 is connected to another channel on the oscilloscope and the phase difference of the two waves is the latency from transmission to reception. This latency includes the system overhead stemming from the Analog/Digital Converter (ADC) and Digital/Analog Converter (DAC) and is therefore closer to the measurement made in A

and A

.

3.3.2 Hardware/Software

The hardware that will be used in the tests are an COTS switch, a processor

evaluation board, Category 5e (CAT-5e) or Category 6 (CAT-6) cables,

22 | Method

DUT 1 Hub

Oscilloscope Sig. Gen.

Figure 3.7: Test setup, latency (AIS)

ÅFDS’s current AIS units as well as oscilloscopes. Which switch is used will depend on what the development of the system prototype produces as the switch is a part of the system that is to be tested. The same goes for exact cabling, whether it is CAT-5e or CAT-6 depends on what the prototype development leads to. The processor development boards to be used is STM32 Nucleo-144 F767ZI to emulate the hardware present in the current units, as the new system should be implemented on as similar hardware as possible.

Furthermore will the hardware used in the AIS regarding transmission, the

optical network devices, be used as that allows for measurements of the current

system. In the test of the new system is a prototype implementation of the

protocols to be used, where the system is as similar as possible between

protocols to eliminate the effect of different software implementations. The

software will contain routines to pulse testpoints when needed. A computer

will be used to log the timestamps from the serial communication by the

device. The oscilloscope will be used to calibrate the data points, and thus

require no less than 10 µs resolution to be able to record the pulses present.

Chapter 4

Prototype Design

This chapter presents the construction of the prototypes and the protocols.

Section 4.1 describes the protocol standards used in the prototype design.

Section 4.2 describes the design of the protocol and network topology.

Section 4.3 describes the implementation of the protocols and construction of the prototypes.

4.1 Study of present solutions

An initial survey is performed to investigate already present solutions for Ethernet based solutions in aviation. This survey produced two relevant standards presently in use: ARINC 664p7 Avionics Full-Duplex Switched Ethernet Network [13], AFDX for short, and AS6802 Time-Triggered Ethernet [16], TTEthernet for short.

4.1.1 ARINC 664p7

AFDX allows the use of a COTS switch and is built on top of regular Ethernet as specified in IEEE 802.3, thus fulfilling the requirement of preferably using COTS parts [13]. It is also a standard used in many avionic systems at present and thus allows for integration into already present systems.

4.1.2 AS6802

TTEthernet AS6802 requires a specialized switch to enable the layer 2 Quality

of Service (QoS) functionality. It is a time-triggered implementation on top

of Ethernet, which otherwise is event-triggered. This allows for limitation of

24 | Prototype Design

latency and jitter for time-triggered traffic whilst also limiting the latency for rate-constrained traffic. The TTEthernet specification is rather complex and requires specialised hardware and is thus rejected for use as ÅFDS wants a system capable of running on a COTS switch.

4.2 System Design

AFDX is chosen for use in the prototype since it allows the use of COTS equipment. This leads to the next step of defining a network topology for the system as well as a packet structure based on the AFDX specification. Two layouts are suggested based one the use case presented by the AIS: one utilising a central hub as seen in figure 4.1 and one without such a hub as seen in figure 4.2. The hub in the first layout emulates the hub found in the original AIS.

The layout without a central hub simplifies the system in terms of number of devices and number of VLs required for operations. It does however make the synchronisation of messages harder since the End System (ES) would have to handle the synchronisation in a distributed manner. The ES would also need to be configured for every new ES added to the network to know their VL. This can be seen in figure 4.1 as the red and green arrows representing the two VL’s, where ES1 and ES2 are end systems capable of transmission. Since ES3 and ES4 does not have a VL configured for them are they not able to transmit messages, only receive. The red arrow shows the route for traffic originating in ES1 and the green traffic originating from ES2.

ES1

ES2 Switch ES4

ES3

Figure 4.1: Layout without central hub

Adding a central hub, as in figure 4.2, eliminates the need for every ES to know about all other ES. In this system, only the hub required to know about all ES while the ES only need to know about the hub. This does however require one more VL than the system without a central hub. This system is also somewhat more vulnerable as it has a single point of failure - the hub.

This does also add the need for an additional device in the network in the form

of a hub, which needs to be developed as a separate unit. The hub is a sort of special case of an ES and thus need a modified code base to handle the broadcasting of received messages.

The model used is the one shown in figure 4.2 with a central hub as it allows for easier implementation of the protocol and more flexible network layout. The flexibility stems from allowing ES to be added by just adding the VL associated with the new ES to the central hub. The other ES remain unaltered through this method.

ES1

ES2 Switch ES4

ES3

Hub

Figure 4.2: Layout with central hub

4.2.1 AFDX Packet Structure

The packet structure for an AFDX packet is presented in figure 4.3 [13]. This is the structure that ÅFDS’s new protocol is built upon as the AFDX Payload.

The packet is based on a MAC frame with a UDP for data encapsulation and IPv4 for addressing. The addition of a SN-byte as presented in figure 4.3 along with the modified addressing scheme for layer 2 MAC-addresses that AFDX specifies are what separates the AFDX-packet from a regular MAC-frame and UDP-packet. This sequence number allows for maintaining the internal order between packets from from a single source.

The AFDX Payload is presented in figure 4.4. This payload is based on

the data structure present in AIS with some minor modifications. The K.28.5

sync word that is present in the old system has been removed as well as the CRC

checksum. The CRC is removed as it would be redundant as it is present in

the MAC frame. The sync word is also not necessary as Ethernet has its own

way of determining the start of a packet using the preamble and a specified

key sequence. An addition made to the structure is the first 48 bits, or 6 bytes,

26 | Prototype Design

where the first byte is a length field specifying the amount of 6-byte channels actually present in the data. The remaining 5 bytes are reserved for future use and should be set to 0x00, thus allowing for expansion of the protocol. The payload shown in figure 4.4 has a maximum size of 1158 bytes and is thus able to fit inside a single UDP packet and MAC frame. [12] [1]

0 7 8 15 16 23 24 31 32 39 40 47

Preamble

10101011 Dest. Address

Dest. Address Src. Address

Src. Address 0x800

IP Header

UDP Header

AFDX Payload

hhhhhhhhhhhh

hhhhhh

hhhhhh

hhhhhh

hhhhhhh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh h

SN CRC

Figure 4.3: Structure of an AFDX packet, based on [13]

4.2.2 Ethernet Packet Structure

For the reference Ethernet implementation are regular UDP-packets used as

defined in RFC 768 [12]. The payload used for these packets is the same as

the one used in the AFDX version as seen in figure 4.4. The regular UDP

header is the same as the one used in the AFDX version, however without the

SN-byte at the end of the payload.

0 7 8 15 16 23 24 31 32 39 40 47

Length Reserved

Channel 1 .. .

hhhhhh

hhhhhh

hhhhhh

hhhhhh

hhhhhh

hhhhhhh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh hh h

Channel n

Figure 4.4: Structure of AFDX Payload for AFDS’s data streams

4.3 Implementation

This section presents the implementation of the AFDX system and the regular Ethernet system.

4.3.1 Addressing Scheme

The AFDX system uses a addressing scheme based on the addresses presented in section 3.2.5 and 3.4.1.4 in ARINC 664p7 [13]. The hub is given the IPv4-address 10.0.0.1 as its unicast address - this is as the hub is given the End System ID 1 as represented in figure 4.6. This address is used by other regular End Systems to address the hub when sending messages. The messages broadcasted from the hub to the End Systems uses the multicast IPv4-address 224.224.0.1 for the messages sent on VL 1 as seen in figure 4.5. The VL’s uses the multicast MAC address scheme, as defined in 3.2.5 in [13]. Therefore is the destination MAC address for messages from the hub 03:00:00:00:00:01 following the structure shown in figure 4.7. The source MAC address is following the addressing scheme found in figure 4.8.

The Net-field can hold either the value 0x20 or 0x40 and corresponds to

Network A and Network B in the redundancy mechanism in AFDX. For this

implementation is the redundancy not used, and therefore is the Net-field

always set to 0x20. The source address is therefore 02:00:00:00:01:20

28 | Prototype Design

for the hub as it has the End System ID of 1.

The regular Ethernet system uses the same IPv4 addressing scheme as the AFDX system. That is the addressing scheme shown in figure 4.5 and 4.6. The MAC addressing used is however following the same scheme as defined in the Ethernet specification [1] rather than the one shown in figure 4.7 and 4.7.

0 7 8 15 16 23 24 31

0xE0 0xE0 Virtual Link ID

Figure 4.5: Structure of Multicast IP for AFDX

0 7 8 15 16 23 24 31

0x0A End System ID

Figure 4.6: Structure of Unicast IP for AFDX

0 7 8 15 16 23 24 31 32 39 40 47

0x03 0x00 0x00 0x00 Virtual Link ID

Figure 4.7: Structure of Multicast MAC for AFDX

0 7 8 15 16 23 24 31 32 39 40 47

0x02 0x00 0x00 End System ID Net

Figure 4.8: Structure of Source MAC for AFDX

4.3.2 Hardware

The development board used is NUCLEO-F767ZI from ST Microelectronics

(STM). The NUCLEO is based on a STM32F767ZIT6U 32-bit ARM processor

running at up to 216 MHz. It has 2 MB of flash storage and 512 kB of

Random Access Memory (RAM). It also has an Ethernet interface capable

of 10BASE-T and 100BASE-T and a RJ45 connector. Furthermore does it

have a GPIO header allowing for the testpoints referred to in the method,

chapter 3. The NUCLEO is capable of running Mbed OS from ARM - a RTOS with a Hardware Abstraction Layer (HAL) allowing fast and easy prototyping of among others the Ethernet implementations tested in this prototype. The switch used is an D-Link DES-1005D, a 100Mbit/s capable full duplex commercially available switch.

Four NUCLEO devices are used for the Ethernet tests, both for AFDX and for the regular version, one used as the hub and one as an end system for both solutions. Furthermore is a COTS switch to be used for the tests.

4.3.3 Software

0 7 8 15 16 23 24 31 32 39 40 47

b0 b1 b2 b3 b4 b5

Channel

length resv0 resv1

Channel* channels

)

DataPacket

Figure 4.9: ÅFDS payload as struct

There are four configurations of the software: Ethernet ES, Ethernet Hub, AFDX ES and AFDX Hub. Some of the code is common between the systems, either across protocols or across Hub/ES, such as the ÅFDS packet structure and the (de)serialisation methods of said packets. The representation of ÅFDS’s packets can be seen in figure 4.9. To generate a timestamp is the methods provided by MbedOS to retrieve the current time since the start of the unit and scale it to µs.

Ethernet Solution

The Ethernet solution for ES is structured as a two-threaded process: one

thread for transmitting packets and one for receiving them. The receiving

thread, ES Listener, is a loop that continually call the recvPacket

method of the Ethernet interface and adding the timestamp data to a queue,

dpoints. The other thread, ES Transmitter, iterates through a for

loop 500 times. Each iteration begin with a 10 µs sleep before generating a

packet, adding some test data such as the packet number and the timestamp,

and then sending it to the Hub. Once the 500 iterations is done is the thread

sleeping for 1 s before iterating over the queue of timestamps, dpoints, that

30 | Prototype Design

the ES Listener thread produced. Each iteration prints the measurement data required to the serial line for that data point.

The Hub is simpler in its construction by just using one thread constantly listening for packets, padding them according to ÅFDS’s protocol, and echoing them out on the multicast address used for the Hub.

The system has two versions of a send call, one for broadcasts and one for unicasts. The broadcast is used by the Hub to send data to all ES while the unicast is used by an ES to send data to the Hub. These methods are the same apart from which parameters they add to the underlying send call with IPv4 addresses and some measurement data such as timestamp handling. The underlying send method creates a standard UDP packet according to RFC 768 [12], serialises the payload and add it as data to the UDP packet and transmits it using MbedOS’s own IPv4/Ethernet implementation.

AFDX Solution

The AFDX solution for ES is structured as two threads and one interrupt.

One of the threads, ES Transmitter, is responsible for transmitting the test packets in the same manner as the Ethernet solution. The difference is that the send method is that it pushes the packet to a send queue rather than immediately sending it. The other thread is AFDX Scheduler and is responsible for scheduling the transmission of packets according to the Bandwidth Allocation Gap (BAG) specified in ARINC 664p7 [13]. The BAG was calculated to be 16 ms. The scheduler pops the first packet in the queue every 16 ms, allocates a buffer for it and transmit it on the physical medium.

The reception of packets is handled by the interrupt which is called for every packet received by MbedOS. The interrupt, recvCb, is split into two parts;

the first part handling the parsing of the raw bytes into a packet and the other which handles the proper sequencing of packets and calling of callbacks for the packets.

The parsing begin with parsing of the 14 bytes long MAC header and a check on whether the type is 0x800; if not the packet is dropped. Next is the IPv4 header parsed and the protocol is checked to be 17, else the packet is dropped. After that is the UDP header parsed and the port number is checked to be 12345. Finally is the payload parsed and the SN stored for later use by the sequencing of the packet.

The second part, the sequencing, is performed using two lists: one for

counters and one for queues. If the packet received is the first for that VL is

the counter for that VL initialised with the SN of the received package. The

next step is to add the packet to the corresponding queue for that VL. After that is, if the SN is the next number expected, the packet and all following packets already in the queue handled. If SN = 0 is a reset procedure performed according to the specification in [13]. This reset is performed by setting the counter for that VL to 0, clearing the queue of remaining packets and handling the received packet.

The Hub uses the same receive interrupt as the ES as well as the same

AFDX Scheduler thread. It does however not have any transmission

thread, but rather a registered callback that handles broadcasting of received

packets in the same manner as the send method of the ES. In that sense is the

Hub interrupt driven rather than polled as the Ethernet implementation is.

32 | Prototype Design

Chapter 5

Results and Analysis

In this chapter, we present the results of the measurements and studies described in chapter 3. The chapter begin with the measurement data from the measurements of the systems followed by the findings from the literature study performed on present protocols and standards. Finally is a calculation on bandwidth utilisation performed.

5.1 The Ethernet System

Figure 5.1: Ethernet Calibration

34 | Results and Analysis

The calibration measure made for the Ethernet based solution is presented in figure 5.1 and shows a median time delta between the timestamp based delta and the testpoint measured delta of 169 µs. That is, the timestamp based measure shows a delta ≈169 µs higher than the actual delta.

Figure 5.2: Ethernet Latency

Figure 5.3: Ethernet Latency (Compensated)

Figure 5.2 shows the measured latency during test A

. The crosses are the absolute time deltas logged during the test and the Rolling Avg. (5) curve is a rolling average of the past 5 data points. The median delta is 853 µs with an upper quartile at 938 µs and a lower at 804 µs. Adjusted according to the calibration is the Median 670.5 µs.

Figure 5.4: Ethernet Latency Distribution

The distribution of the latencies measured in measure A

is shown in figure

5.4. This shows the occurence count in each band of 100 µs.

36 | Results and Analysis

5.2 The AFDX Solution

Figure 5.5: AFDX Calibration

The calibration made for the AFDX based solution is shown in figure 5.5 and

show a median time delta of 67 µs. That is the delta between the timestamp

based measurement and the testpoint based measurement. This gives that the

timestamp based measurement is ≈67 µs higher than the actual delta.

Figure 5.6: AFDX Latency (Crowded)

Figure 5.7: AFDX Latency (Compensated, Crowded)

Figure 5.6 presents the measured latencies in measurement A

for a

crowded scenario; that is with a BAG of 16 ms. The crosses are the absolute

time deltas from the log while Rolling Avg. (5) is the rolling average

of the past 5 data points. The median delta is 20 912 µs, 20 845 µs adjusted for