EXAMENSARBETE INOM 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 An Evaluation of Ethernet as Data Transport System in 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 | i

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 | iii

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 | v

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 | vii

Contents

1 Introduction1 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 Background7 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 | ix

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 | xi

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 | xiii

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 List of acronyms and abbreviations | xv

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 Introduction | 1

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. Introduction | 3

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. Introduction | 5

1.7 Structure of the Thesis

Chapter2 presents relevant background information about current standards and technologies used in aerospace industry. Chapter3 presents the methodology and method used to solve the problem. Furthermore Chapter4 presents the conduct of the development and research. Chapter5 presents results from the measurements presented along with an analysis of the findings. Discussion regarding the findings and their potential effects is performed in Chapter6. Chapter7 finally presents a conclusion of the findings in this thesis as well as potential future work in the field. 6 | Introduction Background | 7

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 theEU, as well as uphold regulation from theEP, 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 Background | 9

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  hh Frame hhhh hhh hhh  hhh hhhh  hhhh hhh  hhh hhhh  hhhh hhh  hhh hh  hhhh  h  Frame Check Seq. 

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 Background | 11

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 hhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh h hhhh 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 Background | 13

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 h hhh hh hhhh hhhh hhh hhh hh hhhh 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] Background | 15

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 ofVLs 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. Method | 17

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/ Case Study Measurements

Statistical Analysis 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. Method | 19

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

Hub

Logger DUT 1 Switch

Oscilloscope

Figure 3.2: Test setup, calibration

Hub

Logger DUT 1 Switch

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

AFDX/UDP Serialise

Figure 3.4: Visualisation of timestamp placement during send

AFDX/UDP Deserialise

Handle Payload Read Timestamp

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 = tnow − tstamp. 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 Method | 21

PN ∆t tstamp tnow

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 A2 is measured using the same setup as in measurement A1, 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 A1 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, PN 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 A1 and A2.

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

Sig. Gen. DUT 1 Hub

Oscilloscope

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. Prototype Design | 23

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 ofVLs 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. TheES would also need to be configured for every newES added to the network to know theirVL. This can be seen in figure 4.1 as the red and green arrows representing the twoVL’s, where ES1 and ES2 are end systems capable of transmission. Since ES3 and ES4 does not have aVL 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 ES3

ES2 Switch ES4

Figure 4.1: Layout without central hub

Adding a central hub, as in figure 4.2, eliminates the need for everyES to know about all otherES. In this system, only the hub required to know about allES while theES only need to know about the hub. This does however require one moreVL 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 Prototype Design | 25

of a hub, which needs to be developed as a separate unit. The hub is a sort of special case of anES 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 allowingES to be added by just adding theVL associated with the newES to the central hub. The otherES remain unaltered through this method.

ES1 ES3

ES2 Switch ES4

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 hhhh h hhhh hhhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh h hhhh 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. Prototype Design | 27

0 7 8 15 16 23 24 31 32 39 40 47 Length Reserved Channel 1 . h . hhhh hh hhhh hhhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh hhh hhh hhhh hhhh hhh

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 onVL 1 as seen in figure 4.5. TheVL’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, Prototype Design | 29

chapter3. 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 DataPacket Channel* channels

Figure 4.9: ÅFDS payload as struct

There are four configurations of the software: EthernetES, Ethernet Hub, AFDXES 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 forES 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 allES while the unicast is used by anES 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 forES 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 thatVL is the counter for thatVL initialised with the SN of the received package. The Prototype Design | 31

next step is to add the packet to the corresponding queue for thatVL. 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 thatVL to 0, clearing the queue of remaining packets and handling the received packet. The Hub uses the same receive interrupt as theES 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 theES. In that sense is the Hub interrupt driven rather than polled as the Ethernet implementation is. 32 | Prototype Design Results and Analysis | 33

Chapter 5

Results and Analysis

In this chapter, we present the results of the measurements and studies described in chapter3. 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) Results and Analysis | 35

Figure 5.2 shows the measured latency during test A1. 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 A1 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. Results and Analysis | 37

Figure 5.6: AFDX Latency (Crowded)

Figure 5.7: AFDX Latency (Compensated, Crowded)

Figure 5.6 presents the measured latencies in measurement A2 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 38 | Results and Analysis

calibration as seen in figure 5.7. The compensated upper and lower quartile is 16 500.5 µs and 25 795 µs respectively.

