status of the ecss-st-50-12c rev.1 standardisation...

ESA UNCLASSIFIED – For Official Use – Privileged

Status of the ECSS-ST-50-12C Rev.1 standardisation process

David Jameux ESTEC 11/04/2013

ECSS-ST-50-12C Rev.1 status | David Jameux | ESTEC | 11/04/2013 | TEC-ED | Slide 2


Background – CR as processed by the SpW Working Group

1. Based on the 54 Change Requests a. Posted by SpW community (mainly SpW WG) b. Processed in details and in length by the SpW WG (thanks!)

2. Most of them technically closed a. Ready to be standardised

3. A few of them still open a. Needed technical work



Scope

4. Number

5. Location of deficiency

clause page

(e.g. 3.1 14)

6. Changes 7. Justification 8. Disposition

3 Whole document

all Clarify definition and behaviour of “nodes” and review all node-related requirements. The term node should be only used as abstract end point (terminal) of the network and not for a physical unit.

Introduce a different term (e.g. device) for electronic modules or units in the network which can contain one or more SpaceWire interfaces.

Introduce a single configuration ports for devices and the permission to contain a routing capability.Remove a number of ambiguities raised by the SpW users (mainly the Working Group).

As reported in [3], [4], [94], [95], [98] and [100]:

Some requirements in ECSS-E-ST-50-12C refer to the term “node” as some electronic module or unit comprising one or several SpW interfaces while other requirements refer to the term “node” as the SpW interface itself as a terminal of the network. This has been creating a lot of confusion, specifically when trying to define other protocols operating on top of SpaceWire.

Amongst the related confusion is the Time-code usage in particular and time distribution in general, which is severely impacted by the definition of a “node”.

Another source of confusion is whether a packet with unexpected destination address shall be discarded, since RMAP does not follow this rule.

Moreover, the design of SpaceWire higher level protocols such as Plug-And-Play require a clear definition of items to be discovered in a SpW network, and the assignment of a configuration port to each of these items.

At last, some discussion in the SpW WG is ongoing whether aligning the definition of nodes to the one of routers (with e.g. the possibility for nodes to switch characters/packets) would clarify this definition and help supporting PnP.

Clarify the terms “port”, “link”, interface”, “router”, “node”, “end-point”, etc. w.r.t. SpaceWire as part of the revision of the standard.

4 Whole document

all Carefully improve the protocol description and consistency formalism (clear layering) and precise the use of some terms (e.g. switching instead of routing) and clearly describing for each protocol “level” the description of syntax, synchronisation, semantics; and include a description of the Service Access Points.

As reported in [2], [11], and [99]:

SpW does not involve routing (OSI layer 3) but only switching (OSI layer 2). In literature the term Wormhole switching is widely used as a synonymous of wormhole routing. However, the development of SpaceWire higher level protocols in general and the SOIS stack in particular involves routing. The use of this term at SpW level therefore may create confusion.

Moreover, the ECSS-E-ST-50-12C Standard mixes for each protocol “level” the description of syntax, synchronisation, semantics; and it does not describe the Service Access Points. The advantage is that it facilitates the first reading/understanding of the major features of SpaceWire but it also increases the risk of ambiguities when it comes to detailed understanding and implementation

Keep the overall layering as it is but remove any kind of (minor) mixing/overlap between layers in the current standard and clearly define Service Access Points.

“SpW concepts clarification”: redefining,

nodes, units, logical network,

etc.



Scope

4. Number


clause page

(e.g. 3.1 14)


8 7 & 8 52 to 86

Introduce Interrupt distribution codes or more general low-latency signalling codes

As reported in [86], [48], [51], [52], [53], [54], [55], [46], [47], and [49]:

A possible use of one reserved state of the two “control bits” of the SpW standard to allow low-latency distribution of interrupts across SpW networks was presented to the SpW Working group several times. The technical solution was discussed thoroughly and improved.

Some optimisation of this technique allowing low-latency distribution of any kind of signalling code, included but not limited to interrupts and time codes, was recently presented to the SpW Working group.

Once validated by ESA through breadboarding, the feature will be ready for introduction into the new release of the standard.

Include the Distributed Interrupts or more general low latency signalling codes as a new feature in the revised standard. For this, one or more of the three reserved states of the two control bits shall be used.

“Distributed Interrupts”:

improving SUAI proposal (timing

issues ?)



Scope

“Simplex and Half-Duplex” stream:

studying the relevance and

technical solutions for simplex and for half-duplex SpW

4. Number


clause page

(e.g. 3.1 14)


29 8 57 Introduce simplex and/or half-duplex mode(s).

As reported in [61] and [62]:

For many high speed payload data applications only a simplex connection from the instrument to the memory is required. In these cases the back channel provided by SpaceWire is often seen as unnecessary complexity and cable mass. It has been proposed to modify the SpaceWire codec and the state machine to support simplex operation. Also the possibility of a half-duplex SpaceWire implementation has been suggested.

