Modeling and Simulation of Aircraft Data Networks

0 downloads 7 Views 3MB Size Report
A comprehensive simulation model for Avionics Full-duplex switched Ethernet ..... 3-Integrated Architecture: Integrated Modular Avionics (IMA) is the new.

AIN SHAMS UNIVERSITY FACULTY OF ENGINEERING ELECTRONICS AND COMMUNICATION ENGINEERING DEPARTMENT

Modeling and Simulation of Aircraft Data Networks A Thesis Submitted in Partial Fulfillment of the Requirements of the Degree of Master of Science Submitted by:

Nour El-Din Safwat Saad Mohamed Mansour B.SC. of Electrical Engineering Electronics and Communication Engineering Department Ain Shams University, 2009

Under the supervision of: Prof.Dr.Abdelhalim Zekry Electronics and Communication Department Faculty of Engineering Ain Shams Universiry

Dr.Mohamed Abou El Atta Electronics and Communication Department Faculty of Engineering Ain Shams Universiry

Cairo, 2014

Abstract Aircraft Data Networks (ADN) s has experienced a great development since the evolution of Avionics which started as early as the 18th century. With the rise of digital technology, equipment was started to be designed to communicate with each other. There was a need for communication Data bus. The increase in Avionics systems leads to increase the number of wirings in the aircraft which resulted in an increase of power consumption and weight. So, changing of avionics system architectures become a need to reduce systems complexity and weight. This leads to development in communication data bus to fulfill the new avionics systems requirement. This thesis presents the evolution of Aircraft Data Networks .It describes various Avionics data network protocols based on the Avionics systems architecture. It discusses the evolution from a simple point-to-point protocol presented in ARINC 429 to a shared data bus protocol presented in ARINC 629. Finally, the new Data network based on AFDX (Avionics Full-duplex Ethernet) is discussed. AFDX is a new standard based on Ethernet technology and able to handle today’s requirements. Comparison between the three different protocols is presented. The comparison shows that AFDX provides better performance and flexibility without losing the compliance with safety, redundancy and reliability of Avionics requirements. A comprehensive simulation model for Avionics Full-duplex switched Ethernet (AFDX) network is developed based on OPNET platform. Accordingly, the performance of AFDX networks is analyzed. The effect of frame size, switching delay and changing frames transmission order on the AFDX network performance I

is investigated. It is found that using faster switches and small frame size reduces the fixed part of the end to end delay. Also, it affects the variable part of end to end delay due to changing of delay in switches buffers and frames transmission order. Finally, The Case study network is implemented using AFDX & ARINC429 and then a comparison between the two networks is presented. It shows the differences in performance, topology, reliability, redundancy and flexibility. Comparing AFDX with the other standard, it is the highest speed and throughput .Also; it complies with safety, redundancy and reliability of Avionics requirements.

II

List of Contents Page

1. Introduction………………………………………...……………………...

1

1.1 Introductions to Avionics ………………………………………………...

1

1.2 Thesis objectives……………………………………………………….….

3

1.3 Thesis organization……………………………………………………….

4

2. AVIONICS networks Requirements….……….…………………….

5

2.1 Functional requirements……………….………………………………….

5

2.2 Environmental Requirements……….…………………………………….

6

2.3 Test requirements…………….…………………………………………....

7

2.4 Safety requirements…………………….…………………………….........

7

2.5 Broadcast bus requirements…………………………….……………. ….

8

2.6 Fault management……………………………………………………........

10

2.6.1 Fault tolerance…………………….……………………………….. …

11

2.6.1.1 Redundancy…………………………………..……………... ……..

11

2.6.1.2 Recovery…………..……………………………………………….

12

2.6.1.3 Monitoring and filters……………………..……………………….

12

2.7 Summary………………..………………………...………………………..

12

3. Old Aircraft Data Networks…..…………………..…………………...

13

3.1 ARINC ……………………………………………………………………..

13

3.2 ARINC 429……………………………………………………………........

13

3.2.1 Network topology……………………………………………………...

13

3.2.2 Physical layer characteristics………………………………………….

14

3.2.3 Protocol………………………………………………………………..

15

3.2.4 Word format……………………………………………………….. ….

15

3.2.5 Fault tolerance features……………………………………………. ….

17

III

Page

3.3 ARINC 629…………………………………………………………………

18

3.3.1 Network topology……………………………………………………...

18

3.3.2 Physical layer…………………………………………………………..

19

3.3.3 ARINC 629 protocols……………………………………………... ….

20

3.3.4 Message structure…………………………………………………. ….

23

3.3.5 Fault tolerance features………………………………………………..

25

3.4 Summary…………………………………………………………….……..

25

4. AFDX………………..……………………………………………………..

26

4.1 AFDX Origin……………………………………………….………………

26

4.2 AFDX Network Architecture……………………………….……………..

26

4.3 Physical topology…………………………………………….…………….

27

4.4 Message flow control………………………………………………………

28

4.4.1 The Virtual Link (VL)…………………………………….…………..

28

4.4.4.1 The virtual link parameters………………………………….……

29

4.4.2 Flow regulation………...…….………………………………….…….

30

4.4.3 Flow scheduling………………………………………………….……

31

4.5 AFDX Network Protocol………………………………………………….

31

4.5.1 AFDX protocol layers………………………………….……………...

31

4.5.2 AFDX Frame Structure…………………………….………………….

32

4.6 Network reliability………………………………………………………...

36

4.6.1 Integrity checking……….…………………………………………….

37

4.6.2 Redundancy Management……………………………………………

38

4.7 AFDX switch………………………………………………………………

40

4.7.1 Frame filtering…………………………….……………………..……

41

4.7.2 Frame policing…………………………….…………………………..

41

IV

Page

4.8 Fault tolerance features….………………………….……………………..

42

4.8 Summary…………………………………………………………………..

42

5. AFDX modeling……………………………………….…………….……

43

5.1End System (ES)…………………………………….……………………...

43

5.1.1 Transmitting ES………….……………………………………………

43

5.1.2 Receiving ES………….……………………………………………….

44

5.2 AFDX Switch………………………………………………………………

45

5.3 AFDX simulation model…… ……………………………………………..

45

5.3.1 Model Specifications………..…………..….………………………….

45

5.4 OPNET Modular…………….…………………………………………….

45

5.4.1Opnet models…………………………………………….……………..

46

5.4.2 Modeling approach………………………………………..…………...

46

5.5 End system model……….…………………………………………………

47

5.6 Switch model………….……………………………………………………

53

5.7 Model Verification and Validation………………………………………..

56

5.7.1 Model Verification ……………………………………………………

56

5.7.2 Model validation…………………………………..…………………..

56

5.7.2.1 End-to-End Delay……………………………………………..…..

57

5.7.2.2 An Example of AFDX network………………………………...…

58

5.7.2.2.1 Topology..……………………………………………………..

58

5.7.2.2.2 Configuration table………………………….....……………..

59

5.7.2.2.3 Scenarios…...………………………………..………………..

59

5.7.2.2.4 Simulation network………………………….………….……

60

5.7.2.2.5 Simulation results…………………………………..…………

61

5.7.2.2.6 Simulation v.s. Calculated results…………………………..…

63

V

Page

5.8 Summary…….……………………………………………………………..

64

6. AFDX network case study………………….………………………….

65

6.1 System function and operation…………..……..…………………………

65

6.2 System Architecture……………..……………..………………………….

67

6.3 Configuration Parameters…….…………………………………..………

67

6.4 Network Simulation ………..……………………………..……………….

69

6.4.1 Simulation results………… …………………………………………..

69

6.4.2 Analysis of the simulation results…………………….………………..

72

6.4.3 Analysis of E-to-E delay……………………………………………….

72

6.5 AFDX vs. ARINC429…………… ………………………………………

77

6.6 Summary……

…………………………………………………………..

82

7. Conclusions and suggested future research...…..……………..…..

84

7.1 Conclusions…. …………………………………………………………….

84

7.2 Suggested future research……………………………………………...…

85

Publications Extracted from the thesis…………………………………………

86

References………………………..…………………………………….………

88

VI

List of Figures Page Figure1.1 Example of Federated Architecture…….…………….……………

2

Figure1.2 Example of Integrated Architecture………………….…………....

3

Figure3.1 ARINC 429 layout with one transmitter and up to 20 receivers…..

14

Figure3.2 ARINC 429 Data Bus……………………………………………..

14

Figure3.3 ARINC 429 Data Encoding……………………………………….

15

Figure3.4 ARINC 429 Frame fields………………………………………….

16

Figure3.5 BCD Data type…………………………………………………….

16

Figure3.6 BNR Data type……………………………………….……….....…

17

Figure3.7 ARINC629 data bus………………………………………………..

18

Figure3.8 ARINC 629 network Components...………………………….……

19

Figure3.9 ARINC 629 Data Encoding………………………….....………….

20

Figure3.10 Terminal Access Flow Chart……………………..………………

22

Figure3.11 Periodic mode timing diagram……..………………….…………

23

Figure3.12 Aperiodic mode timing diagram…………………………...……..

23

Figure3.13 ARINC629 message structure……..…………………………......

24

Figure3.14 example of Message with two word string……...………………..

24

Figure4.1 AFDX network Architecture………..……………………………..

26

Figure4.2 AFDX virtual Links……………………………………………….

27

Figure4.3 AFDX Physical topology…………………………………………

28

Figure4.4 Physical cable and virtual links…………………………..………..

28

Figure4.5 Bandwidth Allocation Gap (BAG) &Jitter…………….………….

30

Figure4.6 Virtual Link Regulation…………………….…………………….

30

Figure4.7 Virtual link Scheduler…………..………………………………....

31

Figure4.8 AFDX protocol layers………………..………………………...….

32

VII

Page Figure4.9 AFDX protocol stack………………..…………………………….

32

Figure4.10 AFDX frame structure………….………………………………..

35

Figure4.11 AFDX frame destination address....................................................

35

Figure4.12 AFDX frame source address…………….………………….……

36

Figure4.13 AFDX integrity checking and Redundancy Management………..

37

Figure4.14 Example of RMA and IC behavior…………………………..…..

39

Figure4.15 example of loss of frame………………………………………..

39

Figure4.16 AFDX switch architecture……………………………..…………

40

Figure5.1 AFDX network elements…………………………………….……

43

Figure5.2 Transmitting ES…...………………………………...………….....

44

Figure5.3 Receiving ES……………………………….……………………..

44

Figure5.4 Switch model……………………………………………………..

45

Figure5.5 Opnet modeling approach………………………….……………..

46

Figure5.6 node:Ethernet_station_adv………………………………….……

46

Figure5.7 AFDX End System node…………………………………………

48

Figure5.8 bursty_source process model…………………………………….

49

Figure5.9 Ethernet_mac_v2 process model………………………………....

50

Figure5.10 regulator process model…………………………………………

51

Figure5.11 Scheduler process model………………………………………..

51

Figure 5.12 Redundancy management process model………………………

52

Figure5.13 Integrity Check process model………………………………….

52

Figure5.14 Redundancy check process model………………………………

53

Figure5.15 AFDX Switch node……………………………………………..

54

Figure5.16 switch_core process model………………………………………

55

Figure5.17 switch_mac_relay_afdx…………………………………………

55

Figure5.18 forwarding table example……………………………………….

55

VIII

Page Figure5.19 model verification & validation………………………………...

56

Figure5.20 network topology…………………………………………………

58

Figure5.21selected virtual link path..................................................................

59

Figure5.22 network simulation scenarios..........................................................

60

Figure5.23 AFDX network mapped in OPNET…………...…………………

60

Figure5.24packets generated from End system1 & packets received in (e6-E1)

61

Figure5.25 end-to-end delay (scenario a)……………………………………..

62

Figure5.26 end-to-end delay (scenario b)…………………………………….

62

Figure5.27 end-to-end delay (scenario c)…………………………………….

63

Figure6.1 FMS message flow……………………………………………….

66

Figure6.2 FMS system architecture…………………………………………

67

Figure6.3 network setup on OPNET………………………..………………..

69

Figure6.4 virtual links End-to-End delay……………………………………..

