UAFX defines the use of gPTP as defined in IEEE Std 802.1AS2020 for the time synchronisation of UAFX Stations. Figure 19 illustrates an exemplary time-synchronised network with two gPTP domains (see 7.4.2.1.1). The usage of an application clock as ClockSource or ClockTarget depends on the IEEE Std 802.1AS defined role for synchronisation. Each instance of ClockSource or ClockTarget is bound to one PTP Instance. The number and type of PTP Instances residing on a UAFX Station depend on the gPTP domains it participates in and its composition, e.g., the presence of a Bridge Component. A UAFX Station can host more than one PTP Instance, e.g., UAFX Stations 1 and 2. A Grandmaster PTP Instance can reside on any grandmaster-capable UAFX Station, e.g., UAFX Station 3. UAFX Station 2 and IA-station support the forwarding of corrected time information in both gPTP domains via PTP Relay Instances (see 7.4.2.1.2).
NOTE The extent of the Working Clock domain and the Global Time domain may differ.
Figure 19 – Usage example of Global Time and Working Clock domains in UAFX.
The gPTP generates a tree-structure clock relationship between PTP Instances in the network. The clocks in all PTP Instances within a gPTP domain derive their time from a clock known as the Grandmaster Clock.
The following subclauses provide further informative descriptions of IEEE Std 802.1AS2020 terminology and how it applies to UAFX.
IEEE Std 802.1AS2020 defines a gPTP domain in which system timing is consistent. A gPTP domain defines the scope of gPTP message communication, state, operations, parameters, and timescale. The Grandmaster PTP Instance is the root of a gPTP domain.
UAFX supports the following two types of gPTP domains:
Working Clock domain maintains a common sense of time for use cases such as enhancements for scheduled traffic (see IEEE Std 802.1Q).
Global Time domain (e.g. wall clock) maintains a common sense of time across an industrial automation network for use cases such as sequence of events.
There are two types of PTP Instances used in a gPTP domain:
A PTP Instance operates in a single Bridge Component or End Station Component within exactly one gPTP domain. A UAFX Station can contain more than one PTP Instance in the same gPTP domain (see 7.4.2.1.4).
PTP Instances interface with the communications network using logical entities called PTP Ports.
A UAFX Station can support one or more gPTP domains. Each gPTP domain is represented by a PTP Instance, which can have an associated ClockSource or ClockTarget. A PTP Instance with an associated ClockSource is a Grandmaster PTP Instance. A ClockSource and ClockTarget can serve as a provider of time for a UAFX Application (e.g., sequence of events).
Figure 20 shows an example of a UAFX Station consisting of a single End Station Component supporting one gPTP domain. Figure 21 shows an example of a UAFX Station consisting of a single End Station Component supporting two gPTP domains. Each gPTP domain has an associated PTP End Instance, which connects via a PTP Port to an Ethernet port.
Figure 20 – UAFX Station example with one PTP End Instance
Figure 21 – UAFX Station example with two PTP End Instances
Figure 22 shows an example of a UAFX Station consisting of a single End Station Component and Bridge Component, each supporting two gPTP domains. This example includes Bridge Component ClockTargets and End Station Component PTP End Instances and ClockTargets for both domains. ClockTargets and PTP End Instances may be omitted in an implementation depending on the expected usage of time.
NOTE How PTP messages are internally dispatched between the PTP Relay Instance and the PTP End Instance is implementation-dependent.
Figure 22 – UAFX Station example with PTP End and PTP Relay Instances
Engineered time synchronisation spanning tree (sync tree) for a given gPTP domain refers to the usage of external port configuration instead of BMCA to construct a desired sync tree with the Grandmaster PTP Instance as the root (see IEEE Std 802.1AS2020, 10.3.1).
One of the advantages of engineered sync trees is to enable a planned, deterministic, and stable configuration of the IEEE Std 802.1AS2020 sync tree for a given gPTP domain, e.g., prevent sync tree changes in case of UAFX Station addition or removal from the network. Working Clock is a use case of the engineered sync tree.
The Grandmaster PTP Instance resides in a dedicated Grandmaster-capable IA-station.
An external sync tree management entity should use the remote management interface described in clause 7.4.2.2.4 to set up an engineered sync tree.
The following configuration is used for all PTP Ports intended to participate in a gPTP domain using an engineered time synchronisation spanning tree:
- The externalPortConfigurationEnabled parameter is set to TRUE;
- The ptpPortEnabled parameter is set to TRUE.
For validation that the computed sync tree configuration can be applied to all PTP Ports intended to participate in the given gPTP domain, the management entity configuring the sync tree will, for example, verify that these ports are up, IEEE Std 802.1AS2020capable, and satisfy topology constraints by checking the following parameters:
- The status of oper-status parameter is up (see IETF RFC 8343) for all participating Ethernet links;
- The status of isMeasuringDelay (see IEEE Std 802.1AS2020, 14.16.4) parameter is TRUE;
- The status of asCapable (see IEEE Std 802.1AS2020, 14.8.7) is TRUE;
- The status of asCapableAcrossDomains (see IEEE Std 802.1AS2020, 14.16.5);
- The status of gmCapable (see IEEE Std 802.1AS2020, 14.2.7) is TRUE, only applicable to the Grandmaster PTP Instance;
- Verify that the number of PTP Relay Instances (hops) between the Grandmaster PTP Instance and any given PTP End Instance is within the limit prescribed by an external sync tree management entity;
- Verify per PTP link that the value of meanLinkDelay (see IEEE Std 802.1AS2020, 14.16.6) is less than or equal to meanLinkDelayThresh (see IEEE Std 802.1AS2020, 14.16.7 and IEEE Std 802.1AS2020 Table 11-1) value to detect, e.g., an anomaly in propagation delay;
NOTE Even if neighbouring PTP Instances do report asCapable, it can be that the link between asCapable neighbouring PTP Instances is not asCapable due to, for example, the wrong setting of meanLinkDelayThresh value. The meanLinkDelayThresh value reflects the estimated propagation delay of the installed link.
The sync tree needs to have the following properties to ensure consistent protocol behaviour and time synchronisation:
- The desiredState of all PTP Ports of the Grandmaster PTP Instance is set to MasterPort;
- The desiredState of exactly one PTP Port of all the other PTP Instances is set to SlavePort;
- The desiredState of remaining PTP Ports that are part of sync tree in non-Grandmaster PTP Relay Instances is set to MasterPort.
- The desiredState of all other PTP Ports is set to PassivePort.
After synthesis, the configuration of the gPTP domain and its engineered sync tree may then be applied and validated, for example:
Set Sync message transmission interval uniformly, e.g., default interval.
Set PTP Port states according to synthesis for all PTP Instances.
Check that the syncLocked (see IEEE Std 802.1AS2020, 14.8.52) parameter is TRUE for all PTP Ports of PTP Relay Instances in MasterPort state.
A UAFX Station supporting gPTP time synchronisation as defined in IEEE Std 802.1AS2020 shall conform to IEEE Std 802.1AS2020, 5 with the definitions specified in 7.4.2.2.2, 7.4.2.2.3, and 7.4.2.2.4.
NOTE Clocks are currently not modelled in OPC UA, and it is a vendor decision to select a gPTP domain for use at the application layer if multiple gPTP domains are supported. Clock representation in OPC UA needs to be added in a future release for UAFX.
A UAFX Station supporting gPTP time synchronisation shall support at least two gPTP domains in a Bridge Component for Working Clock and Global Time and at least one gPTP domain in an End Station Component for Working Clock or Global Time.
The gPTP message priority is defined in IEEE Std 802.1AS2020, 8.4.4.
It is recommended that gPTP messages are transmitted using the traffic class associated with Network Control as defined in Table 1 and derived from 6.4.3.
NOTE IEEE Std 802.1AS2020 defines gPTP messages to be transmitted untagged, i.e., frames do not carry priority information for traffic class selection. At the same time, IEEE Std 802.1AS2020 neither specifies a well-defined device-internal priority nor management capabilities for the configuration of the traffic class to be used for the transmission of gPTP messages.
A UAFX Station supporting remote management (see 6.2) and gPTP time synchronisation shall implement gPTP management for the managed objects defined in IEEE Std 802.1AS2020, 14.
Bibliography
IEEE Std 1588-2019 – Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
https://standards.ieee.org/standard/1588-2019.html
IEEE Std 1588-2019 – Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
https://standards.ieee.org/standard/1588-2019.html
OPC 10000-84, OPC Unified Architecture– Part 84: UAFX Profiles
http://www.opcfoundation.org/UA/Part84/
IEC/IEEE 60802 – Time-Sensitive Networking Profile for Industrial Automation
https://1.ieee802.org/tsn/iec-ieee-60802/
OPC 1000083, OPC Unified Architecture – Part 83: UAFX OfflineEngineering
http://www.opcfoundation.org/UA/Part83/
OPC 10000-100, OPC Unified Architecture– Part 100: Devices
http://www.opcfoundation.org/UA/Part100/
IETF RFC 4594 – Configuration Guidelines for DiffServ Service Classes, August 2006
https://www.rfc-editor.org/rfc/pdfrfc/rfc4594.txt.pdf
IETF RFC 3246 – An Expedited Forwarding PHB (Per-Hop Behavior), March 2002
https://www.rfc-editor.org/rfc/pdfrfc/rfc3246.txt.pdfhttps://www.rfc-editor.org/rfc/pdfrfc/rfc3246.txt.pdf
IETF RFC 8343 – A YANG Data Model for Interface Management, March 2018
https://www.rfc-editor.org/rfc/pdfrfc/rfc8343.txt.pdf
IEEE Std 802.1AS-2011 – IEEE Standard for Local and Metropolitan Area Networks – Timing and Synchronisation for Time-Sensitive Applications in Bridged Local Area Networks
https://standards.ieee.org/standard/802_1AS-2011.html
IEEE Draft Std P802.1ASdn – Draft Standard for Local and Metropolitan Area Networks: Timing and Synchronisation for Time-Sensitive Applications – Amendment: YANG Data Model
https://1.ieee802.org/tsn/802-1asdn/
IETF RFC 6762 – Multicast DNS
https://www.rfc-editor.org/rfc/pdfrfc/rfc6762.txt.pdf
____________