iec 62439-3 annexes - solutil · 2018. 3. 16. · iec 62439-3 annexes iec/ieee 61850-9-3 precision...

© 2017 IEC SC65C WG15

INTERNATIONAL

ELECTROTECHNICAL

COMMISSION

IEC 62439-3 Annexes

IEC/IEEE 61850-9-3

Precision Time Protocol (IEEE 1588) profile for clock synchronization in Industrial Automation networks

Fault-tolerant clocks attached to redundant local area networks, especially PRP and HSR

picture from shawnhallwachs' photostream

2017-02-08 Baden, Switzerland

Prof. Dr. Hubert Kirrmann, Solutil, SwitzerlandIEC SC65C WG15; IEC TC57 WG10; IEEE P1588 Architecture

2 IEC SC65C WG15 / IEC TC57 WG10 2017-02-04 HK Solutil

IEC 62439-3 AnnexesPTP Industry Profile

Abstract

Two standards developed by IEC SC65C WG15 were published in 2016 that provide

microsecond precision clock synchronization for all Ethernet-based industrial networks

They have the same base specifications: IEC 61588 / IEEE 1588 [1588 in the sequel]:

IEC 62439-3:2016 Annexes A-E Industrial Communication Networks (high-availability)

IEC 61850-9-3:2016 Communication Networks for Power Utility Automation

There standards open the way to precision time-stamping and deterministic data

transmission.



Contents

1. Application domain

2. 1588 operating principles

3. Link delay measurement in IEC 61588

4. Clock model

5. RedBoxes as Three-way Boundary Clocks

6. RedBoxes as Doubly-Attached Boundary Clocks

7. RedBoxes as Doubly-Attached Transparent Clocks

8. RedBoxes as Stateless Transparent Clocks

9. MIB



PRECISION TIME APPLICATION DOMAINS



Applications that require sub-micro second synchronization

• Electrical substations: differential protection: 10 µ𝑠 (absolute time)

• Electrical grids: wide area protection: 1 µ𝑠 (absolute time)

• Motion control: newspaper printing : 4 µ𝑠 (relative time)

• Drive (GTO, IGBT firing): 1 µ𝑠 (relative time)

Typical time synchronization protocols:

• SNTP: 10’000 µs accuracy

• PTP: 1 µ𝑠

• GPS / Galileo: 0,1 µs accuracy



Synchrophasor network

PDCs (Phasor Data Concentrators) detect grid instabilities by comparing the phase of current and

voltage measured by PMUs (Phasor Measurement Units) at strategic locations with 4 µs accuracy.



1588 operating principles



Definitions: precision and accuracy of a clock

precision

accuracy

time error: deviation from the time reference used for measurement or synchronization, evaluated over a short

span. in this example: the red curve representing a histogram of the time error.

accuracy: mean of the error on time or frequency between the clock under test and a perfect reference clock, over an

ensemble of measurements.[1588]: in this example: -60 ns

precision: deviation from the mean error on time or frequency between the clock under test and a perfect reference clock

[1588] in this example: 120 ns with a variance of 3

time inaccuracy: time error not exceeded by 99.7% of the measurements, evaluated over a series of 1000 measurements

(about 20 minutes) in steady state [IEC 62439-3]. in this example: 180 ns

clock accuracy: time inaccuracy guaranteed by the manufacturer in this example: 200 ns

clockAccuracy: clock accuracy enumeration transmitted in the Announce message [1588]

3

99,73%

68,28%

+50 +150

time error

[ns]

-150 -50

time inaccuracy

meanclockAccuracy

3

99,73%

68,28%

reference



Notions: Synchronization & Syntonization

Synchronization =

adjust the time

Syntonization =

adjust the frequency

+

-



Precise synchronization: Inaccuracy sources

Usual quartz have high precision

typical: 50 ppm ( 50 μs per second) precision

Usual quartz has a temperature dependence of 1 ppm/Co

(use of oven is costly)

Shock and vibration are a greater inaccuracy source

Influence of the medium

Cable: about 500 ns delay per 100 m (CAT5 cable)

cable asymmetry is nominally 25-50ns/100m

Wireless: 300 ns / 100 m, but reflections can change the path length

Hub / Media converter:

delay 500 ns, jitter about 50 ns, independent of frame length

Bridge (Switch)

cut-through bridges: minimum delay of 1,12 μs, max 124,0 μs if

switch supports prioritization, unlimited otherwise

store and forward bridges: minimal delay 6,7 μs, max 124,0 μs

(with prioritization), asymmetry depending on traffic.

Influence of the quartz



TIME SCALES



UTC vs TAI

TAI (Temps Atomique International) is the international time base maintained by

a network of some 400 atomic clocks worldwide synchronized by GPS satellites,

it bases on the second definition of the Cesium atom.

UTC is the legal time, it increases at the same rate as TAI, but is corrected about

every 1.5 year by a leap second to compensate the slowdown of the Earth rotation.

High-precision clocks have a problem with UTC since the handling of leap seconds is

tricky.

At the same time, it is not possible to calculate time differences without a table of leap

seconds.



Calculating time differences: a problem

Two events were retrieved from the archive. They were time-stamped in the Unix

format (no fractions):

Timestamp value A: <1435 6224 00>

Timestamp value B: <1435 7088 00>

Question: what is the time interval between these two events ?

Answer:

1) if the timestamp is TAI: (1435 7088 - 1435 6224) = 86400 s = 24:00:00 hours

2) If the timestamp is UTC: it depends

....

....

(it was 24:00:01 since there was a leap second on 2015-06-30,

but to know this you need to compute the absolute time and look-up the

actual leap second table)



A recommendation

Industrial control systems should not rely on UTC, but only use TAI.

This applies to OPC, etc…

UTC is a human-readable scale.

We propose to make this a general recommendation in SC65C and TC57



NTP (internet time protocol) only estimates path delays

time

a) symmetrical

network delay

b) asymmetrical

network delay

request

response

t1t2

t3

t4

request

response

t’1

t’2

t’3

t’4 distance