70

Figure6.5 end to end delay distribution of VL1……………………….…………

73

Figure6.6 VLs of (ADRIU1 to FM1) & (NDB to FM1)…………………..…

74

Figure6.7 VL of (RDC1 to ADRIU1)……………..…………………………

75

Figure6.8 end to end delay of VL7, 9, 11 at switch delay =16 µs …………...

76

Figure6.9 Build AFDX network using ARINC429…………………..…….

78

Figure6.10 Redundancy & Flexibility of ARINC 429 V.s. AFDX….………..

81

IX

List of Tables Page Table 2.1 system development assurance levels for civil aircraft...............

9-10

Table 3.1 SSM Codes for BCD data………………………………..……

17

Table 3.2 SSM Codes for NBR data……………………………...………

17

Table 3.3 ARINC 429 and ARINC 629 summary……………………….

25

Table 5.1 configuration table………………………………….…………

59

Table5.2 Calculation of VL1 E-to-E delay V.S. simulation results scenarios

63

Table6.1 messages sizes……………………………………….………….

68

Table6.2 End systems sending time parameters……………………….….

68

Table6.3 Virtual links parameters…………………………………………

68

Table6.4 Virtual links min/max simulation E-to-E delays…….……….…

71

Table6.5 simulation V.S. calculated End-to-end delay….…………………

71-72

Table 6.6 fixed and variable parts of end to end delay of VL11, 7, 9……..

74

Table6.7 E-to-E delay of VL11, 7, 9 at switch delay =16 µs………………

76

Table6.8 Performance AFDX versus ARINC429………………………….

79

Table6.9 the end to end delay of ARINC429 V.S. AFDX…………………

79

Table6.10 Wiring in ARINC429 V.S. AFDX………..…………………….

80

Table6.11 Topology, Reliability, Redundancy and Flexibility.....................

82

X

List of Abbreviations ADN

Avionics Data Network.

AFDX

Avionics Full Duplex switched Ethernet.

ARINC

Aeronautical Radio Incorporated.

BAG

Band Allocation Gap.

BCTT

Best Case Transmission Time.

CMC

Current Mode Coupler.

CRC

Cyclic Redundancy Checksum

CSMA/CA

Carrier Sense Multiple Access with Collisions Avoidance.

CSMA/CD

Carrier Sense Multiple Access with Collisions Detection.

EMC

Electromagnetic Compatibility.

EMI

Electromagnetic Interface.

ESD

Electrostatic Discharge.

ES

End System.

E-To-E

End to End Delay.

FCS

Frame Check Sequence.

FTA

Fault Tree Analysis.

IC

Integrity Checking.

IFG

Interframe Gap.

IMA

Integrated Module Avionics.

IP

Internet Protocol.

LRU

Line Replicable Unit.

MAC

Media Access Control.

MFT

Minimum Frame Time.

NRZ

Non Return to Zero.

OPNET

Optimized Network Engineering Tools.

PSSA

Preliminary Safety Assessment. XI

RMA

Redundancy Management Algorithm.

RM

Redundancy Management.

SFD

Start Frame Delimiter.

SG

Synchronization Gap.

SIM

Serial Interface Module.

SN

Sequence Number.

SSA

System Safety Assessment.

TCP

Transmission Control Protocol.

TG

Terminal Gap.

TI

Transmit Interval.

UDP

User Datagram Protocol.

VL

Virtual Link.

WCTT

Worst Case Transmission Time.

.

XII

Chapter1: Introduction

Chapter 1 Introduction 1.1 Introduction to Avionics “Avionics” is a word derived from the combination of the aviation and electronics, which could be defined as electronics of aircrafts, satellites and spacecrafts. Collinson mentions that the word avionics “was first used in the USA in the early 1950s and has since gained wide scale usage and acceptance” [1]. The development of Avionics started as early as the 18th century. In 1783, the Montgolfier brothers used a barometer to measure altitude. At the end of the 1920s, gyroscopes and radio navigation aids were developed, In the 1940s, “World War 2 drove a number of important advances including navigation aids, airborne radar and electronic warfare equipment” [2]. Aircraft avionics began with a few separate, analog systems such as radar, navigation and communication equipment and cockpit displays, connected by dedicated wiring. The number of avionics increased per aircraft, digital technology appeared and systems began to be more complex. Also with the rise of digital technology, equipment was started to be designed to communicate with each other. This communication increased the number of wirings in the aircraft which resulted in an increase of power consumption and weight. The use of data bus became a need in aviation. Introducing data bus protocol helped to reduce wirings. It also simplified total design and maintenance. Avionics architectures were also developed according to the order below 1- Independent avionics architecture: in independent avionics architecture equipment has its own functionality independent of other similar or different equipment. 2- Federated System Architecture: it integrates different kind of systems emerged as a Federated Avionics Systems. Separate subsystems implementing 1

Chapter1: Introduction

functions using dedicated components, dedicated modules, Line Replicable Units (LRU)’s, and software. Federated Architectures do not share or timeshare component or information across subsystems in the avionics suite. 3-Integrated Architecture: Integrated Modular Avionics (IMA) is the new avionics achitecture which combines functions of LRU’s into software packages running on a single Avionics computer. Most special-to-purpose controllers are replaced by common standardized platforms that usually host applications of several systems. IMA defines the separation of the resources and enables certification independently [4]. For inter-system communication, either IMA module-internal communication or standardized aircraft networking technology with guaranteed bandwidth and high availability is used [5]. Figures 1.1 and 1.2 show the Federated and Integrated architectures. It can be noticed that the number of CPUs and communication channels decreased.

Example of Federated System Architecture CPUs: 3 I/O Modules + Network Interface Modules: 5 Physical Communication Channels: 4 Figure1.1 Example of Federated Architecture [5]

2

Chapter1: Introduction

Example of Integrated System Architecture CPUs: 1 I/O Modules + Network Interface Modules: 4 Physical Communication Channels: 1 Figure1.2 Example of Integrated Architecture [5]

Avionics Data Networks (ADN)’s are the essential enabling technologies of avionic systems integration in both federated and integrated modular avionics architectures. Replacing the traditional point-to-point communication with broadcast bus communication was a need to decrease weight and increase the flexibility of the new avionics architectures. Avionics Full Duplex Switched Ethernet (AFDX) is a suitable data communication specification for IMA. AFDX is the leading edge avionics network technology. The first application of AFDX was started with A380 of Airbus and continued with A400M of Airbus Military and Boeing 787.

1.2 Thesis objectives The main scope of this thesis is as following: 1- Give background on Requirements of communication networks in avionics systems. 2- Study the old aircraft data network and its development. Describe their basic specifications, characteristics and usage. 3

Chapter1: Introduction

3- Study the features of the AFDX specification in details and investigate layers of AFDX and messaging specifications, give a comparison with other avionics buses. 4- Build simulation model for AFDX network components on OPNET and use it to calculate End-to-End delay. 5- Choosing a network case study. Simulate this network based on the developed model of the AFDX protocol. 6- Evaluate the performance of AFDX network and compare the same network implemented with old Avionics data bus ARINC 429.

1.3 Thesis Organization This thesis contains seven chapters organized as following: Chapter 1 is introduction to AVIONICS. Chapter 2 discusses requirements that are placed upon systems and components that are to be used in an aircraft. Chapter3 gives background on old aircraft data network. Describe their basic specifications, characteristics and usage. Chapter4 presents the features of the AFDX specification in details and investigate layers of AFDX and messaging specifications, give a comparison with other avionics buses. Chapter5 explains the development environment, tools and the Developed model Chapter6 explains the network case study .gives the performance evaluation for AFDX network. Finally Chapter7 concludes the thesis and states some future work directions.

4

Chapter 2 Avionics Data Networks requirements Avionics Data Networks are safety critical networks which require more restrictions than the commercial Data networks. Avionics networks requirements can be divided to Functional requirements, Environmental requirements, Test requirements، Safety requirements, Broadcast bus requirements [6]and Fault management.

2.1 Functional requirements [7] Functional requirements are those necessary to obtain the desired performance of a system under the conditions specified. They are a combination of customer desires, operational constraints, regulatory restrictions and implementation realities. These requirements define all significant aspects of the system under consideration. Regardless of the original source, all functions should be evaluated for their safety related attributes. Additionally there are several subcategories of functional requirements to consider: •

Customer requirements vary with the type of aircraft and the usage intended.



Operational requirements define the interface between i.e. flight crew and each functional system.



Performance requirements define attributes that make it useful for the customer such as speed, accuracy and response time. Factors that affect performance requirements of a communication network are e.g. bandwidth, through put, number of nodes, overhead, jitter, delays and response time. Physical and installation requirements define attributes such as size, power, cooling and handling. 5



Maintainability requirements maintenance of equipment.



Interface requirements include the physical system and interconnections between subsystems.

include

scheduled

and

unscheduled

2.2 Environmental Requirement Environmental requirements state that equipment shall function normally and without degradation under the environmental conditions experienced by the equipment and aircraft through its service life unless otherwise stated in the specification. Temperature requirements include normal and severe conditions both on ground and when airborne. All equipment is covered in powered and unpowered condition. The operating temperature range is usually specified from −40◦C to +70◦C [1]. Vibration requirements state what kind of vibration that should be handled by all equipment. Power spectral energy levels of 0.04g2 per Hz are encountered in aircraft designed in the 1970s and levels of 0.7g2 per Hz at very low frequencies are anticipated in future installations [1]. Electromagnetic Compatibility (EMC) requirements deal with Lightning effects; direct and indirect, high intensity radiated fields, EMC environment generated by on board equipment and Electrostatic discharge (ESD). Tests with transients and slow waveforms can be used to show that systems and item do not malfunction under the EMC conditions specified. Environmental requirements are of big importance when designing a safetycritical communication system. A bus or a communication link that extends into the wings of an aircraft is exposed to significant electromagnetic fields, temperatures and vibrations that might degrade the performance as well as the reliability. A big issue when introducing a “new” digital communication concept, such as TTP/C, is the amount of electronics needed out by each actuator where the 6

environment can be very hostile. A big challenge is to prove that the equipments can survive in this hostile environment. Additional difficulties are to expect regarding temperature and EMI (Electromagnetic Interference) with the new lighter wings of composite material. Cable lengths are a concern due to signal distortion that increases with cable length. RTCA/DO-160D deals with environmental issues in airborne systems [7].

2.3 Test Requirements There are two main objectives of testing: - To show that a system performs its intended functions. Testing of an intended function involves evaluation against pass/fail criteria based on the system requirements. - To show that a system do not perform unintended functions that affect safety. Tests are often associated with the development phase of a system. Equally important are build-in self-tests that are carried out every time the system is powered up and continuous self-tests during operation to detect and handle errors [7].

2.4 Safety Requirements Safety requirement can be divided to qualitative and quantitative safety requirements [6]. Qualitative safety requirements: no single failure or event shall lead to a catastrophic or hazardous failure conditions. Quantitative safety requirements: each function is analyzed and given a maximum failure rate per flight hour depending on its criticality. The safety assessment process includes safety requirements identification and verification [9]. 7

Safety requirements identification during system development phase .it includes Preliminary System Safety Assessment (PSSA), which derives (qualitative and quantitative) safety requirements for the subsystems, primarily using Fault Tree Analysis (FTA). Verification includes the System Safety Assessment (SSA) process verifies whether the safety requirements are met in the implemented design.

2.5 Data buses requirements This section contains a compilation of requirements that are especially important for a data bus that is to be used in avionics systems [6]. 1. The bus shall provide bounded (predictable) latency. 2. Adequate bandwidth for the application should be provided by the bus. It is common to have at least 50% of spare bandwidth for future reconfigurations. 3. The probability of lost messages should be consistent with the probability classification of minor (see Table 2.1) under the interference of the specified environment. 4. The probability of undetected corrupted data should be consistent with the probability classification of hazardous (see Table 2.1), the probability of successive occurrences should be consistent with the probability classification catastrophic under the interference of the specified environment. 5. The bus standard should support broadcast or multicast messages. 6. The bus should provide fault isolation mechanisms that provide controlled access to the bus. It is also desirable that the physical bus driver (controller) has a low failure rate. 7. The bus should use components that remain in the market for at least 10 years. 8