Not to introduce simplex and half-duplex in the update of the SpaceWire standard unless more detailed explanations on the technical solution and on the impact on the current SpaceWire standard are provided very soon.



ECSS Working Group

1. ECSS New Work Item approved a. Financial resources approved for WG members (industry) b. Manpower approved for ESA coordination

2. Working Group membership approved

1. Work plan

a. Kick-off meeting 22 May 2012 b. 3 other meetings (every 4 months) c. ECSS draft standard for public review

PersonName Position Company Name Nominated byBouabdallah, Ahmed WG Member TELECOM Bretagne EurospaceCook, Barry WG Member 4Links EurospaceDellandrea, Brice WG Member Thales Alenia Space EurospaceHult, Torbjorn WG Member RUAG EurospaceIsomaki, Makro WG Member Aeroflex Gaisler EurospaceJameux, David WG Convenor ESA ESAJoerg, Stefan WG Member DLR DLRNickl, Mathias WG Member DLR DLRNotebaert, Olivier WG Member Astrium Satellites EurospaceParkes, Steve WG Member University of Dundee ESARastetter, Paul WG Member Astrium Satellites EurospaceVigeant, Fabien WG Member CNES CNES



Background – Open technical issues

1. Tackled through the “SpW Evolutions” TRP activity a. Assessment of simplex and half-duplex SpaceWire – discarded b. Thorough analysis and testing of Distributed Interrupts as

specified by SUAI – refinements c. Clarification of terminology (clear enough to support network

discovery and configuration) 2. Supported by the “Network Discovery Protocols” TRP activity

a. Clarified the concepts of end-point, higher layer and node (including issue of time-code register)

b. Clarified the concept of configuration space for a switch c. Harmonised concepts of configuration space for a switch and

for a node d. Allowed representing any SpW network as a graph