2

servernetworkclient

1

2

1

NTP estimates the path delay end to end, assuming same delay in both directions.

This is far from being the case due to packet delay version (network congestion, route)

time

pathrequest

response

2

)()( 2314 tttt

estimate of

network

delay

NTP distributes UTC only



TC = transparent clock

GC = grandmaster clock

OC = ordinary clock

Each bridging device relays the Sync message from the GC and adds to it a time correction

to compensate for its own residence time and the delay on the link from which the frame came

The master broadcasts TAI time e.g. every 1 s

1588 elements

Reference signal

TCTC

OCOC

GC

TC

Grand Master Clock

OCOC

residence

delays

TC

Sync’

(corrected)Sync

Sync”

GPS

link delay

TC

residence

delayslink delay

transparent clock



1588 time correction

The time received by the slave clock is corrected by the time that elapsed between the

master and the slave, called the “path delay”.

Path delay includes all delays between the master and the slave(s) clock, divided into:

1) Residence delays (~100 µs)

measured using the local clock (possibly syntonized) of the network elements

2) Link delays (~5 ns/m)

measured using a ping-pong exchange with the partner,

assuming that the link delay is the same in both directions,

with two methods:

a) end-to-end

b) peer-to-peer



TC

GPS

MC

residence delay 50µs

link delay 2µs

200µs TC

OC

t0 0

t0 52

t0 257

5µs

4µs

t = t0 + 261

Precision time correction principle

Master Clock

Transparent Clock (switch, bridge)

Transparent Clock (switch, bridge)

Ordinary Clock (slave)



Precise time-stamping by hardware

PHY

bridging logic

PHY

Each clock transition introduces a jitter and a constant delay due to the synchronizer.

To keep track of the time-stamps:

- at reception: subtract the ingress timestamp (and add the peer delay) from the correction field,

- at sending: add the residence delay and the egress timestamp to the correction field.

Transparent Clock

Xtal

link

(e.g. cable)

syncEventIngressTime syncEventEggressTime

pDelay_ReqEventIngressTime pDelay_ReqEventEggressTime

pDelay_RespEventIngressTime pDelay_RespEventEggressTime

reference plane reference plane

link delay residence delay link delay

PHYPHYlink

(e.g. cable)


PTP elements

OC

TC

GC

designated master(back-up clock of domain)

first to become master (after BMCA) if

the current master stopssending Announce

Rb

DC

BC

Boundary Clock has a slave portin the upper region and a master (or passive) port in the lower region

slave port

master port sends Sync & Announce: sets “sourcePortIdentity” for this region

TC

OC

ordinary clock can takethe role of master or slave

Sync & Announce carry the MAC address of the

master, (not that of the

grandmaster)and the

“sourcePortIdentity” of the master

HC HC

Hybrid clocks combinea TC and an OC,

HC have two or more ports

BC

TC

OC

master-enabled OC

(currently slave)

if this link is established, the two regions merge and one boundary clock’s master port becomes either slave or passive, according to the BMCA

OC

subdomain B

top subdomain

subdomain C

slave port

master portsends Sync & Announce

slave port

egress ports

ingress port

bridging nodes

Transparent Clock forwards and corrects PTP messages

slave (or passive) port

grandmaster (role):top level clock of the time domainmaster of the top region, defines grandmaster identity



1588 module with TC/OC functionality

MAC port 3MAC

MAC

MII

MAC

port A port B

port 1

port 2 TS

OC

port 4

PHY PHY

PHY

MII

MIIMII

TS TS

TS

CPU

OC

MC OC

management

workstationbridge

switching

time-stamping

medium-independent

interface



Time distribution in 1588 (1-step correction,

transparent clocks)

every transparent clock along the path estimates the delay it introduces and adds it

to the correction field

ordinary

(slave) clock

transparent

clockmaster

clock

transparent

clock

bridgebridge

time

linklinklink

residence

delay

Sync’

contains

t1, , ()

Sync

contains t1

t2

t1

t1

residence

delaylink delay

Sync” contains

t1, ms = i , (i)

path



Accuracy degradation

grand

master clock

transparent

clock

TC

transparent

clock

TC

slave

clock

SC

total error

(pdf)

local clock error

(pdf)

PTP path

distance

slave clock



Intermediate clocks in 1588

1588 has two different intermediate clocks:

BC: boundary clocks, that are slave clocks in a region acting as master for another region

(used mainly in wide area network routers)

TC: transparent clocks, that are relaying the synchronization signal within a region

(used mainly in local area networks).



grand

master clock

transparent

clock

TC

transparent

clock

TC

transparent

clock

TC

slave

clock

SC

grand

master clock

boundary

clock

BC

boundary

clock

BC

boundary

clock

BC

slave

clock

SC

The mean at the slave clock is the sum of the mean errors

The variance at the slave clock is the sum of the variances

Transparent clocks introduce a small mean error and a small variance (50ns)2

The contribution of the master clock dominates

Boundary clocks introduce both a mean error and a large variance (200ns)2

Their contribution dominate the grand master’s variance, since there form a chain of control loops.

Transparent clocks

Boundary clocks

pdf(time error)

pdf(time error)

Comparison: degradation in TC and BC chains



Why time domains ?

Plant networks are connected for:

Unified Operations / Common Platform

Common communication infrastructure (e.g. bridges)

Power Management e.g. load shedding

Common Network Management

Reuse devices and designs

Use same clock reference for all segments

PROFINET

Proxies

to other

buses

•Profibus

•others

IEC 61850 Field Network

Controllers

Workplaces

MV

DrivesMV

Switchgear LV

Switchgear

LV

ProductsDrives

Remote I/O

Instrumentation

Control Network

HV Valves

GIS

AIS

Distribution

trafoPower

trafo

Web HMI

RbGPS

BDS

Where different time distribution systems are used, they work in different domains

GC

OC

OC



1588 options and profiles



1588 options and IEC 62439-3 profiles

These concepts apply to the major options in IEEE 1588:

• Time correction using 1-step or 2-step

