The notion of time is very important in industrial automation systems. But it is also a complex notion, due to its multiple utilizations at different levels and timescales, relevant for the industrial automation arena. Some examples are the definition of one or more clock domains to be used by industrial automation devices as a base for their time-based tasks and functions, in terms of:
- Execution of application-level tasks
- Realization of timely sequences of events related to the execution of application-level tasks
- Separation of areas of concern in case of different running applications or subsystems in the same system
- Support of distributed applications over a set of devices in a system
The PTP (Precision Time Protocol) known as IEEE 1588v2/IEC 61588 (with several versions and releases) and especially its profile related to the TSN toolset, the IEEE 802.1AS (its last version is 2020, but often existing implementations cover various subversions of the 2011 release) can be used to cover all the use cases defined above.
The 802.1AS specification covers several time scales, several clock domains and it is used for a very important issue related to time, in industrial automation devices and that is the clock synchronization.
Most such devices have an internal clock, based on a quartz crystal, often in relation with their microprocessor chip. These clocks, as one may know from any other devices, of the public arena, deviate, following quartz crystal capabilities, but also due to environment conditions, such as temperature variations. Therefore, to make sure that the four use cases above can be realized, a mechanism for keeping the clocks of devices in a system or in a subsystem synchronized is needed.
Nevertheless, such needs raise several challenges, as for example:
- Which is the best source of time in a system or a subsystem, the so-called grandmaster or Clock Source in 802.1AS topology?
- Which is the influence of the network topology in the propagation of synchronization messaging between the grandmaster and its Clock Targets, given that there may be more than one path of reaching the Clock Targets starting from a Clock Source?
- Which is the influence of the different network types which may need to be crossed, in some systems, in the propagation delays of the synchronization messaging from the Clock Source?
- What is the most relevant device in an industrial automation system to become a Clock Source?
- What level of clock accuracy deviation, at the level of each participating devices clocks, is accepted for a given application or subsystem?
Thus, the domain of time and clocks synchronization is quite vast in industrial automation. We will start investigating it and studying it in the IoT NGIN project by considering some use cases to be reached. The main one would be:
- Realization of timely sequences of events related to the execution of application-level tasksTo be able to do this, we need to make sure that:
- We have the right number of clock domains, potentially only one, for the beginning
- We have a correct Clock Source which can become the grandmaster for devices in the clock domain
- We can propagate clock synchronization signals, for all the devices in the clock domain, even if they are not connected by a wired LAN network with TSN toolset support, but they are in subsystems connected over 5G services (with each subsystem consisting of a wired LAN with TSN toolset support)
- We insure an acceptable maximum deviation of the clock of each involved device, so that its generated events can be recomposed at a monitoring station remotely located, itself being connected to a 5G network
Such a test system is currently being created at ABB location in Helsinki, with the support of Cumucore and University of Aalto:
