2009:105 MASTER'S THESIS Modeling/Evaluation of ...1017316/FULLTEXT01.pdf2009:105 MASTER'S THESIS Modeling/Evaluation of Modular Spacecraft Avionics Network Architectures Yago Montenegro

2009:105

M A S T E R ' S T H E S I S

Modeling/Evaluation of ModularSpacecraft Avionics Network

Architectures

Yago Montenegro Mendez

Luleå University of Technology

Master Thesis, Continuation Courses Space Science and Technology

Department of Space Science, Kiruna

2009:105 - ISSN: 1653-0187 - ISRN: LTU-PB-EX--09/105--SE

SpaceMaster

Joint European Master in Space Science and Technology

2007/2009

THESIS REPORT

Modeling/Evaluation of Modular Spacecraft Avionics Network Architectures

Master Thesis carried out at EADS Astrium Satellites, Toulouse (France), from March to September 2009.

Author: Yago MONTENEGRO MÉNDEZ Supervisor: Luc PLANCHE and Olivier NOTEBAERT, EADS Astrium. Academic Supervisor: Christophe PEYMIRAT, CESR.


2

Abstract

Satellite or deep space exploration spacecraft avionics design is strongly determined by the need to achieve a long lifetime and to autonomously maintain safe operations in case of failure. To cope with an increasing demand in on-board processing and to make architectures more scalable and modular, future spacecraft data management architectures are about to implement solutions selected today by the commercial aircraft industry such as a central high speed backbone network linking processing nodes, with local lower throughput buses enabling such nodes to interact with sensors, effectors and other avionics equipment. Some specific issues to be consolidated today are the sequencing of communications between the high speed backbone and the local buses, the overall fault detection, isolation and recovery strategy and the priority management and monitoring functions to be included within backbone routers.

From an avionics engineering perspective, model driven engineering techniques are now being used to validate operation scenarios, estimate performances and ensure seamless transition between architectural design and the development of resulting hardware and software constituents. A valuable method to deal with the a.m. data management networking issues is to use the AADL (Architecture Analysis and Design Language), an SAE standard.

The scope of this document is to perform a review of the state-of-the-art of reconfigurable, fault-tolerant applications of router-based high speed data networks (mainly in aeronautics and automotive industries). Furthermore to compare and support the selection of solutions suited to spacecraft on-board networking needs through the use of AADL and provide feedback on the applied engineering methodology.


3

Acknowledgements

Without the guidance and support of many people, this work would not have been possible. I would like to acknowledge and thank each one of them.

I am grateful to the people from Data Processing and Advanced Studies (ASG74), a team synonym for expertise and innovation. They welcomed me with open arms and showed me how charming is the French culture. Within this team, once the problems arise, everyone is available and happy to lend a helping hand.

Special thanks go to my supervisors, Luc Planche and Olivier Notebaert, for the countless insights provided and their good advice.

I would like to extent my gratitude to Remi Roques, who opened this opportunity within the department.

On the other hand I would like to thank all the outstanding staff and lecturers of the SpaceMaster programme, together with my fellow SpaceMaster students, learning Space Science and Technology with all of them was a pleasure.

In the same way, I would like to thank the coordinator of the M2P TSI, Cristophe Peymirat, and all other lecturers for their patience with my French and their support.

Most of all, I owe my deepest gratitude to my family, who are everything to me. Thank you once again, GRACIAS!

Finally, I have no words to describe how fortunate I am for having the greatest person in the world next to me… Gracias Elena.


4

Table of Contents

1. INTRODUCTION............................................................................................................................. 8

1.1 DOCUMENT CONTEXT AND OBJECTIVE ........................................................................................... 8 1.2 THESIS SUBJECT.......................................................................................................................... 9 1.3 DOCUMENT ORGANISATION........................................................................................................... 9

2. DATA PROCESSING AND ADVANCED STUDIES DEPARTMENT (ASG74) ........................... 10

3. INTRODUCTION........................................................................................................................... 11

4. FLEXRAY ..................................................................................................................................... 12

4.1 PRESENTATION .................................................................................................................... 12 4.1.1 Technical summary .......................................................................................................... 12

4.1.1.1 Media Access Control ................................................................................................................ 12 4.1.1.2 Coding and Decoding ................................................................................................................ 13 4.1.1.3 Frame Format ............................................................................................................................ 14 4.1.1.4 Clock Synchronization ............................................................................................................... 15

4.1.1.4.1 Time representation............................................................................................................ 15 4.1.1.4.2 Synchronization process .................................................................................................... 16

4.1.1.5 Physical layer ............................................................................................................................. 16 4.1.1.5.1 Network Components ......................................................................................................... 16 4.1.1.5.2 Network Topology............................................................................................................... 17 4.1.1.5.3 Electrical signalling ............................................................................................................. 18 4.1.1.5.4 Bus Guardian...................................................................................................................... 18

4.1.2 Rationale for selection in the original domain .................................................................. 20 4.1.3 Expected benefits............................................................................................................. 21 4.1.4 Typical applications.......................................................................................................... 21 4.1.5 Expected evolutions ......................................................................................................... 21

5. AFDX ............................................................................................................................................ 23

5.1 PRESENTATION .................................................................................................................... 23 5.1.1 Technical summary .......................................................................................................... 23 5.1.2 Rationale for selection in the original domain .................................................................. 29 5.1.3 Expected benefits............................................................................................................. 30 5.1.4 Typical applications.......................................................................................................... 30 5.1.5 Expected evolutions ......................................................................................................... 31

6. CASE STUDY: PLEIADES-HR SATELLITE (TYPICAL SCENARIO) ......................................... 32

6.1 INTRODUCTION TO PLEIADES-HR ............................................................................................ 32 6.1.1 PLEIADES-HR Data Handling System ............................................................................ 33 6.1.2 Avionics Bus Equipments................................................................................................. 37

6.1.2.1 IMU: Inertial Measurement Unit ................................................................................................. 37 6.1.2.2 STR : Star Tracker ..................................................................................................................... 38 6.1.2.3 DORIS Equipment ..................................................................................................................... 39 6.1.2.4 CMG : Control Moment Gyro ..................................................................................................... 40

6.2 PLEIADES-HR AFDX.............................................................................................................. 43


5

6.2.1 Pleiades AVB Virtual Links Specification ......................................................................... 44 6.3 PLEIADES-HR FLEXRAY ......................................................................................................... 49

6.3.1 Calculation of FlexRay parameters .................................................................................. 50 6.3.2 AVB 1553 constraints applied to AVB FlexRay................................................................ 53

7. MODELING THE PLEIADES-HR AVIONICS............................................................................... 56

7.1 INTRODUCTION .......................................................................................................................... 56 7.1.1 Scope of the Case Study ................................................................................................. 56 7.1.2 Modelling Tools ................................................................................................................ 57

7.1.2.1 Architecture Analysis & Design Language (AADL) .................................................................... 57 7.1.2.2 OSATE....................................................................................................................................... 57 7.1.2.3 VERDI ........................................................................................................................................ 58

7.2 PLEIADES AVIONICS MODEL FOLLOWING THE VERDI CONCEPT .................................................... 60 7.2.1 Modeling the Logic Components...................................................................................... 61

7.2.1.1 Resource Elements (REs) ......................................................................................................... 61 7.2.1.2 Integration Areas (IAs) ............................................................................................................... 62 7.2.1.3 Aircraft system level (AC) .......................................................................................................... 63

7.2.2 Modeling of Software Components .................................................................................. 63 7.2.3 Modeling of Hardware Components................................................................................. 64 7.2.4 Setting up the overall system ........................................................................................... 65

8. CONCLUSIONS AND PERSPECTIVES ...................................................................................... 67

9. REFERENCES.............................................................................................................................. 68

9.1 FLEXRAY REFERENCES............................................................................................................... 68 9.2 AFDX REFERENCES.................................................................................................................. 69 9.3 PLEIADES REFERENCES.......................................................................................................... 70 9.4 OTHER REFERENCES.............................................................................................................. 70

10. APPENDIX A: COMPARISON WITH SPACE DOMAIN TECHNOLOGIES .............................. 71


6

List of Figures

Figure 1 – EADS group organization.......................................................Error! Bookmark not defined.

Figure 2 – EADS Astrium locations .........................................................Error! Bookmark not defined.

Figure 3 – FlexRay Cycle ......................................................................................................................13

Figure 4 - CODEC subprocesses ..........................................................................................................14

Figure 5 - FlexRay Frame......................................................................................................................14

Figure 6 - ECU with split termination and common mode choke...........................................................17

Figure 7 - Example of a hybrid bus structure.........................................................................................17

Figure 8 - FlexRay Electrical Signalling.................................................................................................18

Figure 9 - FlexRay node with Local Bus Guardian ................................................................................19

Figure 10 - Dual channel FlexRay network with two independent CBGs ..............................................20

Figure 11 - Virtual Link Concept over AFDX network............................................................................24

Figure 12 - Bandwidth Allocation Gap...................................................................................................25

Figure 13 - Jitter Defined .......................................................................................................................25

Figure 14 - AFDX Frame .......................................................................................................................26

Figure 15 - Network Redundancy..........................................................................................................27

Figure 16 - Integrity Checking and Redundancy Management in the End System...............................27

Figure 17 - Role of Virtual Link Regulation............................................................................................28

Figure 18 - Artist's view of the Pleiades satellite [CNES/Pierre Carril] ..................................................32

Figure 19 - Spacecraft data handling architecture.................................................................................34

Figure 20 – Payload 1553 bus ..............................................................................................................35

Figure 21 – Avionics 1553 bus ..............................................................................................................35

Figure 22 – OBMU Internal 1553 bus....................................................................................................36

Figure 23 – Sagnac effect .....................................................................................................................37

Figure 24 – IMU HW architecture and redundancy ...............................................................................37

Figure 25 – STR unit location on the Spacecraft...................................................................................38

Figure 26 – STR HW architecture and redundancy...............................................................................38

Figure 27 – Doris HW architecture and redundancy .............................................................................40

Figure 28 – CMG principle of actuation .................................................................................................41

Figure 29 – CMG cluster configuration..................................................................................................41

Figure 30 – CMG HW architecture and redundancy .............................................................................42

Figure 31 - Avionics Bus AFDX Description ..........................................................................................43

Figure 32 - CMG Constraint description ................................................................................................48


7

Figure 33 – Avionics Bus FlexRay Schematic.......................................................................................49

Figure 34 – AVB FlexRay Communication Cycle distribution................................................................50

Figure 35 – Application scope of the VERDI toolset..............................................................................56

Figure 36 – OSATE Environment ..........................................................................................................57

Figure 37 – VERDI Blueprint generation process..................................................................................58

Figure 38 – Design time Blueprint concept............................................................................................59

Figure 39 – Avionics System structure/architecture ..............................................................................60

Figure 40 – Modelled Resource Element ..............................................................................................61

Figure 41 – Modelled IMU Integration Area...........................................................................................62

Figure 42 – Modelling of software components.....................................................................................64

Figure 43 – Basic hardware component................................................................................................64

Figure 44 – Modelled hardware platform...............................................................................................65

Figure 45 – Binding of SW and HW.......................................................................................................66


8

1. INTRODUCTION

1.1 DOCUMENT CONTEXT AND OBJECTIVE

This report aims to provide feedback on the stage initially published as “Modeling/Evaluation of Modular Spacecraft Avionics Network Architectures”, which was carried out by Yago Montenegro Méndez in EADS Astrium Satellites at Toulouse (France) during 6 months (from March to September 2009). The Master Thesis corresponds to the 4th Semester of the “Joint European Master in Space Science and Technology” (SpaceMaster), and the 2nd Semester of the “M2P Techniques Spatiales et Instrumentation” organized by CESR (Centre d’Etude Spatiale des Rayonnements) in association with Université Paul Sabatier (UPS).

Joint European Master in Space Science and Technology

SpaceMaster is a two-year European Union sponsored course under the umbrella of the Erasmus Mundus Programme open to students from all over the world. Each year around 30-35 non-European students and 15-20 European Union students join the SpaceMaster programme.

The space expertise of six European universities is pooled together in the programme, which gives students the opportunity to study space science at the top technical and engineering universities in Europe. The consortium of participating universities consists of:

• Luleå University of Technology, Sweden (lead university)

• Cranfield University, UK

• Czech Technical University, Czech Republic

• Helsinki University of Technology, Finland

• Julius-Maximilian Universität Würzburg (JMUW), Germany

• Université Paul Sabatier Toulouse III, France

The two-year course is divided into four semesters: the first semester with Introductory space related modules is located in Würzburg (common for all students), the second semester corresponds to Advanced space related modules in the Kiruna Space Campus (common for all students), the third semester in which I specialized in Space Techniques and Instrumentation in Toulouse, and the fourth semester devoted to the preparation of the Master Thesis.

The following report describes the activities carried out during the mentioned Master Thesis project, from the initial studies on the technologies proposed to the acquisition of expertise to develop the final modelling. It will serve EADS Astrium too as reference for further developments of the concepts explained throughout the report.


9

1.2 THESIS SUBJECT

This report is initially intended to provide insights on the status of two state-of-the-art technologies which are High-speed networks with real-time determinism: FlexRay™ and AFDX™.

FlexRay is called to be the next-generation automotive networking standard. Increased integration and criticality of the next-generation automotive electronics require higher bandwidth and improved support for fault-tolerance that exceeds the capabilities of current standards such as Controller Area Network (CAN). The FlexRay protocol provides increased bandwidth over CAN and also incorporates new mechanisms to increase communication fault-tolerance and determinism, while retaining a high degree of flexibility. Thus, as its predecessor did, the potential of a FlexRay “spin-in” has aroused the interest of the Space community.

On the other hand, AFDX uses a special protocol to provide deterministic timing and redundancy management providing secure and reliable communications over commercial-off-the-self (COTS) Ethernet components. AFDX extends the Ethernet standard by adding Quality of Service (QoS) and deterministic behaviour with a guaranteed dedicated bandwidth. AFDX is currently used in the flagship projects of the aeronautic industry, i.e. the Airbus A380 and A400M, as well as in the Boeing 787 Dreamliner, what makes pertinent its research for Space applications.

As case study to prove the suitability of these technologies the Avionics Bus of the Earth Observation Satellite PLEIADES-HR has been chosen. Properties and performance of the new communication networks have been tested over the actual MIL-STD-1553-B network of the satellite. Furthermore, a hardware/software co-design model has been developed to investigate in the possibilities offered by the Avionics Architecture Design Languages.

1.3 DOCUMENT ORGANISATION

The document is divided into 9 chapters.

In the first chapter, context and goals of the thesis project are introduced, as well as the general structure of the report.

The second chapter provides with a general overview of the EADS Astrium’s ASG74 department, which hosted this project.

The third chapter is a short introduction describing the context of the technologies studies. Whilst for the following two chapters comprise the actual studies: the fourth chapter focuses on FlexRay, whereas the fifth deals with AFDX.

The sixth chapter is occupied by the Pleiades case study where the technology need for adaptation and assessment of benefits is presented.

The seventh chapter follows with the modeling of the Pleiades Avionics Bus in Architecture, Analysis and Design Language (AADL).

The last chapter draws general conclusions of the Master Thesis.

In the appendix, a comparison of FlexRay and AFDX with Space domain technologies, SpaceWire and MIL-STD-1553-B, is given.


10

2. DATA PROCESSING AND ADVANCED STUDIES DEPARTMENT (ASG74)

The master thesis was undertaken in the “Data Processing and Advanced Studies” department (ASG74), belonging to “Data Processing, On-Board Software and Dependability” division (ASG7), within “Central Engineering” (ASG), which is part of the “Subsystems, Equipment and Operations” Division of EADS Astrium Satellites.

ASG74 is involved in many projects at different levels, from support to lead. Main activities comprise ESA R&D, CNES R&D and support to Business Divisions. The department distinguishes two sets of competences: Data Processing Engineering led by Olivier Notebaert and Advanced Digital Systems led by Luc Planche.

Furthermore, the mission of the department is:

• To support the System and Equipment teams in the mastering of the Data Processing functional chains of Platforms and Payloads.

• Bring expertise in:

o On-Board Data Processing hardware and software components (microprocessors, buses, FPGAs),

o Related techniques and services (protocols, traffic modelling, performance assessment, FDIR, autonomy)

o Development processes, methods and environments.

• Improve efficiency by favouring reuse of building blocks and introduction of innovative development approaches.

• To provide expertise from the design or customisation phases to the qualification of the On-Board Data Processing functional chains through avionics testing.

• To inject through a deep involvement in the early phases of the Data Processing architectural and functional definition, innovative technical solutions giving competitive advantages to the Astrium proposals.

• To define future On-Board Data Processing architectures and functions for the new Platforms and Payloads by leading a comprehensive R&D in response to the needs expressed by the Prime Business Divisions and in close collaboration with the Equipment Business Division.


11

3. INTRODUCTION

Satellite or deep space exploration spacecraft avionics design is strongly determined by the need to achieve a long lifetime and to autonomously maintain safe operations in case of failure. To cope with an increasing demand in on-board processing and to make architectures more scalable and modular, future spacecraft data management architectures are about to implement solutions selected today by the commercial aircraft industry such as a central high speed backbone network linking processing nodes, with local lower throughput buses enabling such nodes to interact with sensors, effectors and other avionics equipment. Some specific issues to be consolidated today are the sequencing of communications between the high speed backbone and the local buses, the overall fault detection, isolation and recovery strategy and the priority management and monitoring functions to be included within backbone routers.

The scope of this study is to perform a review of the state-of-the-art of reconfigurable, fault-tolerant applications of high speed data networks represented by the soon-to-be automotive standard FlexRay and the new generation avionics network AFDX (Advanced Full-Duplex Switched Ethernet). Furthermore, in order to compare and support the suitability of the selected solutions to spacecraft on-board networking needs, their performance will be analyzed undertaking the functions of the MIL-STD-1553 Avionics Bus of the Earth Observation Satellite PLEIADES, to be launched in 2010. Feedback will be provided on the applied engineering methodology.


12

4. FLEXRAY

4.1 PRESENTATION

FlexRay defines a High Speed Data Network with real-time determinism. It recently gained industry-wide acceptance as the next-generation automotive networking standard. The core members of the FlexRay Consortium are: BMW, Daimler, Freescale Semiconductor, General Motors, NXP Semiconductors (Philips), Bosch and Volkswagen [1]. Many of the world's OEMs, Tier 1 suppliers, and semiconductor suppliers have joined the FlexRay consortium. The consortium recognizes that increased integration and criticality of the next-generation automotive electronics (namely applications including x-by-wire) will require higher bandwidth and improved support for fault-tolerance that exceeds the capabilities of current standards such as Controller Area Network (CAN). The FlexRay protocol provides increased bandwidth over CAN and also incorporates new mechanisms to increase communication fault-tolerance and determinism, while retaining a high degree of flexibility.

4.1.1 Technical summary

FlexRay’s key features are:

• Synchronous and asynchronous data transmission (scalable).

• Fault-tolerant multi-master clock synchronization.

• Deterministic data transmission, guaranteed message latency and message jitter.

• Message oriented addressing via identifiers (dynamic segment).

• Support of redundant transmission channels.

• Physical layer error containment through the use of a Bus Guardian.

• Single Channel gross data rate of 10 Mbit/sec.

• Supports hybrid combinations of bus and star topologies.

• Scalable Fault-tolerance, error detection and signalling.

• Support of wake-up/sleep functionality via bus.

4.1.1.1 Media Access Control

In the FlexRay protocol, media access control is based on a recurring communication cycle. Within one communication cycle FlexRay offers the choice of two media access schemes. These are a static time division multiple access (TDMA) scheme, targeting high-criticality communication, and a priority-driven dynamic mini-slotting based scheme, targeting run-time flexibility. This insures guaranteed message latency during synchronous transfers and the support of varying bandwidth requirements during the asynchronous transfers. It is illustrated in Figure 3 the FlexRay cycle schema.


13

Figure 1 – FlexRay Cycle

In addition, the FlexRay cycle consists of a symbol window that tests the bus guardian operations, and the network idle time segment used for clock correction. Features of each segment are listed below on Table 1 [18].

Features Slot

length Priorities Bus Guardian

Static Segment

Sends and receives messages Time-Triggered

Fixed length

Fixed by TDMA Because the timing for sending is fixed, it is protected by BG.

Dynamic Segment

Sends and receives messages Event-Triggered

Variable length

Sending in ascending order of ID

Because the timing of sending is undetermined, it cannot be protected by BG.

Symbol Window

Confirms the normality of BG (Only with BG)

Fixed length

- BG can disable sending.

Network Idle Time

Each node calculates and applies clock correction

Variable length

- -

Table 1 - FlexRay segment features

4.1.1.2 Coding and Decoding

Coding and Decoding (CODEC) describes the behaviour of the FlexRay interface between the communication controller and the bus driver. The CODEC consists of five sub-processes: the encoding (ENC), the bitstrobing (BITSTBR) that retrieves a voted value (a bit) from the bus every 8 clock cycles, the wakeup symbol decoding (WUSDEC), the channel idle detection (IDET) and the decoding (DEC). Their interrelation it is illustrated in Figure 4.


14

Figure 2 - CODEC subprocesses

4.1.1.3 Frame Format

An overview of the FlexRay frame format can be seen in Figure 5. The FlexRay frame is divided into three segments: Header, Payload, and Trailer.

Figure 3 - FlexRay Frame

Header segment

• Reserved bit: This is a reserved bit for future protocol use.

• Payload preamble indicator: This bit indicates whether or not the payload segment of the frame contains a network management vector if it is transmitted in the static segment or a message ID if it is transmitted in the dynamic segment.

• Null frame indicator: This bit indicates whether or not the data frame in the payload segment is a null frame, i.e. it contains no useable data.

• Sync frame indicator: This bit indicates whether or not the frame is a sync frame, i.e. a frame that is utilized for system wide synchronization of communication.

• Startup frame indicator: This bit indicates whether or not the frame is a startup frame.

• Frame ID: An ID is assigned to each node at system designing. (Valid range: 1 to 2047).

• Payload length: It indicates the size of the payload segment.


15

• Header CRC: It specifies the CRC calculation values of Sync Frame Indicator, Startup Frame Indicator, Frame ID, and Length that are calculated by the host.

• Cycle count: It indicates the cycle count of the node that transfers the frame during the frame transfer time.

Payload segment

• Data: Data. Valid range is from 0 to 254 bytes.

• NMVector (Optional, only for static segment): The network management vector length must be from 0 to 12 bytes and common to all nodes.

• Message ID (Optional, only for dynamic segment): It uses the first two bytes of the payload segment for definition, and it can be used as the filterable data on the receiving side.

Trailer segment

• Frame CRC: It is computed over the header segment and the payload segment of the frame. A different initialization vector is used for each channel.

4.1.1.4 Clock Synchronization

The FlexRay protocol uses a distributed clock synchronization mechanism in which each node individually synchronizes itself to the cluster by observing the timing of transmitted sync frames from other nodes. The global time base provides for both Rate and Offset correction in µs range. A fault-tolerant algorithm is used.

4.1.1.4.1 Time representation

The time representation inside a FlexRay node is based on cycles, macroticks and microticks. A macrotick is composed of an integer number of microticks. A cycle is composed of an integer number of macroticks

• Microticks are time units derived directly from the communication controller's (external) oscillator clock tick, optionally making use of a prescaler.

• The macroticks are synchronized on a cluster-wide basis. Within tolerances, the duration of a macrotick is identical throughout all synchronized nodes in a cluster. The duration of each local macrotick is an integer number of microticks; the number of microticks per macrotick may, however, differ from macrotick to macrotick within the same node. The number of microticks per macrotick may also differ between nodes, and depends on the oscillator frequency and the prescaler.

• A cycle consists of an integer number of macroticks. The number of macroticks per cycle shall be identical in all nodes in a cluster, and remains the same from cycle to cycle.


16

4.1.1.4.2 Synchronization process

Clock synchronization consists of two main concurrent processes. The macrotick generation process controls the cycle and macrotick counters and applies the rate and offset correction values. The clock synchronization process performs the initialization at cycle start, the measurement and storage of deviation values, and the calculation of the offset and the rate correction values. These processes are executed in every cycle for each node.

Selected nodes (sync nodes) send one frame per communication cycle with the sync identification set. Each node performs rate correction by calculating the time difference between the actual arrival time of the Sync frame and the expected arrival time of the Sync frame. After collecting the relative distances of all nodes, the controller computes the resulting distance to an average line. The rate correction value indicates by how many microticks the node's cycle length should be changed. To improve fault tolerance, a fault tolerant midpoint (FTM) is used instead of an average of rate correction.

Offset correction assumes that the rates of all the other nodes in the network are the same. Cycle length is measured by computing the time difference between the receptions of the same message in two successive cycles. The offset correction value indicates how many microticks the node should shift the start of its cycle. Negative values mean the NIT should be shortened (making the next cycle start earlier). Positive values mean the NIT should be lengthened (making the next cycle start later). The same FTM algorithm is used for offset correction also.

The precision of the FlexRay synchronization is in the range of 1µs.

4.1.1.5 Physical layer

The FlexRay electrical physical layer provides a differential voltage link (bus) between a transmitting and one or more receiving communication modules. The differential voltage is measured between two signal lines, denoted BP (Bus Plus) and BM (Bus Minus).

4.1.1.5.1 Network Components

• Cables: Cable type not defined. Recommended differential mode impedance (80-110 Ω).

• Connectors: Not specified. Characteristics: Contact resistance (<50 mΩ), Impedance (70-200 Ω), Length Coupling connection (<150 mm).

• Cable termination: Not specified. A split termination is recommended in all ECUs (Electronic Control Unit), consisting in two equal resistor parts between the bus wires BP and BM.

• Common mode choke: High impedance for common mode signals. Recommended resistance per line (<1 Ω). Placed between transceiver and split termination. The following figure shows how to integrate the common mode choke in presence of a split termination.


17

Figure 4 - ECU with split termination and common mode choke

4.1.1.5.2 Network Topology

FlexRay topologies supports: point-to-point connections; passive stars; linear passive bus; active star networks (which are working in principle as bidirectional repeaters); cascaded starts (electrically decoupled from each other); and hybrid topologies (combinations of the previous ones). An example of a hybrid bus structure is illustrated in Figure 7.