(from SpW WG mtg#19)



ECSS SpW Rev WG mtg#3, March 2013



ECSS SpW Rev WG mtg#3 - Outcome

Terminology: set of terms agreed with their

relationship • Table of SpW Link Level objects • UML diagram of ECSS-E-ST-50-

12C(Rev1) terms

Layering: reduced set of “levels” agreed with their

interfaces • Clear Service Access Point

definitions (implementation is optional)

• List of objects exchanged between levels

Clear definition of services (lists of SAPs) provided by SpaceWire

• Regardless of the internal layering / link technology • Time-codes now clearly exposed at higher level;

Behaviour of all signalling codes (Time-codes, distributed interrupts and acknowledgements) harmonised (not only at SpW Link Level)

• LA check issue and node configuration space issue solved

• Management parameters identified



Clarified layering

Physical Level

Signal Level

Exchange Level

Character Level

Packet Level

Network Level

Physical Level

Signal Level

Link Level

Network Level



Clear Service Access Point definitions (implementation is optional) 1/7

SpW Phy Level

SpW Signal Level

SpW Link Level

SpW Network Level

Data Char (8b) or EOP or EEP

Time-code (6b)

Distr. Int. (5b)

Distr. Int. Ack. (5b)

bit


Time-code (6b)

Distr. Int. (5b)


Data Char symbol (10b)

Time-code symbol (14b)

Distr. Int. symbol (14b)

Distr. Int. Ack. Symbol (14b)

EOP/EEP symbol (4b)

SpW PhyLevel SpW Phy Level SpW Phy Level

Nx




SpW Phy Level

SpW Signal Level

SpW Link Level

SpW Network Level


Time-code (6b)

Distr. Int. (5b)


bit


Time-code (6b)

Distr. Int. (5b)


Data Char symbol (10b)

Time-code symbol (14b)

Distr. Int. symbol (14b)

Distr. Int. Ack. Symbol (14b)

EOP/EEP symbol (4b)

Phy Level 2 Phy Level 3




SpW Phy Level

SpW Signal Level

SpW Link Level

SpW Network Level


Time-code (6b)

Distr. Int. (5b)


bit


Time-code (6b)

Distr. Int. (5b)



Signal Level 2

bit

Signal Level 3

bit




SpW Phy Level

SpW Signal Level

SpW Link Level

SpW Network Level


Time-code (6b)

Distr. Int. (5b)


bit


Time-code (6b)

Distr. Int. (5b)



Signal Level 2

bit

Signal Level 3

bit

Link Level 2 Link Level 3




SpW Signal Level + SpW Physical

Level

SpW Link Level

SpW Network Level


Time-code (6b)

Distr. Int. (5b)


bit


Time-code (6b)

Distr. Int. (5b)


Phy Level 2

Signal Level 2

bit Link Level + Signal Level +

Physical Level 3




SpW Network to SpW Physical

Levels

SpW Link Level

SpW Network Level


Time-code (6b)

Distr. Int. (5b)



Time-code (6b)

Distr. Int. (5b)


Phy Level 2

Signal Level 2

bit Link Level + Signal Level +

Physical Level 3



Terminology – router/switch (1/3)

1. Router vs router 2. Switch

5 7 1 EEP cargo

51 EEP cargo 51 = 5-7-1

routing (building a

route)





5

7 1 EEP cargo

3

0

6

7

switching





5

7

1 EEP cargo

3

5

6

0

switching



Terminology - nodes

1. Is a node a S/W interface or this interface plus the host? 2. Node = end-point + “higher layer”

5 7 1 EEP cargo

51 EEP cargo

higher layer

switch node

5

7 3

5

6

0

end-point



Terminology – end-points, nodes, units (1/2)

node

1 0 3 4

end-point

2

1 3 4 2

1 0 3 4 2

1 0 3 4 2

switch

higher layer

unit

1553



Terminology – end-points, nodes, units (2/2)

1 0 3 4 2

1 3 4 2

1 0 3 4 2

1 0 3 4 2

GRAPH



Terminology - Table of SpW Link Level objects

data signal <none>

data character data characters(0..255)

ctrl characterend-of-packet

markers(EOP & EEP)

FCT & ESC

signalling codes(time-codes, dictr. Int. codes, distr. Int. ack.

Codes, reseved codes)

NULL &invalid codes

N-Char S-Char L-Charflow-controlled

functionality (for the higher layer)

format(othograph

+ syntax)

character

code(ESC + character)

NOT flow-controlledflow-control

SpaceWire Definitions

ECSS Working Group

1

SpaceWire Definitions A node is …

2

Network

5

Node

Node ID Acceptable LAs

Network

Routing Switch Link

1..M 1..M 0..M

End Point

1..M

1..M

Switch Matrix

1

Routing Table Configured by

Port

Port Number Disable

1 Connects

1

2 Config. Node

Management

0..1

Port

6

Port

Port Number Disable

Input Output

1 1

Link Interface

Enable/Disable

FIFO

…

Node

7

Node


Configuration

Management

Destination Source End Point

Port

Port Number Disable

1..M

1

Input Output Link Interface

Enable/Disable

FIFO

1 1 …

Unit

8

Unit

Unit ID

Processing Mass Memory

… 0..M 0..M

Node


Routing Switch

Time-Code

9

Routing Switch

Port

Port Number Disable

Switch Matrix Config. Node

Management

1..M 1 0..1

Signalling Code

Time-Code

Time Count Signal ID = 00

Holds last received End Point

Local BC Reg

Last time-code

1

Port

Port Number Disable

Holds last received

Node


1..M

Local BC Reg

Last time-code

1

A Node is … A Node is a source or destination of

SpaceWire packets that comprises one or more End Points, has a unique Node ID and a list of Acceptable Logical Addresses that are used to determine which received packets it will accept

A Source Node is a Node that is able to source SpaceWire packets

A Destination Node is a Node that is able to receive SpaceWire packets

A Configuration Node is a Node within a router that is used to access its management information and configure its routing table

10



UML diagram of ECSS-E-ST-50-12C(Rev1) terms (1/4)

Protocol objects

Implemented objects

SpW Network Level

SpW Link Level



Network Level – Header filtering/deletion in end-points (1/2)

SpW Link Level

SpW Network Level


Time-code (6b)

Distr. Int. (5b)



Time-code (6b)

Distr. Int. (5b)


• Encoding/decoding of data character and signalling codes • Finite State Machine • Serialisation/Deserialisation of characters

• Header filtering on 0 (optional) • Interleaving of data characters/time codes/distributed interrupts (ack) • Packet spilling



higher layer

Network Level – Header filtering/deletion in end-points (2/2)

SpW Network Level

• Header filtering on 0 (optional) • Interleaving of data characters/time codes/distributed interrupts (ack) • Packet spilling

51 EEP cargo 0 EEP cargo




51 EEP cargo


EEP cargo 63 4

“raw” SpaceWire RMAP

network discovery



Conclusion (1/2)

1. Layering a. Agreed b. Clear Service Access Points to each level (implementation is

optional) c. Allows substituting levels with other technilogy

2. Nodes vs SpW interface a. Concept of end-point introduced b. Clear definitions of end-points, nodes, units c. “SpW interface” for SpW Link Level, “”SpW port” for SpW

(network level) 3. Clarified “header byte check in nodes”

a. Allows “raw” SpW, packet filtering on LA, network discovery



Conclusion (2/2)

1. Layering in place 2. Network Level and Link level revised 3. Next step: SpW Signal Level and SpW Physical Level

a. Change Requests b. Inputs by WG c. Support activity “Low Mass SpW cable”

4. ECSS mtg#3 in October 5. Goal: start of public review Q2 2014

status of the ecss-st-50-12c rev.1 standardisation...

Documents