9Control system#

9.1Communication interfaces#

9.1.1Communication with STREAMS#

Each item of ITS equipment and/or associated system shall allow autonomous operation and local manual operation independent of STREAMS. All field equipment shall interface with STREAMS or other systems as specified in the relevant Technical Specification. Where ITS equipment is to communicate with STREAMS, it shall be by direct ethernet or direct serial (RS232, RS422) connection to a co-located Field Processor (FP). Where this is not practical the Contractor may seek approval from the Principal to use one of the following alternative means (in the following order of preference): Hold Point 1

1.Remote Ethernet or serial (for example, using a serial / fibre media converter) connection to an FP located elsewhere on the Principal's Telecommunications Network.
2.Digital I/O connection to a collocated FP.
3.Direct connection to a STREAMS Node via Principal's telecommunications network.
4.Connection to a STREAMS Node via a third-party telecommunication network (for example PSTN, PAPL, GSM, 4G, 5G and/or satellite).

Where specified in the Contract an alternate telecommunications channel independent of the Principal's telecommunications infrastructure shall be provided.

Most ITS devices are typically connected to the Transport and Main Roads traffic management system STREAMS. However, some, such as Bluetooth and other data collection devices, are not. These are broadly defined in the subsection below.

9.1.2Communications with Other Control Systems#

For ITS equipment not connected to STREAMS, the equipment shall interface with a control system defined in the project-specific contract. The Contractor shall ensure that the equipment complies with the communication protocols, integration requirements, and functional specifications of the designated control system. Any deviations from the specified control system or its requirements shall require prior approval from the Principal.

9.2Physical interfaces (OSI layer 1)#

Unless otherwise specified, input and outputs shall be electrically isolated from the controlling device. Physical interfaces shall utilise industry-standard connections. Physical interconnections shall be captive, (in the following order of preference):

automatic 'click' type (such as RJ-45)
manual 'click' type (such as retention clips), and
screw-type.

9.3Communications cabling#

Communications cabling shall comply with the relevant parts of AS/NZS 3080, AS/CA S008, AS/CA S009 and MRTS234 Communications Cables as applicable.

9.4Digital I/O signals#

Unless otherwise specified, digital inputs / outputs shall be volt-free 'clean' contacts. Contacts shall be chosen to be 'Normally Open' or 'Normally Closed' such that systems fail to a safe, predetermined default state. Digital signals connected to Field Processors shall be in accordance with MRTS232 Provision of Field Processors. Where digital I/O is provided between ITS Devices and/or Systems, and a Field Processor is co-located with such an ITS device and/or system, the digital I/O signals shall also be connected to the Field Processor. The Field Processor (FP) shall be provided with at least 6 digital inputs. The FP shall have a minimum of 2 spare digital inputs and 2 spare digital outputs. The spare digital inputs and outputs shall be in addition to the digital inputs and outputs required for the design.

9.5Field processor device driver#

The Contractor shall develop a 'Field Processor Device Driver' to allow connection of the respective ITS Device to the Field Processor. The Field Processor Device Driver shall enable full-duplex communications for all control and status interrogation commands relevant to the ITS Device, as described in the respective Technical Specification documents and the design documentation. The Field Processor Device Driver shall utilise a serial protocol (in accordance with Clause 9.6) and/or digital I/O as appropriate to the relevant ITS Device.

9.6Serial protocols between the ITS device and the field processor (OSI layer 2)#

Wherever possible, serial protocols shall utilise widely recognised industry-standards. The serial protocols shall incorporate inherent error-detection against one and 2 bit errors. Cyclic Redundancy Check (CRC) error checking shall be incorporated and/or used wherever possible. ITS Devices with built in EIA/ RS-422 interfaces are preferred. Unless otherwise specified, field devices shall use either EIA/ RS-422 or 4 wire EIA/ RS-232 communication channels. Where communications channel distances are greater than 3 metres, EIA/ RS-422 shall be used. Consequently, if the ITS Device supports only EIA/ RS-232, a RS-232 to RS-422 converter shall be provided. ITS Devices that support only half-duplex services (such as 2 wire EIA/ RS-485) shall not be used. In the case of a RS 422 serial connection, control signals of RTS and CTS, should be used. In the case of a RS 232 serial connection, control signals of RTS, DTR, DSR, CTS, RLSD should be used. The serial data stream may be either 7 or 8 bit asynchronous, with any combination of parity and stop bits. The chosen data stream shall be clearly identified in the design documentation. A data stream with 8 data bits, no parity bit and one stop bit is preferred. The data stream shall be broken into framed, error checked messages. The framing protocol shall have the following characteristics:

the frame shall be clearly recognisable within the data stream
the error checking shall be robust. CCITT CRC16 is preferred over XOR or other simple check sums, and
framing characters shall be 'escaped' so that they are clearly identifiable within the frame.

The preferred escape scheme has the frame characters never appearing in the data stream, other than at the frame boundaries:

all messages shall have a response to determine communication success or failure, and
the message set shall contain status messages to indicate the operational state of the ITS Device, device components and/or ITS System.

An example protocol (assuming an addressable ITS Device) follows:

Control characters: ASCII
Escape character: DLE (0x10)

Escaped value (for example: V) sent as: (DLE, DLE + V).
Start of transmission: SOH (0x01)
Source Address: n bytes (usually n is 2)
Destination Address: n bytes (usually n is 2)
Start of Text: STX (0x02)
Command 1: n bytes (usually n is 1)
Data 1: 0...n bytes
Optional Start of Text: STX (0x02)
Optional Command 2: n bytes (usually n is 1)
Optional Data 2: 0...n bytes
Error checking scheme: CCITT CRC16
End of Transmission: ETX (0x03)

Acknowledgment (ACK) and Failure (NAK) shall be application level messages encapsulated in a full frame. End of Frame character is not included in the CRC.

9.7Messaging requirements#

Wherever possible, ITS Devices that primarily provide data to STREAMS, for example vehicle detectors, shall provide event - driven messages to minimise / avoid polling between the device and Field Processor / STREAMS. Devices that require frequent polling shall communicate at a sufficient data rate for all the available data to be exchanged within a 2 second interval. Event-driven messages shall contain a time stamp marking the time the event occurred. Where communications from an ITS Device are mostly event-driven, a heartbeat (or status) message shall be emitted by the ITS Device at least every minute.

9.8Transmission acknowledgement#

Important message outputs (digital and serial) shall be acknowledged by the receiving device within a determined period. Failure to receive acknowledgement shall be recognised by the transmitting device and initiate an 'Output Communications Fail' alarm.

9.9Local facility switch#

Where specified, a local facility switch shall be provided at the nominated enclosure to allow local manual over-ride operation. The facility switch and associated key shall indicate the currently selected function in accordance with Clause 13.7. Unless otherwise specified, intermediate messages shall not be displayed when changing the switch position. Where an ITS device is connected to a Field Processor the selected position of the facility switch shall be provided to STREAMS in accordance with Clause 9.4.

9.10Failure modes / resilience#

Alarms shall be flagged. Alarm flags shall remain active through power failure / restoration, even where the condition that raised the alarm is reset. The flag shall be able to be cleared and acknowledged by the Principal's TMC operator and/or maintenance staff.

The device and/or system shall comply with the operational requirements for failure modes described in Clause 8.3.

Upon restoration of power, the control system, equipment and/or associated systems shall inhibit any new alarms until steady-state is achieved.

Where a device and/or system is controlled via a remote connection and the telecommunications link fails, it shall automatically re-establish communications as soon as possible.

9.11Internal system clock#

Where an internal system clock is specified for an ITS device, it shall automatically synchronise as specified by the Principal and maintain an accuracy better than ±1 second over a one week period.

Where an internal system clock for an ITS device is not synchronised, it shall maintain an accuracy of better than ±1 second per week and a maximum drift of ±5 seconds per month under normal operating conditions. The clock shall also exhibit long-term stability and be capable of retaining accurate time during power interruptions for a minimum of 150 hours using an internal backup power source.

9.12Computers#

9.12.1Desktops and laptops#

Unless otherwise specified, computers located in the Principal's TMC and laptop computers will be provided by the Principal.

The computers may use supported Microsoft Windows® operating systems, current at the time of use. Any software provided by the Contractor shall be capable of operating on all such operating systems.

The Contractor accessing any part of the Principal's ICT facilities and devices shall comply with the relevant ICT information standards and policies.

9.12.2Hand-helds#

The Contractor shall provide all devices required for configuring the device and/or system in the field.

In addition, where specified, the Contractor shall provide each hand-held operator interface device necessary to interrogate and/or operate the ITS device and/or system.

All hand-held devices, including mobile devices, used for ITS device configuration shall adhere to stringent security standards to protect against unauthorised access, data breaches, and malicious activities. Additionally, all mobile applications used for configuration shall comply with the OWASP Mobile Application Security Verification Standard (MASVS) and address risks identified in the OWASP Mobile Top 10, ensuring secure authentication, data storage, and communication. The solution must provide robust encryption, secure APIs, and proactive threat detection to safeguard sensitive ITS operations. Runtime Application Self-Protection (RASP) is an acceptable method to enhance security by providing real-time monitoring, threat detection, and self-protection during application runtime.