FlexRay communication modules offer the possibility to serve up to two channels. This may be used to increase bandwidth and/or introduce a redundant channel in order to increase the level of fault tolerance.

Figure 5 - Example of a hybrid bus structure

The maximum recommended cable length between any two ECUs, from an ECU to a star, or between two active stars is 24 meters. It is recommended a maximum number of 22 stubs in a passive star or a


18

passive bus structure, therefore a maximum of 22 nodes. The maximum number of nodes in an active star is 64.

4.1.1.5.3 Electrical signalling

The bus may assume four different bus states, denoted: Idle_LP (low-power state), Idle (no-communication state), Data_1 (logical high) and Data_0 (logical low). A principle voltage level scheme is depicted in the following Figure 8.

Figure 6 - FlexRay Electrical Signalling

4.1.1.5.4 Bus Guardian

A physical layer incorporating an independent Bus Guardian provides further support for error containment. Guardians are needed to prevent a faulty node from disrupting system operations (babbling idiot avoidance). There are two types of Bus Guardian in FlexRay: Node-local and Central Bus Guardian [16], [17].

Node-local Bus Guardian

The functionality of the Bus Guardian (BG) is composed of a subset of the functionality of a Communication Controller (CC) with an additional process which supervises the local CC.

The BG operates with an independent clock synchronization process and supervises the CC. The FlexRay communication is handled via CC on both channels. The BG does neither transmit frames on channel A nor on channel B. The BG is able to receive frames on both channels. This is required for the clock synchronization process. The two CCs have separate clock oscillators. The local Bus Guardian is depicted in Figure 9.


19

Figure 7 - FlexRay node with Local Bus Guardian

Central Bus Guardian

The Central Bus Guardian (CBG) is a central device which forwards the communication elements received on its branches. Several critical faults (e.g. short circuited bus lines or babbling idiot behaviour of a node) can be tolerated by a FlexRay system when CBGs are used to protect its channels. Since the CBG has its own clock synchronization unit basically identical to the clock sync unit in a communication controller (CC), and besides, it can decode (but not encode) the data frames.

The CBG is designed to have static schedule information stored. The complete communication schedule of the FlexRay system does not necessarily need to be stored in the CBG, but the CBG should have a sufficient amount of information to protect the frames which are relevant for critical functions and of course to start up and maintain communication as a whole. The critical parts of the schedule as well as the relation of nodes to critical functions have to be specified a priori and shall be frozen. An example for a possible network architecture using two independent CBGs in a dual channel FlexRay system including critical applications can be seen in Figure 10.


20

Figure 8 - Dual channel FlexRay network with two independent CBGs FlexRay communicates via two physically separated lines with a data rate of 10 Mbit/s each. The two lines are mainly used for redundant and therefore fault-tolerant message transmission but can also transmit different messages, in which case the data throughput is doubled. FlexRay can also be operated with lower data rates. FlexRay signal transmission is based on differential transmission of an NRZ-L coded bit stream along a twisted pair cable. It supports the RS-485 physical layer which insures low power dissipation [8].

A more detailed description of the protocol and its operation can be found in the FlexRay Protocol Specification [2], [3], [4].

4.1.2 Rationale for selection in the original domain The creation of FlexRay was imposed by the introduction of advanced control systems, which combine multiple sensors, actuators, and electronic control units (ECUs), which placed boundary demands on the existing CAN communications bus found in most of today’s automobiles. In addition, FlexRay’s main characteristics are directly resulting from the automotive X-by-Wire requirements. Real-time systems that are designed to replace mechanical or hydraulic components in safety-critical automotive applications, such as “drive-by-wire” applications, must achieve a level of safety that is higher or equal to the level of safety of the systems they replace. Such a low failure rate can only be achieved if the system is distributed and tolerates the arbitrary failure of any one of its subsystems [10].

The main motivations which led to the creation of the FlexRay Standard, as described by the FlexRay Consortium [1], are:

• Market need for an industry wide standard scalable communication system.

• Demand for a bus system with a high data rate.

• Deterministic and fault-tolerant bus system for high-speed automotive control applications.

• Support from the bus system for distributed control systems.


21

4.1.3 Expected benefits

Aimed at meeting the demands of high-end control applications, the FlexRay communications protocol provides high bandwidth (10 Mbps) and determinism to enable distributed control. FlexRay can also drive cost reductions by reducing the number of parallel CAN networks that have emerged recently to solve bandwidth bottlenecks. The high bandwidth also allows FlexRay to be used as a vehicle-wide network backbone. The redundancy offered by the dual channel architecture addresses requirements of safety-related applications.

As a result, the achievable benefits by the next generation in-vehicle network include: enhanced control intelligence, simplified vehicle network architecture, increased composability of networked subsystems, or enabling electromechanical replacement of hydraulic components (X-by-wire). The combination of all these benefits makes possible next-generation vehicle designs that are safer, more environmentally sensitive, more intelligent, more reliable and offer an improved driving experience [13].

As defined by the FlexRay Consortium [1], the goals established for the FlexRay technology:

• Develop an advanced communication technology for high-speed control applications in vehicles, to increase safety, reliability and comfort.

• Make the technology available in the market place for everyone.

• Drive the technology as the de facto standard.

• Make the technology available for new application and application domains such as active and passive safety systems, systems for consumer comfort and fuel consumption.

4.1.4 Typical applications

At the moment, FlexRay is in a strong position in order to become the automotive standard, backed by the world’s industry. The first series production vehicle with FlexRay was at the end of 2006 in the BMW X5, enabling a new and fast adaptive damping system. Full use of FlexRay was introduced in 2008 in the new BMW 7 Series, the world's first production vehicle to fully utilize the FlexRay system [12], [14].

In addition the aeronautic industry is strongly interested in utilizing FlexRay. Economic benefits to be derived from the automotive mass market and technological benefits arising from the deterministic communication behaviour are projected. In this regard, EADS Deutschland GmbH is a premium member since 2006 [1].

4.1.5 Expected evolutions

FlexRay will very likely become the facto standard for high-speed control applications within vehicles. The FlexRay communication system has quickly gained momentum with many new members joining the Consortium. With respect to non-automotive use, the core partners of the Consortium are working on a licensing agreement, after the interest showed by other industries in the standard [11].

In the same way the CAN bus has been implemented as main system bus in few spacecraft onboard applications (SMART-1, MATROSHKA, SSTL satellites, GIOVE-A); FlexRay, the CAN successor, might be of interest to consolidate point-to-point CAN connections, to connect different remote units of


22

sub-systems (such as environmental control or power distribution systems), or as a backup data path for critical data [6]. Few studies not significant enough have addressed the applicability of FlexRay for space applications [6], [7], [8], [9].

Regarding the physical layer, the current electrical physical layer limits the maximum distance between nodes to 24 meters, which limits deployment. The FlexRay Consortium plans to extend the physical layer bandwidth to include 2.5M and 5Mbit/s, which will allow longer driving distances. FlexRay does not officially specify an optical layer, but only an electrical physical layer at this point. The FlexRay encoding layer is very similar to the byteflight (predecessor of FlexRay) encoding layers, which may enable the use of byteflight optical layers [6].


23

5. AFDX

5.1 PRESENTATION

Avionic Full-Duplex Switched Ethernet (AFDX), designated ARINC 664 Part 7 [19], is a specification for a deterministic avionics data network based on commercial 10/100Mbit switched Ethernet for aeronautical, railway and military systems. AFDX uses a special protocol to provide deterministic timing and redundancy management providing secure and reliable communications of critical and non-critical data. AFDX communication protocols have been derived from commercial standards (IEEE802.3 Ethernet MAC addressing, Internet Protocol IP, User Datagram UDP) to achieve the required deterministic behaviour for avionics applications. The benefits from using commercial-off-the-shelf (COTS) Ethernet components include reduced overall costs, faster system development and less-costly maintenance for the system network. Hardware components, cables and test equipment for Ethernet are field proven and much more affordable than “built-to-spec” avionics solutions. Standard commercial grade Ethernet won’t meet avionics network requirements. Therefore, AFDX extends the Ethernet standard by adding Quality of Service (QoS) and deterministic behaviour with a guaranteed dedicated bandwidth. AFDX™ is currently used in the Airbus A380 and A400M as well as in the Boeing 787 Dreamliner, and NASA considered ARINC 664 for the new Crew Exploration Vehicle [36].

5.1.1 Technical summary

The AFDX network main components are:

• Avionics specific physical layer.

• COTS components for MAC layer.

• AFDX switches: active elements addressing 3 functions:

- to establish a point to point connection between a sender and several receivers via twisted pairs cable.

- to establish communication between subscribers on the network.

- to check frame integrity and bandwidth.

• AFDX end systems: the AFDX End system is the subsystem which must be embedded in each avionics systems equipment connected to the network [20].

AFDX addresses the shortcomings of IEEE 802.3 Ethernet by adopting concepts from the telecom standard, Asynchronous Transfer Mode (ATM). These extensions to standard Ethernet make possible a deterministic network with guaranteed bandwidth and QoS [23].

The major aspects of AFDX are as follows:

• Profiled network: parameters for various End Systems are defined in configuration tables loaded into the switch at start-up.

• Full duplex: the physical interconnect medium is twisted pair, with separate pairs for transmit and receive channels.

• Switched network: the network is wired with a star topology. Each switch connects a maximum of 24 End Systems. Switches can be cascaded to construct a larger network.


24

• Deterministic: the network emulates a deterministic, point-to-point network through the use of Virtual Links (VL’s) and Traffic Shaping by the use of Bandwitdth Allocation Gaps (BAG’s).

• Redundancy: dual networks provide a higher degree of reliability than a single network scheme provides.

• Fault tolerance: AFDX Switches incorporate functions for filtering and policing, switching (based on configuration tables), end-system and network monitoring.

• No synchronization: the AFDX standard does not deal with End Systems’ synchronization, and it is not needed for its correct operation.

Virtual Links

The most important concept created by AFDX is the Virtual Link (VL). Each VL is a concept of communication channel, defined as a partition of the switched AFDX network, with a well defined transmission time fragmentation, which guarantees:

• Reserved path into the switched network topology from one source to a fixed number of destinations (multicast)

• Reserved bandwidth into the global AFDX network

• Global time scheduling between asynchronized End Systems

• Known maximum latencies and jitters

• Access delay to the network

• End-to-end delivery, without acknowledgements nor retries

The bandwidth control is achieved by the timing constraints associated to each VL. The mapping of the VL into the global switched network realizes a partitioning of the topology; each VL has an associated time fragmentation called BAG (Bandwidth Allocation Gap) and a maximum frame size.

Figure 9 gives a representation of the VL concept (a pipe on the network) [20].

Figure 9 - Virtual Link Concept over AFDX network.


25

Guaranteed Service

Fundamental to an AFDX network is guaranteed service: both the bandwidth and maximum end-to-end latency of the link are guaranteed. However, there is no guarantee of packet delivery. Transmission acknowledgements and retransmission requests must be handled at the application level [20].

BAG

The primary bandwidth control mechanism is the BAG (Figure 10) [19]. The BAG represents the minimum interval in milliseconds between Ethernet frames that are transmitted on the virtual link. BAG values range in powers of 2 from 1ms to 128ms.

Figure 10 - Bandwidth Allocation Gap

Jitter

The End System may introduce jitter when transmitting frames for a given VL. This jitter is defined as the interval from the beginning of the BAG to the first sent bit of the frame being transmitted at the VL's maximum allocated bandwidth (Figure 11) [19]. This jitter may be introduced by the transmitting technology and the traffic-shaping function. A given End System may have to transmit data for multiple VLs, so a frame from one VL can be delayed up to the maximum allowed jitter value to limit the instantaneous End System frame rate and thus accommodate frames from other VLs.

Figure 11 - Jitter Defined

The ARINC 664 specification requires that, in transmission, the maximum allowed jitter on each virtual link at the output of the End System comply with both of the following formulas:


26

Equation 1 - Max Jitter

Nbw is the link bandwidth (100 Mbps). The first formula represents a bound on the jitter arising from an Ethernet frame being delayed by a frame from each of the other virtual links. The second formula is a hard limit, independent of the number of virtual links. These requirements are necessary to demonstrate the overall determinism of an AFDX network.

Frame Format

The AFDX frame format is shown in Figure 12. The destination and source addresses listed contain the MAC addresses for the End Systems. Actual IP address information is contained in the IP Structure block. The UDP structure identifies the appropriate application port. The AFDX payload ranges from 1 to 1471 bytes. Payload sizes less than 17 bytes must be padded to maintain a minimum length of 17 bytes.

The one-byte sequence number is used to maintain ordinal integrity within a given VL. The frame sequence number is initially set to 0 upon End System start-up or reset. During continuous operation, the number wraps back to 1 after reaching a value of 255.

The maximum frame size is set for each VL and is represented by the parameter LMAX. The range of this parameter is between 64 and 1518 bytes.

Figure 12 - AFDX Frame

Redundancy

There are two independent switched networks in an AFDX system, the A and B Networks. Each packet transmitted by an End System is sent on both networks. Therefore, under normal operation, each End System will receive two copies of each packet (see Figure 13) [19].


27

Figure 13 - Network Redundancy

On a per-virtual link and per-network port basis, the receiving End System checks that the sequence numbers on successive frames are in order. This is referred to as "Integrity Checking." After Integrity Checking is complete, the End System determines whether to pass the packet along or drop it because its replica has already been sent along. This is called Redundancy Management (Figure 14).

Figure 14 - Integrity Checking and Redundancy Management in the End System

Virtual Link Scheduling

Each sending AFDX communication port is associated with a virtual link. Messages sent to the communication port are encapsulated within UDP, IP, and Ethernet headers and placed in the appropriate virtual link queue for transmission. The transmission of Ethernet frames in a virtual link queue is scheduled by the End System’s Virtual Link Scheduler. The Virtual Link Scheduler is responsible for scheduling transmissions of all the virtual links originating with this End System.

The Virtual Link Scheduler is responsible for ensuring that each virtual link conforms to its assigned bandwidth limitation. Not only must the Virtual Link Scheduler ensure the BAG and Lmax limitations for each virtual link, but it is also responsible for multiplexing all of the virtual link transmissions so that the amount of jitter introduced by the multiplexing is within acceptable bounds [22].

Virtual Link scheduling consists of two components: packet regulation and multiplexing. Figure 15 shows the role of the Virtual Link Regulators in pacing the frames from the virtual link queues to create zero-jitter output streams. The Virtual Link Scheduler is also responsible for multiplexing the regulator outputs into the Redundancy Management Unit for replication and transmission on the physical links.


28

Figure 15 - Role of Virtual Link Regulation

AFDX Switch

In addition, all frames arrive at the switch in the Filtering & Policing function stage where they are filtered in various steps that apply rules about frame integrity, frame length, traffic budget and acceptable destination(s).

The core of the switching activity is performed by the Switching function. Frames filtered by the Filtering and Policing function are forwarded to the appropriate physical output ports where they leave the switch again. These functions are controlled by configuration data contained in static Configuration Tables.

The filtering causes the switch to distribute only valid frames to selected destinations. Upon arrival in a switch, each frame is examined and the contents of certain fields of the frame header (e.g. destination address field, frame check sequence field, etc.) and the construction of the frame itself are monitored:

• The frame size: whether the frame is either longer or shorter than the envelope allows

• The frame integrity: whether the FCS embedded in the frame matches the calculation upon reception


29

• The frame path: whether the destination requested by the content of the Destination Address field (which in case of the AFDX is the Virtual Link Identifier) of the arriving frame is permitted or not

The End System stage provides the means to communicate with the Switch (receives frames dedicated to the Switch and allows the Switch to send frames). This is used for Data Loading and monitoring functions.

All operations are monitored by a Monitoring function that logs events such as the arrival of a frame or a failed CRC check and additionally creates statistics about the internal situation. Since the switch is part of a network, it communicates with the Network Management Function for operational information and for health related information.

The AFDX monitoring is based on the following:

• The MIB (Management Information Base) implemented in each AFDX component (equipment, subscriber and Switch) to store information about the components

• The SNMP agent implemented in each AFDX component (equipment, subscribers and Switch) to communicate with the Network Management Function using SNMP

• The Network Management Function, that realizes the correlation of information collected from all the components to detect/localize failure and to analyze network performances

A more detailed description of the protocol and its operation can be found in the ARINC 664 specifications [19] and a more comprehensive discussion in [20], [21], [22]. Regarding the Ethernet physical layer, it is defined in ARINC 664 Part 2.

5.1.2 Rationale for selection in the original domain

During the 90s, Airbus has performed a series of technology programs in the context of the A380 project. The goal was to assess which newest technology in various domains (databus communication, flight control, power management, structure) would be the most beneficial for a new generation of aircraft like the A380 (performance, availability, risk and cost). As far as databus communication is concerned, Airbus’ goal was to move away from ARINC429 bus in considering several drivers: Cost, bus performance, Flexibility, Applicability [20].

• Cost covers Non-recurring engineering (NRE), the release candidate (RC) but also certification, Operation, logistics.

• Bus performance considers throughput but also latency, quality of service.

• Flexibility must be considered in term of design, maintenance and evolution.

• Applicability had to be addressed in the specific context of civil aircraft/avionics requirements.

A first consideration was the adoption of other avionics bus e.g. ARINC629 but later on the focus was given on bus technology coming from the COTS telecommunications with a special interest for Ethernet.


30

In general, commercial buses offer a good ratio performance versus cost with a high degree of technology maturity, the issue being to assess the extra cost to make them applicable to civil aerospace requirements. The maturity, the experience across market, the growth potential and the standardization aspect made the Ethernet the preferred choice of Airbus, and more precisely Airbus decided to make most of the use of Full Duplex (switched) Ethernet. Main advantages were:

• Duplex traffic collision free

• Time bounded latency

• Physical segregation

• Possible mapping of other buses e.g. 429, 1553

• Existing integrity and deterministic mechanics adaptable for avionics purpose.

The adoption and modification of the Full Duplex (switched) Ethernet for avionics requirements led to the inception of the AFDX (Avionics Full Duplex Switched Ethernet) protocol specified by Airbus.

5.1.3 Expected benefits

Primary benefits are:

• AFDX can dramatically reduce the number, weight, and volume of cable interconnects with respect to ARINC 429.

• AFDX can provide a thousand times higher data throughput than its predecessor, ARINC 429.

• It can provide reliable time determinism and fault tolerance to meet the needs of fly-by-wire systems.

• AFDX use of the Ethernet IEEE 802.3 standard with abundance of COTS components, maturity, and the standardization increases the reliability of avionics systems, while offering reduced overall costs, faster system development and less-costly maintenance for the system network.

• AFDX provides flexibility in software design, validation and verification.

• AFDX brings simplified network management, increased network capability, ease of reconfiguration and extension, and compliance with industry network standards [27].

5.1.4 Typical applications

The AFDX bus is used in Airbus A380/A350/A400M, Boeing 787 Dreamliner, the Chinese ACAC ARJ21 and the Sukhoi Superjet 100. It is being used as the backbone for all systems including flight controls, cockpit avionics, air-conditioning, power utilities, fuel systems, landing gear and others. The A400M provides an interesting case study, as it implements AFDX-to-1553 interfaces in order to take advantage of existing military LRUs (Line-replaceable units) which use 1553, as well as new avionics which use AFDX [31].

AFDX was considered as the avionics data network for the Orion Crew Exploration Vehicle (the Shuttle’s successor) [30] [32]. However, it is reported that the Orion Crew Exploration Vehicle selected another combination of Ethernet and time-triggered regulation developed by Honeywell International [35].


31

5.1.5 Expected evolutions

For future aircraft, the addition of other types of flows (audio, video, best-effort …) on the AFDX network is envisioned. Moreover, future avionic network architectures will include heterogeneous field-buses such as controller area network (CAN) or FlexRay in addition to AFDX (currently, there are already CAN buses embedded in aircraft).

Since the announcement of the NASA’s Constellation program in 2004, AFDX has been subject of several studies in order to consider its suitability to be the backbone of the Orion Crew Exploration Vehicle [28], [29]. AFDX was suggested as “Virtual Backplane” data communication network for an IMA (Integrated Modular Avionics) concept by NASA’s Ames Research Center. Furthering these studies the Ames Research Center, with AFDX as virtual backplane, prototyped an “Ancillary Sensor Network” for spacecraft’s system health monitoring (their research is mainly oriented to space transportation, e.g. ISS, Shuttle) making use of four end stations (smart-sensor modules) [27].

For the utilization of AFDX in the space radiation environment, component certification is needed. Aboard the Columbus module of the International Space Station, the physical layer of AFDX, i.e. IEEE 802.3, it is implemented by means of COTS components (HP’s ProCurve Ethernet switches) connecting crew’s computers and non-critical payload data [33], [34].


32

6. CASE STUDY: PLEIADES-HR SATELLITE (TYPICAL SCENARIO)

The typical scenario which shall be analyzed to prove the performance of FlexRay and AFDX is based in the PLEIADES-HR avionics architecture. Following is described the PLEIADES-HR satellite and mission.

6.1 INTRODUCTION TO PLEIADES-HR

Figure 16 - Artist's view of the Pleiades satellite [CNES/Pierre Carril]

The decision about the setting up of the Pleiades program is the result of an in-depth study about the user needs evolution. A cooperation program was initiated between France and Italy, taking advantage of all the CNES Earth observation skills, to develop ORFEO, a dual Earth observation system with metric resolution, in which Pleiades (France) is the optic component and Cosmo-Skymed (Italy) is the radar component.

This component is made of two "small satellites" (mass of one ton) offering a spatial resolution at nadir of 0.7 m and a field of view of 20 km. Their great agility enables a daily access all over the world, which is a critical need for defence and civil security applications, and a coverage capacity necessary for the cartography kind of applications at scales better than those accessible to SPOT family satellites. Moreover, PLEIADES have stereoscopic acquisition capacity to meet the fine cartography needs,

notably in urban regions, and to bring complete information given by aerial photography [36].

Characteristics

Mass: 1000 kg

Panchromatic resolution: 0.7 m at nadir

Multispectral resolution: 4 times panchromatic resolution

Swath: 20 km at nadir

Sun-synchronous, quasi circular orbit at 694 km altitude

Acquisition capability: up to 450 images/day

Solar generator power: 1500 W

Instrument TM link rate: 450 Mbits/s

On board mass memory: 600 Gbits

Lifetime: 5 years


33

6.1.1 PLEIADES-HR Data Handling System

The Pleiades On-Board Software (OBSW) is executed by the active Processor Module (PM) of the On-Board Management Unit (OBMU). The OBSW is in charge of:

• Ground/board communication through telecommand (TC) and telemetry (TM)

• Platform management (equipment configuration and monitoring)

• Satellite attitude and rates control through the Attitude and Orbit Control System (AOCS)

• Payload configuration according to mission programmation

• Management of decentralized system: Star tracker, Doris

• Satellite Power management

• Bus and Instrument thermal control

Furthermore, the set of services provided by the OBSW is divided into the following subsystems:

• System Software:

- Software Initialization sequence.

- System modes management.

• Data Handling System (DHS) Software:

- Management of the OBMU and its external IO.

- Management of the MIL-STD-1553B protocol on the three 1553 buses.

- Configuration of the on-board time and the synchronization with the DORIS equipment for the correlation of the spacecraft time with the TAI (International Atomic Time) reference.

- Handling of the telecommand flows, including the management of time-tagged TC list, the routing of 1553TC to an equipment connected on one 1553 bus, and the distribution of TCH (Telecommand Software) inside the OBSW.

- Handling of the telemetry flows, including housekeeping TM, diagnostic TM, telemetry onboard storage, and packet transmission control.

- Monitoring service.

• AOCS Software:

- AOCS modes management.

- Spacecraft Guidance, Navigation and Attitude Control

- AOCS equipments management:

Sensors: CSS (Coarse Sun Sensor), MAG (Magneto-Meter), DORIS (Détermination d’Orbite et Radio positionnement Intégré par Satellite), IMU (Inertial Measurement Unit), STR (Star Tracker)

Actuators: RW (Reaction Wheel), CMG (Control Moment Gyro), MTQ (Magneto-Torquer), RCS (Reaction Control System)


34

- Functional AOCS monitorings.

• Payload Software:

- Instrument management.

- Instrument thermal control.

- COME (Compressor and Memory) equipment management.

- TMI (Telemetry of Instrument) management.

- DCU (Deciphering Ciphering Unit) equipment management.

• Platform Software:

- The battery charge regulation and its monitoring.

- The bus thermal control.

- The Deployment sequence.

The OBSW is in interface with equipments through three redundant MIL-STD-1553B buses. The Figure 17 hereafter presents the satellite data handling architecture and the organisation of the equipments connection to the three 1553 buses accessible by the OBSW.

Figure 17 - Spacecraft data handling architecture


35

On Pléiades, three redundant 1553 buses are managed by the OBMU:

• the Internal Control Bus of the OBMU

• the Avionics bus

• the Payload bus

The OBSW handles all the exchanges, acquisitions and commands, with the Remote Terminals connected on each 1553 bus. These exchanges are limited to messages between BC and RT, i.e. there is no communication RT to RT.

For each external bus, the channel A is connected to the PM A and the channel B to the PM B, i.e. the BC on a PM manages only one channel. Each RT is connected to both channels of a bus. The following figures present the layout of the equipments on the three 1553 buses of the Pléiades spacecraft.

Payload 1553 bus coupler interfaces

Figure 18 – Payload 1553 bus

The following strings are used for the Payload 1553 bus:

MSI : Module of Services for Instrument (Instrument)

COME : Compressor and Memory

DCU : Deciphering Ciphering Unit

DRU : Distribution and Regulation Unit

Avionics 1553 bus coupler interfaces

Figure 19 – Avionics 1553 bus


36

The following strings are used for the Avionics 1553 bus:

CMG : Control Moment Gyro

STR : Star Tracker

FOG : Fiber Optic Gyro

DORIS : Détermination d’Orbite et Radio positionnement Intégré par Satellite

OBMU Internal 1553 bus coupler interfaces

Figure 20 – OBMU Internal 1553 bus

The following strings are used for the OBMU Internal 1553 bus:

MM : Mass Memory

TTR : Telemetry, Telecommand and Reconfiguration board

IOT : Input/Output for Thermal and power chain