Figure 5.8: AFDX Latency Distribution (Crowded)

The distribution of the latencies measured in measure A2, the crowded scenario, is shown in figure 5.8. This shows the occurrence count in each band of 1000 µs. Results and Analysis | 39

Figure 5.9: AFDX Latency (Ideal)

Figure 5.10: AFDX Latency (Compensated, Ideal)

Figure 5.9 presents the measured latencies in measurement A2 for an ideal scenario, that is with a BAG of 1 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 1031.5 µs, 964.5 µs adjusted for calibration 40 | Results and Analysis

as seen in figure 5.10. The compensated upper and lower quartile is 1050.5 µs and 908 µs respectively as shown in figure 5.10.

Figure 5.11: AFDX Latency Distribution (Ideal)

The distribution of the latencies measured in measure A2, the ideal scenario, is shown in figure 5.11. This shows the occurrence count in each band of 100 µs.

5.3 AIS

The old optical system, the AIS, was measured to have a round trip time of 1.42 ms. The system was found to have that round trip time with negligible fluctuations. The round trip time was measured since that allowed measurements without any modifications to the system to allow for internal measurements. Due to the broadcasting nature of this system is this equivalent to the time it would take from one end system to another.

5.4 Literature

The survey found two Ethernet based protocols for avionics: AFDX[13] and TTEthernet[16]. Furthermore was a basic Ethernet based protocol utilising UDP and IPv4 designed and used as a reference. Results and Analysis | 41

Table 5.1: Comparison of Systems Found

Name QoS Ratelimited Synchonised Time Packet order Ethernet None No No Not Guaranteed AFDX Optional Yes No Preserved TTEthernet Required Yes Yes Preserved

AFDX is timeslotted using BAG’s therefore guaranteeing a maximum rate of packets on aVL. The BAG must be in the range [1 : 128] where k tBAG = 2 ms and k ∈ [0; 7]. The bandwidth available for a BAG of 16 ms is Lmax 76812 bytes per second, 614496 bit/s, when Lmax = 1229 and BW = BAG . An Lmax of 1201 bytes is given from the maximum length of a payload from the AIS protocol, 6 + 192 ∗ 6 = 1158, together with the static overhead of MAC, IPv4, UDP and AFDX.A BAG of 1 ms as in the ideal scenario gives a bandwidth of 1201000 bytes per second, 9608000 bit/s. The maximum jitter allowed is determined by P −6 i∈VL0s (20 + Lmax) · 8 Jmax ≤ 40 · 10 + NBW

−6 and Jmax ≤ 500 · 10 . That results in a Jmax of 235 µs as

P (20 + 1201) · 8 40 · 10−6 + i∈1,2 = 235 · 10−6 100000000

5.4.1 Functional Aspects AFDX is usable both with a regular COTS Ethernet switch and a specialised switch with firmware capable of using the QoS part of AFDX. The usage of a specialised switch enables the usage of a larger part of the specification, especially the use of a network with more than one switch. [13] TTEthernet is also timeslotted as it is built upon ARINC 664p7 (AFDX). It is also time-triggered rather than event-triggered and thus allowing for real- time streams of data with reliable timings between packets. This while still allowing and supporting event-triggered packets in the network to support co-existence with other Ethernet traffic such as rate-constrained AFDX and regular Ethernet. It requires a specialised switch to perform the QoS functions of TTEthernet and facilitate the synchronisation scheme. The synchronisation 42 | Results and Analysis

Table 5.2: Ethernet packet size (bytes)

Part MAC IPv4 Header UDP Header Payload Sub. Tot Size 14 20 8 1158 1200 Part Prelude SFD CRC Frame Gap Total Size 7 1 4 12 1224

Table 5.3: AFDX packet size (bytes)

Part MAC IPv4 Header UDP Header Payload SN Sub. Tot Size 14 20 8 1158 1 1201 Part Prelude SFD CRC Frame Gap Total Size 7 1 4 12 1225

is based on so called Protocol Control Frames (PCF). They are similar to regular rate-constrained traffic such as the AFDX packets other than their priority being the highest. [16] The regular Ethernet based solution requires no QoS functions and is thus compatible with all COTS switches. It has no ratelimiting of packets and neither does it guarantee the ordering of packets. It does not guarantee that the packets arrive at all and has no way of knowing if a transmission has failed. The packets are sent on a best-effort basis. This is a consequence of UDP not including any flow-control [12] as the Ethernet specification [1] does not specify any flow-control mechanisms. IPv4[9] does not specify any as well as that is the responsibility of upper layers of the OSI stack if that functionality is needed. A comparison chart can be seen in table 5.1.