8. The physical layer should allow communication on the bus even if a node is removed. 9. The physical layer should be able to accommodate at least 30 nodes and have a bus length of at least 100m. 10. The physical layer should be able to use transformer couplers to achieve galvanic isolation at each node. System Failure rate Development (failures/ Assurance hour) Level

Failure condition classification

A

λ< 10E-9

Catastrophic

B

10E-9 < λ < 10E-7

Hazardous / Severe-Major

C

10E-7 < λ < 10E-5

Major

9

Failure condition description

Failure conditions that would prevent continued safe flight and landing. Failure conditions that would reduce the capability of the aircraft or the ability of the flight crew to cope with adverse operating conditions to the extent that there would be: a large reduction in safety margins or functional capabilities, physical distress or higher workload such that the flight crew could not be relied on to perform their tasks accurately or completely, or adverse effects on occupants including serious or potentially fatal injuries to a small number of those occupants. Failure conditions which would reduce the capability of the aircraft or the ability of the crew to cope with adverse operating conditions to the extent that there would be, for example, a significant reduction in safety margins or functional capabilities, a significant increase in crew workload or in conditions

D

E

impairing crew efficiency, or discomfort to occupants, possibly including injuries. Failure conditions which would not significantly reduce aircraft safety, and which would involve crew actions that are well within their capabilities. Minor failure conditions may include, for 10E-5 < λ < 1 Minor example, a slight reduction in safety margins or functional capabilities, a slight increase in crew workload, such as, routine flight plan changes, or some inconvenience to occupants. Failure conditions that do not affect the operational Any range No safety effect capability of the aircraft or increase crew workload. Table 2.1: System development assurance levels for civil aircraft [6].

2.6 Fault Management There are two approaches to achieve reliability in a system. Fault avoidance prevents faults occurrence in the system. This approach is implemented both in the design phase and in the planning of service and maintenance .the second one is Fault tolerance which accepts faults in a limited capacity and masks their manifestation.

2.6.1 Fault tolerance When designing a fault-tolerant system an explicit fault hypothesis must be used that describes the number, type and arrival rate of the faults it is intended to tolerate. Designers must ensure that no single point of failure can cause a catastrophic failure. Redundancy, recovery and monitoring & filters are Fault tolerance mechanisms which will be described in the following section [6].

10

2.6.1.1 Redundancy • Static redundancy In static redundancy (active replication or masking) the application is executed at N redundant nodes in parallel and a majority vote is performed to prevent faulty data to propagate to other parts of the system [6].

• Dynamic redundancy In dynamic redundancy (passive replication or reconfiguration) some nodes are active and some are used as stand-by spares, which are activated in case of failure. The stand-by spares can either be cold (unpowered) or hot (powered). A shadow node is hot but does not deliver anything to the bus except for in case of failure. A hot spare generally uses less time to replace the faulty node than a cold spare. However, the cold spare generally have lower failure rate [6].

• Hybrid redundancy Hybrid fault tolerance uses hybrid redundancy, which is a combination of static and dynamic redundancy [10].

• Replicated communication channels Replicated communication channels are used to tolerate faults on the communication channels. Faults that can occur are short-circuit, cut off wires and disturbances such as radiation and lightning [6].

• Software and data redundancy These are systematic error handling functions implemented at system-level and component level. Common techniques are: replicated messages, message

11

checksums, error detection and correction for memory, assertion checks, N version programming and test programs (i.e. BIT) [6].

2.6.1.2 Recovery [6] • Roll back recovery Roll back recovery is the simplest scheme where calculations are allowed to be reexecuted in additional time when a failure is detected.

• The recovery block approach Is similar to active and passive replication but uses a simpler backup spare to reduce the time to provide a correct output.

2.6.1.3 Monitoring and filters [6] • Health monitoring Monitoring nodes at a higher system level monitors subordinate nodes and performs periodical life sign controls. Through this system it is possible at aircraft level of a system to have complete information regarding the status of the aircraft.

• Self-tests Check of components by running a program with known input and comparing output with known result.

2.7 Summary In this chapter Avionics Data networks requirements are discussed. In Avionics, safety requirements are more restricted due to criticality of these systems. Data buses requirements differ from requirements of the commercial one as shown in 2.5. The next chapter discusses the old aircraft data network showing their specification and characteristics.

12

Chapter 3: Old Aircraft Data Networks

Chapter 3 Old Aircraft Data Networks This chapter gives a background on the old aircraft data networks. It describes their basic specifications and characteristics. ARINC 429 and ARINC 629 protocols are introduced. ARINC 429 is simple point to point protocol which is used widely in the most of aircrafts and ARINC 629 is shred data bus developed by Boeing and is used in Boeing-777 aircraft.

3.1 ARINC Aeronautical Radio, Incorporated (ARINC) is a major company that develops and operates systems and services to ensure the efficiency, operation, and performance of the aviation and travel industries. It was organized in 1929 by four major airlines to provide a single license and coordinator of radio communications outside the government.

It has provided leadership in developing specifications and standards for avionics equipment.

3.2 ARINC 429 The characteristics of ARINC 429 were agreed among the airlines in 1977-78, and it was first used throughout the B757/B767 and Airbus A300 and A310 aircraft.

3.2.1 Network topology In its simplest form, an ARINC 429 network consists of a single transmitter (source) connected to a single receiver (sink). Up to 20 receivers can be connected to a single transmitter as shown in Figure 3.1. ARINC 429 is a simplex data bus so; if any of the sink equipment needs to reply then it will require its own transmitter.

13

Chapter 3: Old Aircraft Data Networks Transmitter

Receiver 1

Receiver 2

Receiver 20

Figure 3.1An ARINC 429 layout with on transmitter and up to 20 receivers

3.2.2 Physical layer characteristics ARINC 429 uses shielded twisted cable to transmit ARINC data is differential signal form as shown in figure 3.2 .the electrical characteristics can be summarized as following: •

Transmission medium: 78 ohm twisted shielded cable is used to connect the nodes