IOS : Input/Output for Servicing equipments

IOP : Input/Output for Propulsion chain

HKOBS : House Keeping Observation (OBMU board)

MAG : Magneto-meter

MTQ : Magneto-torquer

CSS : Coarse Sun Sensor

RWA : Reaction Wheel Assembly


37

6.1.2 Avionics Bus Equipments

6.1.2.1 IMU: Inertial Measurement Unit

The IMU contains four independent measurement axes based on a given Fiber Optic Gyro channel mounted along a regular tetrahedral configuration. So, the IMU measures the inertial angular motions around up to four independent axes and provides them on a data bus. The IMU delivers raw uncompensated inertial data (i.e. cumulated angular increments).

The FOG measurement principle is based on Sagnac effect : considering an optical ring in a plan with a light transmitter/receiver, two light pulses emitted in opposite directions, are received at the same time if there is no rotation in the plan of the ring. When a phase difference is detected at reception of the two signals, it is proportional to the rotation of the ring. The Sagnac effect is depicted in the following figure.

Figure 21 – Sagnac effect

The IMU is broken down into two distinct components:

• the Inertial Core Unit (ICU) containing the four fiber coils and proximity optical components,

• the Gyro Electrical Unit (GEU) containing the corresponding four FOG electronics (power interface, data interface, FOG loop electronics, optical laser source).

Figure 22 – IMU HW architecture and redundancy


38

6.1.2.2 STR : Star Tracker

The Star TRacker (STR) performs the measurement of the stars location and brightness in a two dimensional frame and delivers a three axes attitude of a measurement reference frame in J2000 inertial reference frame (the average celestial frame the first January 2000, 12h TU).

Three STR are mounted on the spacecraft as illustrated bellow. All the STR are functionally and electrically independent units operated in hot redundancy. They deliver attitude quaternions representative of the STR measurement reference frame orientation in the inertial J2000 reference frame.

Figure 23 – STR unit location on the Spacecraft

The STR has a modular architecture featuring:

• a separated optical part : STR-O = optical head + baffle + proximity electronics + thermal HW

• a electronics part : STR-E = power + data interface + measurement processing

The STR-O is directly mounted on the spacecraft instrument primary structure for a tight mechanical stability with respect to instrument line of sight. Whereas the STR-E is located inside the spacecraft BUS.

Figure 24 – STR HW architecture and redundancy


39

6.1.2.3 DORIS Equipment

The worldwide Doris radio-localisation system (Doppler Orbitography and Radiopositioning Integrated by Satellite), based on a global network of about 50 ground beacons (transmitting at 400 MHz and 2GHz), allows to compute the spacecraft position and velocity with a high precision. The DORIS equipment supplies the Pléiades onboard system with precise orbit positionning and datation information, acquired through a specific communication protocol on the Avionics MIL 1553B bus.

This information generated autonomously by Doris is provided within TM Packets which have all the same structure. These Doris TM packets are of the following types:

• One Datation bulletin (in TAI time), used for spacecraft on board time synchronisation, generated at 1 Hz following the 1 Hz PPS reception by Doris,

• Three Navigation bulletins (respectively in J2000, geodetic and ITRF reference frames), the first one being used for on board navigation algorithms, all three being generated autonomously at 1/10 Hz,

• One Doppler bulletin, containing Doppler measurements, generated autonomously at 1/10 Hz, and constituted from three consecutive packets in the same sub-address,

• Routine or Anomaly reports, generated on event (e.g. mode change, anomaly,...),

• Three Tests reports, generated on ground request by specific TC,

• One Attitude bulletin (Disabled, as it is not used for Pleiades)

The Quality Index of the J2000 navigator bulletin, used by the on board navigation algorithms, is checked by the centralised software before taking into account the incoming data, and to monitor the equipment behaviour. This QI is processed by the OBSW as the datation one, with a specific convergence threshold. The other information provided by Doris via the MIL 1553B protocol is not used on board, and is only collected for ground information through telemetry.


40

Figure 25 – Doris HW architecture and redundancy

The Doris chains are managed in cold redundancy, i.e. only one Doris equipment is powered at a time (since only one antenna exists on board). The central flight software running on the active PM (A or B) can access to both Doris equipments, via the active Avionics 1553 bus and via the direct input/ouput lines supported by the active OBMU I/O boards.

6.1.2.4 CMG : Control Moment Gyro

A CMG (also called AG for Actionneur Gyroscopique) is composed of three main parts:

• a wheel providing a angular momentum when spinning

• a motorized gimbal which supports the wheel

• an electronics which drive both wheel and gimbal.

The principle of actuation by a CMG is the following: commanding a gimbal rotation when the wheel is spinning provides a torque because of the gyroscopic effect .


41

Figure 26 – CMG principle of actuation

The CMG cluster configuration implemented on the spacecraft includes four CMG in a tetrahedral position along the spacecraft Z axis. The angle between the each gimbal direction and the spacecraft Z axis is 60 dg. Hereafter is illustrated the CMG cluster configuration.

Figure 27 – CMG cluster configuration

The AOCS can use the CMG cluster for two kinds of control. During the manoeuvre, the AOCS is in charge of computing consistent angular position, rate and acceleration profile for all the CMG, given that the requirement variation of spacecraft angular momentum is of great magnitude. Outside manoeuvres, the AOCS control torques are small, so very small magnitude commands are sent to CMG. The CMG are commanded around their current position with almost zero rate.

With respect to the hardware architecture configuration, each PM can access to each CMG through the redounded 1553 bus. All CMG can be switched on at the same time, and the monitoring data including temperature is available for each channel. Bellow, there is an illustration of the hardware architecture.


42

Figure 28 – CMG HW architecture and redundancy


43

6.2 PLEIADES-HR AFDX

Following is the description of the AFDX proposed solution to accommodate the Avionics bus.

Figure 29 - Avionics Bus AFDX Description

There are two independent switched networks in the AFDX system, the A and the B Networks. Each packet transmitted by an End System is sent on both networks. Therefore, under normal operation, each End System will receive two copies of each packet, such that data flows are protected against the failure of any network component such as a link or a switch.

As mentioned in the previous study, the 100 Mbps Ethernet link of an End System can support multiple virtual links. These virtual links share the 100 Mbps bandwidth of the physical link. Just as partitions are used to isolate Avionics subsystems from one another, a similar mechanism is required to isolate individual virtual links, in order to prevent the traffic on one virtual link from interfering with traffic on other virtual links using the same physical link. This is done by limiting the rate at which

AFDX Switch B

AFDX Switch A

CMG 1

AFDX ES

CMG 2

AFDX ES

CMG 3

AFDX ES

CMG 4

AFDX ES

PM A

AFDX ES

PM B

AFDX ES

FOG 1

AFDX ES

FOG 2

AFDX ES

FOG 3

AFDX ES

FOG 4

AFDX ES

STR 1

AFDX ES

STR 2

AFDX ES

STR 3

AFDX ES

DORIS A

AFDX ES

DORIS B

AFDX ES

hot redundancy

cold redundancy


44

Ethernet frames can be transmitted on a virtual link and by limiting the size of the Ethernet frames that can be transmitted on a virtual link.

Each virtual link is assigned two parameters:

• Bandwidth Allocation Gap (BAG), a value ranging in powers of 2 from 1 to 128 milliseconds

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

The BAG represents the minimum interval in milliseconds between Ethernet frames that are transmitted on the virtual link. For example, if a virtual link (VL 1) has a BAG of 64 milliseconds, then Ethernet packets are never sent faster than one packet every 64 milliseconds on VL 1. If VL 1 has an Lmax of 120 bytes, then the maximum bandwidth on VL 1 is 15000 bits per second (Lmax/BAG).

In the case of performing cycling acquisitions at 8 Hz, to provide adequate bandwidth to the virtual link, we should select a BAG that is less than 125 ms. The first available BAG is 64 ms, which corresponds to a frequency of 15.625 Hz. With a BAG of 64 ms, it is guaranteed that the virtual links are able to perform the acquisitions without any backlog.

On the other hand, Lmax should be chosen to accommodate the largest Ethernet frame to be transmitted on the virtual link. A complete AFDX frame will contain at most 1526 bytes (minimum length is 72 bytes), having a Payload ranging from 17 to 1471 bytes. (Preamble: 7; Start Delimiter: 1; MAC Header: 14; IP Header: 20; UDP Header: 8; AFDX Payload: 17 ...1471; Sequence Number: 1; FCS: 4)

6.2.1 Pleiades AVB Virtual Links Specification

All Virtual Links are designed following AFDX specifications to suit the needs of the on-board software Data constraints, for Acquisitions (ACQ) and Commands (CMD), which are hereafter illustrated from the User Requirements Document.

Data Type Constraint Identification Constraint Description

Cyclic (ACQ) URD.DHS.1553.FUNC.0500 The OBSW shall be able to acquire RT data cyclically, on one of the following frequencies: 32 Hz or 8 Hz.

Dwell (ACQ) URD.DHS.1553.FUNC.0900 The OBSW shall be able to program new cyclic acquisitions of 8 Hz or 32 Hz frequency on ground request, during a given period, for any RT connected on a 1553 bus.

Accurate (CMD) URD.DHS.1553.FUNC.1300 The OBSW shall be able to send accurate commands on the next RTC cycle with a resolution better than 32 ms.


45

Data Type Constraint Identification Constraint Description

Asynchronous (CMD)

URD.DHS.1553.FUNC.1100 The OBSW shall be able to send asynchronous commands, that will be transmitted on the bus in the incoming order, and within the next 250 ms following the request.

Asynchronous Urgent (CMD)

URD.DHS.1553.FUNC.1200 The OBSW shall be able to send urgent asynchronous commands that shall be sent within 125 ms after this request is raised.

Asynchronous Raw

URD.DHS.1553.FUNC.1600 The OBSW shall allow to exchange raw data or CCSDS packets with a remote terminal on the 1553 bus according to the specific protocols required by the equipments and managed at application level.

Table 2 – Data Types as specified in the Pleiades URD

The table below indicates the different data types specified in the Pleiades User Requirements Document and their virtual links associated characteristics. The obtained BAG times are overdimensioned since the valid values are powers of 2. Besides, the Jitter is calculated for the requirements from the maximum jitter formula.

Data type CMD /ACQ Data Length Requested Accuracy BAG Max_jitter (per VL)

Cyclic ACQ 64 125 ms 64 ms 11.12 µs

Dwell ACQ 64 31.25 ms 16 ms 11.12 µs

Accurate CMD 64 < 32 ms 16 ms 11.12 µs

Asynchronous CMD 64 Worst case 125 ms 64 ms 11.12 µs

Async_Urgent CMD 64 Worst case 62.5 ms 32 ms 11.12 µs

Async_Raw 1471 Best-effort 128ms 122.08 µs

Table 3 – Virtual Links associated to the URD Data Types

According to the previous considerations, the Pleiades Avionics Bus complete Virtual Links description and their characteristics are presented. It is indicated: the source and destination End Systems, the VL identifier (for each Source ES), the type of transfer for every VL, whether if the transfer is a command or an acquisition, the BAG, the jitter for the associated end system, the maximum length of the VL frames and the bandwidth reserved.


46

Source ES

VL Destination ES

Transfer CMD /ACQ

BAG JITTER Lmax Bandwidth (Lmax/BAG)

CMG 1 1 PM A/B Cyclic ACQ 64 53,58µs 96+55 2359.375 B/s




STR 1 1 PM A/B Cyclic ACQ 64 92.08µs 576+55 9859.375 B/s



FOG 1 1 PM A/B Cyclic ACQ 64 62,24µs 64+55 1859.375 B/s

FOG 1 2 PM A/B Cyclic (32Hz)* ACQ 16 62,24µs 64+55 7437.5 B/s







DORIS A/B

1 PM A/B Accurate 16 51,12µs 64+55 7437.5 B/s

PM A/B 1 CMG 1 Async_Urgent CMD 32 380µs 64+55 3718.75 B/s




PM A/B 5 STR 1 Async_Urgent CMD 32 380µs 224+55 8718.75 B/s



PM A/B 8 FOG 1 Asynchronous CMD 64 380µs 64+55 1859.375 B/s




PM A/B 12 DORIS A/B Accurate 16 380µs 64+55 7437.5 B/s

PM A/B 13 Dwell ACQ 16 380µs 64+55 7437.5 B/s


47

Source ES

VL Destination ES

Transfer CMD /ACQ

BAG JITTER Lmax Bandwidth (Lmax/BAG)




PM A/B 17 ** Asynchronous 64 64+55

PM A/B 18 Async_Raw CMD 128 380µs 1471+55 11921.875 B/s

Notes:

* There is one IDVA acquisition by FOG and by 32Hz cycle.

** Not necessary. There is overcapacity in all the other VLs.

Table 4 – Pleiades Avionics Bus Virtual Links

As a result the following table contains an overview of the Bus bandwidth occupancy as compared to the actual 1553 on Pleiades.

BUS Frame occupancy

AVB AFDX 1.45 % (1449.75 Kbits/s)

AVB 1553 60.00 %

Table 5 – AFDX Bus Bandwidth occupancy

It should be remarked that AFDX accounts with a maximum bandwidth of 100Mbits/s, whereas the theoretical rate of the MIL-1553-B is 1Mbits/s. In the same way, all the virtual links were designed with spare bandwidth, resulting that the actual frame exchange load is within the same range in both buses.

