Space engineering - Time triggered Ethernet

Using standard communication protocols for spacecraft communication links
can provide interface compatibility between communication devices and
components. Thus, it can improve the design and development process as well
as integration and test activities at all levels and provide the potential of
reusability across projects.
The aim of this space engineering standard is to define the interface services
and to specify their corresponding network protocol elements for spacecraft
using the Time-Triggered Ethernet data network. It also aims at defining
requirements for the harmonisation of the physical interfaces and usage of the
[IEEE 802.3] and [SAE AS6802] layer features.
This standard may be tailored for the specific characteristic and constraints of a
space project in conformance with ECSS‐S‐ST‐00

Raumfahrttechnik - Zeitgesteuertes Ethernet

The transmission of onboard data is ever increasing. Particularly in the manned space arena, requirements already exist for concurrent transmission of many different types of data with different data rates, time criticality and priority. Currently this is handled by multiple busses and LANs but could be supported by a single TTE based infrastructure.
A form of TTE is already in use by the Multi-Purpose Crew Vehicle (MPCV), a NASA led manned vehicle which includes a separate service model under development by ESA. In addition TTE has been selected by for use by the Ariane 6 program. Both of these developments require the transmission of mixed data types at relatively high speeds.
The present MPCV implementation is based on a proprietary approach. It is effectively a closed development by a non-European single vendor with a design that includes ITAR components. Indeed MPCV TTE implementation cannot be applied to European Launchers and in general to future European programs which could need an open standard able to be implemented by multiple suppliers. For this reason ESA has been approached by industry requesting that an ECSS standard is being produced.
The existing SAE standard may form the basis for such a standard but needs to be extended for space in the areas of physical medium, redundancy, testing and verification. Some aspects of time distribution must be more precisely documented and any patent issues resolved.
This standard would foster a faster adoption of the technology and simplify the customer/ supplier contractual relationship especially with an IP core based synchronisation client available to the Space Industry via ESA IP core portfolio.
Whether this standard would complement the existing SAE6802 by filling existing gaps , especially on the physical layer and the interoperability, or would include all necessary information from the SAE 6802 issue 1 to achieve a stand-alone document, is part of a trade-off assessment the WG will have to undertake.

Ingénierie spatiale - Ethernet déclenché par le temps

L'utilisation de protocoles de communication standard pour les liaisons de communication des engins spatiaux peut fournir une compatibilité de l'interface entre les périphériques et les composants de communication. De cette manière, il est possible d'améliorer le processus de conception et de développement, ainsi que les activités d'intégration et d'essai à tous les niveaux, et d'offrir un potentiel de réutilisabilité au travers de plusieurs projets.
La présente norme d'ingénierie spatiale vise à définir les services d'interface et à spécifier leurs éléments de protocole réseau correspondants pour un engin spatial utilisant le réseau de données Ethernet à déclenchement temporel (TTEthernet). Elle vise par ailleurs à définir les exigences nécessaires à l'harmonisation des interfaces physiques et à l'utilisation des fonctionnalités des couches [IEEE 802.3] et [SAE AS6802].
La présente norme peut être adaptée aux caractéristiques et contraintes spécifiques d'un projet spatial, conformément à l'ECSS‐S‐ST‐00.
Approche
L'approche du groupe de travail ECSS, dans le cadre de la définition de la présente norme, vise à identifier les couches, services et fonctions du réseau de communication TTEthernet courant afin de garantir l'utilisation de cette technologie pour divers projets spatiaux. La présente norme vise à :
- identifier les architectures de référence (couches, services, fonctions et éléments de protocole) du réseau de communication TTEthernet courant ;
- caractériser les services, fonctions et éléments de protocole pour chaque couche au sein des architectures de référence identifiées, en utilisant des spécifications de projet concrètes ;
- définir des exigences normatives plutôt que des recommandations.
Dans la mesure du possible, les exigences de communication définies sont tirées de l'expérience avec des spécifications d'engins spatiaux existantes.