• Link delay measured by end-to-end or peer-to-peer

• Communication takes place on Layer 2 (Ethernet) or Layer 3 (IP)

• Boundary clocks and transparent clocks

end-to-end

peer-to-peer

layer2

1-step

“L2PTP”

utilities

layer3

“L3E2E”

drives

2-step



The IEC 62439-3 Annex C profiles

Master clock accuracy 250 ns

Transparent clock inaccuracy 50 ns

Boundary clock inaccuracy 200 ns

Sync correction method 1-step and 2-step (mixed)

Delay measurement end-to-end

Announce interval (default) 2 s (*)

Sync message interval 1 sPdelay message interval 1 sRedundancy method PRP slave choses masterSNMP MIB

IEC 62439-8

Profile identifier 00-0C-CD-00-01-4z

peer-to-peer

1 s

00-0C-CD-00-01-8z

L3E2E L2P2P

Transmission multicast

Medium Ethernet

common

(*): there is no technical reason for the 2s Announce interval, it is a legacy value.



Compatibility L3E2E – L2P2P

The L3E2E and L2P2P protocols cannot be used in the same time domain

simultaneously because they use different delay measurement mechanisms.

The 1588 standard currently prohibits transparent clocks that support both the

E2E and the P2P delay calculation, even in different time domains.

This is overspecified, since manufacturers of equipment can build such devices

and they will be interoperable.

It can be expected that L2PTP will become the industry standard.



The L3E2E Profile

PTP attribute Default value Range

portDS.logAnnounceInterval 0 -3 to +1 log seconds

portDS.logSyncInterval 0 -3 to +1 log seconds

portDS.announceReceiptTimeout 2 for preferred grandmasters

3 for all other grandmasters

2 to10 sync intervals

portDS.logMinPdelay_ReqInterval 0 0 to 5 log seconds

defaultDS.priority1 128 for not slave-only clocks

255 for slave-only clocks

0 to 255

255 for slave-only

clocks



0..255

255 for slave-only

clocks

defaultDS.domainNumber 0 as specified in Table 2

of IEC 61588-2009

transparentClockdefaultDS.

primaryDomain

0 as specified in Table 2

of IEC 61588-2009

• end-to-end link delay measurement,

• layer 3 communication,

• 1-step and 2-step



The L2P2P Profile

PTP attribute Default value Range

portDS.logAnnounceInterval 0 -3 to +1 log seconds

portDS.logSyncInterval 0 -3 to +1 log seconds

portDS.announceReceiptTimeout 2 for preferred grandmasters

3 for all other grandmasters

2 to10 sync intervals

portDS.logMinPdelay_ReqInterval 0 0 to 5 log seconds



0 to 255

255 for slave-only

clocks



0..255

255 for slave-only

clocks

defaultDS.domainNumber 0 as specified in Table 2

of IEC 61588-2009

transparentClockdefaultDS.

primaryDomain

0 as specified in Table 2

of IEC 61588-2009

• peer-to-peer link delay measurement,

• layer 2 communication,

• 1-step and 2-step



Standardisation and experience



State of standardization

To avoid the emergence of a parallel standard in IEEE, IEC and IEEE moved the Power

Utility Profile of IEC 62439-3 under the umbrella of the Joint Development IEC/IEEE

61850-9-3.

The text in IEC/IEEE 61850 is essentially the same as in IEC 62439-3, profile L2P2P,

with the addition that the range was further restricted, that time domain 93 was

recommended and that double attachment is not mandatory. Both use exactly the same

network management, IEC 62439-3 Annex E

IEC 62439-3 was published on 2016 April 1st.

IEC/IEEE 61850-9-3 was published on 2016 May 1st.

IEC SC65C WG15 is responsible for keeping the two specification aligned, so a device

that claims conformance to IEC 62439-3 will be conformant to IEC/IEEE 61850-9-3.

The reverse is not true since a IEC/IEEE 61850-9-3 device is not obliged to implement

redundant attachment according to PRP or HSR.



Plug-fest and interoperability test (IOT), San Francisco 2012

13 companies deployed “IEC 62439-3” devices, among them two IED manufacturers

(ABB - HSR/PRP master-capable) and SEL (slave-only end device).



Brussels interop test

In November 2015, an interop test for IEC/IEEE 61850-9-3 was conducted in

Brussels with a number of companies and observers.

No flaws were encountered with the clock synchronization, while some

improvements of the PRP and HSR specifications made their way into the standard

released in 2016



IEEE 1588 Correction Transmission

1-step <> 2-step



1-step and 2-step correction

Each transparent clock corrects the time by the amount:

(received correction + egress timestamp – ingress timestamp (+ path delay1))

IEEE 1588 foresees two correction methods for

1-step correction:

The sender of a Sync message inserts the correction while transmission is in progress.

1-step requires hardware support to read the egress timestamp and insert the correction

on-the-fly.

2-step correction

The sender of the Sync forwards the Sync it received and reads its egress timestamp. It

sends in a subsequent Follow_Up message the correction.

2-step correction can be implemented by software, but needs hardware timestamps.

This solution has a weakness since the path taken by the Follow_Up is not necessarily

the one taken by the Sync.

1) only in peer-to-peer



1588 Sync Message (P2P)

64-bit clockIdentity +

16-bit portNumber 0

Announce: 0

Pdelay_Resp: t3-t2

Pdelay_Req: 0

HTPID = x897F (2)

destination (6 octets)

source (6 octets)

PTP = 0x88F7 (2)

ETPID = x8100 (2)

sequenceNr (2)

size (2)path

VID (12 bits) (2)prio CFI

preamble

messageLength (2)

reserved (1)

correctionField (8)

reserved (4)

sourcePortIdentity (10)

sequenceId (2)

controlField (1)

flagField (2)

logMessageInterval (1)

domainNumber (1)

HSR Tag (optional)

802.1Q tag (optional)

1588 EtherType

802.3 preamble

timeStamp point

reserved versionPTP

transportSpec messageType

timestamp (10)

incremented per message

type and destination, except

for responses and follow-ups

0: Sync

1: Delay_Req

2: Pdelay_Req

3: Pdelay_Resp

8: Follow_Up

9: Delay_Resp

A: Pdelay_Resp_Follow_Up

B: Announce

C: Signalling

D: Management

0 alternateMasterFlag

1 twoStepFlag

2 unicastFlag

5 profileSpecific 1

6 profileSpecific2

7 security

0 leap61,

1 leap59

2 currentUtcOffsetValid

3 ptpTimeScale,

4 timeTraceable

5 frequencyTraceable-3: 125 us

0: 1s

2: 4s

0: default

1: 802.1AS

padding (10)

FCS (4)



1-step correction in a Sync frame

1-step correction requires on-the-fly modification of a frame while it is being sent.

subtract ingress time-stamp

from egress time-stamp, add link delay and

add to former correction

timestamp

point

preamble FCScorrection

>1760 ns > 2240 ns

correct checksum

header body

@ 100 Mbit/s



IEEE 1588 Path delay measurement

End-to-end <> peer-to-peer



Path delay calculation methods

Path delay consists of the sum of residence delay in the transparent clocks and of

the link delays

Each transparent clock evaluates its own residence delay based on its local

clock

For the link delay measurement, there are two methods

1. E2E end-to-end (former IEEE 1588v1): each slave evaluates the delay to the

master (with the help of the master)

2. P2P peer-to-peer (IEEE 1588-2008): each transparent clock evaluates the

delay to its peer



distance

Slave receives

t4 and sm

t4

time

Delay_Resp

(t4, sm)

Delay_Req

(0, sm2)

Delay_Req

(0 ,0)

sm

sm1

t10

t11

t21

t22

residence

delay

t3