Regarding this solution, there are certain aspects that have to be considered. Contrary to the 1553 Bus full time determinism, the AFDX approach only assures a bounded period of time in which the message it is going to be delivered, by restricting the best-effort defined in the Ethernet protocol. Thus, the AFDX protocol defines the length of the frames to be transmitted and the maximum transmission rate between two consecutive frames (BAG). It is a requisite of the End Systems to schedule its exchanges in order to fulfil the URD constraints.

For example, the CMG constraint “All CMG actuation commands must be sent at the latest 60 ms after the PPS 32 Hz following the second FOG IDVA acquisitions” is further analyzed in Figure 30. The CMG associated virtual link has a BAG time of 32 ms, which allows the OBMU to place the requested message up to 28 ms after the PPS 32 Hz. Therefore, the OBMU End System must define at application level the scheduling of the command in order to fulfil the constraint.


48

Figure 30 - CMG Constraint description

AFDX End Systems must provide both sampling and queuing port services, as described in ARINC 653. These ports work as FIFO buffers (First In, First Out) so that it is not possible to set priorities within the ES Scheduler for the different virtual links. Consequently, in the case that two Ethernet frames arrive to the same buffer within a short delay, the ES internal scheduler will regulate the stream of frames to a rate determined by the BAG, thus the second Ethernet frame will experience a queuing delay of maximum a BAG time. To prevent this fault in design, it is recommended to increase the number of virtual links to avoid overloading, as it is specified in this study for the case of the Fiber Optic Gyros.

Furthermore, Jitter is introduced at the output of the regulator when multiplexing the signal from various virtual links within the same ES; however, this jitter can be estimated and does not exceed a maximum AFDX jitter specification. Both the jitter and the BAG times have been calculated for the Avionics Bus and are specified for every virtual link in the tables above. An illustration of the ES packet regulation and multiplexing can be seen in Equation 1 - Max Jitter.

Concerning the data integrity, AFDX provides a sequential stream of data (by using sequence numbers for the redundancy management) at the defined time intervals (BAG) with a very high degree of error detection, using cyclical redundancy check (CRC). Whilst errors in transmission look like missing data for AFDX, it is regarded as delayed data by Ethernet, thanks to the mentioned sequence numbers and the time determinism. However, due to an inherent design tradeoff, errors in AFDX are rejected, therefore, packet retries or acknowledgements should be implemented at the application level. This is a result of the protocol’s commitment with the time determinism of the transfers.

PPS 32Hz

2nd FOG ACQ

60 ms

32 ms (BAG) 28 ms


49

6.3 PLEIADES-HR FLEXRAY

Hereafter it is presented the FlexRay bus structure adapted to the architecture of the Pleiades Avionics bus.

Figure 31 – Avionics Bus FlexRay Schematic

As depicted, the FlexRay Pleiades bus will consist of 15 avionic nodes, 4 of them in cold redundancy (DORIS and the Processor Modules), connected to two independent buses (channels A and B), providing a dual-channel redundancy to improve the robustness of the network. Both the two redundant processor modules and the two DORIS nodes will be assigned to the same static slots, as they will never be communicating in the same cycle.

The topology of the network was chosen a bus since there are not specific requirements in the Pleiades URD, and in order to respect the topology configuration of the MIL-STD-1553B which is a

hot redundancy

cold redundancy

PM A

PM B

CMG 1

CMG 2 CMG 3 CMG 4

STR 1

STR 2

STR 3

FOG 1 FOG 2 FOG 3

FOG 4

DORIS A

DORIS B

Channel A

Channel B

BG BG BG

BG

BG

BG

BG

BG

BG BG BG

BG

BG

BG

BG

BG Node Bus Guardian


50

Bus. If there would be needed more partitioning to avoid the spreading of errors, central bus guardians could be used instead of node guardians to isolate the different systems.

As an extension to the network, the communication cycle distribution is illustrated in Figure 32.

Figure 32 – AVB FlexRay Communication Cycle distribution

Furthermore, each node in the network will have a Communications Controller handling the communications on both channels, a node Bus Guardian ensuring the time-determinism of the communications, and a Bus Driver undertaking the transmission of the data through the channel. This local bus guardian configuration was already described in the previous FlexRay study.

Regarding to the data throughput, the standard for FlexRay communications is 10 Mbits/s, even though it can operate at slower rates, down to 2.5 Mbits/s. In the case the two channels would transmit independently, which is feasible under this configuration, the throughput could reach 20 Mbits/s. However, within this study the configuration is considered redundant in order to achieve a high fault-tolerant performance.

6.3.1 Calculation of FlexRay parameters

The FlexRay configuration parameters will be defined following a top-down strategy, to meet the requirements imposed by the operating frequency of the PLEIADES functional control loops (32 Hz, 8 Hz) from the User Requirements Document. Due to the fact that the FlexRay cycle is limited by the protocol specification to a maximum of 16000 µs, i.e. 62.5 Hz, the operation of the cyclic acquisition

2 1 4 3 6 5 12 7 8 10 9 11 13 A

2 1 4 3 6 5 12 7 8 10 9 11 13 B

Static segment

Static slot

15 1 4 16 19

15 14

16 19

Dynamic segment

Mini slot

Communication Cycle

NIT 18 17

18 17

SW

SW

37

37

,,,

,,,


51

and commands should take advantage of an underlying feature of FlexRay which is the Cycle Multiplexing.

The Cycle Multiplexing can be used if processes need a slower transmission period than the defined cycle time. For example, if the cycle time is 2 ms, and a process only needs to send frames every 6 ms this slower process could use cycle multiplexing and transmit every 3rd cycle. Therefore, frames can be transmitted with a period that is multiple of the cycle time. Within the same slot different frames can be transmitted in different cycles. The sender of the different frames is constantly the same in the static segment, but can be different in the dynamic segment.

With respect to the PLEIADES communication cycle, since the maximum allowed cycle length in FlexRay is 16ms, the control loops 8 Hz operating frequency (125ms) is split into 8 recurring cycles. Thus, obtaining a FlexRay cycle with a frequency of 64 Hz, the one can deal with all the required communication constraints. Hereafter is presented the cycle schedule.

Time (ms) 15.625 31.25 46.875 62.5 78.125 93.75 109.375 125 140.625 …

FlexRay Cycle 0 1 2 3 4 5 6 7 8 …

Pleiades 32 Hz 1 2 3 4 5 …

Pleiades 8 Hz 1 2 …

Table 6 – Cycle schedule

The FlexRay cycle is thereafter 15.625 ms. This includes the static segment, the dynamic segment, the symbol window (required by the protocol) and the network idle time (utilized to synchronize the nodes).

The duration of a nominal macrotick will be configured to 5 µs for all FlexRay nodes, having that it is feasible multiple of the node’s internal clock and it suits the following distribution. Notwithstanding, the number of microticks per macrotick will vary for each node, depending on the node’s internal clock frequency.

Allowing for large extra bandwidths in both static and dynamic segments, the next configuration was designed. A static slot will consist of 120 macroticks, i.e. 600 µs; therefore, the duration of the static segment will last, for the 13 nodes, 7800 µs within on cycle. On the other hand, the dynamic segment will be allocated 6000 µs, allowing the transmission of asynchronous and raw data. The dynamic segment will account with 24 minislots that will mark the possible starting periods for the asynchronous transmissions, lasting 50 macroticks each. Moreover, the Symbol Window (SW), needed for FlexRay protocol commands, and the Network Idle Time (NIT), needed for synchronization, have reserved 1825 µs.


52

The following is a summary of the FlexRay Protocol Specification parameters, and the selected for the Pleiades Avionics Bus:

Parameter Pleiades Configuration FlexRay Min FlexRay Max

Cycle length 15625 µs 10 µs 16000 µs

Payload length variable 0 254 Bytes

Macrotick (MT) 5 µs 1 µs 6 µs

Minislot duration 50 MT 2 MT 63 MT

Static slot duration 120 MT 4 MT 661 MT

Number of Minislots (dynamic segment) 24 0 7986

Number of Static slots (static segment) 13 2 1023 *

Symbol window duration 50 MT 0 142 MT

Network Idle Time 315 MT 2 MT 805 MT

* Highest static slot ID number

Table 7 – FlexRay parameters for Pleiades

Once the main parameters are described, hereafter is presented the complete list of the static and dynamic slots for the Pleiades Avionics AFDX Bus and their characteristics. It is indicated: the number of the slot, the node assigned to the slot, the channels the node is connected to (channel A or channel B, or both channels A and B), the maximum length of the payload data frames, the duration of the slot, and finally, whether the slot belongs to the static segment, for cyclic acquisitions multiplexed in time, or to the dynamic segment, for asynchronous transmissions. More information can be found in the dedicated frame definition document.

Slot Node Channel Payload Max. Duration

1 CMG 1 A & B 254 Bytes 600 µs




5 STR 1 A & B 254 Bytes 600 µs



8 FOG 1 A & B 254 Bytes 600 µs

Stat

ic s

egm

ent

9 FOG 2 A & B 254 Bytes 600 µs


53

Slot Node Channel Payload Max. Duration

10 FOG 3 A & B 254 Bytes 600 µs

11 FOG 4 A & B 254 Bytes 600 µs

12 DORIS A/B A & B 254 Bytes 600 µs

13 PM A/B A & B 254 Bytes 600 µs

14 Asynchronous A & B 254 Bytes 250 µs



… … … … …

Dyn

amic

seg

men

t


Table 8 – FlexRay static and dynamic slot division

To illustrate the Bus bandwidth occupancy obtained from the case study as compared to the actual 1553 bus on Pleiades, the next table is presented.

BUS Frame occupancy

AVB FlexRay 7.79 %

AVB 1553 60.00 %

Table 9 – AFDX Bus Bandwidth occupancy

Analogously, we should be aware that FlexRay disposes of 10Mbits/s of bandwidth, whereas the theoretical rate of the MIL-1553-B is 1Mbits/s. Moreover, as in the previous study, both the static and dynamic segments account with overcapacity, and the exchange of data is approximately the same in all three buses.

6.3.2 AVB 1553 constraints applied to AVB FlexRay

As a result of this study, it can be appreciated that FlexRay is conceived for full strict time determinism, on the contrary to AFDX which, as seen in the previous chapter, lacked of a delivery time for each transmission, having instead a probabilistic time of delivery within established bounds.

In order to verify that the FlexRay definition of the Avionics Bus is compliant with the 1553 constraints expressed in the user requirement documents, the different constraints and associated checks are detailed below.


54

FOG constraints

Constraint:

• FOG IDVA must be acquired each 32 Hz cycle, at least 1 ms after PPS 32 Hz and before the next PPS 32 Hz.

Check:

• There is one IDVA acquisition by FOG (name = FGFOGRAIN9_x) and by 32 Hz cycle.

• The first four acquisitions are done in cycle 0, at least 1 ms after slot 1 and before cycle 2.

• The second four acquisitions are done in cycle 2, at least 1 ms after slot 1 and before cycle 4.

• The third four acquisitions are done in cycle 4, at least 1 ms after slot 1 and before cycle 6.

• The second four acquisitions are done in cycle 6, at least 1 ms after slot 1 and before cycle 8 (end of Pleiades’ cycle).

STR constraints

Constraint:

• The OBSW must acquire permanently the sub-addresses SA13 to SA19 of each STR.

• Sub-addresses S1 and SA13 to SA19 must be acquired at least 7.8 ms after start of cycle.

Check:

• Sub-addresses SA13 to SA19 (name = WGSTRTTM_x, WGSTRTD1_x to WGSTRTD6_x) are acquired for the three STR.

• First STR acquisitions (name = WGSTRSA_x) is acquired in cycle 1, at least 7.8 ms after start of cycle 0.

CMG constraints

Constraint:

• All CMG actuation commands must be sent at the latest 60 ms after the PPS 32 Hz following the second FOG IDVA acquisitions.

Check:

• First and last CMG actuation commands (name = HGCMGWHEEL1, HGCMGGIMBAL4) are sent between 50 and 60 ms after the PPS 32 Hz.

DORIS constraints

Constraint:

• The “transmit vector word” must be sent at least 75 ms after 1Hz PPS pulse.

• The “Synchronise with data word” must be sent at least 25 ms before 1 Hz PPS pulse.

• The Attitude TC mus be sent after the ground TC in the 8 Hz cycle.

Check:

• The “transmit vector word” (name = VWSDW) is sent at least 75 ms after start of cycle 0.


55

• The “Synchronise with data word” (name = VWSDW) is sent at least 25 ms before end of cycle 7 (end of Pleiades’ cycle).

• The Attitude TC (name = DORATTCMD) is sent after the ground TC (name = DORCMD).


56

7. MODELING THE PLEIADES-HR AVIONICS

7.1 INTRODUCTION

Avionics systems are steadily increasing in complexity, added to the fact that their development is carried out by multidisciplinary and geographically distributed teams, make the classic approaches to system engineering obsolete. Therefore, model based techniques are taking over, offering an improvement between the transition of the different project phases, the harmonization of the interfaces relaying the subsystems development, and making the system more flexible to changes in the requirements.