5.5 Bandwidth utilisation

The bandwidth utilisation for a single stream from an Ethernet system, where a stream is a single way communication, has a bandwidth utilisation following the below formula 1 BW = ∗ 1224 ∗ 8 tperiod Results and Analysis | 43

and 1 BW t ∗ 1224 ∗ 8 N = = period util 100000000 100000000 where Nutil is the utilisation in percent. The size of 1224 bytes is based on the sizes presented in table 5.2. The sizes are worst case where all channels are present in a payload. The above formulas give a utilisation of 0.979% per stream when tperiod = 10 ms The bandwidth utilisation for a single stream from an AFDX system has a bandwidth utilisation following the below formula 1 BW = ∗ 1225 ∗ 8 tperiod and 1 BW t ∗ 1225 ∗ 8 N = = period util 100000000 100000000 where Nutil is the utilisation in percent. The size of 1225 bytes is based on the sizes presented in table 5.3. The sizes are worst case where all channels are present in a payload. For the ideal scenario is the bandwidth utilisation 0.980% per stream when tperiod = 10 ms. That is, even though the BAG is 1 ms is a packet only sent every 10 ms. If the BAG would be used fully would the utilisation be 9.800% per stream. In the crowded scenario is the bandwidth utilisation at 0.613% per stream. The sizes found in table 5.2 and 5.3 are retrieved from the respective specifications: [1], [9], [12] and [13]. 44 | Results and Analysis Discussion | 45

Chapter 6

Discussion

In this chapter are the results analysed and discussed in relation to the problem formulation in chapter1. Section 6.1 compares the results of the measurements on the AFDX and Ethernet systems. Section 6.2 discuss the measurements of the AIS. Section 6.3 discusses the TTEthernet standard. In section 6.4 are the systems compared to each other with their pros and cons and finally in section 6.5 is the bandwidth utilisation discussed. 46 | Discussion

6.1 AFDX and Ethernet

Figure 6.1: Illustration of queue size over time (Crowded)

The AFDX solution shows a higher latency than the Ethernet solution, a consequence of the BAG specified in ARINC 664p7 [13]. The BAG does, however, allow for a more stable latency for the transmission of packets, that is, less jitter. The results show more jitter in the crowded AFDX solution than the Ethernet solution, but the tests were conducted in ideal conditions for the regular Ethernet solution; just one end system and one hub and no extra traffic. This gives ideal conditions for a UDP packet to arrive quickly and with little jitter. This while the conditions were not ideal for the AFDX solution as the packets were sent at a rate differing from the BAG, a packet produced and added to the scheduler every 10 ms while a packet was popped from the queue and sent every 16 ms. An illustration of the queue size over time while sending 20 packets with 10 ms intervals can be seen in Figure 6.1. This can be compared to the ideal scenario where a packet is still added to the send queue every 10 ms while a packet is popped from the queue every 1 ms. Thus is the latency lowered as well as the jitter. The jitter now present is ≈ 240 µs, if the occasional spikes of latency is disregarded. They appear as the worst case scenario is when a packet is added to the send queue just after one send period was performed, thus adding about 1 ms of latency, as well as the same situation happening at the hub thus adding another 1 ms totalling 2 ms. Discussion | 47

With a more crowded network would the latency and jitter of the Ethernet solution most likely deteriorate as the switch would have to handle more packets on a first come first serve basis. Furthermore were the measurements made without an AFDX enabled switch, something that AFDX supports, which may affect jitter in a unfavourable way as a regular COTS switch will handle AFDX traffic the same as all other Ethernet traffic. The BAG is chosen as 1 ms for the ideal scenario due to that being the lowest allowed value that can accommodate the bandwidth needed. The most optimal BAG, if the power of 2 limitation was not present, would be 12.29 µs. Lmax This is as, according to the formula found in section 5.4, BW = BAG =⇒ Lmax BAG = BW which, with Lmax = 1229 and BW = 100000000 gives a BAG of just 12.29 µs. The BAG of 16 ms was chosen for the crowded scenario as that simulates a situation where the bandwidth available for the solution is just 614412 bit/s, ≈ 0.6% of all bandwidth on a 100Mbit/s network.