Vesoljska tehnika - Časovno proženi ethernet

Uporaba standardnih komunikacijskih protokolov za komunikacijske povezave vesoljskih plovil lahko zagotovi združljivost vmesnikov med komunikacijskimi napravami in komponentami. Tako je mogoče izboljšati postopek načrtovanja in razvoja kot tudi vključevanja in preskusnih dejavnosti na vseh ravneh ter zagotovi možnost
vnovične uporabe pri drugih projektih.
Cilj tega standarda vesoljske tehnike je opredeliti vmesniške storitve in določiti njihove ustrezne elemente omrežnega protokola za vesoljska plovila z uporabo časovno proženega podatkovnega omrežja Ethernet. Cilj je tudi opredeliti zahteve za harmonizacijo fizičnih vmesnikov in uporabo funkcij plasti iz standardov [IEEE 802.3] in [SAE AS6802].
Ta standard se lahko prilagodi posameznim lastnostim in omejitvam vesoljskega projekta v skladu s standardom ECSS‐S‐ST‐00.

General Information

Status
Published
Public Enquiry End Date
28-Apr-2021
Publication Date
23-Jan-2022
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
29-Dec-2021
Due Date
05-Mar-2022
Completion Date
24-Jan-2022
Standard
SIST EN 16603-50-16:2022 - BARVE
English language
103 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)


SLOVENSKI STANDARD
01-marec-2022
Vesoljska tehnika - Časovno proženi ethernet
Space engineering - Time triggered Ethernet
Raumfahrttechnik - Zeitgesteuertes Ethernet
Ingénierie spatiale - Ethernet déclenché par le temps
Ta slovenski standard je istoveten z: EN 16603-50-16:2021
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 16603-50-16