Model-based engineering serves as a platform to guide the project through its different steps. It supports the analysis of the customer requirements, the system specification, the definition of the top-level architecture and the previous system verification and validation processes. The definition of the system is undertaken recursively, decomposing the system in various hierarchy levels to attain a certain desired level of detail. The benefits obtained from this approach translate into reduction of overall life cycle cost, increased operational performance and the reutilization of components from legacy source code.

Figure 33 – Application scope of the VERDI toolset

7.1.1 Scope of the Case Study

The model-based design favours the development of avionics hardware-software co-design activities, by giving the software and hardware teams a common understanding of requirements. In this regard, the scope of the Case Study is to familiarize with an Avionics Architectural Description Language (AADL) to create a Model of the Avionics Architecture of the Pleiades satellite.


57

7.1.2 Modelling Tools

7.1.2.1 Architecture Analysis & Design Language (AADL)

AADL is a modeling language standardized by the Society of Automotive Engineers (SAE) that supports early and repeated analyses of a system's architecture with respect to performance-critical properties through an extendable notation, a tool framework, and precisely defined semantics.

The language employs formal modeling concepts for the description and analysis of application system architectures in terms of distinct components and their interactions. It includes abstractions of software, computational hardware, and system components for specifying and analyzing real-time embedded and high dependability systems, complex systems of systems, and specialized performance capability systems and mapping of software onto computational hardware elements.

The AADL is especially effective for model-based analysis and specification of complex real-time embedded systems. AADL enjoys growing acceptance in avionics, aerospace, automotive, and robotics communities. Organizations such as the SEI, Airbus, Honeywell, Rockwell-Collins, the European Space Agency, TNI Europe, and General Dynamics actively contribute to AADL development.

7.1.2.2 OSATE

The Model has been created with an open-source AADL tool environment called OSATE. The toolset provides textual, object-based and graphical editing capabilities for defining functional and physical system architectures integrated within a single IMA (Integrated Modular Avionics) system. OSATE has been developed by the Software Engineering Institute of the Carnegie Mellon University. It includes an AADL front-end and architecture analysis capabilities as a set of plug-ins on top of the open-source Eclipse platform. Besides, Airbus is providing an open source graphical editor that is integrated with OSATE under the TOPCASED initiative. The OSATE toolset environment is illustrated hereunder.

Figure 34 – OSATE Environment


58

7.1.2.3 VERDI

VERDI (Verified Engineering of Runtime blueprint Data for IMA systems) is a tool for the automated generation of System Configuration Data, referred as “Blueprints”, created by EADS Defense & Security.

IMA systems comprise a functional and physical architecture which specifies components at the application and platform level, respectively. The mapping of functional onto physical architectures is defined by the so called system configuration tables or blueprints. In order to cope with the inherent system complexity, the aim of VERDI is to tightly integrate the automated generation of blueprints into the overall system design process. Key requirement for a tight process integration is a generic open IMA design representation that is not only capable of modeling any IMA standard but also supports the translation from and to design representations used by other tools. The applicability of VERDI is illustrated in the following figure.

Figure 35 – VERDI Blueprint generation process The VERDI System Integration Toolset itself is based on OSATE (Open Source AADL Tool Environment). Therefore the system models are specified in AADL notation. Blueprint generation is based on models. Furthermore, there are separate models for functional and physical architecture and also for combined systems. The different models are called Design time Blueprints:

• Configuration Blueprint: Represents the system design and defines the system’s hierarchical structure and its composition.

• Application Blueprint: Describes the occupation and consumption of processing resources for a specific application.

• CFM Resource Blueprint: Describes the characteristics of processing resources provided by a specific Common Functional Module (CFM).


59

• Platform Resource Blueprint: Defines the whole IMA Core System platform with regards to Power- and Network management.

• System Blueprint: Fuses Application Blueprints, Resource Blueprints and the Configuration Blueprint. Acts as interface for Runtime blueprint generation.

The relevant steps for performing an IMA system integration with the VERDI toolset comprise the 4 subsequently summarised steps:

Design of the Functional Architecture: This is the application architecture of an IMA system. It comprises a set of interconnected application components which constitute a set of functional chains.

Design of the Physical Architecture: This denotes the platform architecture of an IMA system. It comprises a set of computing resources interconnected by network resources. Physical architectures can be modelled at any level of abstraction ranging from the pure hardware to the middleware level.

Integration of Functional and Physical Architecture: This denotes the actual IMA system integration step. Based on the designs of both functional and physical architectures OSATE binds the systems together.

Blueprint Generation: This is merely a transformative step. One of the previously calculated mappings is selected and translated into a blueprint or configuration table. These are standardised XML formats for the specification of bindings between the components of the functional and physical architectures of an IMA system.

For the purpose of this case study this last Blueprint Generation step was not considered necessary since the interest of the project remained in the actual modeling of the avionics physical and logical levels. The Main benefit of this modular structure is independence of hardware and software models which enables their reuse. Hereafter is depicted the design Blueprint concept utilized by VERDI. The modeling takes place incrementally with a bottom-up approach.

Figure 36 – Design time Blueprint concept


60

7.2 PLEIADES AVIONICS MODEL FOLLOWING THE VERDI CONCEPT

Regarding the system design, it is a main goal to define the Integration Areas and therefore the system management hierarchy. Within VERDI the design is started by modeling the Resource Elements (RE) which contains the real hardware respectively software. Afterwards corresponding REs are combined into an Integration Area (IA) which is responsible for controlling and monitoring a function. A system can comprise several IA levels, but at the top there is only one Aircraft (AC) level which is responsible for the overall IMA system behaviour. The structure/architecture of such a system for the PLEIADES avionics is illustrated below:

Figure 37 – Avionics System structure/architecture

The different hierarchy levels indicate the architecture relationships within the AC (Aircraft) system. The depicted Integration Area (IA) of the On-Board Management Unit (OBMU) includes the two redundant Processor Modules (PMs). The IA for Inertial Measurement Unit (IMU) consists of 4 Resource Elements for the Fiber Optic Gyros (FOG). With respect to the DORIS equipments, they are integrated in the Doris function IA. The Control Moment Gyros (CMG), as well as the Star Trackers (STR), are not contained in an IA because each one of them posses an independent control function.

The architecture is the starting point for software respectively hardware modelling activities. The system structure is refined by modelling the detailed hardware (processor, memory, bus) and software (application, process, port, connection) components.

AC

IA

RE RE

DORIS_A

IA

RE RE

PM_A PM_B

DORIS_B

OBMU BDR

RE

CMG1

IA

RE RE RE RE

FOG1 FOG3

FOG2 FOG4

IMU

RE

CMG4

●

●

RE

STR1

RE

STR3

●

●


61

OSATE offers three editors for the architectural design of systems. This tool enforces the semantically correct editing of the aforementioned generic design representation and provides guidance for the design and integration of IMA systems. For ease of understanding the graphical models will be presented.

7.2.1 Modeling the Logic Components

7.2.1.1 Resource Elements (REs)

At the beginning low level logic components are defined i.e. Resource Elements (RE). Each and every RE include a Generic System Manager (GSM), as required by VERDI, which deals with the Health Monitoring and Fault Management (HMFM) and the Control Management (CM) of the equipment. The RE is administered by a Broker process which sends the required cyclic acquisitions (ACQ) and receives the asynchronous commands (CMD) from the OBMU.

Figure 38 – Modelled Resource Element

The external Port Connections of the REs are configured according to the Virtual Link characteristics needed for each sub-system data exchange. They define the Data Type (i.e. ACQ or CMD), the Exchange Type (Cyclic, Dwell, Accurate, Asynchronous, Urgent or Raw Data), the frequency required for the open loop (32 Hz or 8 Hz, in the case of PLEIADES), the maximum Data Size and the maximum Exchange Data Rate of the associated Virtual Link. The AADL code below is an example of a cyclic acquisition port and an asynchronous command port with the Virtual Link features defined.

Broker_OBMU_ACQ_Out: out event data port { PLEIADES_Ports::Data_Type => ACQ; PLEIADES_Ports::Exchange_Type => Cyclic; PLEIADES_Ports::Exchange_Frequency => 32.0 Hz; PLEIADES_Ports::Exchange_Data_Size => 64 B; PLEIADES_Ports::Exchange_Data_Rate => 5.0 Kbps; };


62

Broker_OBMU_CMD_In: in event data port { PLEIADES_Ports::Data_Type => CMD; PLEIADES_Ports::Exchange_Type => Asynchronous; PLEIADES_Ports::Exchange_Frequency => 32.0 Hz; PLEIADES_Ports::Exchange_Data_Size => 64 B; PLEIADES_Ports::Exchange_Data_Rate => 5.0 Kbps;

};

7.2.1.2 Integration Areas (IAs)

As next step the integration area systems are defined. The integration area system can contain the IA level GSM, which analogously to the RE GSM is in charge of the health monitoring and control of the Integration Area. The integration area contains its subordinated systems, that is the resource elements and the application system that manages the main function. Taking the Inertial Measurement Unit (IMU) as an example, the IA contains the 4 resource elements of the FOGs and the application that manages the IMU function. The Figure below shows the diagram of the modelled IMU IA with its subcomponents.

Figure 39 – Modelled IMU Integration Area

This system contains the ports for communication between the brokers on different boards and the ports for application communication, too. These ports serve as interfaces between the process to process connections.


63

7.2.1.3 Aircraft system level (AC)

The AC level system is the superior system in VERDI. An AC system has to contain an AC GSM system, which is defined in the GSM package, as the aforementioned GSMs, and subordinated systems, that is to say the Integration Areas (IAs) and the independent Resource Elements (REs). Furthermore the AC system also contains the connections between the included subcomponents.

The displayed AC system of the PLEIADES avionics includes primarily the OBMU (IA1) which interacts with the 4 CMGs (RE31 to RE34), the IMU (IA2), the 3 STR (RE41 to RE43), the DORIS equipments (IA3) and all the other status signals in the GSM AC. The AC system also contains the connections between the included subcomponents.

7.2.2 Modeling of Software Components

An application can consist of several processes with ports and connections. Moreover, each process can be subdivided in a number of threads. A example of an application system formed by the Health Monitoring and Fault Management process and the Control Management process is shown below:


64

Figure 40 – Modelling of software components

7.2.3 Modeling of Hardware Components

At the beginning low level hardware components are defined i.e. memory, busses and processors. From these elements a board (CFM) is then built up. The basic CFM chosen to represent the equipments consists of: processor (PE), memory (MEM) and a double Ethernet interface (NIU) for the redundant networks.

Figure 41 – Basic hardware component

Then, all boards are combined to a hardware platform which represents the overall hardware system including the redundant network (NSM) structure:


65

Figure 42 – Modelled hardware platform

7.2.4 Setting up the overall system

In this step the binding of the modelled hardware- and software-components is realised. Out of the individual components a complete system is instantiated. This instantiated system contains all information about the system structure including software and hardware. In the figure below there is an example of the generated model in the object-oriented view.


66

Figure 43 – Binding of SW and HW

Based on a instantiated system VERDI performs an automatic RTBP generation. The Runtime Blueprints are in comparison to Design time Blueprints not used for modelling but for configuring a real system. Nevertheless, as the purpose of this study is not to configure a real system and the RTBP generation tool was not available, this step was not undertaken.


67

8. CONCLUSIONS AND PERSPECTIVES

As current spacecraft bus technologies are facing challenges due to the increasing system demands, it was necessary to perform a review of the state-of-the-art of reconfigurable, fault-tolerant applications of high speed data networks, which could offer higher performance. The technologies chosen were: FlexRay from the automotive industry and AFDX from aeronautics.

As discussed in the FlexRay chapter, aimed at meeting the demands of high-end control applications, the FlexRay communications protocol provides high bandwidth and determinism to enable distributed control. FlexRay can also drive cost reductions by reducing the number of parallel CAN networks that have emerged recently to solve bandwidth bottlenecks. Therefore, FlexRay is in a strong position in order to become the automotive de facto standard, backed by the world’s industry.

On the other hand, AFDX communication protocols have been derived from commercial standards to achieve the required deterministic behaviour for avionics applications. The benefits from using commercial-off-the-shelf (COTS) Ethernet components include reduced overall costs, faster system development and less-costly maintenance for the system network.

As a result of the case study conducted over the Pleiades Avionics bus, it is clear that FlexRay is conceived for full strict time determinism, whereas AFDX lacked of a fixed delivery time for each transmission, having instead a probabilistic time of delivery within established bounds.

Regarding the throughput of the transfers, both networks had a superior transfer rate (100Mbps for AFDX and 10Mbps for FlexRay, compared to 1Mbps for 1553B) as to replace with efficacy the 1553B bus. Moreover, both of them presented over-capacity (higher than 90%), which responds to the increasing demands of On-Board Data Handling in Satellites.

Future avionic network architectures might include heterogeneous field-buses such as controller area network (CAN) or FlexRay in addition to AFDX, as backbone network. Nevertheless, at the moment these technologies are still in a very early phase of development as to be implemented in space applications. In this regard, it should be mentioned that the majority of current Satellites utilize the MIL-STD-1553-B bus, which standard was first published in 1973.