2

)()( 3241 smmstttt

Delay_Req

(0, sm)

End-to-end link delay measurement

1-step correction

ordinary

(slave) clock

1-step

transparent

clock

master

clock

1-step

transparent

clock

bridge 1 bridge 2

link link link

residence

delay

Sync’

(t1, ms2)

Sync

(t1 , 0)

ms

ms1

t2

t1

t1

residence

delay link delay

Sync”

(t1, ms)Add ()

Master responds

with Delay_Resp (t4, sm)

Delay_Resp

(t4, sm)

Delay_Resp

(t4, sm)

In this figure, Delay_Req is sent

before Sync to outline that a Sync

cannot be evaluated without a

previous Delay_Req. I

link delay calculation



Delay_Resp contains

(ms), t4

distance

Slave receives

t4 and sm

t4

link delay

time

Delay_Resp

Delay_Resp

Delay_Req (1)

Delay_Req

t10

t11t21

t22

residence

delayt3

Master responds

with (ms)

End-to-end link delay measurement

2-step correction

ordinary

(slave) clock

2-step

transparent

clock

master

clock

2-step

transparent

clock

bridge 1 bridge

link link link

Sync + Follow_Up

contain = (i + i)

Sync (t1)

Sync

Sync

t2

Follow_Up* contains

= (ms), t1

Follow_Up

Follow_Up’

t1

t4

residence delay

t1

link delay

calculation



Peer-to-peer link delay measurement

1-step correction

Sync

distance

Sync

(contains + )

residence

time

link delay

Sync

t2

(contains ms + )

2

)()( 2314 tttt

path delay

calculation

t1

residence time

ordinary

(slave) clock

1-step

transparent

clock

master

clock

1-step

transparent

clock

bridge bridge

link link link

Pdelay_Req

Pdelay_Respt12

t13

t14

t11

Pdelay_Req

Pdelay_Respt12

t13

t14

t11

Pdelay_Req

Pdelay_Respt12

t13

t14

t11

time

distribution



t11

Pdelay_Resp

t2

t3

t1

t4

(contains t3-t2)

peer delay

calculation

Peer-to-peer link delay measurement

1-step correction (both directions)

distance

ordinary

(slave) clock

1-step

transparent

clock

master

clock

1-step

transparent

clock

bridge bridge

link link link

Pdelay_Respt12

t13

t14

Pdelay_Req

Pdelay_Respt12

t13

t14

Pdelay_Req

Pdelay_Respt12

t13

t14

Pdelay_Req t11Pdelay_Req

Pdelay_Respt12

t13

t14

t11

t11

residence

delay

Sync’

contains

t1 + +

Sync

contains t1

t2

t11

t1

t21

t22

t1

residence

delay link delay

t11

Sync” contains

= (i + i)

Pdelay_Req



Peer-to-peer delay measurement

2-step correction

distance

time

link delay

Pdelay_Resp_Follow_Up

(contains t3-t2)



Sync + Follow_Up

contain = (i + i)

Sync

Sync

Sync

t2

Follow_Up* contains

= (i + i)

Follow_Up

Follow_Up’

t1

ordinary

(slave) clock

2-step

transparent

clock

master

clock

2-step

transparent

clock

bridge bridge

link link link

Pdelay_Req

Pdelay_Respt12

t13

t14

t11Pdelay_Req

Pdelay_Respt12

t13

t14

t11

Pdelay_Req

Pdelay_Respt12

t13

t14

t11



Considering redundant paths



Redundant attachment of clocks

The present 1588 standard do not consider clocks synchronized

over redundant, simultaneously active paths.

This extension of 1588 is needed for high availability automation networks

as specified in IEC 62439-3 (PRP/HSR), but also others.

The duplicate discard method of IEC 62439-3 cannot be applied to PTP messages,

since the correction field depends on the path taken. Also, the Pdelay_Req messages

are link-specific and therefore have no duplicates.

The PTP messages have no RCT trailer in PRP and cannot use the HSR header to reject

duplicates in HSR.

Since the same master can appear over redundant paths,

the Best Master Clock Algorithm needs extension with a time quality selection,

and the clock model needs extension for doubly attached clocks.

The transition between duplicated and single paths, especially

using RedBoxes as transparent clocks and boundary clocks need specification.

These changes are specifically reflected in the clock object model and in the MIB.



Connection of a Master to a Slave clock over PRP

MCSync A Follow_Up A Sync BFollow_Up BAnnounce A

OC

Sync A(Follow_Up A) Announce A

Announce B

Sync B (Follow_Up B)Announce B

LAN_BLAN_A

residence

delay

link delay

residence

delay

link delay

RedBox

SANOC

residence

delay

link delay

link delay

LAN_A and LAN_B are independent

link delay



LAN_A LAN_B

(master)

OC1

(slave)

BC

Doubly-attached clock as Boundary Clock

port A Port B

This model exists already in IEEE 1588 and could be used for

doubly attached clocks. For this, the BMCA must be adapted to handle the same master

seen over two ports. An application-dependent clock quality shall select the port rather

than the port identity. This allows to select the best clock signal and also to switch

regularly to test the other path.



Doubly attached clock as Boundary Clock

provide additional redundancy

OC1

grand master

OC2

LAN_A LAN_B

slave

SAN

OC4

Issues:

can fault-independence of A

and B still be guaranteed ?

Should simple sensors with

limited processing power be

able to host a boundary clock ?

master (passive) slave

port A Port B

port A Port B

master master

master

singly-attached OC4 can be

synchronized over OC2 if

port A of OC1 fails.



Doubly-attached clock

To fulfill the requirements of L3E2E, a new clock type was introduced,

“doubly attached clock”, which behaves like a boundary clock,

excepts that only one port synchronizes the slave clock, and the other port

cannot become master.

This same model can also be used by L2P2P

It is described as a common solution in IEC 62439-3 Annex A.



Doubly Attached Clock as Transparent Clock variant

MCA

OC

slave

port A Port B

MCB

region A region B

portDS.state = SLAVE portDS.state = PASSIVE_SLAVE

A doubly attached clock consists of an ordinary clock with two ports

(in IEEE 1588, an ordinary clock has only one port)

Conceptually, only one port synchronizes the slave clock.

The slave can use for this the BMCA, but information from both ports can also be used.

This is the general case. PRP is a particular case, when both MCA and MVB are the same



Doubly Attached Clocks with same master

port A Port B

MC

grandmaster

OC

LAN_A LAN_B

ordinary clock (slave)

port A Port B

portDS.state

= MASTERportDS.state

= MASTER

one ordinary clock with two ports

portDS.state

= SLAVEportDS.state

= PASSIVE_SLAVE



PRP-HSR RedBoxes as Boundary Clocks

LAN A LAN B

RedBox

A

interlink A interlink B

GMC

Sync A Follow_Up A Sync BFollow_Up B

Sync BA

RedBox

BHC

Sync A

Sync BB

HC HC HCHC

B A B A B A B A

BC BC

HSR Ring

proven operation



Change with respect to 1588

The “2 OC plus HW clock” and the ”two-port OC” models do not exist in 1588

1588 foresees that ordinary clocks have one port only.

Boundary clocks have several ports, and for each port a state machine.

Annex A adapted a two-port model for an ordinary clock.

A doubly attached clock is therefore different from a boundary clock,

although it is possible to achieve redundancy with a boundary clock.

The only addition to the 1588 is the PASSIVE_SLAVE state, which is similar

to the PASSIVE state, with the difference that the port in PASSIVE_SLAVE is

supervising the path it is attached to.



Changes to the BMCA and port model



BMCA for BC with same master on both ports

A > B B > A

error-1error-2

A within 1 of B

A = B

A = B

A = B

compare Steps

Removed of

A and B

compare Steps

Removed of

A and B

compare

quality of

A and B

if available

compare

Port Numbers of

Receivers of

A and B

A > B+1 B > A+1return

B better than A

return

A better than B

Receiver < Sender

A > B B > A

Receiver < Sender

Receiver < SenderReceiver < Sender

compare

identities of

Receiver of A and

Sender of A

compare

identities of

Receiver of B and

Sender of B

return

A better

by topology

than B

return

B better

by topology

than A

error-1

A > BB > A

A = B

compare

identifiers of

senders of

A and B

A > B B > A

A = B

The application-specific

criterion assess the clock

quality before the port identity

is used as tie-breaker.

It can consider for instance

the magnitude of the

correction field, but should

include a hysteresis to avoid

frequent change of side.

Infrequent change is

recommended to test the

inactive path

IEEE 1588-2008 does not

have a time-out on Sync or

Pdelay_Resp.



state machine

extended by:

PASSIVE_SLAVE stateBMC_PSLAVE

READY

FAULT_CLEARED INITIALIZING

LISTENING

BMC_SLAVE

PRE_MASTER

BMC_SLAVE

MASTER

SLAVE

PASSIVE_MASTER

UNCALIBRATED

FAULTYDISABLED

FAULT_DETECTED DESIGNATED_DISABLED

BMC_SLAVE

BMC_MASTERANNOUNCE_TO

BMC_SLAVE &&

new_master ==

old_master

MASTER_CLOCK_SELECTED

BMC_SLAVE &&

new_master !=

old_master

SYNC_FAULT

BMC_SLAVE &&

new_master !=

old_master

BMC_SLAVE QUALIFICATION_TIM

EOUT_EXPIRES

any

DESIGNATED_ENABLE

D

INITIALIZE

any

ANNOUNCE_TO

ANNOUNCE_TO

ANNOUNCE_TO

BMC_PASSIVE

BMC_PSLAVE

BMC_PSLAVE

PASSIVE_SLAVE

BMC_SLAVEBMC_PSLAV

E

POWER_UPany



Why a change to the BMCA ?

The default BMCA in 1588 does not consider the case when two masters are the

same, seen over different paths (since it assumes RSTP or IP would cut loops).

The extended BMCA applies to the slave clock to chose one master over the other by

considering its clock quality and correction field, all other fields being equal.

The extended BMCA also applies to the master in end-to-end delay measurement.

Indeed, only one port may be in the master state, responding to Delay_Req. The other

is in the PASSIVE_MASTER state and does not respond to Delay_Req.

Therefore, IEC 62439-3 introduces an additional port state and extends the

comparison algorithm.

This method is identical to IEC 61588 in the non-redundant case.

IEC 61588 explicitly allows to define an alternate BMCA in a profile.



REDBOXES

Three models of Redboxes are considered:

1) Three-way Boundary Clocks