6.2 Stability of the AIS

The old, optical, system is stable as it is timeslotted. Each end system has its turn to send and the hub has its cycles of when to send, thus having a constant interval between packets. Therefore is the latency constant as well as the jitter being very low, close to zero. The latency presented in the results are including the latency of the ADC and the DAC and thus somewhat larger than that of just the networking.

6.3 TTEthernet

TTEthernet is more complex and limited as it requires a specialised switch capable of handling the QoS that is specified by SAE AS6802 [16]. Furthermore is the complexity based on the synchronisation protocol that TTEthernet uses. This complexity and additional cost related to the specialised switch may be acceptable in certain scenarios where such precise timing is required. The traffic presented by ÅFDS do not require such precise timing nor does it meet the wish to use COTS equipment. 48 | Discussion

6.4 Comparison of Systems

Ethernet allows for flexibility of implementation as any protocol above the link layer in the OSI model could be specified and customised to the users liking. Most likely are already present solutions to be used such as IPv4 for adressing and TCP as an alternative to UDP. Not being locked in regard to timings is also a benefit as the user could design the timing requirements in accordance to the needs of the implementation. This would however require the user to own the network to control the load and ensure that no interference will appear. AFDX allows for interoperation on a single network with other equipment manufactures devices due to AFDX being a standard used for avionics in particular. It is also more resilient to disturbances from other traffic in the network since the traffic is partitioned into their respective BAGs. AFDX does however lock in the user to a specific protocol stack with IPv4 and UDP as well as timings of messages. Since AFDX does not allow a transmission rate faster than 1 kHz are implementations requiring higher sampling rates required to use buffers or other additional features to mitigate the rate limit. TTEthernet allows for precisely timed data transmissions with the same interoperability as AFDX except the need for a TTEthernet enabled switch. It is however more precisely specified than AFDX and thus more limiting in what the user may customise for their needs. Considering these points is a Ethernet solution more suitable for ÅFDS’s needs if they own the network due to the flexibility in regards to timings and flow-control. This allows for a more specialised solution with a more controlled environment thus easing the work of servicing and debugging the systems, as well as keeping the costs down. If they, however, would have to share the network with other manufacturers is AFDX still possible to use, while potentially adding extra complexity to circumvent some of the limitations presented by the rate limiting. The fastest available BAG of 1 ms will still require significant modifications to the AIS as the sample rate of 11 kHz require a transmission rate of 100 µs. Some alterations of the AIS will most likely be needed for a custom Ethernet solution as well, but will likely be be smaller in size and number as the Ethernet protocol may be modified to suit the use case to a certain extent. Discussion | 49

6.5 Bandwidth Utilisation

The bandwidth utilisation of both the regular Ethernet solution and the AFDX solution are very similar since the maximum packet size only differs by one byte. Thus is it not necessary to consider bandwidth utilisation when choosing between Ethernet and AFDX. The minimal utilisation would however be the double that of one stream since at least one end system and a hub is required. Therefore would the utilisation approximately follow the formula Nutil ∝ |E| + 1 where E = {The set of End Systems}. In the case of having a period between packets of 1 ms is the utilisation ≈ 0.98(|E| + 1) percent and thus, with a network of 10ES, a utilisation of ≈ 10.78%. That results in a remaining capacity of ≈ 89.22% for other network traffic. Not all of that remaining capacity is likely usable as some margin for unforeseen spikes of interference would be useful. 50 | Discussion Conclusions and Future work | 51

Chapter 7

Conclusions and Future work

This chapter concludes the findings of this thesis. In section 7.1 is the conclusions of the findings in this study presented along with a proposed course of development for ÅFDS. Section 7.2 discusses some of the limitations of this thesis and its findings. In section 7.3 is some suggestions for future work in this area discussed. Finally in section 7.4 is the environmental and economical issues and effects of the findings in this thesis reflected on.

7.1 Conclusions

This thesis presents two starting points for an Ethernet based system, one based on the AFDX standard and the other upon regular Ethernet using UDP. Furthermore is the performance of the solutions measured and their remaining capacity calculated. The results are evaluated from the perspective of the needs of a company in the avionics industry such as ÅFDS. A test and evaluation environment is delivered for further testing and development by ÅFDS. A survey of the present standards and technologies regarding Ethernet implementations for avionics is also presented in the thesis along with raw measurements of performance. The thesis finds that Ethernet based solutions work with the legacy AIS protocol presented by ÅFDS and data streaming protocols similar to that. It furthermore finds that AFDX and regular Ethernet using UDP have an mostly equivalent performance at their respective ideal conditions. AFDX have strengths in regard to interoperability with other manufacturers and sharing of network infrastructure whilst having weaknesses regarding the flexibility of the protocol and the availability of different timings of packets. This as Ethernet has strengths in regard to flexibility in implementation as it has no 52 | Conclusions and Future work