The last part of the Master Thesis consisted in the study of new approaches to system engineering. Relaying on the VERDI toolset for the design of IMA systems, it was successfully created a model of the Pleiades Avionics architecture. Model-based engineering serves as a platform to guide the project through its different steps. It supports the analysis of the customer requirements, the system specification, the definition of the top-level architecture and the previous system verification and validation processes. The benefits obtained from this approach translate into reduction of overall life cycle cost, increased operational performance and the reutilization of components from legacy source code.

Therefore, this document was conceived for providing insights into state-of-the-art high speed deterministic networks, and eventually, as a first try within our department of the VERDI toolset. Having this in mind, all performances were successfully tested against a typical scenario: the avionics architecture of the PLEIADES-HR satellite.


68

9. REFERENCES

9.1 FLEXRAY REFERENCES

1. FlexRay Consortium’s webpage: http://www.flexray.com

2. FlexRay Consortium (2005), FlexRay Communications System Protocol Specification Version 2.1.

3. FlexRay Consortium (2006), FlexRay Communications System Electrical Physical Layer Specification Version 2.1.

4. FlexRay Consortium (2005), FlexRay Requirements Specification Version 2.1.

5. Srinivasan, J. and Lundqvist, K. (2002), Real-time architecture analysis: a COTS perspective. In Digital Avionics Systems Conference 2002.

6. Paulitsch, M. and Hall, B. (2008), FlexRay in aerospace and safety-sensitive systems. In Aerospace and Electronic Systems Magazine, IEEE, September 2008.

7. Heller, C., Schalk, J., Schneele, S. and Reichel, R. (2008), Approaching the Limits of FlexRay. In Network Computing and Applications 08, July 2008.

8. Gunes-Lasnet, S. and Furano, G. (2007), FlexRay – An answer to the challenges faced by spacecraft on-board communication protocols. Proceedings of DASIA 2007 conference.

9. Gunes-Lasnet, S. and Notebaert, O. (2008), Prototype implementation of a routing policy using FlexRay frames concept over a SpaceWire network. Proceedings of DASIA 2008 conference.

10. Kopetz, H. (2006), Fault containment and error detection in the time-triggered architecture. Proceedings of the Sixth Symposium on Autonomous Decentralized Systems, April 2006.

11. FlexRay Consortium (2007), The Quintessence of the current FlexRay Consortium Activities. In FlexRay Product Day, November 2007.

12. Schedl, A. (2007), Goals and Architecture of FlexRay at BMW. In Vector FlexRay Symposium, March 2007.

13. Freescale semiconductor (2008), Next-generation, in-vehicle networking solution.

14. Berwanger, J., Schedl, A., BMW Group and Temple, C. (2006), FlexRay hits the road.

15. Gwaltney, D.A. and Briscoe, J.M (2006), Comparison of Communication Architectures for Spacecraft Modular Avionics Systems.

16. FlexRay Consortium (2005), FlexRay Communications System Preliminary Central Bus Guardian Specification Version 2.0.9.

17. FlexRay Consortium (2005), FlexRay Communications System Preliminary Node-local Bus Guardian Specification Version 2.0.9.

18. FlexRay – Fujitsu. http://www.fujitsu.com/global/services/microelectronics/technical/flexray/

http://www.flexray.com

http://www.fujitsu.com/global/services/microelectronics/technical/flexray


69

9.2 AFDX REFERENCES

19. Aeronautical Radio, Inc. (2005), Aircraft Data Network Part 7 Avionics Full-Duplex Switched Ethernet (AFDX) Network.

20. Creative Electronic Systems S.A. (2003), CES White Paper on AFDX.

21. Schaadt, D. (2007) AFDX/ARINC 664 Concept, Design, Implementation and Beyond.

22. Condor Engineering, Inc. (2005), ADFX Protocol Tutorial.

23. Actel Corporation (2005), Developing AFDX Solutions.

24. Charara H. (2007), Evaluation des performances temps réel de réseaux embarqués avioniques.

25. Scharbard, J.L., Ridouard, F. and Fraboul, C. (2009), A Probabilistic Analysis of End-To-End Delays on an AFDX Avionic Network. In IEEE Transactions on Industrial Informatics, February 2009.

26. Webb, E. (2002), Ethernet for Space Flight Applications. Proceedings of the IEEE Aerospace Conference, March 2002.

27. Alena, R.L., Ossenfort, J.P., Laws, K.I., Goforth, A. and Figueroa, F. (2007), Communications for Integrated Modular Avionics. Proceedings of the IEEE Aerospace Conference, March 2007.

28. Schuster, T. and Verma, D. (2008), Networking concepts comparison for avionics architecture. Proceedings of the Digital Avionics Systems Conference, October 2008.

29. Black, R. and Fletcher, M. (2004), Next Generation Space Avionics: a highly reliable layered system implementation. In Digital Avionics Systems Conference, October 2004.

30. McHale, J. (2009), Commercial aircraft avionics leveraged for next-generation NASA spacecraft. http://avi.pennnet.com/display_article/346535/143/ARTCL/none/FEAT/1/Cockpit-for-the-stars/

31. Oishi, R. (2008), Deterministic Ethernet for Avionics. In Avionics Magazine, October 2008. http://www.aviationtoday.com/av/categories/commercial/26289.html

32. Sysgo Press Release (2007), NASA Evaluate AFDX and ARINC 653 for Exploration Vehicle. http://www.sysgo.com/news-events/press-releases/browse/1/article/51/sysgo-participates-in-nasa-evaluation/

33. Hewlett-Packard (2007), International Space Station welcomes aboard ProCurve Networking. http://www.hp.com/rnd/case_studies/International_Space_Station.htm

34. Musich, P. (2008), Space: The Final Frontier for Ethernet. http://www.eweek.com/c/a/IT-Infrastructure/Space-The-Final-Frontier-for-Ethernet/

35. Eger, G.W. (2008), Orion’s Command and Data Handling Architecture. AIAA Space 2008 Conference & Exposition, September 2008.

http://avi.pennnet.com/display_article/346535/143/ARTCL/none/FEAT/1/Cockpit-for-the-stars



http://www.aviationtoday.com/av/categories/commercial/26289.html

http://www.sysgo.com/news-events/press-releases/browse/1/article/51/sysgo-participates-in-nasa-evaluation



http://www.hp.com/rnd/case_studies/International_Space_Station.htm

http://www.eweek.com/c/a/IT-Infrastructure/Space-The-Final-Frontier-for-Ethernet




70

9.3 PLEIADES REFERENCES

36. CNES (2006), PLEIADES HR Satellite. http://smsc.cnes.fr/PLEIADES/

37. EADS Astrium (2004), On Board Flight Software User Requirements Document, PLEIADES HR.

38. EADS Astrium (2006), System Software User Requirements Document, PLEIADES HR.

39. EADS Astrium (2005), DHS Software User Requirements Document, PLEIADES HR.

40. EADS Astrium (2006), OCS Software User Requirements Document, PLEIADES HR.

41. EADS Astrium (2006), Payload Software User Requirements Document, PLEIADES HR.

42. EADS Astrium (2005), Platform Software User Requirements Document, PLEIADES HR.

43. EADS Astrium (2006), OBSW Performance Report, PLEIADES HR.

9.4 OTHER REFERENCES

44. EADS Military Air Systems, EADS Deutschland GmbH (2008), VERDI AADL User Manual.

http://smsc.cnes.fr/PLEIADES


71

10. APPENDIX A: COMPARISON WITH SPACE DOMAIN TECHNOLOGIES

Hereafter are summarized the characteristics of the main two data networks deployed nowadays in spacecraft on-board data handling: MIL-STD-1553 and SpaceWire, compared with the aforementioned candidates: FlexRay and AFDX. This comparison is an extent to a study carried out by NASA [15].

Feature MIL-STD-1553 SpaceWire FlexRay AFDX

Description Military standard defining electrical and protocol characteristics for a serial data bus with centralized message control.

Spacecraft communication network based on the IEEE 1355 created by the ESA.

Automotive network communication protocol developed by the FlexRay Consortium.

Next generation Aircraft Data Network specified by IEEE 802.3 and ARINC 664, Part 7.

Application Primarily military avionics. Also used in spacecraft on-board data handling.

High-speed links and networks for use onboard spacecraft.

Automotive control applications.

Developed by Airbus Industries for commercial aircraft.

Deployed Systems

ISS, Shuttle payloads, military aircraft, and ships.

Among other ESA missions: Rosetta, Gaia, Herschel. NASA’s JWST, SWIFT, GOES-R spacecrafts.

BMW X5, BMW 7 Series automobiles.

Airbus A380, A400M, A350 and Boeing 787 aircrafts.

Communication Control

Event-triggered (command/ response) requires bus controller.

Event-triggered Time-triggered (static segment) and event-triggered (dynamic segment)

Event-triggered, based on host message generation, bandwidth predefined and guaranteed by hard limits.

Maximum Data Rate (MB/s)

1 MB/s 400 MB/s 10 MB/s (20 MB/s non-redundant)

100 MB/s using Ethernet physical layer.

Message Size 640 bits (512 data bits)

5 Bytes overhead, data payload not limited by std.

8-Bytes overhead, 0-254 Bytes data.

55 Byte overhead, 17-1471 Byte data.

Message CRC No, application-level data CRC

No Yes Yes


72


Broadcasting No Remote Terminal (RT) to all, only through broadcast messages, Bus Controller (BC) to all RT.

Only if all messages are sent as broadcast.

Yes Can be done via packet distribution at routing switches.

Duplex Half Full Half Full

Media Access TDMA (command/ response)

Flow control via tokens

TDMA for static segment and asynchronous mini-slotting for dynamic segment.

Traffic shaping by end system based on VL definition. Filtering and policing at switch.

Media Access Without Arbitration

Bus master only No Yes for static segment, no for dynamic segment

No

Encoding Manchester II bi-phase

Data Strobe NRZ encoding Ethernet encoding (4B/5B)

Clock Synchronization

Available through master command (not required)

Not required, but allows for time distribution.

Yes No

Global Time Base

No No Yes No

Latency jitter <12 µs for RT response (may be extended to >20 µs)

Variable based on topology, estimated <=10 µs.

Programmable 1-6 µs

<=500 µs

Maximum number of Nodes on Single Bus

31 224 (logical addresses per cluster)

64 Governed by number of switched ports available.

Physical Layer Length

Not limit specified, can be >100 m

10 m 24 m point-to-point or total bus length

Same as Ethernet 100 Base-T (>100 m)

Implementation Physical Layer

Twisted shielded pair.

4 Twisted shielded pairs with LVDS (Low Voltage Differential

Twisted pair Ethernet 100 Base-T twisted pair.


73


Signalling)

Coupling Transformer and direct.

9-pin D connector. Direct with Bus Driver.

Ethernet connector (RJ45)

Network Topologies

Single and multiple level buses.

Point-to-point and Switched

Bus, passive star, point-to-point, active star with central bus guardian.

Switched star, cascaded stars.

Supports Hot Swap of Same Type Nodes

Depends on implementation.

Yes Not specifically addressed

Yes

Inherent redundancy

Dual-redundant bus.

No Yes for static frames on dual redundant bus, optional for other frames.

Yes, dual redundant switches and links.

Redundancy Management

Defined at application level

No No, must be implemented at application level.

Defined at application level.

Fault Containment

Yes, if secondary bus can be used to remove or tolerate the fault

No Yes, by the local bus guardian, or the central bus guardian.

Yes, if fault is confined to one dual-redundant switched network.

Babbling idiot avoidance

Not inherent, defined at application level.

None Yes, bus guardian.

Detected and suppressed by switch.

Message Failure Detection

Yes, status bit Yes, parity, invalid destination, credit error, error end of packet.

Yes Yes, port detects overflow errors or switch identifies message failure and discards.

Tolerant to Message Loss

No, retransmit required

No For redundant messages

On one dual redundant switch network.

Node Failure Detection (Controller

Only for RTs, via response timeout, no other at

Only via link disconnect error and failure to reconnect.

Yes, with local bus guardian.

No


74


Hardware Level) hardware level. Timeout indicator provided to app.

Node Failure Reported Consistently and With low-latency (yes/no)

Only master knows

Yes, in the case of link failure only.

No Only nodes expecting data may be aware at application level.

Tolerant to Node Loss

No, if bus master is lost, otherwise yes, communication still proceeds between remaining nodes

Yes, communication will proceed between remaining nodes.



Error Handling Approach

Terminal shutdown/ reset.

Reset of link and error reporting to application. Reports detectable link physical connection faults to application.

Bus Guardians prevents the transmission of faulty nodes.

Error packets are discarded by Switch and in the End System by the Redundancy Management. Switch enters quiet mode for catastrophic failure.

Extensibility (Ease of expansion)

Depends on implementation

Requires routing configuration

Requires design of new schedule for new static slots.

Requires design of new switch configuration data table

Availability of Off-the-Self Hardware

Yes Yes Yes Yes

RAD-Hard/Tolerant Off-the-Self Parts

Yes Yes No (requires rad-tolerant FPGAs)

No (requires rad-tolerant FPGAs)

IP Available for ASIC and FPGA implementation

Yes Yes Yes, consortium only

Yes, limited availability

Documents

2009:105 MASTER'S THESIS Modeling/Evaluation of ...1017316/FULLTEXT01.pdf2009:105 MASTER'S THESIS Modeling/Evaluation of Modular Spacecraft Avionics Network Architectures Yago Montenegro