2) Doubly attached Boundary Clocks

3) Doubly attached Transparent Clocks

4) Stateless Transparent Clocks



General naming of components

7

8

9

10

BC

BC

TC

TC

LAN A LAN B

OC

OC2

OC1

OC4

SAN

slaveDAC slave

3 4

1

2

SAN

master

TC TC

OC6

PASSIVE_SLAVE

MASTER MASTER

DAC master

port A port B

port C

RedBox

M

TC

SLAVE

SAN slave

OC5

6

TC

5SAN master

OC3

port A port B

port C

RedBox

S

LAN D

LAN C

1) OC1: DAC connected to both LANs, as master;

2) OC2: DAC connected to both LANs, as slave;

3) OC3: SAC in one of the PRP LANs, as master;

4) OC4: SAC in one of the PRP LANs, as slave;

5) OC5: SAC outside of the PRP LAN, as master;

6) OC6: SAC outside of the PRP LANs, as slave;

7) BC7: RedBox M connected to the singly attached

master clock OC5, as DABC;

8) BC8: RedBox S connected to the singly attached

slave clock OC6, as DABC;

9) TC9: RedBox M connected to the singly attached

master clock OC5, as DATC or SLTC;

10) TC10: RedBox S connected to the singly attached

slave clock OC6 as DATC or SLTC.



RedBoxes as Three-Way Boundary Clockthat execute the BMCA and forward in all directions



RedBoxes as Three-Way Boundary Clock - Principle

LAN A LAN BOC

OC2

OC1

OC4

SAN

slaveDAC slave

SAN

master

TC TC

OC6

RedBox

S

PASSIVE

port A port B

SLAVE MASTER

BC8

DAC master

port A port B

port CRedBox

port C

BC7

TC

SLAVE

SAN slave

OC5

TC

SAN master

OC3

PASSIVE

MASTER

LAN C

LAN D

MASTER

SLAVE

OC3 is best master



RedBox as Three-way Boundary Clock -

The Redboxes behave as a three-way Boundary Clock as defined in

IEC 61588:2009, with the addition of the consideration of the clock quality in case

the same Master emerges on two ports.

The RedBox at the same time can bridge LAN_A and LAN B and add to resiliency.

However, this can introduce a single mode of failure.



Redboxes as Doubly-Attached Boundary Clockthat executes BMCA to select port A or port B



RedBoxes as Doubly Attached Boundary Clock

End-to-End

The Boundary Clock

decouples the PRP

networks from the SANs

This works for both

peer-to-peer and

end-to-end

LAN A LAN BOC

OC2

OC1

OC4

SAN

slaveDAC slave

3 4

1

2

SAN

master

TC TC

OC6

PASSIVE_SLAVE

MASTER MASTERDAC master

port A port B

port CRedBox

M

BC7

TC

SLAVE

SAN slave

OC5

6

8

TC

5

7

SAN master

OC3

port A port B

port C

RedBox

S

BC8

LAN D

LAN C

Delay_Req B

Delay_Resp BSync A

Sync D

Sync B

Sync C

Delay_Req C

Delay_Resp C

Delay_Req A

Delay_Resp A

Pdelay_Req DPdelay_Resp D

Pdelay_Req DPdelay_Resp D

LAN A and LAN B

operate independently,

the OCs chose the side,

but Delay_Req and

Delay_Resp are sent

on both LANs



RedBoxes as Doubly Attached Boundary Clock, Peer-to-Peer, 1-step

LAN A LAN B

OC

OC2

OC1

OC4

SAN

slaveDAC slave

3 4

1

2

SAN

master

TC TC

OC6

PASSIVE_SLAVE

MASTER MASTER

DAC master

port A port B

port C

RedBox

MBC7

TC

SLAVE

SAN slave

OC5

6

8

TC

5

7

SAN master

OC3

port A port B

port C

RedBox

S

BC8

LAN D

LAN C

Sync ASync B

Pdelay_Req

Pdelay_Resp

Sync_D

Delay_ReqDelay_Resp

Sync_C

Pdelay_Req

Pdelay_Resp

LAN A and LAN B

operate independently,

the OCs chose the side.

Pdelay_Req and

Pdelay_Resp are sent

on all links



RedBoxes as Doubly Attached Boundary Clock

Why not use always Boundary Clocks ?

Some claim that boundary clocks in series cause loop instabilities.

The theoretical limit seems to lie by 16 BCs in series.

Evidence for this is scarce.

However, in the worst case, there are only two boundary clocks in series.

Although there is no strict necessity for this, it is attempted to model RedBoxes

with transparent clocks also as a means to generalize the solution.

A number of problems though exist.



RedBoxes as Doubly-Attached Transparent Clocksthat execute the BMCA to select A or B



RedBoxes as Doubly-Attached Transparent Clocks

General model

LAN

ALAN

B

OC

OC2

OC1

OC4

SAN

slaveDAC slave

3 4

1

2

SAN

master

TC TC

OC6

DAC master

port A port B

port CRedBox

M

TC9

TC

SAN slave

OC

5

10

TC

5

9

SAN master

OC3

port A port B

port C

RedBox

STC10

LAN

D

LAN

CTCs provide a more robust

connection of clocks than BCs

DATC choose the best port

according to the BMCA



RedBoxes as Doubly-Attached Transparent Clocks

End-to-End, 1-step

LAN

ALAN

B

OC

OC

2

OC

1

OC

4SAN

slaveDAC slave

3 4

1

2

SAN

master

TC TC

OC

6

DAC master

port A port B

port C

RedBox

M TC9

TC

SAN slave

OC

5

10

TC

5

9

SAN master

OC

3

port A port B

port C

RedBox

STC1

0

LAN

D

LAN

C