restrictions on the transport layer nor on the timings other than the limitations of the medium and bandwidth supported by the infrastructure. It does however have some weaknesses due to not having a specification on cooperation of different traffic whist still guaranteeing the latency and jitter. Thus is it recommended to only use the Ethernet solution if the infrastructure is non- shared. TTEthernet has strengths when strict timings are needed but come with a large overhead in the form of a synchronisation protocol along with the requirement of specialised switch hardware. For ÅFDS is it proposed that they proceed with a custom Ethernet based system to minimise the overhead of adapting to the timing restrictions of AFDX. Some adaptations will still be necessary due to the switched nature of Ethernet, but the packet interval can be faster than the 1 ms interval supported by AFDX. It is also more future proof as it allows the use of infrastructure constructed for bandwidths higher than the 100 Mbit/s supported by AFDX. It is suggested that someone interested in porting their legacy system to an Ethernet based system consider what requirements the system has in regard to timings and protocol shaping. Furthermore is the question regarding interoperability needing an answer - if it is required then AFDX or TTEthernet is recommended. TTEthernet is only recommended if the timing requirements require the strictness of TTEthernet as it comes with a large overhead. If full control over the shaping of the protocol or more fine grained timings than AFDX permits are needed is a custom Ethernet based solution recommended instead. If this thesis was to be redone would an actual crowded test be made where additional dummy devices generating dummy traffic be used to emulate the load seen in an actual usage scenario and thus showing the impact it has on the jitter on the tested systems.

7.2 Limitations

One limitation of this thesis is the lack of an AFDX switch to run tests on for the AFDX solution. To be able to see the differences in running AFDX on a regular COTS switch and on an AFDX capable switch would have given further data on the performance of AFDX and insights on the cost to utility ratio on such a device. Furthermore is the thesis limited in its lack of measurements on the performance impact of the Ethernet and AFDX handling routines. This is not measured since the code was never optimised for performance, it is optimised for speed of development. Thus would any measurements of the Conclusions and Future work | 53

processor time spent on handling the traffic not be a fair comparison between the solutions nor a usable pointer on which solution is the more performant. The prototypes constructed are not verified to be built to the standard specified by ETSO-C139. That is the RTCA DO-178B which specifies grades of separation required between different parts of software and a grading of each part.

7.3 Future work

There are a few aspects of the thesis that leave openings for future work; one is the need to perform measurements of crowded networks. That is networks where there is more traffic present than just the one that is to be measured to find the effect that has on the reliability and performance of the solution. Another aspect is to construct an optimised implementation of each protocol regarding encoding and decoding and measure the performance from a processor time perspective. This to enable the selection of protocol based on hardware performance requirements. Furthermore would measurements performed while transmitting the data that would be used in an actual usage scenario at the required rate be a useful metric to find if the suggested protocol would work in a real world scenario. This would also be interesting in combination with the previous processor measurement to see if the solution as a whole can handle its other responsibilities added by the encoding and decoding of the sound samples. The most interesting one would, however, likely be to perform experimental measurements of a TTEthernet implementation in the same manner as the Ethernet and AFDX implementations in this thesis. This would enable a, not only theoretical but, statistical comparison of the solution against the other two.

7.4 Reflections

By enabling the use of a more open standard and physical network is the life time of the system prolonged as upgrades are possible without replacing the whole system. Additions can be easily made to older aircrafts by connecting them to the switch and use the pre-existing infrastructure once the Ethernet system is in place. The added capacity and the high remaining capacity of an Ethernet based system allows for future additions and upgrades without needing a complete rebuild or replacement of the installed systems, which 54 | Conclusions and Future work