NORME EUROPÉENNE
EUROPÄISCHE NORM
December 2021
ICS 49.140
English version
Space engineering - Time triggered Ethernet
Ingénierie spatiale - Ethernet à déclenchement Raumfahrttechnik - Zeitgesteuertes Ethernet
temporel (TTE)
This European Standard was approved by CEN on 5 December 2021.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2021 CEN/CENELEC All rights of exploitation in any form and by any means
Ref. No. EN 16603-50-16:2021 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 8
1 Scope . 9
2 Normative references . 10
3 Terms, definitions and abbreviated terms . 11
3.1 Terms from other standards . 11
3.2 Terms specific to the present standard . 11
3.3 Abbreviated terms. 15
3.4 Nomenclature . 17
4 Overview . 18
4.1 Reference Model . 18
4.2 Physical Layer . 19
4.3 Data Link Layer . 19
4.3.1 Data Link Layer Overview . 19
4.3.2 Data Link Layer Functionalities . 20
4.3.3 Time-Triggered Ethernet . 21
4.4 Network Level . 23
4.4.1 Network Level Overview. 23
4.4.2 Message Processing at the Switch . 24
4.4.3 Time-Triggered Ethernet Network Building Blocks . 28
4.4.4 Virtual Link . 29
4.4.5 Time-Triggered Traffic Policing . 30
4.4.6 Rate-Constrained Traffic Policing . 30
4.4.7 Clock Synchronization . 31
4.5 Redundancy Concept . 34
4.5.1 Introduction . 34
4.5.2 TT traffic . 35
4.5.3 RC traffic . 35
4.6 Failure-modes . 36
5 Network Architecture . 37
5.1 Overview . 37
5.1.1 Introduction . 37
5.1.2 Single Channel Network Topology . 37
5.1.3 Dual Channel Network Topology . 38
5.1.4 Triple Channel Network Topology . 39
5.1.5 Mixed Network Topology . 40
5.1.6 Multiple Networks Topology . 41
5.1.7 Compatibility with standard Ethernet Network . 42
5.2 Network Topology Requirements . 43
5.2.1 Single Network Topology . 43
5.2.2 Multiple Networks Topology . 45
6 Device Services . 46
6.1 Overview . 46
6.2 Media Access Control (MAC) Sublayer . 47
6.2.1 MAC sublayer functions . 47
6.2.2 MAC Addressing . 47
6.2.3 Traffic Classes . 48
6.2.4 MAC Transmit . 49
6.2.5 MAC Receive . 50
6.2.6 Switch Traffic Policing . 50
6.2.7 Switch Transmit . 51
6.2.8 Switch Frame Routing . 52
7 Interoperability Specification . 53
7.1 Overview . 53
7.2 Device Specification . 54
7.2.1 Device Parameters Description . 54
7.2.2 General Requirements . 55
7.2.3 Switch Level Specification . 55
7.2.4 End-System Level Specification . 59
7.2.5 Clock Synchronization . 60
7.3 Configuration Parameters . 61
7.3.1 Device Level and Clock Synchronization Parameters . 61
7.4 Configuration and Scheduling guideline . 67
7.4.1 Overview . 67
7.4.2 Delays . 68
7.4.3 Latencies . 69
7.4.4 Transparent clock . 70
7.5 Scheduling requirements . 70
7.5.1 Delays to be identified . 70
7.5.2 Delays compensation . 70
7.5.3 PCF latency . 71
7.5.4 Maximum transparent clock . 72
7.5.5 PCF transparent clock jitter . 72
7.5.6 Precision parameter . 73
7.5.7 Time-Triggered minimum gap . 73
7.5.8 Time-Triggered Switch receive window . 73
7.5.9 Time-Triggered Switch minimum transmission . 75
7.5.10 Time-Triggered End-System reception . 75
8 Network Setup and Services . 76
8.1 Overview . 76
8.2 General Requirements . 77
8.2.1 Overview . 77
8.2.2 Internet Protocol (IP) . 77
8.2.3 UDP . 78
8.2.4 ICMP . 79
8.3 Dataloading via TFTP . 80
8.3.1 Trivial File Transfer Protocol (TFTP) Overview . 80
8.3.2 Dataloading requirements . 81
8.4 Diagnostics and Status-Information via SNMP . 81
8.4.1 Simple Network Management Protocol (SNMP) Overview . 81
8.4.2 SNMP requirements . 83
8.4.3 Diagnostic and Status-Information requirements . 84
8.4.4 Monitoring Mode . 88
8.5 Error management in End-System and Switch . 88
9 Test and verification . 90
9.1 Test Specification . 90
9.2 Test references . 90
9.2.1 Overview . 90
9.2.2 Requirements for implementation at system level . 91
10 Tailoring . 92
10.1 Scope . 92
10.2 Tailoring options and parameters . 92
10.2.1 Overview . 92
10.2.2 Step 1: Function and service selection . 92
10.2.3 Step 2: Services configuration . 92
10.3 IEEE 802.3 Tailoring . 93
10.4 SAE AS6802 Tailoring . 97
Bibliography . 102

Figures
Figure 3-1: Structure of a Packet . 13
Figure 4-1: OSI Reference Model . 18
Figure 4-2: Physical Layer Model . 19
Figure 4-3: Data Link Layer . 20
Figure 4-4: Time-Triggered Ethernet Services . 21
Figure 4-5: Traffic Partitioning . 23
Figure 4-6: Network Communication Channel . 23
Figure 4-7: A TTE example network . 24
Figure 4-8: Full Duplex Links . 24
Figure 4-9: Message Processing at the Switch . 25
Figure 4-10: Preemption . 26
Figure 4-11: Shuffling . 27
Figure 4-12: Media Reservation . 27
Figure 4-13: Network Building Blocks . 28
Figure 4-14: Network Building Blocks Examples. 28
Figure 4-15: Virtual Link . 29
Figure 4-16: Bandwidth Reservation . 30
Figure 4-17: Time-Triggered Ethernet two step clock synchronization algorithm . 31
Figure 4-18: Example of an integration PCF Frame exchange . 34
Figure 4-19: Redundancy Communication. 34
Figure 4-20: Redundancy Management at the Receiver . 35
Figure 5-1: Single Channel Network Topology . 37
Figure 5-2: Single Channel Network Topology – without cascaded Switches . 38
Figure 5-3: Single Channel Network Topology – with cascaded Switches . 38
Figure 5-4: Dual Channel Network Topology . 38
Figure 5-5: Dual Channel Network Redundancy without cascaded Switches . 39
Figure 5-6: Dual Channel Network Redundancy with cascaded Switches . 39
Figure 5-7: Triple Channel Redundant Network Topology . 39
Figure 5-8: Triple Channel Network Redundancy without cascaded Switches . 40
Figure 5-9: Triple Channel Network Redundancy with cascaded Switches . 40
Figure 5-10: Mixed Architecture . 40
Figure 5-11: Multiple Networks Topology . 41
Figure 5-12: Synchronization priority assignment recommendation . 42
Figure 5-13: Time-Triggered Ethernet topology composed of standard Ethernet nodes . 43
Figure 6-1: OSI Layer Services . 46
Figure 6-2: Destination MAC Address . 47
Figure 6-3: Source MAC Address . 47
Figure 7-1: Configuration Interface Tool – IP . 53
Figure 7-2: Example of delays at system level . 68
Figure 7-3: Example of delays related to a device . 69
Figure 7-4: Impact of delays on synchronization precision . 69
Figure 7-5: Impact of delays on synchronization precision . 71
Figure 7-6: Impact of delays on synchronization precision . 71
Figure 8-1: Network Diagnostic and Monitoring Service Layers . 77
Figure 8-2: FTP Message Types . 81
Figure 8-3: Simple Network Management Protocol (SNMP) . 82
Figure 8-4: Global SNMP architecture . 83

Tables
Table 6-1: Interface ID . 48
Table 7-1: General Interoperability Parameter Table . 54
Table 7-2: Switch Interoperability Parameter Table . 54
Table 7-3: End-System Interoperability Parameter Table . 55
Table 7-4: End-System Schedule Parameters . 61
Table 7-5: End-System Output VL Parameters . 61
Table 7-6: End-System Input VL Parameters . 62
Table 7-7: End-System Best-Effort Filtering Parameters . 62
Table 7-8: End-System Clock Synchronization Parameters . 62
Table 7-9: End-System General Parameters . 64
Table 7-10: Switch Scheduling Parameters . 64
Table 7-11: Switch Output VL Parameters . 65
Table 7-12: Switch Input VL Parameters . 65
Table 7-13: Switch Best-Effort Filtering Parameters . 65
Table 7-14: Switch Clock Synchronization Parameters. 65
Table 7-15: Switch General Parameter . 67
Table 7-16: Max Transparent Clock parameter table . 72
Table 7-17: Precision parameter Table . 73
Table 7-18: TT Switch Receive Window start and end time . 74
Table 7-19: Time-Triggered Switch receive window Table . 74
Table 10-1: Requirements selection . 93
Table 10-2: Tailoring to [IEEE 802.3] - Part 3 . 93
Table 10-3: Tailoring to [SAE AS6802] . 97
Table A-1 : Clock Synchronization . 98
Table A-2 : Time-Triggered Communication . 99
Table A-3 : Dependability . 99