Delay_Req (src=10)

Sync

Delay_Req (src=11)

Delay_Req (src=00) Delay_Req (src=00)

Delay_Resp (src=00,req=00)Delay_Resp (src=00, req=00)

Delay_Resp (src=00,req=11)Delay_Resp (src=00,req=10)

Delay_Resp (src=00, req=00)

Delay_Req (src=00)

Difficulty: keep the information

about which path was taken

in the redundant LAN for end-to-

end link delay measurement

Trick: use the source port identity

The four most significant bits of

the source port identity are

reserved, the number of ports per

device reduced to 4096



RedBoxes as Doubly Attached Transparent Clock

Stateful RedBox (DATC)

The RedBox operates as Transparent Clock with three ports: PRP Port A & Port B (paired), and

SAN Port C. It does not transfer between Port A and Port B.

Master side:

When the RedBox receives a Sync or a Delay_Resp on port C, it duplicates it (after individual

correction) to port A and port B.

When a RedBox (master side) receives a Delay_Req from port A or port B, it forwards it over

port C (there are twice as many Delay_Req on LAN C as in the non-redundant case). It

however tags the Delay_Req as coming from A or B by setting the two most significant bits to

“10” resp. “11”.

When the RedBox receives a Delay_Resp from port C, it sends it over the port from which it

received the Delay_Req.

Slave side:

When the RedBox receives a Sync from its best port A or B, it forwards it (corrected) to port C.

When a RedBox (slave side) receives a Delay_Resp on its best port A or B, it forwards it (after

correction) to port C. It discards the Delay_Resp that comes over the other port, but

nevertheless registers its arrival to check the redundancy.




End-to-End (1-step or 2-step)

Sync B

Sync D

ABt1

t2

Sync A

tAms

Sync CAB CD

t4

Delay_Req

Delay_Req

Delay_Resp (00, 11)

Delay_Resp A

t3

ordinary

(slave)

clock

master

clock

RedBox S RedBox Mlink D

link B

link Clink A

A

B

CD

AD, BD

DA, DB

A

B

CD AC, BC

CA, CB

Delay_Resp A

(t4, sm)

tAsm

Delay_Resp (00, 10)

Delay_Req (10)

59106

tD3

Delay_Req Delay_Req (11)

Delay_Resp B

(source, request)

does not indicate

over which LAN

RedBox S

accepted Sync

(Delay_Req and

Delay_Resp tagged

on LAN C)

Selection of Sync and

Delay_Resp

done by BMCA

at reception

(RedBox S)




Peer-to-Peer, 1-step

Pdelay_Req

Pdelay_Resp

Sync

The TC forwards only

the Sync that it received

from its best master port

LAN A LAN B

OC

OC2

OC1

OC4

SAN

slaveDAC slave

3 4

1

2

(SAN

master)

TC TC

OC6

(DAC master)

port A port B

port CRedBox

M

TC9

TC

SAN slave

OC5

6

10

TC

5

9

SAN master

OC3

port A port B

port C

RedBox

S

TC10

LAN C

LAN

D

Sync C

Pdelay_ReqPdelay_Resp




Sync B

Sync C

Sync A




Peer-to-Peer (1-step)

CBSync D

(t1, ms +Ams)

Pdelay_Req A

AB

Pdelay_Resp B

Pdelay_Resp A

CA

t1

t2

Sync A (t1, Ams+Ams)

tAms

ordinary

(slave)

clock

master

clock


link B

link Clink AA

B

CD

AD, BD

DA, DB

A

B

CD AC, BC

CA, CB

Sync C (t1, 0)AB CD

Pdelay_Resp C

Pdelay_Req C

59106

Sync B (t1, Bms+Bms)

Pdelay_Req BPdelay_Resp D

Pdelay_Req D



REDBOXES - Stateless Transparent Clock



RedBoxes as Stateless Transparent Clock (SLTC)

The RedBox operates as Transparent Clock Fork with three ports: PRP Port A and Port B

(paired), SAN Port C. It does not transfer between Port A and Port B.

Master side:

When the RedBox receives a Sync or a Delay_Resp on port C, it duplicates it (after individual

correction) to port A and port B.

When a RedBox (master side) receives a Delay_Req from port A or port B, it forwards it over

port C (there are twice as many Delay_Req on LAN C as in the non-redundant case). It

however tags the Delay_Req as coming from A or B by setting the two most significant bits to

“10” resp. “11”.

When the RedBox receives a Delay_Resp from port C, it sends it over the port from which it

received the Delay_Req.

Slave side:

When the RedBox receives a Sync from its best port A or B, it forwards it (corrected) to port C.

When a RedBox (slave side) receives a Delay_Resp on its best port A or B, it forwards it (after

correction) to port C. It discards the Delay_Resp that comes over the other port, but

nevertheless registers its arrival to check the redundancy.



RedBox as Stateless Transparent Clock, End-to-end

LAN

ALAN

B

OC

OC2

OC1

OC4

SAN

slave

DAC slave

3 4

1

2

SAN

master

TC TC

OC6

PASSIVE_SLAVE

MASTER MASTE

RDAC master

port A port B

port C

RedBox

M TC9

TC

SLAVE

SAN slave

OC5

10

TC

5

9

SAN master

OC3

port A port B

port C

RedBox

STC10

LAN

D

LAN

C

Delay_Req (10)

Delay_Resp (00,10)

Sync (00)

Sync (tagged as “A”)

Delay_Req (11)

Delay_Resp (tagged as “B”)

Sync (tagged as “B”)

Delay_Req (10) Delay_Req (11)

Delay_Resp (tagged as “A”)

Delay_Resp (00,11)

Delay_Req (00)



RedBox as Stateless TC, End-to-End

t4

Sync (11)

Delay_Req (00)

Delay_Req (src=10)

AB

Delay_Resp (00, 11)

t1

t2

t3

Sync A 00)

ordinary

(slave)

clock

master

clock


link B

link Clink AA

B

CD

AD, BD

DA, DB

A

B

CD AC, BC

CA, CB

Sync C (00)

Delay_Resp (10, 00)

tAsm

AB CD

Delay_Resp

(src=00, req=10)

Delay_Req (src=10)

59106

Sync B (00)

tD3

tD2

Delay_Req (src=11) Delay_Req (src=11)

tagged as “A”

Delay_Resp

(src=00, req=11)

(source, request)

does not indicate over

which LAN Sync was

accepted

Sync (10)

Delay_Resp

(src=00, req=10)

11

10

00

01Delay_Resp (00, 10)

Delay_Resp (11, 00)Delay_Resp (00, 11)



Stateless RedBox

When transparent clocks operate in cut-through, it is not possible to chose the port

over which transmission should take place.

once transmission began. Therefore, stateless RedBoxes cannot rely on the BMCA

to chose the best port, selection must be done at reception



RedBox for HSR



RedBox as Transparent Clock To HSR

TC

GMC

Sync1Step A Sync1Step B

Sync 2-step

Follow_Up A

Announce

RedBox

HSR

TC

Redbox does the transition from 2-step to 1-step.

works, but not used



LAN A LAN B

RedBox

A

interlink A interlink B

GMC

Sync A Follow_Up A Sync BFollow_Up B

Sync BA

RedBox

BHC

Sync A

Sync BB

HC HC HCHC

B A B A B A B A

TC TC

Sync AA Sync AB

RedBoxes as Transparent Clocks,

PRP-HSR: not any more considered !

HSR Ring

no implementation yet

issue: four Syncs in the ring,



Changes to the clock model of 1588 and MIB



Doubly-attached clock model

BMCA

timestamp timestamp

state

machine

state

machine



IEEE 1588 clock model: datasets for Boundary Clock

and doubly-attached clock

timePropertiesDS

about received time information (UTC,..)

parentDS

about whom the time is received from

currentDS

quality of received time

foreignMasterDS

about all discovered masters

INITIALIZING

FAULTY

DISABLED

LISTENING

PRE_MASTER

MASTER

PASSIVE

UNCALIBRATED

SLAVE

Port A

INITIALIZING

FAULTY

DISABLED

LISTENING

PRE_MASTER

MASTER

PASSIVE

UNCALIBRATED

SLAVE

Port B

per clock

defaultDS

about this clock

(quality, etc..)

per port

1588 defines the

state machine

per port.

The port in the

SLAVE state

controls the

local clock



Alternative

It was proposed to introduce the concept of using two ordinary clocks with each

one port, both controlling in an application-dependent way the local clock.

Although one can implement the doubly-attached clock this way, it is not practicable

for modelling since the dependencies between the ports cannot be expressed.

In particular, the application cannot see from which master the clock is taken and over

which path it is synchronized.

This introduces a layer of redundancy which is different from application to

application.

Also, such a double OC model does not cover the simple model of a boundary clock.



IEEE 1588 Datasets details

timePropertiesDS

⎯ currentUtcOffset /* offset between UTC and TAI in s */

⎯ currentUtcOffsetValid Bool /* currentUtcOffset valid */

⎯ leap59 Bool

⎯ leap61 Bool

⎯ timeTraceable Bool

⎯ frequencyTraceable Bool

⎯ ptpTimescale Bool

⎯ timeSource Enum8 /* atomic, GPS,… */

defaultDS: /* ordinary clock */

- twoStepFlag BOOL

- clockIdentity: Octet [8]

- numberPorts: UInt 16

- clockQuality

.clockClass ENUM8 /* 6 = synch’ed to ref */

.clockAccuracy UINT8 /* 25ns, 100 ns */

.offsetScaledLogVariance Uint16

- priority1 UINT8

- priority2 UINT8

- domainNumber UINT8

- slaveOnly BOOL

parentDS /* master and grandmaster */

⎯ parentPortIdentity Octet [8]

- parentStats Bool /* below are valid */

- observedParentOffsetScaledLogVariance /* */

⎯ observedParentClockPhaseChangeRate /* */

- grandMasterIdentity Octet [8]

- grandMasterClockQuality Strct32

- grandMasterPriority1 Uint8

- grandMasterPriority2 Uint8

currentDS /* synchronization state */

- clockstepsRemoved

- offsetFromMaster

- meanPathDelay

portDS /* per port */

- portIdentity Octet [10]

- portState Enum8

- logMinDelay_ReqInterval Int8

- peerMeanPathDelay Int64

- logAnnounceInterval Int8

- announceReceiptTimeout Int8

- logSyncInterval Int8

- delayMechanism Bool

- logMinPDelay_ReqInterval Int8

- versionNumber Uint8

foreignMasterDS /* for each <= 5 master */

- foreignMasterPortIdentity

- foreignMasterAnnounceMessages



MIB 62439-8

The MIB for IEC 62439-3 doubly attached clocks are derived from the IEEE 1588

object model

Three additions were necessary:

1) Indicate the profile

2) indicate which other port is paired for PRP

3) introduce the PASSIVE_SLAVE in the port status enumeration

These changes are already inserted in IEC 61850-90-4 object model or will be

amended when moving to IEC 61850-7-4.



MIB basic structure

OcBc

additional objects: net Protocol, profile ID,…DefaultDs

PortDS

ieee1588Base

CurrentDs

ParentDs

ports

TimePropDs

Tc

tcDefaultDs

PortDS

tcPorts

additional objects: profile ID, …

additional objects: Paired, DelayAsymm, PTP enabled, …

missing objects: Paired, DelayAsymm, PTP enabled, …

TLVs

TLV1: MANAGEMENT

TLV9: ALTERNATE_TIME_OFFSET_INDICATORnew



MIB tree

addition for redundancy

addition for power profile

1588 PortDS



Other changes

This MIB can be used by all IEC 62439-x variants.

Therefore, it is proposed to append the MIB not to IEC 62439-3,

but as a general MIB as IEC 62439-8.

iec 62439-3 annexes - solutil · 2018. 3. 16. · iec 62439-3 annexes iec/ieee 61850-9-3 precision...

Documents