could incentivise customers to upgrade existing aircrafts rather than replace when new equipment is needed. All this works in favour of the United Nations (UN) Sustainable Development Goal (SDG) 12 regarding responsible consumption and production. Especially target 12.5 is affected regarding substantially reducing waste generation [17]. The upgrade path introduced with an Ethernet based system also allows for cost reduction for customers and for the manufacturer as the system does not need replacing to upgrade functionality. Furthermore does an Ethernet based solution allow for cost reduction as a consequence of using COTS parts. The availability of parts for long support, production and repairs is also benefiting from the nature of COTS parts wide availability. REFERENCES | 55

References

[1] IEEE Standard for Ethernet (802.3-2018), eng. New York, USA: IEEE, 2018, pp. 1–5600, isbn: 9781504450904. [2] R. Schroer, “Introduction [a century of powered flight:1903-2003]”, IEEE Aerospace and Electronic Systems Magazine, vol. 18, no. 7, pp. 5–12, 2003. [3] ——, “Aviation radio [a century of powered flight 1903-2003]”, IEEE Aerospace and Electronic Systems Magazine, vol. 18, no. 7, pp. 19–26, 2003. [4] “Regulation (EU) 2018/1139”, Official Journal of the European Union, vol. 61, no. L 212, issn: 1977-0677. [5] EASA eRules, “Easy Access Rules for European Technical Standard Orders (CS-ETSO) (Amendment 6)”, en, European Union Aviation Safety Agency, Cologne, DE, Standard, 2018. [Online]. Available: https : / / www . easa . europa . eu / sites / default / files/dfu/Easy%5C%20Access%5C%20Rules%5C%20CS- ETSO%5C%20%5C%28Amendment%5C%206%5C%29.pdf. [6] “Regulation (EU) 748/2012”, Official Journal of the European Union, vol. 55, no. L 224, issn: 1977-0677. doi: 10.3000/19770677.L_ 2012.224.eng. [7] “ED Decision 2016/013/R Annex II”, en, European Union Aviation Safety Agency, Cologne, DE, Tech. Rep., 2016, ch. ETSO-C139a. [8] G. Bochmann, “Protocol specification for osi”, eng, Computer Networks & ISDN Systems, vol. 18, no. 3, p. 167, 1990, issn: 01697552. [Online]. Available: http : / / search . proquest . com / docview / 199625521/. 56 | REFERENCES

[9] J. Postel, Internet Protocol, RFC 791 (Internet Standard), RFC, Updated by RFCs 1349, 2474, 6864, Fremont, CA, USA: RFC Editor, Sep. 1981. doi: 10.17487/RFC0791. [Online]. Available: https://www. rfc-editor.org/rfc/rfc791.txt. [10] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 8200 (Internet Standard), RFC, Fremont, CA, USA: RFC Editor, Jul. 2017. doi: 10.17487/RFC8200. [Online]. Available: https: //www.rfc-editor.org/rfc/rfc8200.txt. [11] J. Postel, Transmission Control Protocol, RFC 793 (Internet Standard), RFC, Updated by RFCs 1122, 3168, 6093, 6528, Fremont, CA, USA: RFC Editor, Sep. 1981. doi: 10 . 17487 / RFC0793. [Online]. Available: https://www.rfc-editor.org/rfc/rfc793. txt. [12] ——, User Datagram Protocol, RFC 768 (Internet Standard), RFC, Fremont, CA, USA: RFC Editor, Aug. 1980. doi: 10 . 17487 / RFC0768. [Online]. Available: https://www.rfc- editor. org/rfc/rfc768.txt. [13] “Aircraft data network part 7 avionics full-duplex switched ethernet network”, ARINC, Standard 664 P7, 23rd Sep. 2009. [14] “Avionics full duplex ethernet and the time sensitive networking standard”, Presentation, presented at the IEEE 802.1 Interim Meeting (May 2015), Pittsburgh, PA, USA, 20th May 2015, [Online]. Available: http:// www.ieee802.org/1/files/public/docs2015/TSN- Schneele-AFDX-0515-v01.pdf (visited on 26/03/2020). [15] M. Jakovljevic, “Audio/Video and Hard Real-Time Capability for Advanced IMA Architectures”, eng, SAE International Journal of Aerospace, vol. 4, no. 2, pp. 1293–1300, 2011, issn: 1946-3901. [16] “Time-triggered ethernet”, SAE, Standard SAE6802, 9th Nov. 2016. [17] (). “Sustainable development goal 12”, United Nations, [Online]. Available: https : / / sustainabledevelopment . un . org / sdg12 (visited on 04/06/2020). TRITA-EECS-EX-2020:763

www.kth.se