Voltage levels: +5V, 0V,−5V (each conduct or with respect to ground +10V, 0V,−10V (conductor A with respect to conductor B)

Figure 3.2: ARINC 429 Data Bus

14

Chapter 3: Old Aircraft Data Networks

Figure 3.3: ARINC 429 Data Encoding



Data encoding: Bi-Polar Return to Zero as shown in figure 3.3.



Word size: 32 bits Transmission of sequential words is separated by at least four bit times of NULL (zero voltage). This eliminates the need for a separate clock signal and it makes the system self-clocking.



Bit rate (high): 100K bits per second.



Bit rate (low): 12.5K bits per second.



Slew rate (high): 1.5ms (±0.5 ms).



Slew rate (low): 10ms (±5 ms).

3.2.3 Protocol Since there can be only one transmitter on a twisted wire pair, ARINC 429 uses a very simple, point-to-point protocol. The transmitter is continuously sending 32bit data words or is placed in the NULL state.

3.2.4 Word format ARINC frame consists of a single 32-bit data word. Figure 3.4 shows the five primary fields of RINC 429 (Label, SDI, Data, SSM and Parity). Bits are transmitted starting with bit 1 of the label and the final bit transmitted is the parity bit 15

Chapter 3: Old Aircraft Data Networks

Figure 3.4 ARINC 429 Frame fields

The Label field is an octal value that indicates the type of data (e.g. airspeed, altitude, etc) that is being transmitted.

The SDI field (source distention identifier) is used when a transmitter is connected to multiple receivers but not all data is intended for used by all the receivers. In this case each receiver will be assigned an SDI value and will look only at labels which match its SDI value. In some cases, these bits are used for data

The Data field contains the actual data to be sent. Data Types can be classified to three types: • • •

(BCD) Binary Coded Decimal. (BNR) binary coding. (DSC)Discrete.

BCD Data Encoding Its data fields contain up to five sub-fields as shown in figure 3.5. The most significant sub-field contains only the three bits. If the maximum decimal value is greater than 7, bits 29 through 27 are padded with zeros and the second sub-field becomes the most significant.

Figure 3.5: BCD Data type

16

Chapter 3: Old Aircraft Data Networks BNR Data Encoding Bit29 is the sign bit and bit 28 is the most significant bit of the data field, which represents one half of the maximum value of the parameter being defined. Successive bits represent the increments of a binary fraction series. Figure 3.6 represent BNR Data type.

Figure 3.6: BNR Data type

SSM (Sign/Status Matrix) contains hardware equipment condition, operational mode, or validity of data. Table 3.1 shows SSM codes for BCD data type and Table 3.2 for NBR data type.

Bit

Meaning

31

30

0

0

Plus, North, East, Right, To, Above

0

1

No Computed Data

1

0

Functional Test

Bit

Minus, South, West, Left, From, 1

1

Below.

Meaning

31

30

0

0

Failure Warning

0

1

No Computed Data

1

0

Functional Test

1

1

Normal Operation

Table 3.2 SSM Codes for NBR data

Table 3.1 SSM Codes for BCD data

Parity The MSB is always the parity bit for ARINC 429. Parity is normally set to odd except for certain tests.

3.2.5 Fault tolerance features Parity bit is the only fault tolerance feature in ARINC 429. More details about ARINC429 could be found in [11][12][13][14][15].

17

Chapter 3: Old Aircraft Data Networks

3.3 ARINC 629 Another standard, ARINC 629, introduced by Boeing for the 777 provides increased data speeds of up to 2 Mbit/s and allowing a maximum of 120 data terminals.

3.3.1 Network topology ARINC 629 is a true data bus in that the bus operates as a multiple-source, multiple-sink system as show in figure 3.7. That is, each terminal can transmit data to, and receive data from every other terminal on the data bus. This allows much more freedom in the exchange of data between units in the avionics system than the single-source, multiple-sink ARINC 429 topology. The ARINC 629 data bus operates at 2 Mbytes/sec or twenty times that of ARINC 429.it support up to 120 data terminal on the data bus.

Figure 3.7 ARINC 629 data bus

18

Chapter 3: Old Aircraft Data Networks

3.3.2 Physical Layer The network core consists of four main components (Bus cable, CMC, Stub, LRU) as shown in figure 3.8

Figure 3.8 ARINC 629 network components

Bus cable It is an unshielded twisted wire pair. Its Characteristic Impedance: Zc = 130 ohms (+/- 5%), Bus frequency 2 Mbits/s and Length of 100 m (120 terminals max,) Stub Two shielded twisted pairs with an additional outer shield. Its Characteristic impedance of each twisted pair Zc = 100 Ohms (+/- 1o %) and Length of 40 m max. Current mode coupler (CMC) The CMC provides interface between the terminal and the ARINC 629 current mode communication bus. It includes dual transmit and receive channels. The CMC is magnetically coupled to the bus by individual transformers. Line replacement unit (LRU) LRU is consists of: •

The Serial Interface Module (SIM) 19

Chapter 3: Old Aircraft Data Networks •

Terminal Controller



Subsystem

As in figure 3.9, Subsystem generates data in form of None Return to Zero (NRZ) data .Terminal Controller converts NRZ to Manchester format data.SIM converts Manchester data to Doublet format to send to CMC then to Data Bus.

Figure 3.9 ARINC 629 Data Encoding

3.3.3ARINC629 Protocols There are two types of ARINC629 protocols Basic protocol and combined protocol.

Both have two modes, periodic mode and non periodic mode, but the

combined protocol support prioritized data. Basic Protocol Provides an equal priority access for each terminal to transmit either Periodic or Aperiodic data .If no bus overload exists and transmission lengths are constant, terminals transmit at a constant interval (Periodic Mode) but 20

Chapter 3: Old Aircraft Data Networks otherwise If the bus is overloaded, it will automatically switch to an( Aperiodic mode) with no loss of data. Because there are more than one terminal may begin to transmit when the Bus is free, a method of avoiding clashes must be used. Method used by ARINC 629 is called CSMA/CA which achieved by use of three timers • • •

Transmit Interval (TI) Terminal Gap (TG) Synchronization Gap (SG)

The Transmit Interval (TI) This timer is common to all terminals on the bus. It is the minimum time between two transmissions on a same terminal. TI is the longest of the three timers and starts every time a terminal begins to transmit. The Synchronization Gap SG This timer is also common to all terminals on the bus. The SG timer starts when the bus is quiet. It is reset if a carrier appears on the bus before it has elapsed. The Terminal, Gap TG This timer is unique for each terminal on the same bus. The TG timer determines which terminal transmits if two or more terminals transmit intervals has elapsed and the bus is busy. The TG timer is reset by a presence of a carrier. The TG timer should begin only after the SG timer has elapsed and only if no carrier is present. The Basic Protocol is based on the terminals ability to satisfy three criteria’s before it can transmit again • • •

The TI has elapsed. The SG Quiet period has existed on the bus The TG quiet period has existed on the bus since the SG occurred. These three rules allow transmission without collisions. Figure 3.10 shows terminal access flow chart.

21

Chapter 3: Old Aircraft Data Networks

Figure3.10 Terminal Access Flow Chart

Minimum Frame Time (MFT) it is equal to the synchronization gap plus the sum of all the messages and terminal gaps in a bus minor frame. • •

If TI > MFT, the bus will operate in the Periodic Mode (Terminals will transmit in the order they powered up). As shown in figure 3.11. If MFT > TI, the bus will operate in the Aperiodic Mode (Terminals will always transmit in the order of shortest to longest TG). As shown in figure 3.12.

22

Chapter 3: Old Aircraft Data Networks

Figure 3.11 Periodic mode timing diagram

Figure 3.12 Aperiodic mode timing diagram

3.3.4 Message Structure Data is transmitted in groups called Messages. Between each Message a unique Terminal Gap. Message is composed of Word-strings (31max). Word string begins with a label word followed by 0 –256 data words. There are 4 bit time gap between word-strings. Minimum word string (1 label and no data word) and 23

Chapter 3: Old Aircraft Data Networks Maximum (31 labels with 256 data words).figure 3.13 shows message structure of ARINC 629.figure 3.14 is example of message with two word string. It shows the 4 bits gap between word strings, 20 bits label word which begin with 3 bit Hi to Low Sync bits and 20 data word which begin with 3 bits Low to Hi Sync bits.

Figure 3.13 ARINC629 message structure

Figure 3.14 example of Message with two word strings

24

Chapter 3: Old Aircraft Data Networks

3.3.5 Fault tolerant features (a) Distributed control, each node has its own controller, without the need for a bus controller (avoiding single-point failure mode) (b) Each terminal monitors its own transmissions. This is done by (SIM) which part of its functions is Fault Monitoring and Management. Checks its own output waveform, Checks received waveform, Causes/verifies coupler channel switching, Inhibits coupler transmission, if necessary and Outputs fault information to Terminal Controller. (c) Non-intrusive, inductive coupling. More details about ARINC629 could be found in [13][15][16][17].

3.4 Summary Table 3.3 shows the summary of ARINC 429 and ARINC 629 characteristics and specification ARINC 429 Unidirectional data bus high speed 100 kbit/s, low speed 12.5 – 14.5 kbit/s shielded twisted pair return to zero bipolar tristate modulation

Type Data rate Medium Bit encoding

Massage

Architecture

Protocol

Max. no. of nods

ARINC 629 bidirectional 2 Mb/s unshielded twisted pair Manchester

composed of Word 32-bit word, 255 word data strings (31max), begin block in block transfer with a label word mode followed by 0 –256 data words single source multiple sink multi-master Simplex single source CSMA/CA; Basic multiple sink plus full protocol (periodic and duplex RTS/CTS non periodic) and handshake. Classes of Combined protocol (for service: periodic, sporadic periodic and non periodic and file transfer traffic, with priority) 20 sinks, 1 source up to 120 terminals

Table 3.3: ARINC 429 and ARINC 629 summary

25

Chapter 4: AFDX

Chapter 4 AFDX AFDX (Avionics Full-duplex Ethernet) is a promising network protocol which comes to meet the new avionics requirements. Compared with old avionics data bus networks, AFDX supports high speed up to 100Mbit/sec, flexible architecture and low cost.

4.1AFDX origin AFDX is based on conventional Ethernet as it is well established protocol. Although Ethernet support high speed and low cost parts, it is based on Probabilistic protocols as CSMA/CD and non redundant architecture which don’t meet the main avionics network requirements determinism and reliability. AFDX adapted the conventional Ethernet to be applicable to Avionics Network.

4.2AFDX Network Architecture

Figure4.1 AFDX Network Architecture [18]

AFDX network consists of three main parts End system (ES), switches and communication links as shown in figure4.1. •

End system is the interface between the subsystems (for example flight control computer) and the network. As explained in chapter (1), in IMA architecture Avionics computer system is capable of supporting multiple 26

Chapter 4: AFDX Avionics subsystems Partitions provide isolation between Avionics subsystems within the same Avionics computer system. •

AFDX switch is the central element of the AFDX network that interconnects source End System to destination End system. Links between AFDX network in twisted pair cables but they are divided to virtual links.



Virtual Link defines a logical unidirectional connection from one source end-system to one or more destination end-systems as shown in figure4.2.

Figure4.2 FDX virtual links [26]

Each Virtual Link has a dedicated maximum bandwidth. This bandwidth is allocated by the System Integrator.

4.3 Physical Topology AFDX network is a star topology network as shown in figure4.3. Each ES has two AFDX ports connected to 2 redundant networks. Packets are transmitted and received over two redundant channels to ensure the reliability and availability of the AFDX standard.

27

Chapter 4: AFDX

Figure4.3 AFDX Physical Topology [3]

4.4Massage flow control AFDX ensures a deterministic behavior through traffic control. Traffic control is achieved by guaranteeing the bandwidth of each logical communication channel, called a Virtual Link (VL), thereby limiting the jitter and transmit latency.

4.4.1The Virtual Link (VL):

Figure4.4 Physical Cable and Virtual Links [3]

28

Chapter 4: AFDX As shown in figure4.4, the communication between two AFDX (ES)’s takes place over a single physical communication link. However, it is possible to establish many logical communication links, called Virtual Links (VL). AFDX implements transmit VLs as well as receive VLs. Each transmit VL can only be assigned to one ES. Receive VLs can be assigned to several ESs.

4.4.1.2The virtual link parameters: •

Bandwidth Allocation Gap (BAG), a timeslot confining the VL's bandwidth by defining the minimum gap time between two consecutive frames as shown in figure4.6. The BAG value must be in the range 1 128ms and must be a power of 2. The choice of BAG for a particular virtual link depends on the requirements of the AFDX ports that are being provided linklevel transport by the virtual link. For example, suppose an Avionics subsystem is sending messages on three AFDX communications ports that are being carried by the same virtual link. Let’s assume the message frequencies on the ports are 10 Hz, 20 Hz, and 40 Hz, respectively. The total frequency of the combined messages (they will be combined on the same virtual link) is 70 Hz. The average period of the message transmissions is 14.4ms. Accordingly, to provide adequate bandwidth on the virtual link, we should select a BAG that is less than 14.4 ms. the first available BAG is 8 ms, which corresponds to a frequency of 125 Hz. With a BAG of 8 ms, we are guaranteed that the virtual link is able to transport the combined messages from the three ports without any backlog. The source End System is required to enforce BAG restrictions for each outgoing virtual link. A number of virtual link scheduling algorithms can be used by the End System [18].



Lmax, the largest Ethernet frame, in bytes, that can be transmitted on the virtual link.



Jitter is an upper bounded transmit latency appearing as a frame time offset within the BAG as shown in figure4.5.

29

Chapter 4: AFDX

Figure4.5 Bandwidth Allocation Gap (BAG) & Jitter

In transmission, the maximum allowed jitter on each VL at the output of the ES should comply with both of the following formulas:

{

∑𝑗𝑗𝑗𝑗 {𝑠𝑠𝑠𝑠𝑠𝑠 𝑜𝑜𝑜𝑜 𝑉𝑉𝑉𝑉𝑉𝑉 �20𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏 + 𝐿𝐿𝑚𝑚𝑚𝑚𝑚𝑚 𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏 � × 8𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵/𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏 max⁡_𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗 ≤ 40µ𝑠𝑠 + 𝑁𝑁𝑁𝑁𝑁𝑁𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏 /𝑠𝑠 max⁡_𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗𝑗 ≤ 500µ𝑠𝑠

max_jitter is in micro-seconds (μs); Nbw is medium bandwidth in bits/s; Lmax is in octets, 40μs is a typical minimum fixed technological jitter According to the formula, the maximum allowed jitter will be lower for end-systems having few VLs and small frame sizes to process. In all cases, the jitter is bounded at 500μs to limit the impact on determinism for the whole network.

4.4.2 Flow Regulation Figure4.6 shows the role of the Virtual Link Regulators in spacing the frames from the virtual link queues to create zero-jitter output streams. The outputs of the Regulator consist of regulated streams of AFDX frames based on the Bandwidth Allocation Gap (BAG) which is unique to each VL.

Figure4.6 Virtual Link Regulation

30

Chapter 4: AFDX

4.4.3 Flow Scheduling The Virtual Link Scheduler is responsible for multiplexing the regulator outputs as shown in figure4.7. Jitter is introduced when the Regulator outputs are combined by the Virtual Link Scheduler MUX; Ethernet frames arriving at input to the MUX at the same time will experience queuing delay (jitter).

Figure 4.7 Virtual link Scheduler

4.5 AFDX Network Protocol 4.5.1AFDX Protocol layers AFDX protocol comprises five layers, as shown in Figure 4.8.As a protocol derived from Ethernet, the AFDX Media Access Control (MAC) data link layer is almost identical to the Ethernet MAC layer. The only difference, as shown in figure 4.9, is the so called Sequence Number (SN) which can optionally be inserted as the last byte of the Ethernet payload. The function of the SN will be explained in section 4.6. On top of the Ethernet layer, AFDX implements the Internet Protocol (IP) layer which manages frame fragmentation and re-assembly as well as packet forwarding. The latter, however, is not being used in AFDX since the routing is carried out on a VL basis. The last protocol layer of the AFDX protocol stack is the User Datagram Protocol (UDP) which is connectionless with no transmission error control. UDP was chosen since it is more efficient than the alternative Transmission Control Protocol (TCP). Although TCP is a connectionoriented protocol providing transmission error control, this is not required since 31

Chapter 4: AFDX the AFDX bandwidth policing and redundancy management ensures a very low frame loss probability. The UDP payload holds the ADFX user data [19].

Figure 4.8 AFDX protocol layers

Figure 4.9 AFDX protocol stack [19]

4.5.2AFDX Frame Structure Figure 4.10 shows the AFDX frame structure which consists of following fields. Ethernet Preamble To signal the transmission of a new message on the network, the transmitting ES sends out a stream of bytes, called the preamble, prior to transmission of the actual 32

Chapter 4: AFDX frame. The preamble consists of alternating 0 and 1 bits that give the receiving ESs time for synchronization and otherwise prepare for reception of the actual frame. At the end of the preamble, the transmitting ES sends out the Start Frame Delimiter (SFD) to break this pattern and signal the beginning of the actual frame immediately after the SFD. MAC Addressing [21] A Virtual Link should only be identified by the MAC destination address, and the MAC source address of AFDX frames should be the MAC unicast address used to identify the physical Ethernet interface. •

Destination address

A MAC destination address in the AFDX frame should be a Group and Locally Administered address and should be compliant with the following format. As shown in figure 4.12 each ES should get "constant field" and "Virtual Link Identifier" values from the system integrator. The constant field should be the same for each ES in any given AFDX network. The least significant bit of the first byte indicates the group address (always = 1). In order to use the standard Ethernet frame, MAC group addresses should be used to send frames from End System to End System(s). The second to least significant bit of the first byte indicates the locally administered address (always = 1). Even if at MAC layer, only group addresses could be used, unicast communication can be seen at IP layer level by using IP unicast destination address. •

MAC Source Address The Constant field is set to “0000 0010 0000 0000 0000 0000” as shown in Figure 4.13. The least significant bit of the first byte indicates the Individual Address = 0. 33

Chapter 4: AFDX The second to least significant bit of the first byte indicates the locally administered address = 1. The User_Defined_ID is a single 16-bit field. It should be used as the system integrator deems appropriate to give each IP addressable host on the network a unique and meaningful IP address. The Interface_ID, indicates to which redundant AFDX network(s) the Ethernet MAC controller is connected (001 network A, 010 network B) Protocol type After the MAC addresses follows the Ether Type field which is used to indicate which protocol type is transported in the Ethernet frame. In AFDX this 2 byte field always has the value 0x0800 meaning Internet Protocol, Version 4 (IPv4). Ethernet Payload Following the Ether Type field is the Ethernet payload which contains the IP structure, the UDP structure as well as the AFDX payload followed by the Sequence Number (SN). The IP and UDP structures are 20 and 8 bytes long, respectively and the SN is 1 byte long. Since the Ethernet frame is specified to be in the range of 64 to 1518 bytes, the ADFX payload must consequently be in the range 17 to 1471 bytes. This calculation is done by simply subtracting the protocol overhead (6 + 6 + 2 +20 + 8 + 1 + 4 = 47) from the max. and min. frame sizes. Furthermore, by using padding it's possible to specify the AFDX payload down to 0 bytes. Ethernet Error Control The last field of the Ethernet frame is the Frame Check Sequence (FCS) which is 4 bytes long. The transmitting ES uses the Cyclic Redundancy Checksum (CRC) algorithm to calculate a checksum over the entire frame which is then appended as trailing data in the FCS field. The receiving ES uses the same algorithm to 34

Chapter 4: AFDX calculate the checksum and compare it with the received checksum. If the two checksums are not identical the receiving ES discards the frame Ethernet Postamble Ethernet specifies a minimum idle period between transmissions of frames called the Interframe Gap (IFG), which is not strictly required by AFDX. However, for reasons of compatibility, the IFG also applies to AFDX. The IFG is specified to be 96 bit times, i.e. the time it takes to transmit 96 bits on the network. On a 10Mbit/s network, the IFG idle time is thus 9.6 us. On a 100 Mbit/s network, the IFG idle time is 960 ns.

Figure 4.10 the AFDX frame structure [19]

4.11. AFDX frame destination address

35

Chapter 4: AFDX

4.12. AFDX frame source address

4.6Network Reliability[19] The inherent AFDX features such as traffic shaping (bandwidth management and bandwidth policing) and limited transmit latency and jitter, make AFDX a deterministic and reliable network. However, in order to improve reliability even further, the AFDX network has a double, i.e. a redundant network transmitting the exact same data. The two AFDX networks are called "network A" (also "red network") and "network B" (also "blue network"). The purpose of the redundant network is to mitigate the consequences of potential network failures caused by e.g. damaged cables and connectors or devices (e.g. switches) generating babbling data. Since ultimately only one valid data stream is required by the ES application, a handling of the redundant streams is required. As depicted in figure4.13, the ES implements Integrity Checking (IC) and Redundancy Management (RM) to ensure data integrity and that only one data stream is forwarded to the upper protocol layers and from there to the application. The IC and RM services are provided by the ES without the involvement and knowledge of the application.

36

Chapter 4: AFDX

Figure 4.13 AFDX Integrity Checking and Redundancy Management [19]

4.6.1Integrity Checking (IC) The first step for handling the redundant data streams is the IC, which is done separately for each network and on a per VL basis. The function of IC is to detect and eliminate invalid frames. The IC is applied on the MAC layer, i.e. on the Ethernet frame which contains a one byte Sequence Number (SN) as the last byte of the payload as illustrated in figure 4.11. The SN is the basis for the IC algorithm and is used differently in transmitting and receiving mode. •

SN Usage in Transmitting Mode

The SN is a value in the range 0 - 255 and is handled separately for each VL on each of network A and B. Prior to transmission, the SN is incremented by one for each consecutive frame (whether fragmented or not) on the same VL. With SN = 255 in the last transmitted frame, the SN is wrapped around to 1 in the following frame. Upon a reset or start-up of the transmitting ES, the SN is set to 0 in the first transmitted frame. •

SN Usage in Receiving Mode

In receiving mode, the IC uses the SN to determine if frames have been lost or whether a babbling switch is causing the same frame (with the same SN) to be

37

Chapter 4: AFDX transmitted over and over again. The IC algorithm accepts all frames that comply with one of the following criteria: •

SN = 0 (The transmitting ES is started or reset)



SN = Previous SN + 1



SN = Previous SN + 2

All frames not complying with these criteria are discarded.

4.6.2 Redundancy Management (RM) The purpose of the Redundancy Management (RM) is to evaluate the two frame sequences delivered by the IC, discard possible duplicate frames, and forward only one copy of each frame to the upper protocol layers. The RM makes use of the configurable SkewMax parameter which is given in ms and must be specified for each receive-VL defined in the ES. SkewMax defines the maximum allowed time between the reception of two redundant frames (i.e. with the same SN), one received on network A and the other on network B. If SkewMax is not exceeded, the RM applies a "first-valid-wins" policy on the two frames, i.e. the first received frame is forwarded whereas the later received frame is discarded. However, if SkewMax is exceeded, the RM considers the two frames to be different from each other and hence forwards both. In the case where the RM is disabled, both frame sequences are forwarded directly from the IC to the upper layers. Figure 4.15 illustrate the behavior of RMA and IC .IC_B discarded frame B99 as it is not in the correct sequence. RMA accepted frame B5 not A5 based on "firstvalid-wins" policy

38

Chapter 4: AFDX

Figure 4.14 Example for RMA and IC behavior [12]

The Redundancy Management function must forward only in-sequence frames, but reordering is not required. As a consequence, in some cases, the loss of one frame on one network could also lead to the loss of its copy. For example, in Figure 4.16, the frame “A2” is lost on the A network and the frame “A3” arrive on this network before the copy “B2” of the lost frame arrives on the B network. In this case, the copy B2 will not be forwarded to the partition despite being the first #2 frame received.

Figure 4.15 loss of a frame

39

Chapter 4: AFDX Other Redundancy management algorithms are proposed to overcome this faulty behavior. More details can be found in [22].

4.7 AFDX Switch [19] [21] The purpose of the AFDX switch is to physically interconnect the ESs and police that the communication takes place according to the network configuration. As depicted in figure 4.16; the switch consists of various components each performing a certain task of the switch.

Figure 4.16 AFDX Switch Architecture [3]

The main component of the switch is the switching function which implements a filtering and policing function to ensure that only valid incoming frames are forwarded to the right physical ports. The setup of the switching function is done using configuration data held in static configuration tables. The purpose of the monitoring function is to monitor and log all switch operations and events such as frame arrivals and invalid frames. The Monitoring function 40

Chapter 4: AFDX communicates with the network management function for operational and health related information. The purpose of the switch ES is to provide a means for functions that are external to the network to communicate with the switch. For example data loading and network management functions communicate with the switch via the embedded ES.

4.7.1 Frame Filtering The switch filtering functions examines all incoming frames and ensures that only valid frames are forwarded to selected destinations. The filtering function verifies the following: •

Ethernet destination address validity, i.e. the validity of the VL identifier including the constant part



The VL is received on an allowed destination port according to the configuration table



FCS Validity



Ethernet frame size range, i.e. the frame size must be in the range 64 -1518 bytes

Incoming frames not complying with these conditions are automatically dropped.

4.7.2 Traffic Policing Traffic policing can be implemented using two different algorithms of which one uses byte-based policing and the frame-based policing. The byte based traffic policing filters out the VL in terms of bandwidth usage expressed in bits per second.The frame-based traffic policing filters out the VL in terms of bandwidth usage expressed in frames per second. The switching function may implement one or both of the two algorithms. The implemented algorithm(s) operates on the basis of the VL identifier contained in the MAC destination address. The VL defines a traffic flow and is characterized 41

Chapter 4: AFDX by certain properties such as BAG, jitter and group of recipients. The properties of each VL are contained in the configuration tables. Traffic policing ensures containment of faults caused by ESs. Incoming frames that do not comply with the configuration of the traffic flow (VL) to which they belong are automatically discarded by the policing function.

4.8 Fault tolerant features As we mentioned before in chapter 2 section 6, one of the fault tolerant mechanisms is redundancy. At AFDX static redundancy is used. At transmission, End System duplicates the frame and sends them at the same time. At reception, End System checks that frames received in correct sequence by Integrity Check and selects one of the duplicated frames by Redundancy Management. Network redundancy overcome faults which come from physical disconnect of wires and switch failures.

4.9 Summary AFDX protocol is based on conventional Ethernet which adapted to meet the Avionics requirements as determinism and reliability. Physical and data link layers are changed. Redundancy in Physical layer, duplicated network, is used to fulfill reliability. Virtual Links, divide physical channel to logical channels with dedicated bandwidth, is used to achieve determinism. Avionics networks are safety critical and real time network, so one of the most important performance evaluation parameters is end to end delay. In the next chapter a simulation model for AFDX is developed to calculate End to End delay

42

Chapter 5: AFDX modeling

Chapter 5 AFDX modeling AFDX network consist of two main elements: ES which generates and receives AFDX frame and Switch which responsible for physically interconnect the ESs and police that the communication takes place according to the network configuration. Figure 5.1 show the AFDX network elements and a simple hierarchy of each element.

Figure 5.1 AFDX network elements [26]

5.1 End System (ES) 5.1.1 Transmitting ES As shown in figure 5. 2 The transmitting ES consists of: 1- Regulators: regulates frames coming from Virtual Links based on BAGs 2- Schedule (Multiplexer): multiplexes the frames coming from several Virtual Links and conducts to Redundancy Management. 43

Chapter 5: AFDX modeling 3- Redundancy Management unit: produces two instances of the same frame if not disabled. 4- MAC interface: put its source MAC address to the frame and passes to the physical layer. Regulator

BAG PHY. Layer

VL1

MAC A

Scheduler

Regulator

BAG

Redundancy

VL2

Regulator

MUX

Management

BAG

PHY. Layer

MAC B

VL3

Figure 5.2 transmitting ES

5.1.2 Receiving ES As shown in figure 5.3 the receiving ES consists of: 1- MAC interface: Received frames (according to MAC number, after CRC) are passed to Integrity Check. 2- Integrity Check unit:

checks the Sequence Numbers and passes to

Redundancy check if not disabled. If RM is disabled, both frames pass to next step. 3- Redundancy check unit: passes the first valid frame to de-multiplexer. 4- De-multiplexer: delivers frames according to Virtual Links to the upper layer.

Figure 5.3 receiving ES

44

Chapter 5: AFDX modeling 5.2 AFDX Switch As shown in figure 5.4 switch models consists of: Configuration Table

1- I/O queuing ports. 2- The switching function which implements a

Switching function

filtering and policing function to ensure that only valid incoming frames are forwarded to

Filtering/Traffic policing

the right physical ports. 3- configuration table is a static table which is responsible for setup of the switching function

I/O ports

Figure 5.4 switch model

5.3 AFDX simulation model Developing simulation model is important step to evaluate network performance. As Avionics networks are real time and safety critical network so that the end to end delay is the most important parameter we are interested in.

5.3.1 Model specifications 1- Model is built in OPNET 2- It is based on OPNET Ethernet model 3- It covers up to data link layer in AFDX protocol 4- Model consist of ES model and AFDX switch model

5.4 OPNET Modular OPNET stands for Optimized Network Engineering Tools. It is used widely by researchers, engineers, university students. It supports time-clocked simulation and discrete event simulation. The programming language for writing OPNET Models is called Proto-C. There are not many syntax differences between 45

Chapter 5: AFDX modeling programming in C and Proto-C. The major difference is the methodology adapted by Proto-C to program models. Unlike programming standalone C/C++ applications, Proto-C is designed to handle OPNET predefined data types via an existing simulation engine, which can be regarded as a half-done application in a standalone C/C++ application. This simulation engine needs to incorporate the Proto-C model code to generate a final runnable and debuggable standalone simulation application [20].

5.4.1Opnet models Node model: Layering of protocol functions Process model: consist of states. Transitions describe the possible movement of a process from state to state and the conditions allowing such a change. Type of sates: •

Initial state.



Forced state: does not allow pause during the process (Green).



Unforced state: allows pause during the process (Red).

Each state has enter-executives and exit-executives.

5.4.2 Modeling approach Opnet Modeler provides a structured modeling approach as shown in figure5.5 •

Nodes and links make up the network model



Node model contains various modules



Each module contains one or more processes



Each process has a state transition model



Each state of the state transition model contains logic in C/C++.

46

Chapter 5: AFDX modeling

Figure5.5 OPNET Modeling approach

5.5 End system model As AFDX is similar to Ethernet ,so that opnet node model named ethernet_station_adv which shown in figure 5.6 is choosen to be the base of AFDX EndSystem node model as in figure 5.7 .

Figure 5.6 node: ethernet_station_adv

47

Chapter 5: AFDX modeling

Figure5.7 AFDX End System node

The ES node is designed by: 1- Modifying the following Ethernet station node blocks •

Data generation block: it is based on bursty_source process model as shown in figure5.8. “init” state Schedules the first OFF-period by setting a self-interrupt for the start time. “off” state Determines the time for which the process remains in the "off" state. When the "off" state duration expires, a self-interrupt will be Scheduled to transit to the "on" state. “on” state Determines the time at which this process will enter the next "off" 48

Chapter 5: AFDX modeling state. Then. It Generates the packets based on the loaded parameters for traffic generation. . It is modified to generate AFDX data format frame and insert Virtual Link identifier to the generated frame

Figure5.8 bursty_source process model •

MAC block: it is based on Ethernet_mac_v2 process model as shown in figure5.9. AFDX is a full duplex, so the half duplex section, surrounded by red line in figure 5.9, in the model is deleted .”INIT” state initializes state variables. It Checks if this MAC is unconnected or not .if it is unconnected, it transits to “unconnect” state. If it is not unconnected, it transits to “start” state. “start” state Initializes the variable that indicates the earliest time when the next transmission can take place in .it Determines the input and output stream indices to be used when sending/receiving packets from the MAC interface layer after this it schedules interrupt to transit to “FDX” . in case of interrupt comes from “start” state, “FDX” state detect if stream comes from physical layer or higher layer. If it comes from physical layer, it will be accepted and encapsulated. If it comes from higher layer, it will be accepted and queued. Addressing is changed to meet AFDX requirement as mentioned in section 4.5.2. After packet processing a self interrupt will be sent to “FDX” state to begin to process the next packet.

49

Chapter 5: AFDX modeling

figure5.9 Ethernet_mac_v2 process model

2- Adding the new AFDX blocks •

Transmitting : Regulator: regulate packets from data generator by BAG. Regulator

process model is shown in figure5.10. This model is based on acb_fifo process model. “init” state set the server to idle and get BAG parameter. It transits to “arrival” state when packet arrives or transits to idle as a default. “transit” state inserts packet in queue. If it failed to insert the packet, it destroys it.

When

server is not busy and insertion is ok, it transits to “BAG” state. At “BAG” state server is changed to busy and the packet is handled from the queue. an interrupt is scheduled for this process based on the BAG time and then, it transits to “idle” state .when packet service time complete it transits to “ svc_compl” state which sends packet and changes server to idle again.

50

Chapter 5: AFDX modeling

Figure5.10. regulator process model

Scheduler: it multiplexs packets come from regulators. Figure5.11 shows scheduler process model which is based on acb_fifo model. It operates like the regulator but differs in “svc_start” state. The service time in scheduler depends on the service rate of scheduler not BAG time.

Figure5.11 Scheduler process model

Redundancy management: figure 5.12 shows Redundancy management process model. “INIT” state gets packet. If it is the first packet in the stream or in 51

Chapter 5: AFDX modeling case of rest, it adds SN=0. Otherwise SN begins from 1 to 255. After adding SN, it transits to “out1, 2” to duplicate packet and sent both of them.

Figure5.12 Redundancy management process model

Receiving: Integrity check: it checks that frames come in correct order using sequence number. “Intial” state gets packet and extracts SN from it. If SN=0, it transits to “RESET” state which store pervious SN and sent packet. Otherwise it transits to “NORMAL” state which check current SN equals SN +1 or +2 .if not it discard packet. Figure5.13 shows Integrity Check process model.

Figure5.13 Integrity Check process model.

52

Chapter 5: AFDX modeling Redundancy check: the process model of redundancy check is shown in figure5.14. It selects one of the redundant frames based on RM algorism13 proposed in [22]. It is chosen because it is very robust against critical sequence number resets.

Figure5.14 redundancy check process model

5.6 Switch model Switch node as shown in figure5.15 is based on Ethernet switch node Ethernet16_switch_adv. Switch node consists of two main process models MAC and Switch. MAC process model is modified to meet AFDX requirement as the one in End System. Switch process model in Ethernet totally differs from AFDX switch. In Ethernet16_switch_adv, switch process is done by building up table to learn all MAC’s connected to switch process model. Then, mapping this MAC’s to ports and building spanning tree table to route frames to the right destination. But, in 53

Chapter 5: AFDX modeling AFDX, switching is static. A forwarding table is statically built and input to switch process model to begin to send frame according to this table. Figure5.16 shows the switch_core process model which is responsible for mapping the connected End System to switch ports and send frames to another embedded process model called switch_mac_relay_afdx, shown in figure 5.17, which is responsible for acquiring the forwarding table file and routing the packets according to it.

Figure5.15 AFDX Switch node

54

Chapter 5: AFDX modeling

Figure5.16 switch_core process model

Figure5.17 switch_mac_relay_afdx

The forwarding table in a .CSV an example for it is shown in figure5.18.for each switch, the virtual link identifier (VL_ID), Source MAC address of the Virtual link (Src_add) and Destination address of the Virtual link (Dst_add) are written.

Figure5.18 forwarding table example

55

Chapter 5: AFDX modeling

5.7 Model Verification and Validation One of the most difficult problems facing the simulation analyst is determining whether a simulation model is an accurate representation of the actual system being studied. If the simulation model is not valid, then any conclusions derived from it are of virtually no value. So, Validation and verification are two of the most important steps in any simulation project. Figure5.19 shows validation and verification relations between real world system, conceptual mode and simulation program.

Figure5.19 model verification & validation

5.7.1 Model Verification Verification is the process of determining whether a simulation computer program works as intended (i.e., debugging the computer program). Verification is iterative process which deals with building the model right. This is done by dividing the AFDX nodes to modules. Each module is debugged using OPNET modeler debugging mode to check it operate correctly. Then the complete AFDX nodes are assembled and its operation is verified with the conceptual model by using trace point and animation of OPNET modeler debugging mode.

5.7.2 Model validation Validation is the process of determining whether the model is an accurate representation of the actual system being analyzed. Validation deals with building 56

Chapter 5: AFDX modeling the right model. This is done by comparing calculated End-to-End delay results of AFDX network with the simulation results of the same network.

5.7.2.1 End-to-End Delay Determinism is one of avionics requirements. As illustrated in chapter 4, AFDX ensures a deterministic behavior through traffic control. Traffic control is achieved by guaranteeing the bandwidth of each logical communication channel, called a Virtual Link (VL), thereby limiting the jitter and transmit latency. This determinism has to be proved for certification reasons and an important challenge is to demonstrate that an upper bound can be determined for end-to-end communication delays. Characterization of the end-to-end delay of a VL [16]: Let’s consider a path px of a VL v. The end-to-end delay D(Fv, px) of a frame Fv transmitted on px is defined by D(Fv , px ) = LD(Fv , px ) + SD(Fv , px ) + WD(Fv , px ) Where: • LD(Fv, px) is the transmission delay over the links. the transmission delay over a link is tbyte × s(Fv) where tbyte is the transmission time of one byte and s(Fv) is Fv length. Therefore, considering that all the links have the same bandwidth c (consequently, tbyte is the same for all the links), LD(Fv , px ) = nbl(px )×(tbyte × s(Fv )) Where nbl(px) is the number of links in px. • SD(Fv, px) is the delay in switches between input and output ports. This is technology delay which is bounded by a constant for specified hardware and switch capacity.ti is a guaranteed upper bound of 16 μs[16]. Thus SD(Fv , px ) = nbs(px ) × td Where nbs(px) is the number of switches in px.

57

Chapter 5: AFDX modeling • WD(Fv, px) is the delay in switches and end system output buffers: this delay highly depends on each output port load at the time where Fv reaches it. Thus WD(Fv, px)= WD(Fv, px, ev) + ∑𝒔𝒔𝒔𝒔∈𝜳𝜳𝒑𝒑𝒑𝒑 𝐖𝐖𝐖𝐖(𝐅𝐅𝐅𝐅, 𝐩𝐩𝐩𝐩, 𝐬𝐬𝐬𝐬)

Where ev is Fv source end system, 𝛹𝛹𝑝𝑝𝑝𝑝 is the set of switches in px, WD(Fv, px, ev) is the delay in ev output buffer and WD(Fv, px, sk) is the delay in sk output port buffer. Consequently, D(Fv, px) can be divided into a fixed part LD(Fv, px) + SD(Fv, px) and a variable part WD(Fv, px). •



The fixed part can be statically computed since it depends on:  The path px  The length of the frame Fv  The bandwidth o the links. The variable part depends on Dynamic characteristics such as:  

The sequence of frames which are emitted by each VL (the length of each frame) The offsets between the different VLs, i.e. the emission instant of the first frame of each VL.

5.7.2.2 An Example of AFDX network 5.7.2.2.1 Topology This network consists of Five End Systems, five virtual links and three switches connected as in figure 5.20

Figure 5.20 network topology

58

Chapter 5: AFDX modeling

5.7.2.2.2 Configuration table This configuration includes five unicast VLs v1. . . v5. The parameters of these VLs - their BAGs, frames sizes and paths - are given in table 5.1.The bandwidth of every link is 100 Mb/s (tbyte = 0.08 μs).

Table 5.1 configuration table

5.7.2.2.3 Scenarios The analysis focuses on the end-to-end delay of the frame F1 of VL v1 (The path is p1 = e1 - s1 - s3 - e6).as shown in figure 5.21.there are three scenarios will be discussed as shown in figure5.22.In scenario a, (e1) sends frame (1) of 500 byte .this frame will wait for frame (2) in the output buffer of switch (s1) and for frame (3) at switch (s3). Scenario b, (e1) sends frame (1) of 300 byte .this frame will wait for frame (5) in the output buffer of switch (s3). Scenario c, (e1) sends frame (1) of 500 byte but no frame is sent by (e5).

Figure 5.21 selected Virtual Link path

59

Chapter 5: AFDX modeling

Figure 5.22 network simulation scenarios

5.7.2.2.4 Simulation network Figure5.23 shows the AFDX network mapped in OPNET .source end system is named E1 and the destination end system is named E6.

Figure 5.23 AFDX network mapped in OPNET

60

Chapter 5: AFDX modeling

5.7.2.2.5 Simulation results The first result to check is the delivery of frames from source to destination. In figure 5.24 shows that all frames were generated from End system (E1) were received at the destination end system (E6).

Figure 5.24 packets generated from End system 1 & packets received in (e6-E1)

The simulation results of the end to end delay for each scenario are shown in figure 5.25, figure 5.26 and figure 5.27. End to end delay of scenario a =213µsec, scenario b =129µsec and scenario c=152µsec.

61

Chapter 5: AFDX modeling

Figure 5.25 end-to-end delay (scenario a)

Figure 5.26 end-to-end delay (scenario b)

62

Chapter 5: AFDX modeling

Figure 5.27 end-to-end delay (scenario c)

5.7.2.2.6 Simulation v.s. Calculated results End to end delay calculation •

LD (F1, p1): path consists of 3 segments. The bandwidth of every link is 100 Mb/s (tbyte = 0, 08 μs).so transmission delay =(3x(0.08 x frame length in bytes))



SD (F1, p1): delay in switches = (no of switch x switch delay). Switch delay is assumed to be zero in this example [23].



WD (Fv, px): delay in switches buffers. It is dynamic delay and depends on various parameters as frames order and size.

Table 5.2 summerize the calculation of end to end delay of VL1 for the three scenarios. And compare it with the simulation results. LD(F1, p1) scenario a

3 × (0,08 × 500) = 120 μs scenario b 3 × (0,08 × 300) = 72 μs scenario c 3 × (0,08 × 500) = 120 μs

WD(Fv, px) 𝑫𝑫(𝑭𝑭𝑭𝑭, 𝒑𝒑𝒑𝒑)𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 𝑫𝑫(𝑭𝑭𝑭𝑭, 𝒑𝒑𝒑𝒑)𝑠𝑠𝑠𝑠𝑠𝑠 60μs 35 μs

180 μs 107 μs

213 μs 129 μs

0 μs

120 μs

152 μs

Table 5.2 calculation of VL1end to end delay V.S. simulation results scenarios.

63

Chapter 5: AFDX modeling It is found that simulation results are greater than the calculated one because in simulation the switches delay is taken into account. If the switches delay is added to the calculated results, the simulation results will be all most equal the calculated one for example, in scenario c if we add switches delay which is equal to (2x16=32), the end to end delay will be 120+32=152 μs. Depending on the previous analysis, this model is valid to represent AFDX Es and switch nodes.

5.7.2.2.7 Summary In this chapter the developed AFDX model on Opnet is presented .it covers up to data link layer of the AFDX protocol. This model will be the base of next part of the thesis which focuses on simulation of an AFDX network. It is important to make sure that this model is valid to represent the AFDX network in acceptable range. So, the AFDX end to end parameter is discussed and an example for AFDX network was simulated. The simulation results were accepted compared with the calculated one which means that this model is valid. In the next chapter AFDX network simulation and analysis of network performance is presented.

64

Chapter 6: AFDX Network simulation and analysis

Chapter 6 AFDX Network simulation and analysis AFDX network Case study represents a part of flight management system (FMS) [24].This system manages part of the displays in the cockpit. It provides some information on a waypoint requested by the pilot and periodically refreshes dynamic data related to this waypoint (distance and estimated time of arrival).

6.1 System function and operation Pilot and co-pilot interact with FMS through displays and keyboards. They input their request through keyboard and the system displays the waypoint information. For safety reasons, the FMS is based on a redundant architecture .it is composed of two channels rated 1 and 2.On each channel i, the FMS is composed of a function Kui (For Keyboard and cursor Control Unit) controls the keyboard and function MFDi (For Multi Functional Display) managing the discharge pages with navigation information. Pilot or co-pilot can enter a waypoint display request. This request is received by the KU function i (i = 1 for the pilot, i = 2 for the co-pilot). This request is then sent to flight managers FM1and FM2 (FM Flight Manager) which send parallel request to navigation database (NDB for navigation Data Base). NDB replies to FM with the static waypoint information. Waypoint information is periodically updated by FM based on flight data (speed, position,. . . ) which are

Produced by Air Data Inertial Reference Units

(ADIRU)s. Finally, each FMi periodically sends this information to each MFDi which sends it to displays. Figure 6.1 represents the signal flow from pilot or co pilot request to waypoint display. 65

Chapter 6: AFDX Network simulation and analysis

Figure6.1. FMS message flow

-The variables exchanged between these functions are: -

Reqi: The request from the pilot or co-pilot,

-

WpIdi: The identifier of the waypoint selected by the pilot or co-pilot,

-

Queryi: The request sent to the NDB by FMi to retrieve information from the waypoint

-

Answeri: Response sent to FMi by NDB containing the waypoint information,

-

WpInfoi: The waypoint information transmitted between FMi and MFDi,

-

Dispi: The displayed page by MFDi combining static waypoint information and the time ETA Estimated time of arrival i,

-

Presi: The value of the atmospheric pressure outside the aircraft,

-

Speedi: The value of the speed of the product deduced from the external pressure,

-

ETAi: The estimated time of arrival at waypoint

66

Chapter 6: AFDX Network simulation and analysis

6.2 System Architecture

Figure6.2. FMS system architecture [24]

System network, as shown in figure 6.2., consists of 7 modules which represent 7 End systems. Module 1 and 2 each consists of 2 sub-end system. Sensor 1and 2 interfaced with AFDX network through RDC (Remote Data Concentrator). Interconnecting between network End systems is done through 5 switches.

6.3 configuration parameters Table 6.1 contains the size of messages which are sent by each end system. Table 6.2.contains the period, duration and offset for each end system to send their message. Table 6.3 contains virtual links configuration parameters. Each Virtual Link is defined by a source, a destination or destinations, a path and Bandwidth Allocation Gap (BAG). 67

Chapter 6: AFDX Network simulation and analysis Variable req1,req2 wpId1,wpId2 query1,query2 answer1,answer2 wpInfo1,wpInfo2 pres1,pres2 speed1,speed2 ETA1,ETA2 disp1,disp2

Size (bits) 600 600 1000 4000 5000 512 800 1000 8000

Table6.1 messages size

Partition

period (µs)

duration (µs) offset (µs) module

KU1 MFD1

50 50

25 25

0 25

1 1

KU2 MFD2 FM1 FM2 ADIRU1 ADRIU2 NDB

50 50 60 60 60 60 100

25 25 30 30 30 30 20

0 25 0 0 0 0 0

2 2 3 4 5 6 7

Table6.2 End systems sending time parameters

Virtual Links VL1 VL2 VL3 VL4 VL5 VL6 VL7 VL8 VL9 VL10 VL11

Source KU1 KU2 FM1 FM1 FM2 FM2 NDB NDB RDC1 RDC2 ADRIU1

Destination(s) variable (s) BAG(ms) FM1,FM2 wpId1 32 FM1,FM2 wpId2 32 MFD1 wpInfo1,ETA1 8 NDB query1 16 MFD2 wpInfo2,ETA2 8 NDB query2 16 FM1 answer1 64 FM2 answer2 64 ADRIU1 pres1 32 ADRIU2 pres2 32 FM1,FM2 speed1 32

VL12

ADRIU2 FM1,FM2

speed2

32

Table6.3. Virtual links parameters

68

path(s) S1,S2 , S1,S3 S1,S2 , S1,S3 S2,S1 S2,S1 S3,S1 S3,S1 S1,S2 S1,S3 S4 S5 S4,S1,S2 , S4,S1,S3 S5,S1,S3 , S5,S1,S2

Chapter 6: AFDX Network simulation and analysis

6.4 Network simulation Network setup on OPNET is represented in figure6.3. It consists of 9 End systems and 5 switches .end system configuration parameters are shown in tables 6.1, 6.2 & 6.3. For switches, the technology latency is estimated to be140 µs in A380 [24]

Figure6.3 network setup on OPNET

6.4.1 Simulation results `The OPNET simulation results of end-to-end delay of VL1 to VL12 are displayed in Figure 6.4 as a function of the simulation time. Table6.4 summarizes the simulation results. Table 6.5 shows our simulated end-to-end minimum and maximum delay compared to the end –to-end delay given in reference [24].

69

Chapter 6: AFDX Network simulation and analysis

Figure6.4 virtual links End-to-End delay

Time (m, s)

70

Chapter 6: AFDX Network simulation and analysis

VLs VL1 VL1 VL2 VL2 VL3 VL4 VL5 VL6 VL7 VL8 VL9 VL10 VL11 VL11 VL12 VL12

Source

Destination

KU1 KU1 KU2 KU2 FM1 FM1 FM2 FM2 NDB NDB RDC1 RDC2 ADRIU1 ADRIU1 ADRIU2 ADRIU2

FM1 FM2 FM1 FM2 MFD1 NDB MFD2 NDB FM1 FM2 ADRIU1 ADRIU2 FM1 FM2 FM1 FM2

Simulation(µs) min max 298 317 298 321 298 317 298 318 310 467 310 360 310 470 400 432 400 434 400 463 152 154 152 154 452 478 452 495 452 487 452 487

Table6.4 virtual links min/max simulation End-to-End delays

VLs VL1 VL1 VL2 VL2 VL3 VL4 VL5 VL6 VL7 VL8 VL9

Source Destination BCTT(µs) WCTT(µs) KU1 KU1 KU2 KU2 FM1 FM1 FM2 FM2 NDB NDB RDC1

FM1 FM2 FM1 FM2 MFD1 NDB MFD2 NDB FM1 FM2 ADRIU1

298 298 298 298 310 310 310 310 400 400 150 71

444 444 444 444 490 450 490 450 508 508 156

Simulation(µs) min

max

298 298 298 298 310 310 310 400 400 400 152

317 321 317 318 467 360 470 432 434 463 154

Chapter 6: AFDX Network simulation and analysis VL10 VL11 VL11 VL12 VL12

RDC2 ADRIU2 ADRIU1 FM1 ADRIU1 FM2 ADRIU2 FM1 ADRIU2 FM2

150 452 452 452 452

156 584 584 584 584

152 452 452 452 452

154 478 495 487 487

Table6.5 simulation V.S. calculated End-to-End delay

6.4.2 Analysis of the simulation results In figure 6.4, the change in end to end delay of each VL is due to changing the start time to send frames of some VLs in the simulation configuration. This is done to cover wide range of scenarios because there are modules don’t send frames periodically. For example KU1 doesn’t send frame until pilot request From table 6.5, by inspecting the values given in the table, one sees that our simulation results are laying within the minimum and maximum computed end – to-end delay values in [24] which is acceptable for simulation approach. The end to end delay distribution of VL is of interest to characterize a network. Therefore, Figure 6.5 shows a typical simulated delay distribution of VL1. It is clear from the figure that the delay distribution is close to the calculated BCTT (Best Case Transmission Time) and far from the calculated WCTT (West Case Transmission Time). This is mainly due to the fact that the AFDX network is lightly loaded. Thus, the probability that several frames reach the same output port at the same time is very low.

72

Chapter 6: AFDX Network simulation and analysis

Figure6.5: end to end delay distribution of VL1

6.4.3 Analysis of E-to-E delay The previous analysis in 5.7.2.1 shows that the parameters affect end to end delay are frame size, switching delay and changing frames transmission order. Table 6.6 shows the results of end to end delay analysis for the fixed and variable parts of VL11, 7, 9 which represent max and min delays of VLs in the case study network. It is noticed from the table that: •

The switching delay SD (Fv, px) is the dominate part in the end to end delay of VLs. VL11,as shown in figure6.6, is the max end to end delay as it is the longest path (ADRIU2 - S5- S1-S2- FM1).



The Transmission delay LD (Fv, px) is high in VL7, shown in figure 6.6, having the path (NDB - S1-S2-FM1) as it transmits large frame size.



VL9 has the min end to end delay time as it is the shortest path),as shown in figure 6.7, (RDC1 - S4- ADRIU1)and smallest frame size. 73

Chapter 6: AFDX Network simulation and analysis

VL no.

path

11

ADRIU2 - S5- S1S2- FM1 NDB - S1-S2-FM1

7 9

E-to-E delay Fixed delay (Max) (µs) LD(Fv, px) SD(Fv, px)

Variable (Max) WD(Fv, px)

492

32

420

38

477

120

280

77

RDC1 - S4154 10.24 140 3.76 ADRIU1 Table 6.6: fixed and variable parts of end to end delay of VL11, 7, 9

Figure 6.6 VLs of (ADRIU1 to FM1) & (NDB to FM1)

74

Chapter 6: AFDX Network simulation and analysis

Figure 6.7 VLs of (RDC1 to ADRIU1)

In order to study the effect of the switching time on the end to end delay time a network simulation is done again using faster switches with delay around 16 µs [13]. Simulation results are shown in Figure6.8. Table 6.7 shows the fixed and delay parts of the paths after changing the switch delay. It is noticed that: •

The end to end delays in all VLs are decreased compared the previous case with longer switch delay. VL7 became the max end to end delay instead of VL11 as the transmission delay becomes higher than switching delay.



Variable delay part is changed in VLs. In VL 11 & 7, Variable delay decreased because using faster switches minimize the delay in the switches buffers. In VL 9, variable delay increase due to the change of the order of frames arrival time at switch 4 of the other VLs.

75

Chapter 6: AFDX Network simulation and analysis

Figure6.8: end to end delay of VL7, 9, 11 at switch delay =16 µs

VL no.

11

7

9

E-to-E delay path

(Max) (µs)

ADRIU2 - S5S1-S2- FM1 NDB - S1-S2FM1 RDC1 - S4ADRIU1

Variable

Fixed delay

(Max)

LD(Fv, px) SD(Fv, px) WD(Fv, px)

92

32

48

12

194

120

32

42

33

10.24

16

6.76

Table6.7: end to end delay fixed and variable parts of VL11, 7, 9 at switch delay =16 µs From the previous analysis, it is found that using faster switches and small frame size reduces the fixed part of the end to end delay. Also, it affects the variable part of end to end delay due to changing of delay in switches buffers and frames transmission order. 76

Chapter 6: AFDX Network simulation and analysis

6.5 AFDX VS. ARINC429 In this section the case study network will be built using A429 protocol. This means that the switching network will be replaced by point to point connection between T and Rx units and End system consist of N-partitions will be replaced by N- separate LRUs as shown in figure 6.9 . Comparison will be in the following points: • • • • •

Performance. Weight and Harness. Topology’s Reliability, Redundancy, and Flexibility. Partitioning. COTS Availability and Software Development.

77

Chapter 6: AFDX Network simulation and analysis

AFDX

ARINC 429

Figure 6.9 build AFDX network using ARINC429

78

Chapter 6: AFDX Network simulation and analysis •

Performance Table6.8 summarizes the differences between AFDX and ARINC 429.

As illustrated before, one of AFDX advantages is the high speed compared with old protocols like ARINC 429. Latency in AFDX not fixed as illustrated in 5.7.2.1 but, there are techniques to calculate safe boundary for it. Table6.9 shows the E-to-E delay of VLs in AFDX network and their equitant in ARINC 429 network. If VL1 is taken as an example, it can be found that ARINC 429 E-to-E delay is about 10~20 times of AFDX delay.

Speed Latency QoS

ARINC 429

AFDX

100 kb/s Fixed 100%

100 Mb/s Bounded Configurable

Table 6.8 AFDX versus ARINC 429

Table 6.9 the End to End delay of A429 vs. AFDX

79

Chapter 6: AFDX Network simulation and analysis •

Weight and Harness

According to the case study the table 6.10 shows the wiring required for each network.ARINC429 requires more wire than AFDX. Smiths Aerospace, the CCS designer, estimates the design utilizing AFDX on the Boeing 787 will yield a weight saving of more than 1000 pounds [25]. wiring ARINC429

16 shielded twisted pair

AFDX

12 shielded twisted pair + 5 switches Table 6.10 wiring in ARINC429 vs. AFDX

Topology’s Reliability, Redundancy, and Flexibility ARINC429 is point-to-point topology which is the most reliable one. AFDX is switched star topology which has little less reliability than point-to-point for a specific function. As shown in figure 6.10, redundancy in ARINC 429 requires Hardwire and wires to be double. In AFDX implores redundancy with dual switches.

Adding new subsystem in ARINC 429 requires adding new ARINC 429 interface for each subsystem the new one will communicate with. The capability to integrate with newer systems is limited by speed as well. In AFDX If another subsystem is added, it is simply connected to available ports on a switch as shown in figure 6.10and summarized in Table6.11.

80

Chapter 6: AFDX Network simulation and analysis

AFDX

ARINC 429

Figure 6.10 Redundancy & Flexibility of ARINC 429 V.S. AFDX

81

Chapter 6: AFDX Network simulation and analysis ARINC 429

AFDX

Topology

point-to-point

Reliability

the most reliable

switched star little less reliability than point-to-point for a specific function

Redundancy hardware and wire is doubled

Flexibility

redundancy with dual switches

New subsystem is added, every subsystem communicates with If another subsystem is added, it is must add another ARINC 429 simply connected to available ports on a interface. Limited by speed as switch well. Table6.11 Topology, Reliability, Redundancy and Flexibility

 Partitioning  ARINC 429 busses support a partitioned architecture only by way of physically separate busses.  AFDX compliant network harmonizes with the Integrated Modular Avionics concept [25].  COTS Availability and Software Development  With ARINC interfaces, customers must pay suppliers for software development because there is no off-the-shelf software for these interfaces to integrate into their systems.  SYSGO is even offering a “Portable AFDX” software node and host driver. This modular solution allows subsystem suppliers to add-in this capability without overhauling their hardware [25].

6.6 Summary In this chapter, A case study is discussed .it represents a part of flight management system (FMS). The network is simulated on OPNET using proposed model. Maximum and minimum End-to-End delays are analyzed. Parameters that affect the End-to-End delay is discussed. It is noticed that using faster switches and small frames minimizes the fixed part of End-to-End delay. The variable part is 82

Chapter 6: AFDX Network simulation and analysis affected by Dynamic characteristics such as the sequence of frames which are transmitted by each VL (the length of each frame) and the offsets between the different VLs, i.e. the emission instant of the first frame of each VL.

The AFDX Case study network is implemented using ARINC429 and comparison between the two networks is presented. The comparison between ARINC 429 and AFDX shows that AFDX provides better performance and flexibility without losing the compliance with safety, redundancy and reliability of Avionics requirements.

83

Chapter 7: Conclusions and suggested future research

Chapter 7 Conclusions and suggested future research 7.1 Conclusions A brief introduction for Avionics is presented. It shows the development in Avionics systems. With the rise of digital technology, equipment was designed to communicate with each other. The use of data bus became a need in aviation. Introducing data bus protocol helped to reduce wiring which represent a considerable weight to the aircraft. It also simplifies total design and maintenance. Then, a background on the old aircraft data networks is presented. It describes their basic specifications and characteristics. ARINC 429 and ARINC 629 protocols are introduced. ARINC 429 is simple point to point protocol which is used widely in the most of aircrafts and ARINC 629 is shred data bus developed by Boeing and is used in Boeing-777 aircraft. Then, AFDX (Avionics Full-duplex Ethernet) is presented. It is a promising network protocol which comes to meet the new avionics requirements. Compared with old avionics data bus networks, AFDX supports high speed up to 100Mbit/sec, flexible architecture and low cost. After introducing different types of aircraft data network, a proposed model for AFDX is presented. It is built on OPNET.AFDX case study network is introduced and simulated on OPNET. Simulation results and analysis is presented. Analysis of results shows parameters that affect End-to -End delays. End –to-End delay is divided to fixed part and variable part. Fixed part depends on number of switches in the path and switches speed. Also it depends on the transmission delay which depends on frame length. Variable part Dynamic depends on characteristics such 84

Chapter 7: Conclusions and suggested future research as sequence of frames which are emitted by each and the offsets between the different VLs. Also, the network case study is built using ARINC 429 and AFDX. A Comparison between the two networks shows that AFDX provides better performance and flexibility without losing the compliance with safety, redundancy and reliability of Avionics requirements.

7.2 Suggested future research 1- Updating proposed model to cover up to transport layer not only data link layer 2- Study the effect of routing the entertainment data traffic with Avionics Data traffic 3- Apply quality of service to the network .for example giving higher End-to End delay paths higher priority than the lower End-to-End delay paths .then, show it can help in improvement of the End-to-End delays of these paths.

85

Publications Extracted from the thesis

• Safwat, N. E. D., El-Dakroury, M. A., & Zekry, A. “The Evolution of Aircraft Data Networks”. International Journal of Computer Applications, 94, 2014. • Safwat, N. E. D., Abouelatta, M., & Zekry, A. “Avionics Fullduplex switched Ethernet (AFDX): Modeling and Simulation” will be published

86

References

References [1] Collinson, R. P. G., “Introduction to Avionics Systems”, Springer, 2003. [2] Faulconbridge, R.I., “Avionics Principles”, Argos Press, January 2007. [3] EMRE ERDİNÇ, “SOFT AFDX (AVIONICS FULL DUPLEX SWITCHED ETHERNET) ENDSYSTEM IMPLEMENTATION WITH STANDARD PC AND ETHERNET CARD”, Master These, MIDDLE EAST TECHNICAL UNIVERSITY, 2010. [4] “Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations”, DO-297, August 2008. [5] Shahsavar, Amin., “Defining a modular, high speed and robust avionic architecture for UAV's” ,Master thesis, lulea university of technology,2008. [6] Dan Gunnarsson, “Safety-Critical Communicationin Avionics”, Master These, Lund Institute of Technology, ISRNLUTFD2/TFRT--5782—SE, December 2006. [7] SAE, ARP4754, “CERTIFICATION CONSIDERATIONS FOR HIGHLY-INTEGRATED ORCOMPLEX AIRCRAFT SYSTEMS”, issue date 1996-11 [9] Anjali Joshi,Mike Whalen,Mats P.E. Heimdahl “Model-Based Safety Analysis Final Report” Advanced Technology Center,Rockwell Collins, Inc., [10] Ellis F. Hitt, Dennis Mulcare, “Fault-Tolerant Avionics”, Science Applications International Co. [11] AIRLINES ELECTRONIC ENGINEERING COMMITTEE, “ARINC SPECIFICATION 429 PART 1-17”, PUBLISHED: May 17, 2004 [12] AIRLINES ELECTRONIC ENGINEERING COMMITTEE, “ARINC SPECIFICATION 429P3-18”, PUBLISHED: OCTOBER 12, 2001 [13] Mike Tooley “Aircraft Digital Electronic and Computer Systems: Principles, Operation and Maintenance”, Butterworth-Heinemann, 2007 [14] “ARINC Protocol Tutorial” ZHHKTECH Co.ltd, 23 May, 2005. 87

References [15] Janusz Zalewski, Dawid Trawczyński, Janusz Sosnowski, Andrew Kornecki, MarekŚnieŜek “SAFETY ISSUES IN AVIONICS AND AUTOMOTIVE DATABUSES”.

[16] Ian Moir,Allan G Seabridge, “Civil Avionics Systems”, Professional Engineering Publishing Limited, London and Bury St Edmunds, UK.,2003 [17] Alban Gabillon , Laurent Gallon ,“Availability of ARINC 629 Avionic Data Bus”, IUT de Mont de Marsan, Université de Pau LIUPPA/CSySEC [18] “AFDX / ARINC 664 Tutorial (1500-049)” Condor Engineering, Inc. Santa Barbara, CA 93101, May 2005, ver: 3 [19] “AFDX® / ARINC 664 Tutorial”, ID : 700008_TUT-AFDX-EN_1000, TechSAT GmbH, Poing,Release Date 29/08/2008. [20] ZHENG LU, HONGJI YANG, “Unlocking the Power of OPNET Modeler” , Cambridge University Press 2012. [21] AIRLINES ELECTRONIC ENGINEERING COMMITTEE “ARINC SPECIFICATION 664P7”, PUBLISHED: June 27, 2005 [22] Jan Täubrich, “Formal Specification and Analysis of a Redundancy Management System with TLA+”, Diploma Thesis , September 21, 2006. [23] Jean-Luc Scharbarg, Christian Fraboul “Methods and Tools for theTemporal Analysis of Avionic Networks” Université de Toulouse - IRIT/ENSEEIHT/INPT, France,2010. [24] Michaël Lauer, “Une méthode globale pour la vérification d’exigences temps reel Application à l’Avionique Modulaire Intégrée”, 04 Jul 2012. [25] Teresa Schuster, “NETWORKING CONCEPTS COMPARISON FOR AVIONICS ARCHITECTURE”, 27th Digital Avionics Systems Conference October 26-30, 2008. [26] Implementation of the hardwired AFDX NIC; Pusik Park, Hangyun Jung, Daekyo Shin, Kitaeg Lim, Jongho Yoon; 1st Asia NetFPGA Developers Workshop; Daejeon, Korea; June 14, 2010.

88

Suggest Documents