European Foreword
This document (EN 16603-50-16:2021) has been prepared by Technical
Committee CEN-CENELEC/TC 5 “Space”, the secretariat of which is held by
DIN.
This standard (EN 16603-50-16:2021) originates from ECSS-E-ST-50-16C.
This European Standard shall be given the status of a national standard, either
by publication of an identical text or by endorsement, at the latest by June 2022,
and conflicting national standards shall be withdrawn at the latest by June 2022.
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. CEN [and/or CENELEC] shall not be held
responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request given to
CEN by the European Commission and the European Free Trade Association.
This document has been developed to cover specifically space systems and has
therefore precedence over any EN covering the same scope but with a wider
domain of applicability (e.g. : aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards
organizations of the following countries are bound to implement this European
Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Scope
Using standard communication protocols for spacecraft communication links
can provide interface compatibility between communication devices and
components. Thus, it can improve the design and development process as well
as integration and test activities at all levels and provide the potential of
reusability across projects.
The aim of this space engineering standard is to define the interface services
and to specify their corresponding network protocol elements for spacecraft
using the Time-Triggered Ethernet data network. It also aims at defining
requirements for the harmonisation of the physical interfaces and usage of the
[IEEE 802.3] and [SAE AS6802] layer features.
This standard may be tailored for the specific characteristic and constraints of a
space project in conformance with ECSS‐S‐ST‐00.

Approach
The approach of the ECSS working group for defining this standard aims at
identification of layers, services and functions of the typical Time-Triggered
Ethernet communication network to ensure the use of the technology for
various space projects. The standard aims at:
 Identifying Reference Architectures (Layers, Services, Functions and
Elements of protocol) of typical Time-Triggered Ethernet communication
network;
 Characterizing Services, Functions and Elements of Protocol of each
Layer within identified Reference Architectures, using concrete project
specifications;
 Define normative requirements rather than recommendations.
As far as possible, the defined communication requirements are extracted from
the experience on existing spacecraft specifications.

Normative references
The following normative documents contain provisions which, through
reference in this text, constitute provisions of this ECSS Standard. For dated
references, subsequent amendments to, or revision of any of these publications
do not apply. However, parties to agreements based on this ECSS Standard are
encouraged to investigate the possibility of applying the more recent editions of
the normative documents indicated below. For undated references, the latest
edition of the publication referred to applies.

EN reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS System - Glossary of terms
ARINC 664 part 7, Aircraft Data Network Part 2: Avionic Full-Duplex
23 September 2009 Switched Ethernet Network
IEEE 802.3, Ethernet Standard
28 December 2012
SAE AS6802, Time-Triggered Ethernet
November 2011
RFC 768, User Datagram Protocol (UDP)
28 August 1980
RFC 791, September Internet Protocol (IP)
RFC 792, September Internet Control Message Protocol (ICMP)
RFC 1157, May 1990 A simple network management protocol (for
SNMPv1)
RFC 1350, July 1992 The TFTP Protocol (Revision 2)
Terms, definitions and abbreviated terms
3.1 Terms from other standards
For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-
01 apply.
3.2 Terms specific to the present standard
3.2.1 acceptance window
timing interval in which the reception of the frame associated with a VL-ID is
expected
3.2.2 bandwidth allocation gap
minimum delay between two consecutive Rate-Constrained frames belonging
to the same sending interval
[ARINC 664 part 7]
3.2.3 Best-Effort traffic
standard Ethernet frame which is neither critical traffic nor flow controlled
traffic
NOTE A Best-Effort frame or traffic as specified by the
standard [IEEE 802.3].
3.2.4 broadcast
transmission of an Ethernet frame from one sender to all receivers
3.2.5 cluster
Ethernet network composed of nodes synchronized to each other by the Time-
Triggered Ethernet protocol
3.2.6 compression master
role of an element of the cluster that collects protocol control frames (PCFs)
from the synchronization masters and uses them in a timing algorithm
(compression) before sending them back to the configured synchronization
masters and synchronization clients, to be used for synchronization purposes
3.2.7 critical traffic
flow of critical traffic frames, where each frame has the most significant 32 bits
set to the critical traffic marker
NOTE Critical Traffic Marker is the value of the most
significant 32 bits of the MAC Destination
Address that identifies a frame as Critical
Traffic.
3.2.8 device
element of an Ethernet network or an element connected to an Ethernet node
NOTE A device can be either a Switch or an End-
System or a host computer. A device does not
necessarily support RC or TT or BE traffic.
3.2.9 End-System
network component which provides the host device an interface to the network
NOTE Each host device uses an End-System interface
to guarantee a secure and reliable data
interchange with other host device.
3.2.10 flow controlled traffic
sequence of Ethernet packets from one sender to one or multiple receivers
NOTE A Flow controlled traffic as specified by [RFC
3697].
3.2.11 frame
part of a packet
NOTE 1 The following frame types are used throughout
this document:
 Best-Effort frame: Basic Frame
 Critical Traffic frame: Rate-Constrained (RC)
frame; Protocol Control Frame (is a RC
frame); Time-Triggered (TT) frame
NOTE 2 Example of a packet is shown in Figure 3-1.
3.2.12 globally administered MAC
unique MAC address assigned to the network interface card by the
manufacturer
3.2.13 link
physical connections between nodes in a network providing the means for
transferring frames between them
3.2.14 locally administered MAC
unique MAC address assigned to the network interface card locally
3.2.15 multicast
transmission of an Ethernet frame from one sender to multiple receivers
3.2.16 node
element of an Ethernet network
NOTE A node can be either a Switch or an End-
System. A node does not necessarily support
RC and TT traffic but at least BE.
3.2.17 packet
complete Ethernet message including the header information consisting of the
preamble and the start of frame delimiter
NOTE The Ethernet packet is specified in, 1000Base-X
PCS, [IEEE 802.3] Clause 36 [2], section
1/section 3 ”Media Access Control (MAC)
frame and packet specifications”. The structure
is shown in Figure 3-1.
Packet
Frame
Preamble MAC Destination MAC Source MAC Client Data Pad Bytes Frame Check
Address Address Sequence
Figure 3-1: Structure of a Packet
3.2.18 protocol control frame
standard Ethernet frame whose Ethernet type field is set to 0x891D, which is
used by the synchronization protocol
[SAE AS6802]
3.2.19 raster granularity
timeline on which scheduling events are placed
3.2.20 Rate-Constrained
guaranteed bandwidth traffic as specified by the standard
[ARINC 664 part 7]
3.2.21 schedule table
time schedule of transmission and reception events for critical traffic.
3.2.22 Switch
hardware device that connects multiple End-Systems or Switches to one
network
Start Frame Delimiter
Length / Type
Field
NOTE A Switch works on Layer 2 of the Ethernet
specification and has two different ways of
packet switching between the different devices
connected to its Ethernet ports which are static
and dynamic switching. The static packet
switching works according to a defined static
switching table. Dynamic switching describes
an automated forward path for a given MAC
destination address based on the current
network architecture.
3.2.23 synchronization client
role of an element of the cluster that consumes protocol control frames (PCFs)
received from compression masters for synchronization purpose, without
actively participating in the network synchronization process
3.2.24 synchronization master
role of an element of the cluster that generates protocol control frames (PCFs),
transmits them to the compression masters, and consumes PCFs received from
compression masters for synchronization purpose, actively participating in the
network synchronization process
3.2.25 synchronization precision
worst-case Local Clocks offset between any two correctly synchronised End-
Systems or Switches in the system
NOTE The calculation is given in [SAE AS6802]
paragraph 3.2.
3.2.26 Time-Triggered frame
Critical Traffic (CT) frame which is sent over the network at predefined times
and take precedence over all other frames types, except for Protocol Control
Frames
3.2.27 unicast
transmission of an Ethernet frame from one sender to one receiver
3.2.28 virtual link
logical unidirectional connection path between one node towards one or more
nodes
[ARINC 664 part 7]
3.2.29 virtual link identifier
least significant 16 bits of the MAC Destination Address of a Critical Traffic
Frame
NOTE Per definition of the standard [ARINC 664
part 7], the VL-ID uniquely identifies a
multicast group with a dedicated sender of the
message and a set of receivers.
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms and symbols from
ECSS-S-ST-00-01 and the following apply:

Abbreviation Meaning
API
Application Programming Interface
ARINC
Aeronautical Radio Incorporated
BAG
Bandwidth Allocation Gap
BE
Best-Effort
CD
Collision Detection
CM
Compression Master
CRC
Cyclic redundancy check
CSMA
Carrier Sense Multiple Access
CT
Critical traffic
DLL
Data Link Layer
ECSS
European Cooperation for Space Standardization
EMC
Electromagnetic compatibility
ES
End-System
ESCC
European Space Components Coordination
FCS
Frame check sequence
FDIR
failure detection, isolation and recovery
FT
Fault Tolerant
Gbps
Giga bit per second
GMII
Gigabit media independent interface
GND
Ground
H/W
Hardware
IC
Integrity Checking
ICMP
Internet Control Message Protocol
ID
Identifier
IEEE
Institute of Electrical and Electronics Engineers
IFG
Inter frame gap
IHL
Internet Header Length
IP
Internet protocol
IP
Intellectual Property
ISO
International Standard Organisation
LAN
Local Area Network
LLC
Logic Link Control
LVDS
Low Voltage Differential Signalling
Abbreviation Meaning
MAC
Media access control
Mbps
Mega bit per second
MIB
Management Information Base
MII
Media independent interface
OSI
Open system interconnection
PCB
Printed circuit board
PCF
Protocol Control Frame
PCS
Physical Coding Sub-layer
PHY
Physical Layer
PLS
Physical Coding Sublayer
PMA
Physical Medium Attachment sub-layer
PMD
Physical Medium Dependent sub-layer
QoS
Quality of service
RC
Rate-Constrained
RM
Redundancy Management
SAE
Society of Automotive Engineers
SC
Synchronization Client
SFD
Start Frame Delimiter
SM
Synchronization Master
SN
Sequence number
SNMP
Simple Network Management Protocol
SW
Switch
TFTP
Trivial File Transfer Protocol
TT
Time-Triggered
TTE
Time-Triggered Ethernet
UDP
User Datagram Protocol
VL
Virtual Link
VL-ID
Virtual Link Identifier
3.4 Nomenclature
The following nomenclature applies throughout this document:
 The word “shall” is used in this Standard to express requirements. All
the requirements are expressed with the word “shall”.
 The word “should” is used in this Standard to express recommendations.
All the recommendations are expressed with the word “should”.
NOTE It is expected that, during tailoring,
recommendations in this document are either
converted into requirements or tailored out.
The words “may” and “need not” are used in this Standard to express positive
and negative permissions, respectively. All the positive permissions are
expressed with the word “may”. All the negative permissions are expressed
with the words “need not”.
The word “can” is used in this Standard to express capabilities or possibilities,
and therefore, if not accompanied by one of the previous words, it implies
descriptive text.
NOTE In ECSS “may” and “can” have completely
different meanings: “may” is normative
(permission), and “can” is descriptive.
The present and past tenses are used in this Standard to express statements of
fact, and therefore they imply descriptive text.
Overview
4.1 Reference Model
This Clause provides an overview of the Time-Triggered Ethernet Standard for
the use of deterministic Ethernet in space applications. It covers the most
important OSI model layers applicable for space applications and extensions
providing useful features to the space community.
Time-Triggered Ethernet takes into consideration the [IEEE 802.3], as well as the
[ARINC 664 part 7] and is specified in the Time-Triggered Ethernet Standard
[SAE AS6802].
[SAE AS6802] Time-Triggered Ethernet standard is a Layer 2 Quality-of-Service
(QoS) enhancement that defines Time-Triggered services for Ethernet networks.
Time-Triggered Ethernet is designed for the development of highly dependable
systems for applications in multiple industries, including integrated systems in
aerospace, ground vehicles and industrial process control. It provides the
capability for deterministic, synchronous, and congestion-free communication
among distributed applications, unaffected by any asynchronous Ethernet
traffic load. [SAE AS6802] is fully compatible with lower (1-2) and higher OSI
layers (3-7) and is transparent to applications designed to use asynchronous
Ethernet (Figure 4-1)
Time-Triggered Ethernet is a full‐duplex, bidirectional, point‐to‐point data link.
It encodes data according to [IEEE 802.3] with 10/100/1000Mbps speeds. It
further encompasses different media types as copper and fibre.
Application
Presentation
Session
Transport
Network
Data Link
Physical
Figure 4-1: OSI Reference Model
4.2 Physical Layer
The physical level provides the actual interface between the network
components including both the mechanical and electrical interface. This Clause
covers:
 cable construction,
 connectors,
 cable assemblies, and
 PCB and backplane tracking.
Ethernet was developed to meet the EMC specifications of high reliable
applications cross industry. However, since there are lots of space applications
where power consumption is a key requirement, in some cases, the use of LVDS
as physical layer provides advantages over the typical Ethernet physical layer.
Since Ethernet specifies also the interface to the Ethernet physical layer
transceiver, the media independent interface (MII), this interface can be used
with LVDS transceivers to provide a solution for short distances with already
available physical layer building block. As illustrated in Figure 4-2, Ethernet
specifies the following three different functional layers within the physical
layer:
 PCS (Physical Coding Sub-layer),
 PMA (Physical Medium Attachment sub-layer), and
 PMD (Physical Medium Dependent sub-layer)
OSI
Reference
Model
Network
Layers
Data Link
Application
Physical
Presentation
PLS Reconciliation Reconciliation Reconciliation Reconciliation
Session
MII MII GMII XGMII
Transport
AUI PLS PCS PCS PCS
Network
AUI PMA PMA PMA
Data Link
PMA PMA PMD PMD AN
Physical
MDI MDI MDI MDI MDI
Medium Medium Medium Medium Medium
1Mbps - 10Mbps 10Mbps 100Mbps 1Gbps 10Gbps

Figure 4-2: Physical Layer Model
4.3 Data Link Layer
4.3.1 Data Link Layer Overview
In a Local Area Network (LAN), the Data Link Layer consists of the Media
Access Control (MAC) and the Logic Link Control (LLC) Sublayers as
illustrated in Figure 4-3.
OSI
Reference
Model
Layers
Application
Presentation
Logic Link Lontrol (LLC) Sublayer
Session
Transport
Network
Media Access Control (MAC) Sublayer
Data Link
Physical
Figure 4-3: Data Link Layer
4.3.2 Data Link Layer Functionalities
The MAC sublayer defines a medium-independent facility, built on the
medium-dependent physical facility provided by the Physical Layer, and under
the access-layer-independent LAN LLC sublayer (or other MAC client). It is
applicable to a general class of local area broadcast media suitable for use with
the media access disciplines known as Time-Triggered Ethernet and Carrier
Sense Multiple Access with Collision Detection (CSMA/CD).
The LLC sublayer and the MAC sublayer together are intended to have the
same function as that described in the OSI model for the Data Link Layer alone.
In a broadcast network, the notion of a data link between two network entities
does not correspond directly to a distinct physical connection. Nevertheless, the
partitioning of functions requires three main functions generally associated
with a data link control procedure to be performed in the MAC sublayer. They
are as follows:
 Data encapsulation (transmit and receive):
 Framing (frame boundary delimitation, frame synchronization)
 Addressing (handling of source and destination addresses)
 Virtual Link handling
 Error detection (detection of physical medium transmission errors)
 Media Access Management
 Medium allocation (collision avoidance)
 Contention resolution (collision handling)
 Network Synchronization
 Start-Up Service
 Restart Services
 Fault-Tolerant Clock Synchronization Service
The Media Access Management is not covered to a very large extend since this
can be implemented as defined in the [IEEE 802.3]. For Time-Triggered traffic
this is handled via the configurations of the devices in the network according to
the global schedule created by the configuration tools. Also for Rate-
Constrained traffic the flow-control of [IEEE 802.3] according to [ARINC 664
part 7] has to be disabled.
4.3.3 Time-Triggered Ethernet
Time-Triggered Ethernet specifies Time-Triggered services that are added to the
standards for Ethernet established in [IEEE 802.3]. Figure 4-4 shows a parallel
view of the Time-Triggered services and the common Open Systems
Interconnection OSI model layers. A communication controller that implements
the Time-Tri
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...