Using telemetry protocols Time zone management

Both local time and UTC time are available at the RTU when using UTC as the coordinated system time. Use UTC time synchronization to the RTU (e.g. from the remote SCADA master station or local time source such as NTP or GPS). Configure the local time zone offset at the RTU and use the Daylight Savings control to adjust the “local” time in the RTU.

Time-of-day control and time-stamped event reporting in remote SCADA solutions rely on accurate time synchronization between a remote SCADA master station and remote RTUs. The use of best-practice time management is part of Schneider Electric‟s energy management solutions, offering customer benefits in process and remote SCADA systems.

A common question for time management is “In which time zone should my devices operate?” Remote SCADA operates smoothly when using UTC (Universal Coordinated Time). Best-practice time management has all devices and systems synchronized to UTC time. Time-of-day

operations are a local factor and should be offset from UTC at each RTU device.

DNP3 specifies that the “time” to be used for time synchronization and event time stamps is UTC. Using UTC time at the RTU provides:

No disruption of historical data during Daylight Savings transitions

Common time reference in the same system, and interconnected systems, for RTUs and master stations operating across multiple time zones

Common time format regardless of the time source. E.g. UTC is uniformly used in DNP3 protocol, IEC 60870-5 protocol, NTP time synchronization (IP), time synchronization from a locally connected GPS device

Aligned diagnostics between RTUs and remote SCADA master stations in different time zones

Uniform time information for auditing purposes (operational audit, security audit and so on) Many remote SCADA master stations use UTC time internally. RTU time management from the master station is simplified if UTC time is used to all remote devices.

Smart RTUs typically provide built-in facilities for dealing with both UTC and local time at the RTU.

Standard SCADAPack, SCADAPack E and M340 PAC with additional RTU module are all designed to synchronize time using UTC. Events that are time-stamped at each RTU are

internally recorded using UTC. For time-of-day control, each RTU provides configuration for local time-zone offset and Daylight Savings control to allow local time to be available at the RTU. This

provides both UTC and local time at every RTU, adhering to the remote SCADA best practice and telemetry protocol standards for the use of UTC time synchronization.

Impact of multiple protocols

A common requirement in remote SCADA systems is to optimize the use of a physical

communication channel by simultaneously supporting communication of multiple protocols. This is often required when multiple brands of legacy devices are installed in remote sites within the same system. This can occur when an existing system is upgraded or when parts of a system are replaced with equipment that uses a different protocol.

In general, attempting to use multiple protocols on the same communication link should be examined carefully as incompatibilities can cause unintended operation. For example, interleaved messages can be incorrectly rejected, message integrity checking can be compromised,

message addressing and data content can be confused, or simultaneous polling from multiple sources can cause collisions and communication inefficiency.

A communication technology should be chosen that can easily separate multiple protocols in order to avoid problems. For example, Schneider Electric‟s Trio radio solutions allow multiple virtual communication streams to operate on the same physical radio channel. This segregates different protocols such that individual streams operate as if there were the only protocol present on the channel. Trio serial radio solutions (K-Series and E-Series radios) provide this capability using Trio‟s MultiStream™ feature. Trio IP radio solutions (J-Series and ER45e radios) provide this capability through IP connection handling.

5.6.

Remote communication network subsystem

This section provides information to consider when choosing remote communication network infrastructure.

Remote communication network types (permanent, non-permanent and connection on-demand) are described in section 3.6.

Permanent Non-permanent Connection on-demand Example Network Ethernet, fiber optic, extension _{of business network} Data radio, GPRS, leased-_{line, audio radio, satellite}

PSTN (dial-up) GSM

Data Collection Current values and time-_{stamped events} Time-stamped events Time-stamped events

Permanent Non-permanent

Connection on-demand Polling Methodology

Integrity polls (events and

current values) Event polls

Integrity poll after connection

High Priority Alarms Collected by polling Collected by event poll or _{unsolicited response}

By polling, or

unsolicited response if the site can dial in

Inter-site Connection (DNP3 protocol)

Direct peer-to-peer,

Multiple masters to the same RTU

Multi-drop peer-to-peer Site-to-site dialing

Table 7: Remote communication network use - case comparison

In broad terms, the cost and bandwidth dimensions for various remote communication networks can be characterized as follows:

Table 8: Remote communication network operational comparison

Note: Where a public infrastructure communication network (primarily including Internet

infrastructure, but including other infrastructure as well) is used to interconnect parts of a remote SCADA system, careful attention should be paid to system security. Best practice and defense-in-depth security should be deployed.