d&c ts917 - omcs requirements - c2c interface for motorways · c2c interface for motorways ....

ROADS AND MARITIME SERVICES (RMS)

RMS SPECIFICATION D&C TS917

OMCS REQUIREMENTS - C2C INTERFACE FOR MOTORWAYS

NOTICE

This document is a Roads and Maritime Services D&C Specification. It has been developed for use with Design & Construct roadworks and bridgeworks contracts let by Roads and Maritime Services. It is not suitable for any other purpose and must not be used for any other purpose or in any other context.

Copyright in this document belongs to Roads and Maritime Services.

REVISION REGISTER

Ed/Rev Number

Clause Number Description of Revision Authorised

By Date

Ed 3/Rev 0 First issue as D&C, based on previous non D&C Specification TS917 Ed 2 Rev 0.

Interaction requirements with other control centres clarified.

MM, VS 21.09.16

Ed 3/Rev 1 Specification title changed MM, VS 10.02.17

Edition 3 / Revision 1 ROADS AND MARITIME SERVICES February 2017

GUIDE NOTES (Not Part of Project Deed)

Previous Versions

This Specification was previously published as a non D&C Specification TS917 up to Edition 2 Revision 0.

From Edition 3 onwards, this Specification will be published as a D&C Specification.

Using Specification D&C TS917

Specification D&C TS917 describes the Centre to Centre Interface between traffic management centres and is part of the Operations Management and Control System (OMCS) Specifications.

The OMCS Specifications are intended for use in the development, design, construction, operation and maintenance of motorway projects throughout NSW. The OMCS Specifications describe the requirements for design, construction, operation and maintenance of various Traffic Management, Mechanical, Electrical, Fire and Safety systems in road tunnels and motorways.

Specification D&C TS901 “OMCS Overview and General Requirements” describes and outlines the various parts of the OMCS Specifications and provides the context for the use of D&C TS917.

This Specification is a technical specification which is inter-related to other similar technical specifications that detail the requirements for RMS middleware and TfNSW TMC. Figure GN 1 shows where this Specification sits in the context of pertinent C2C interface documents.

The methods of measurement and payment, and acceptance of work are not covered in this Specification. However, payment is covered in a higher level contract document. Acceptance of work under D&C TS917 is part of the Testing stages of the software development process and is addressed in the ICT Systems Engineering Management Plan, Software Development Process Plan and other associated documentation.

ii

SPECIFICATION D&C TS917


Copyright – Roads and Maritime Services IC-DC-TS917

VERSION FOR: DATE:

Edition 3 / Revision 1 ROADS AND MARITIME SERVICES February 2017

OMCS Requirements - C2C Interface For Motorways D&C TS917

CONTENTS

CLAUSE PAGE

FOREWORD .............................................................................................................................................. III RMS Copyright and Use of this Document ................................................................................. iii Base Specification ....................................................................................................................... iii

1 GENERAL ........................................................................................................................................ 1 1.1 Scope .............................................................................................................................. 1 1.2 Related Specifications .................................................................................................... 1 1.3 Structure of the Specification ......................................................................................... 2 1.4 Definitions and Acronyms .............................................................................................. 3 1.5 Normative and Informative Documents ......................................................................... 6

2 TECHNICAL ARCHITECTURE .......................................................................................................... 7 2.1 Interface Context ............................................................................................................ 7 2.2 Messaging Orientation ................................................................................................... 8 2.3 Message Payload – Data Object Definitions .................................................................. 8 2.4 Message Exchange Patterns ........................................................................................... 8 2.5 Message Acknowledge Receipt ...................................................................................... 9 2.6 Connection Technologies ............................................................................................... 9 2.7 Subscription to and Presentation of RMS Data .............................................................. 9 2.8 Service Oriented Architecture ...................................................................................... 10

3 FUNCTIONAL REQUIREMENTS ...................................................................................................... 10 3.1 OMCS Centre Activation (Traffic Sub Centre) ........................................................... 10 3.2 New Motorway Incident and Planned Event ................................................................ 11 3.3 Updated Incidents ......................................................................................................... 12 3.4 incident Clearance ........................................................................................................ 12 3.5 Complementary Incidents ............................................................................................. 12 3.6 Complementary Multi-way Messaging ........................................................................ 12 3.7 Boundary Incident ........................................................................................................ 13 3.8 Boundary Multi-way Messaging .................................................................................. 13 3.9 Incident Polling ............................................................................................................ 14 3.10 Motorway Device Status .............................................................................................. 14 3.11 Motorway Device Fault ................................................................................................ 15 3.12 RMS Device Access ..................................................................................................... 15 3.13 Adjacent Motorway Device Access ............................................................................. 15 3.14 Device Polling .............................................................................................................. 15 3.15 Over Height Sensors ..................................................................................................... 16 3.16 Ramp Metering ............................................................................................................. 16 3.17 Movable Medians ......................................................................................................... 16 3.18 Barriers and Boom Gates ............................................................................................. 16 3.19 Weather Stations .......................................................................................................... 16 3.20 Device Control ............................................................................................................. 17 3.21 Motorway Traffic Data (Sensor) .................................................................................. 20 3.22 Travel Time .................................................................................................................. 21 3.23 Inventory ....................................................................................................................... 22

4 NON-FUNCTIONAL REQUIREMENTS ............................................................................................. 22 4.1 Transport ...................................................................................................................... 22 4.2 Message Formation and Parsing ................................................................................... 23 4.3 Schema Validation ....................................................................................................... 23

Ed 3 / Rev 1 i

D&C TS917 OMCS Requirements - C2C Interface For Motorways

4.4 Security ......................................................................................................................... 24 4.5 Interface Computing Resources .................................................................................... 24 4.6 Time Source .................................................................................................................. 24 4.7 Non Invasiveness .......................................................................................................... 25 4.8 OMCS Message Processing Times ............................................................................... 25 4.9 Acknowledge Processing Times ................................................................................... 25 4.10 Reliability and Availability .......................................................................................... 25 4.11 Service Priority ............................................................................................................. 26 4.12 Interface Management, Diagnostics and Logs .............................................................. 26 4.13 Persistence .................................................................................................................... 27

5 INSTALLATION AND COMMISSIONING .......................................................................................... 27 5.1 Development Environment ........................................................................................... 27 5.2 Factory Acceptance testing (FAT) ............................................................................... 27 5.3 Installation .................................................................................................................... 28 5.4 Future Devices and Systems ......................................................................................... 28 5.5 Systems Integration Test (SIT) ..................................................................................... 28 5.6 User Acceptance Test (UAT) ....................................................................................... 29 5.7 Production Shakedown Test (PST) .............................................................................. 29 5.8 Production Verification Test (PVT) ............................................................................. 30

6 OPERATIONS AND MAINTENANCE ................................................................................................ 30 6.1 Maintainability and Support Requirements .................................................................. 30 6.2 Service Contracts .......................................................................................................... 31 6.3 Operations and Maintenance Manual Requirements .................................................... 31 6.4 Training Requirements ................................................................................................. 31

ANNEXURES TS917/A TO TS917/B – (NOT USED) ................................................................................ 32

ANNEXURE TS917/C – SCHEDULES OF HOLD POINTS AND IDENTIFIED RECORDS ................................ 32 C1 Schedule of Hold Points ............................................................................................... 32 C2 Schedule of Identified Records..................................................................................... 32

ANNEXURES TS917/D TO TS917/L – (NOT USED)................................................................................. 33

ANNEXURE TS917/M – REFERENCED DOCUMENTS .............................................................................. 34

LAST PAGE OF THIS DOCUMENT IS .......................................................................................................... 34

ii Ed 3 / Rev 1


FOREWORD

RMS COPYRIGHT AND USE OF THIS DOCUMENT

Copyright in this document belongs to the Roads and Maritime Services.

When this document forms part of a deed

This document should be read with all the documents forming the Project Deed.

When this document does not form part of a deed

This copy is not a controlled document. Observe the Notice that appears on the first page of the copy controlled by RMS. A full copy of the latest version of the document is available on the RMS Internet website: http://www.rms.nsw.gov.au/business-industry/partners-suppliers/specifications/index.html

BASE SPECIFICATION

This document is based on Specification RMS TS917 Edition 2 Revision 0.

Ed 3 / Rev 1 iii

http://www.rms.nsw.gov.au/business-industry/partners-suppliers/specifications/index.html

http://www.rms.nsw.gov.au/business-industry/partners-suppliers/specifications/index.html

(RMS COPYRIGHT AND USE OF THIS DOCUMENT - Refer to the Foreword after the Table of Contents)

RMS SPECIFICATION D&C TS917


1 GENERAL

1.1 SCOPE

This Specification sets out the requirements for the Centre to Centre (C2C) Interface between the Motorway’s Traffic Management Control System (TMCS) and the RMS’s central traffic management control systems, including Transport for NSW’s (TfNSW) Transport Management Centre (TMC).

The C2C Interface must be designed, constructed, installed, commissioned, operated and maintained as part of the Motorway’s Operations Management and Control System (OMCS), to:

(a) exchange traffic and traffic management data between the RMS systems and the OMCS;

(b) facilitate the coordination of incidents on the Motorway with RMS and other Motorways;

(c) provide remote monitoring of traffic systems and traffic movements on the Motorway including the approach roads and ramps to RMS controlled sections;

(d) provide shared, priority control of Motorway traffic devices by RMS.

The C2C Interface must function so that the operation of the Motorway complies with the requirements of the OMCS Specifications and the deed. This Specification must be read in conjunction with the relevant OMCS specification for the Motorway.

This Specification mandates the minimum requirements and levels of performance to achieve effective Motorway operations.

1.2 RELATED SPECIFICATIONS

The Specification defines the functional and performance requirements of the Operations Management and Control System (OMCS) in conjunction with the following Level 2 specification documents:

• D&C TS901 “OMCS Overview and General Requirements”;

• D&C TS911 “OMCS Requirements - Motorway Control Centre”;

• D&C TS912 “OMCS Requirements - Traffic Management and Control System”;

• D&C TS913 “OMCS Requirements - Plant Management and Control System”;

• D&C TS914 “OMCS Requirements - Electrical Power Supply and Distribution”;

• D&C TS915 “OMCS Requirements - Motorway Network Communications System”;

• D&C TS916 “OMCS Requirements - Electronic Toll Collection System”.

• D&C TS918 “OMCS Requirements - Road Tunnel and Underpass Lighting”.

Ed 3 / Rev 1 1



1.3 STRUCTURE OF THE SPECIFICATION

This Specification includes a series of annexures that detail additional requirements.

1.3.1 (Not Used)

1.3.2 (Not Used)

1.3.3 Schedules of HOLD POINTS and Identified Records

The schedules in Annexure TS917/C list the HOLD POINTS that must be observed. Refer to Specification RMS D&C Q6 for the definition of HOLD POINTS.

The records listed in Annexure TS917/C are Identified Records for the purposes of RMS D&C Q6 Annexure Q/E.

1.3.4 (Not Used)

1.3.5 (Not Used)

1.3.6 Referenced Documents

Standards, specifications and test methods are referred to in an abbreviated form (eg AS 1234). For convenience, the full titles are given in Annexure T917/M.

2 Ed 3 / Rev 1



1.4 DEFINITIONS AND ACRONYMS

1.4.1 Definitions

The terms “you” and “your” mean “the Contractor” and “the Contractor’s” respectively.

The following definitions apply to this Specification:

Alert A notification (typically automated) of some event that needs to be brought to the attention of an Incident Manager.

Alert Threshold Number of alerts per device (or class of device) per unit time above which it triggers a meta-alert.

Boundary Device A device located on a Boundary Road that has a bearing on the operation of two segregated control Systems joined by the C2C Interface.

Boundary Incident An Incident that occurs on a Boundary Road or that can have an impact on an adjoining Motorway.

Boundary Region A set of Boundary Roads eternal to the Motorway lease area, comprising the perimeter and operational context of the Motorway.

Boundary Road A road that is outside but adjacent to the Motorway lease area. It may be part of the RMS road network that is approaching or departing from a Motorway or it may be part of an adjacent Motorway.

Complementary Incident

An incident (replete with its own life-cycle) that is created as a result of and to complement an incident received from another control centre.

Control Centre An operational centre for activities related to the operation of a road network and the maintenance of road network infrastructure assets. This includes TMC, RMS control centres, and private motorways.

Degraded Mode Operations

A failure of network communications or equipment or sending/receiving software applications or where one or more services or message classes is disabled or showing systemic failure.

Device queue The message stack or buffer of a specific device (such as a VMS, VSLS etc) where a number of messages waiting to be displayed are held in a priority order, with only the highest priority message displayed.

Enterprise Service Bus

An architectural component that provides Web Services connections, transformations, routing and security for participating nodes.

External Centre A Control Centre that is not part of the Motorway. Examples are other motorways and NSW Transports TMC.

Fault A defect either in hardware, software or in the design. Fault is an identified or potential cause of an error.

Functional Requirements

Requirements for the provision of the general data flows or object classes that are exchanged over the C2C Interface. The general data flows are detailed further to RMS specific data elements in the solution design document as per MS-TS-001.

Ed 3 / Rev 1 3



Incident An event or issue that has or may have an impact on the flow of traffic on the road network, and is described to the System by a set of data defining the position in the network, the severity and the type of the event, etc. Incidents do not include plant management issues or non-invasive maintenance activities that do not impact traffic operations.

In Service (device) The device is operational and available for use by the automated TMCS system.

Incident clearance The incident affecting the traffic has been cleared or resolved and any incident specific plans or settings have been removed.

Message Bus /Message Orientation

A message-oriented middleware (MOM) which is infrastructure focused on sending and receiving messages that increases the interoperability, portability, and flexibility of an application by allowing the application to be distributed over heterogeneous platforms.

Middleware A software that connects or sits ‘in the middle’ between other software applications and their users.

Motorway The road including all: • Open roadway sections • Tunnel sections • Approaches / on-ramps • Exits / off-ramps

within the Motorway lease area.

Near real time A system performance characteristic that allows some delay in response time, within limits (usually single digit seconds), without significantly degrading the functionality.

C2C Node Any system directly connected to the ESB via web services, capable of sending or receiving C2C messages.

Non-Functional Requirements

Specific qualities of services required from the system generally or from specific functions.

Operator A control room operator, responsible for road network oversight, either in the RMS’s or Motorway’s Control Room.

Outside of the messaging protocol

Non C2C web services communications between organisations, using email, meetings, written advice etc.

Owner Centre The Control Centre that has direct connectivity and control over a roadway and its devices.

Planned Event A scheduled traffic incident anticipated to impact traffic operations, that has been planned for and the response prepared in advance.

Service Contracts Documentation for general service qualities required for development and support.

4 Ed 3 / Rev 1



Test Harness Test data configured to test a program unit by running it under varying conditions and monitoring its behaviour and outputs.

Traffic Management Plan

A predefined or dynamically generated response to an incident or event.

Type Test Testing to determine whether a product or system meets the specified standard prior to full scale deployment.

Transients Alarms or faults that arise and fall rapidly and often continuously.

Valid (XML) The XML conforms to the elements and types defined in the XSD.

Well formed (XML) A well-formed element is the one that is opened, subsequently closed and properly nested (not overlapping).

1.4.2 Acronyms

The following acronyms apply to this Specification:

ATTS Advisory Travel Time Sign

C2C Centre to Centre

CMS Changeable Message Sign

COTS Commercial Off the Shelf (product)

DMS Dynamic Message Signs including VMS, VSLS, TMS, CMS and Conspicuity Flashers on static signs (e.g. Over Height Vehicle and Prepare to Stop)

DMZ Demilitarised Zone. An untrusted, shared IP Network outside the firewall

ESB Enterprise Service Bus

HMI Human Machine Interface or user interface

IMS Incident Management System

IP Internet Protocol

ITS Intelligent Transport System

IVLD Intelligent Vehicle Loop Detectors

ISLUS Integrated Speed and Lane Use Sign

JMS Java Messaging Service

LCS Lane Control System with individual lane association, including ISLUS, LUS and Movable Medians

LUS Lane Use Sign

NTCIP National Transportation Communications for ITS Protocol

NTP Network Time Protocol

OMCS Operations Management and Control System

RFC (Internet) Request for Comments

RMS Roads and Maritime Services

SNMP Simple Network Management Protocol

Ed 3 / Rev 1 5



SOAP Simple Object Access Protocol

SWTC Scope of Works and Technical Criteria

TCP Transmission Control Protocol

TFTP Trivial File Transfer Protocol

TfNSW Transport for NSW

TMC Transport Management Centre

TMCS Traffic Management Control System (A subsystem of the OMCS)

TMP Traffic Management Plan

TMS Tunnel Message Sign

TMU Traffic Monitoring Unit (Including general IVLDs, CCTV, Radar and other ‘virtual loop’ technologies)

UDDI Universal Description Discovery and Integration

UTC Universal Time Coordinated (nee ‘Greenwich Mean Time’)

VMS Variable Message Sign

VSLS Variable Speed Limit Sign

WSDL Web Services Description Language

XML Extensible Mark-up Language

XSD XML Schema Definition

1.5 NORMATIVE AND INFORMATIVE DOCUMENTS

1.5.1 Normative Documents

You must refer to and use the documents shown in Table TS917.1.

Table TS917.1 − Normative Documents

Doc Number Document Name

NTCIP 9010 NTCIP − XML in ITS Center-to-Center Communications, Verion 01, Nov 2004

XML 1.0 W3C − Extensible Markup Language (XML), Version 1.0, Feb 2004

SOAP 1.2 W3C − Simple Object Access Protocol (SOAP), Version 1.2, June 2003

WSDL 1.1 W3C − Web Services Description Language (WSDL), Version 1.1, Mar 2001

ISO 24097-1 ITS - Using web services for ITS service delivery — Part 1: Realization of interoperable web services, Version 1.0, Sep 2009

MS-TS-001 V1.0

C2C Interface Design Document, Version 1.0, October 2013

1.5.2 Informative Documents

Familiarise yourself with the documents shown in Table TS917.2.

6 Ed 3 / Rev 1



Table TS917.2 − Informative Documents

Doc Number Document Name

NTCIP 9001 NTCIP − The NTCIP Guide, Version 04, July 2009

FHWA-HOP-06-112

US Dot −Regional ITS Architecture Guidance, Version 2.0, July 2006

TS003.002 UTMC − Framework Technical Specification, 2008

2 TECHNICAL ARCHITECTURE

2.1 INTERFACE CONTEXT

This Specification describes the requirements for the C2C Interface, the inter-connection between RMS’s central traffic management and control applications and the Motorway’s own Traffic Management and Control System (TMCS) component of the OMCS.

The C2C Interface excludes Motorway’s Plant Management Control Systems (PMCS) information, where the Motorway’s OMCS includes this sub-system - often where a tunnel is involved. Where some plant/equipment event requires or is otherwise associated with a traffic systems response, the plant event must be indicated within the OMCS Incident record and included within the C2C Interface.

This Specification refers to the Motorway’s system as the OMCS, and not the TMCS subsystem / component.

Other operational interfaces essential for the context of the cooperation of the Motorway and RMS, refer Figure TS917.1, are as follows:

(a) Time: A network time synchronisation protocol (NTP) is provided from RMS to the Motorway;

(b) Video: Video, analogue and/or digital CCTV feeds are provided to Operators to and from both RMS and the Motorways. This video interface is external to this Specification;

(c) Telephone: Communications between Operators at the Motorway and RMS includes person-to-person telephone calls. Operations of the C2C Interface are taken to occur in the context of and be supportive of any person-to-person exchange.

Ed 3 / Rev 1 7



RMSMotorway

OMCS

Network Time Server

Network Time Client

Video Server Video Server

Central Management Applications

Traffic Management

Control System

RMS Private Fibre Optic

Network

PSTN

MotorwayField

Equipment

RMSField

Equipment

This C2C Spec

Figure TS917.1 − Interface Context Diagram

2.2 MESSAGING ORIENTATION

The C2C Interface must be viewed as web services connected (or accessed) through message oriented middleware. Messaging middleware is an enterprise integration pattern suited to loosely couple heterogeneous systems.

2.3 MESSAGE PAYLOAD – DATA OBJECT DEFINITIONS

The message definitions and content must be based on Traffic Management Data Dictionary (TMDD) and Message Sets for External Traffic Management Centre Communications standards by ITE/ AASHTO.

The Traffic Management Control System internal data attributes are to be mapped in a configuration exercise with RMS to appropriate TMDD values, refer Clause 3.2. Where no appropriate TMDD standard value exists to match the OMCS’s traffic management methods or attributes (as configured to site or project in accordance with the Motorway’s Concept Of Operations), RMS may extend the dictionary to accommodate any specific OMCS traffic management attributes it requires from the OMCS implementation.

2.4 MESSAGE EXCHANGE PATTERNS

Message protocol exchange patterns must be according to NTCIP 2306, specifically SOAP v1.2.

Message patterns must include:

(a) Message–Acknowledge (asynchronous)

(b) Message–Acknowledge (synchronous)

(c) Request-Response (synchronous)

(d) Publish and Subscribe (asynchronous)

8 Ed 3 / Rev 1



2.5 MESSAGE ACKNOWLEDGE RECEIPT

Where any node receives a message acknowledgement or receipt, this is an indication of receipt only. It is not an indication that the information has been read or acted upon.

Acknowledgements returned from RMS may be either from the RMS ESB (asynchronous transactions), or from the RMS or TfNSW central management node in synchronous transactions.

Synchronous acknowledgements are mandated where a timeout or a returned failure by the receiving node allows the (message) originating node to take some risk mitigating action.

2.6 CONNECTION TECHNOLOGIES

Connections to the RMS messaging system must be made via Web Services as per NTCIP 2306, pp 11, Sub Profile Solution 3.1(a) “SOAP over HTTP”:

“Using SOAP encoded messages over the hypertext transfer protocol (HTTP), centers will be able to describe and deploy center interfaces that support the request-response and subscription-publication message patterns”.

The C2C interface is a set of Web Services defined by WSDLs, passing SOAP messages over HTTP(S) with agreed standardised content based upon the TMDD (refer AASHTO-ITE TM 2.1), ‘packaging together’ messages and responses into near-synchronous transactions.

2.7 SUBSCRIPTION TO AND PRESENTATION OF RMS DATA

You may be informed of External Centre’s controlled devices and traffic management information available for subscription outside of the operation of the messaging system.

(a) Traffic management data made available from External Centres to a participating Motorway node will be subject, to:

(i) The SWTC and relevant OMCS specifications;

(ii) The ITS Context. The relevance to the OMCS traffic management operations of external devices and other traffic and transport Incident management centres;

(iii) Inter-agency agreements;

(iv) Privacy and security legislation;

(b) The Motorway will be able to gain access (or ‘subscribe’) to a message type and/or pertaining to specific devices or location(s) outside of the messaging protocol (eg through email, meetings, etc);

(c) When approved, those types of messages will then be accessible at the Motorway through systems re-configuration

(i) Subscription for Device types and Incidents types, priorities, locations and other filters (refer AASHTO-ITE TM 2.1) are configured between systems by their owners, in accordance with commercial, contractual and web service contracts.

(d) The Motorway will determine how that information is presented to the operator, or otherwise used in its traffic and incident management capacity;

(e) The Motorway will be able to cancel subscriptions (outside of the messaging protocol) when it does not require to see that message type.

Ed 3 / Rev 1 9



2.8 SERVICE ORIENTED ARCHITECTURE

The C2C Interface must provide a number of services, each with a number of discrete operations. These services are outlined in Clause 3 and are defined for implementation in MS-TS-001.

MS-TS-001 takes precedence over any XSD files referenced in the WSDLs. Where there exists any difference in definition between an XSD file and MS-TS-001, MS-TS-001 must be followed. MS-TS-001 applies additional constraints to the XSD.

3 FUNCTIONAL REQUIREMENTS

3.1 OMCS CENTRE ACTIVATION (TRAFFIC SUB CENTRE)

The Activation State of the OMCS must be employed by the end-to-end system for establishing the on-going availability of a node on the network, initialising the interface connection during start-up, notifications of discrete service failures and recovering from channel, network or application outages.

(a) The OMCS must advise RMS that it is active following OMCS system (Message Node) start-up;

(b) System activation will be acknowledged by RMS;

(c) The OMCS must respond to periodic requests from External Centres for confirmation that it is active;

(i) Where the OMCS is running in a ‘degraded mode’ (where one or more services or message classes are disabled or indicating systemic failure), then the OMCS’s specific response to the request for OMCS activation state must be an error indicating that this degraded mode is in effect.

(d) During a network or channel failure event, all the OMCS messages will go un-acknowledged by RMS. During this degraded mode, the OMCS must:

(i) Mark any Incident(s) changes and/or Device(s) status changes (described below) as unsent and pending (to be sent);

(ii) Periodically send OMCS Activation messages that may remain un-acknowledged;

(iii) Periodicity of the OMCS Activation poll must be between 10 and 20 seconds;

(iv) When acknowledged, deem the interface as recovered / available and cease polling;

(v) On recovery, resend the full current status of all incidents created, updated or closed and the current status of devices that have unacknowledged changes during (constituting) the interface failure;

(vi) Incidents that have opened and closed during the failure period are not required to be sent;

(vii) Traffic data does NOT require holding for re-transmittal beyond the initial connection retry;

(viii) Where an error (other than destination unreachable) occurs from Incidents and device operations with multiple frames (many Incidents and devices statuses) within a message, break down those multiples to individual incidents and devices and send separately.

(e) During an RMS application failure event, some OMCS message types will not be acknowledged by RMS. During this degraded mode, the OMCS must:

10 Ed 3 / Rev 1



(i) Continue to send message types for which it continues to receive acknowledgements, and continue to respond to requests that contain any supported message type;

(ii) Mark any unacknowledged Incident(s) changes and/or Device(s) status changes as unsent and pending (to be sent);

(iii) Periodically send OMCS Activation messages that may remain unacknowledged during (constituting) the failure;

(iv) When acknowledged, deem the interface as recovered/available;

(v) On recovery, resend the full current status of all incidents created, updated or closed and the current status of devices that have unacknowledged changes during (constituting) the failure;

(vi) Incidents that have opened and closed during the failure period are not required to be sent;

(vii) Where an error (other than destination unreachable) occurs from incidents and device operations with multiple frames (many incidents and devices statuses) within a message, break down those multiples to individual incidents and devices and send separately.

(f) On interface recovery, RMS may poll the OMCS for status of all devices and/or request a refresh of the full Incident update for open Incidents.

3.2 NEW MOTORWAY INCIDENT AND PLANNED EVENT

(a) The Motorway must send all Incident Data (see Definitions for Incident) to RMS.

(b) You must conduct a TMCS Incident data element mapping exercise with RMS to:

(i) Agree with RMS on which internal TMCS data elements are associated with Incident management and are therefore required to be passed over the interface;

(ii) Relate any vendor specific TMCS Incident data attributes to the TMDD (refer AASHTO-ITE TM 2.1).

(c) Do not send information under the “Incident” data object that relates to the Plant Management System or any general Operations and Maintenance activity that does not have a planned, present or potential bearing on Traffic Operations.

(d) The Motorway must be configured to receive and process an acknowledgement for new Incidents from RMS:

(i) Failure to receive an acknowledge receipt for an Incident message requires the Motorway to mark the i\Incident as undelivered and resend the entire Incident status when the connection is deemed available.

HOLD POINT

Process Held: Sending Incident Data to RMS.

Submission Details: Detailed TMCS Incident data element mapping.

Release of Hold Point: The Nominated Authority will consider the submitted documents prior to authorising the release of the Hold Point.

Ed 3 / Rev 1 11



3.3 UPDATED INCIDENTS

(a) The Motorway must provide updates to RMS of any change or addition to the Incident data:

(i) Updates to Incidents must include the full set of current incident attributes, not only the changed or added value(s).

(b) The Motorway must be configured to receive and process an acknowledgement of Incident Update from RMS.

(i) Failure to receive an acknowledge receipt for an Incident Update message must cause the Motorway to mark the Incident as undelivered and resend the entire incident status when the connection is deemed available.

3.4 INCIDENT CLEARANCE

(a) The Motorway must provide Incident Clearance data to RMS.

(b) The Motorway must be configured to receive and process an acknowledgement of Incident Clearance from RMS.

(i) Failure to receive an acknowledge receipt for an Incident Clearance message must cause the Motorway to mark the incident as undelivered and resend the entire incident status when the connection is deemed available.

3.5 COMPLEMENTARY INCIDENTS

Where a Control Centre chooses to create and manage its own Incident to complement a boundary Incident, the other Control Centre must be able to publish the details of this Complementary Incident referenced to the Motorway’s initial incident.

(a) Other Control Centre’s complementary incidents will be sent to the Motorway;

(b) The Motorway must be configured to receive and process incident messages sent from External Centres to the Motorway, referenced to the original incident. Processing the received incident message must include:

(i) Presenting the supplied incident information to the Motorway’s control room operator in the context of the Motorway’s original incident.

3.6 COMPLEMENTARY MULTI-WAY MESSAGING

Where an External Centre’s operators have comments or questions related to the Incident details published from the Motorway to them, these operators’ “free-text” comments and/or queries will be sent to the Motorway, referenced to the Motorway’s originating incident.

(a) The Motorway must be configured to receive and process free-text messages sent from External Centres to the Motorway, referenced to the Motorway’s original Incident. Processing the free-text message must include:

(i) Presenting the received free-text to the Motorway’s control room operator in the context of the original Incident and of the Motorway’s own free-text entries, if any.

(b) The Motorway must acknowledge receipt of the free-text message. This acknowledgement is a protocol acknowledgement, and is not a “read receipt” indicating that the OMCS has read (or acted upon) the message.

12 Ed 3 / Rev 1



(c) The Motorway must send OMCS operator’s comments related to the initial Incident to RMS unsolicited, or in reply to request messages:

(i) The free-text messages and replies must be presented in order to the Motorway’s control room operator in the context of the original Incident.

(d) The OMCS operator’s comments must follow the same pattern as incident messages in grouping of multiple comments and in failure and recovery.

The free-text message may be for information only of the Motorway to provide network contextual information and enhance Incident management through situational awareness. The free-text may be further broadcast or multicast to multiple Motorways and traffic organisations.

The free-text message may prompt the Motorway to make an adjustment to the incident management, or make a new free-text entry into the Incident record in response to a direct query for more information. Any adjustments to incident management or free-text entries made against the Motorway’s Incident are subject to being communicated back to RMS in accordance with Clause 3.3.

3.7 BOUNDARY INCIDENT

Where an External Centre creates an Incident located within the “boundary of interest” of the Motorway, or a distant Incident has a high impact including the established boundary region, that type of Incident can be made available to the Motorway:

(a) As part of the system development process, you must conduct a Concept Of Operations exercise with RMS support to establish and agree the “boundary roads” of the Motorway;

(b) Once configured, External Centre Incidents that occur within the established boundary will be sent to the Motorway:

(c) The Motorway must be configured to receive and process boundary Incident messages sent from External Centres. Processing the boundary Incident message must include:

(i) Presenting the Incident information to the Motorway’s control room operator in the context of the Motorway’s operations;

(ii) Where available, displaying the location of the Incident graphically on a map.

(d) The Motorway must respond with an acknowledgement of the Incident Update to the creator of the Incident.

HOLD POINT

Process Held: Establishing boundary roads of the Motorway.

Submission Details: Concept of Operations.


3.8 BOUNDARY MULTI-WAY MESSAGING

Where an External Centre’s operator has comments related to the incident on the boundary of the Motorway, these operator’s “free-text” comments and/or queries will be sent to the Motorway, referenced to the originating “boundary Incident”.

Ed 3 / Rev 1 13



(a) The Motorway must be configured to receive and process free-text messages sent from External Centres referenced to the original Incident. Processing the free-text message must include:

(i) Presenting the free-text to the Motorway’s control room operator in the context of the Motorway operations, referenced to the boundary Incident where known, and in context of the Motorway’s own free-text entries, if any.

(b) The Motorway must acknowledge receipt of the “boundary Incident” free-text. This acknowledgement is a protocol handshake, not a “read receipt” (A read receipt would indicate that the OMCS has read (or acted upon) the free-text message).

(c) The Motorway must respond to this message referencing the originating Incident.

(d) Where the Motorway has received a Boundary Incident from an External Centre, the Motorway must be configured to send an unsolicited message referencing the originating Incident.

The free-text may be for information only to provide network contextual information to the OMCS operator for their Incident management.

The free-text may be broadcast or multicast to multiple Motorways and traffic organisations where they consider the originating Incident’s location to be within their boundary roads.

3.9 INCIDENT POLLING

(a) The Motorway must be configured to receive and process unsolicited requests for open Incidents from External Centres.

(b) The Motorway must return the full status of all current open Incidents.

(c) The Motorway must be able to poll the status of an active incident that it has received from an External Centre. The polling mechanism can be triggered by the operator through the OMCS’s HMI.

3.10 MOTORWAY DEVICE STATUS

(a) The Motorway must send all ITS device settings, status and changes to RMS.

(b) Device settings and status must only be sent to RMS when the setting or status of the device changes or in accordance with Section 3.1 during a network or channel failure event .

(c) Device data must include the attributes relevant for the operation of each specific ITS device type in use, and:

(i) the Incident Identifier of the Incident to which the setting change is addressed, if any;

(ii) the Traffic Management Plan Identifier with which the setting change is associated, if any.

(d) When the field device is not detected by the OMCS, then the Device Status sent to RMS must indicate that the device is unobtainable.

(e) The Motorway must distinguish between devices being obtainable or unobtainable (communication to the device has failed, including OMCS internal faults and communications channel failures).

14 Ed 3 / Rev 1



(f) The Motorway must be configured to receive and process an acknowledgement of the Device Status settings and changes from RMS.

(i) Failure to receive an acknowledge receipt for a Device message requires the Motorway to mark the device status as undelivered and send the current device status when the connection is deemed available.

3.11 MOTORWAY DEVICE FAULT

The Motorway must provide to RMS the Device Fault data that defines the readiness for use of all Motorway devices known to RMS. Fault data can include confirmed and suspected faults.

(a) The Motorway must send all device faults to RMS;

(b) When the device is obtainable, Device Fault details must be in accordance with TSI-SP-003, where that protocol is in use to communicate with field devices;

(c) Where an alternative protocol to TSI-SP-003 is in use to field devices (such as PLCs as distinct from VMS), supply comparable devices fault details;

(d) Categorise device faults as a minimum into:

(i) Out of Service (Disabled);

(ii) Critical Fault (Non-operational);

(iii) Minor Fault (Operational);

(e) Filter transient device faults that arise and clear within 2 (two) seconds and suppress them from being passed to the interface.

3.12 RMS DEVICE ACCESS

The Motorway can subscribe (request outside of the messaging protocol) for access to see the status and setting of an RMS “boundary device”. Where agreed:

(a) RMS device status and setting changes will then be sent to the Motorway;

(b) The Motorway will be able to cancel (outside of the messaging protocol) the subscription to the RMS device when it no longer wants to receive the device status.

3.13 ADJACENT MOTORWAY DEVICE ACCESS

The Motorway can request (outside of the messaging protocol) an adjacent Motorway for subscription to an adjacent Motorway (boundary) device status and settings. Where agreed:

(a) Device status and setting changes will then be sent to the Motorway;

(b) Device status messages published as a result of that subscription will not require an acknowledgement to the adjacent Motorway;

(c) The Motorway will be able to cancel (outside of the messaging protocol) the subscription to the adjacent Motorway device when it no longer wants to receive the device status.

3.14 DEVICE POLLING

(a) The Motorway must be configured to receive and process an unsolicited request for device settings and status from an External Centre.

Ed 3 / Rev 1 15



(b) Requests for device settings from an External Centre will be in the form of a list of devices (minimum of one device).

(c) The Motorway must return the current device settings and status (including faults if applicable) of the requested device(s).

(d) The Motorway must be able to poll the status of any devices that it has subscribed to from External Centres. The polling mechanism can be triggered by the operator through the OMCS’s HMI.

3.15 OVER HEIGHT SENSORS

The Motorway must send Over Height sensor data to RMS, including:

(a) Trigger time;

(b) Activation state;

(c) Associated DMS identifier(s);

(d) Associated DMS warning activation Message and time;

(e) Associated DMS warning reset time.

3.16 RAMP METERING

Where Ramp Metering is implemented by the OMCS, the Motorway must send Ramp Metering data through to RMS, including:

(a) Ramp operating mode;

(b) Ramp sensor data;

(c) Traffic data parameters within the OMCS specification.

3.17 MOVABLE MEDIANS

(a) The Motorway must send Movable median status and fault data to RMS.

(b) Receipt of Movable median status messages will be acknowledged by RMS.

3.18 BARRIERS AND BOOM GATES

(a) The Motorway must send Barriers and Boom gate status and fault data through to RMS.

(b) Receipt of Barriers and Boom gate status data will be acknowledged by RMS.

3.19 WEATHER STATIONS

(a) The Motorway must send weather data from Weather Stations to RMS.

(b) Provide dynamic weather parameters (wind speed, temperature, etc):

(i) on breach of threshold set points;

(ii) every 5 minutes.

16 Ed 3 / Rev 1



(c) Include the weather station threshold set points with the message of threshold breach.

3.20 DEVICE CONTROL

This Clause specifies the capability requirements for the OMCS’s devices to be controlled by External Centres and for the OMCS to control External Centre’s devices. Each centre can act both as an Owner or an External Centre depending on the scenario and both capabilities are required.

It is assumed that the Owner Centre’s application employs “virtual queues” or “stacks” of messages that are placed in priority order and queued to go up onto the physical sign device.

An interleaved priority system as that provided in the OMCS Specification ensures the Owner Centre is always able to assert control over its own signs where an External Centre has events or messages of the same priority:

(a) External Centres must be able to set the display on all message or advisory signs on Owner Centres including, but not restricted to:

(i) Variable Message Signs;

(ii) Variable Speed Limit Signs;

(iii) Tunnel Message Signs;

(iv) Lane Usage Signs;

(v) Integrated Speed and Lane Use Sign;

(vi) Advisory Travel Times Signs (ATTS includes congestion indicator).

In general, External Centres will access only VMS, VSLS and ISLUS for network traffic management;

(b) Tunnel management devices control must be disabled unless only agreed by the Concept of Operations workshop;

(c) External Centres must be allowed access to control Owner Centres Message Signs using a priority schema;

(d) The VMS is controlled by the TMCS and external RMS System via the C2C interface using the VMS message priorities. The priority of different types of messages displayed on the VMS is specified by the VMS Message Priority Table defined below:

C2C

Priority VMS Message Purpose Reserved for Notes

1 Local area incident messages Unplanned incidents and active planned incidents within the owner centre's management area.

Owner centre

The owner centre always has the ability to take control of the sign using this highest priority.

Ed 3 / Rev 1 17



2 Adjacent area incident messages Unplanned incidents and active planned events within an adjacent external centre's management area, where the incident is impacting, or is expected to impact on, roads managed by the owner centre.

External centre

The adjacent external centre would use selected VMS controlled by the owner centre near their shared boundary. TMC is considered an external centre when TMC is directly managing the roads in the adjacent management area.

3 Wide area incident messages Major unplanned incidents or major active planned events, outside the owner centre management area, that have widespread impact on the road network. Public safety messages: - Amber alerts (abducted child)

TMC If the adjacent external centre does not have the ability to request "adjacent incident messages" (P2) then TMC would do so on their behalf, at this priority.

4 Local area warnings (non-incident) Warning/caution messages. Potential or actual hazards in the owner centre's management area. e.g. - Animals on road - Water on road - Severe weather warning (rain, fog, ice, wind) - Bushfire/smoke Nightly sign blanking (for safety reasons)

Owner centre

Warning/caution messages are used for current road conditions that pose an immediate potential or actual hazard to road users, but which are not significantly affecting traffic.

5 Adjacent area warnings (non-incident) Warning/caution messages. Potential or actual hazards within an adjacent external centre's management area, where the incident is impacting, or is expected to impact on, roads managed by the owner centre.. e.g. - Animals on road - Water on road - Severe weather warning (rain, fog, ice, wind) - Bushfire/smoke

External centre

The adjacent external centre would use selected VMS controlled by the owner centre near their shared boundary. TMC is considered an external centre when TMC is directly managing the roads in the adjacent management area.

6 Travel time, with interleaving TTPS Includes interleaving with a single frame lower priority message.

18 Ed 3 / Rev 1



7 Local area notification and safety messages Advance notification messages of future events that concern the traffic within the owner centre's management area. e.g. - Toll increase notices (single frame) - Future roadwork. - Future maintenance. - Future planned events. - Other future road occupancies. Targeted behavioural/safety messages: - Cover your load - Don't use mobile phone, etc

Owner centre

There is no adjacent area version of this. But, given that this is for planned events any messaging about planned events in adjacent management areas can be managed by the owner centre using a complimentary incident. Targeted behavioural/safety messages are a response to very recently observed road user behaviour, with the intent of reducing the number of incidents on the motorway.

8 Wide area advance notifications messages Advance notification messages for future planned events outside the owner centre's management area that will have widespread impact on the road network. e.g. Sydney Harbour Bridge closure.

TMC

9 Local area background messages - Generic motorway messages

Owner centre

10 Generic background messages - General campaign messages

TMC

(e) The Owner Centre must be configured to receive and process requests to display a message from an External Centre.

(f) Processing the request message must include:

(i) Checking that the device is:

(A) obtainable (responds to communication requests);

(B) in service (available for automation);

(C) has no critical fault (that renders it unavailable for use);

(ii) Responding to the request with an appropriate failure message where the device is:

(A) Unobtainable;

(B) out of service;

(C) has a critical fault;

(D) otherwise rendered unavailable for External remote control;

(iii) Checking the device queue (any messages or settings waiting in line to go up onto the sign) for current messages and their priority;

Ed 3 / Rev 1 19



(iv) Checking the request message priority against the messages and priorities in the device queue;

(v) Where the request message has a higher priority message than the current setting or any setting in the device queue,

(A) Displaying that request message on the device;

(B) Responding back to the request with the new device setting status as per Clause 3.10, referenced to the setting message;

(vi) Where the request message priority does not have the highest priority:

(A) Inserting the request message into the device queue;

(B) Responding back to the request with an appropriate message, such as “Requested Setting Placed in Device Queue”;

(vii) When a request for control placed in the device queue reaches the top of the device queue (all higher priority message have been cleared) the Owner Centre must:

(A) Advise it’s operator of remote control by the External Centre;

(B) Display that requested message on the device;

(C) Respond back to the request with the new device setting status as per Clause 3.10, referenced to the setting message;

(viii) When an External Centre’s request for control is placed in the device queue, and that new request matches a request already in the queue (request identifier, priority value and requesting organisation), the previous request must be replaced with the new request and the new request must then be processed as if it was the latest request at that priority level.

(g) The Owner Centre must be configured to receive and process cancellation of a previous request to display a message:

(i) Processing the cancellation message must include removing the setting from the device or from the device queue as necessary.

(h) Cancellation Messages must be acknowledged by the Owner Centre after the setting is removed from the device or device queue.

(i) The Owner Centre must be configured to receive and process requests to view the contents of the device queue:

(i) Processing the device queue request must include returning the full contents of the device queue to the requesting Control Centre, including the message content at each Control Centre priority level.

(j) The Owner Centre will cancel any device control request, where that request contains an explicit command end time, when that end time is older than the current system time. This check for expired messages will be performed at least every one minute;

(k) The External Centre must be capable of sending device control requests to other Control Centres devices, where an agreement is in place (outside of this messaging protocol) for that control to take place.

3.21 MOTORWAY TRAFFIC DATA (SENSOR)

(a) The Motorway must send traffic data from Traffic Monitoring Sites to RMS.

(b) Data from each Monitoring Site’s individual sensor must be aggregated for configurable time intervals.

20 Ed 3 / Rev 1



(c) Configurable time intervals must include:

(i) 30 seconds;

(ii) 3 minutes.

(d) The default setting for Traffic Monitoring Site data aggregation is 30 seconds;

(e) Where employed, the 3 minute aggregate data from all Traffic Monitoring Sites must be:

(i) synchronised to start at the ‘top’ of the minute (ie samples at mm:ss 00:00, 03:00, 06:00 etc);

(ii) sent to RMS within 30 seconds of the end of the period to which the data pertains ie by 00:30, 03:30, 06:30 etc).

(f) Traffic Data must include:

(i) Detector Identifier;

(ii) Lane Number;

(iii) Direction;

(iv) Speed;

(v) Occupancy;

(vi) Vehicle Volumes (Flow):

(A) Total (sum of short, medium, long);

(B) Short;

(C) Medium;

(D) Long;

(vii) Aggregation period of the sample (ie 30 seconds/3 min);

(viii) The Suspect Flag (poor data quality) will be set on an aggregate sample when:

(A) The Traffic Monitoring Site is out of service;

(B) The Traffic Monitoring Site displays a fault that may affect traffic counting;

(C) The aggregation algorithm detects any failure to correctly acquire the requisite number of samples per period;

(D) Anomalies in data acquisition or processing render the calculation suspect.

(ix) The Motorway must send detector station fault data to RMS as per Clause 3.11.

3.22 TRAVEL TIME

The Travel Time Route Definitions must be supplied by the Motorway in flat file format at least 6 months in advance of the systems integration test. Interface messages containing a bulk transfer of the route definitions must be employed.

(a) The Motorway must send travel time date to RMS including;

(i) Route Definition ID;

(ii) Calculation time (Synchronised by NTP);

(iii) Route time;

Ed 3 / Rev 1 21



(iv) Congestion level;

(v) Confidence level;

(b) The Motorway must send:

(i) travel time data every 3 minutes; The travel time cycle must be synchronised to start on the hour;

(ii) travel times to RMS within one minute of the end of the period to which the data pertains.

3.23 INVENTORY

HOLD POINT

Process Held: System integration test.

Submission Details: Complete TMCS Device Inventory (in flat file), at least six (6) months before the systems integration test (refer Clause 5.5).


Subsequently during operations:

(a) An External Centre will send a message to OMCS requesting details of the ITS equipment configured in the OMCS;

(b) The OMCS must reply with a versioned inventory of devices;

(c) Discrete inventory requests will be separate based on device type (refer AASHTO-ITE TM 2.1):

(i) DMS

(ii) LCS

(iii) Detectors

(iv) OHD

4 NON-FUNCTIONAL REQUIREMENTS

4.1 TRANSPORT

(a) The Motorway’s Message Client must present to the participating nodes connections that provides compliance with Section 5.1 of NTCIP 2306.

(b) The Motorway must provide all communications hardware from the OMCS to the RMS external network.

(c) The Motorway must configure all communications hardware from the OMCS to the RMS external network to allow the transmission of messages between the Motorways OMCS environments and RMS.

22 Ed 3 / Rev 1



(d) The Motorway must present its C2C interface endpoints at a single fixed IP address to network. All messages sent to and from the Motorway must be sent via this address. Any failover/redundancy, clustering or load-balancing implemented on the Motorway’s infrastructure must be transparent to other nodes on the network.

4.2 MESSAGE FORMATION AND PARSING

HOLD POINT

Process Held: Validating Message Formation and Parsing.

Submission Details: Software Requirements Specification (SRS), Software Interface Description defining implementation as per MS-TS-001(refer Clause 2.8).


(a) The Motorway must ensure that the message construction is “well formed” XML prior to submitting any Message for transmission;

(b) On receipt and identification of any incorrectly formed message, the Motorway must:

(i) send a reject message to the initiating system in response identifying the error as ‘Not well-formed message’;

(ii) log the failure event to the system logs.

4.3 SCHEMA VALIDATION

HOLD POINT

Process Held: Validating XML schema.

Submission Details: Detailed TMCS data element mapping.


The XML schema in use must be agreed between RMS and the Motorway in accordance with the incident data elements mappings exercise (required under Clause 3.2).

(a) The Motorway must ensure that the XML Schema in use by the OMCS for message construction is “validated” in agreement with RMS. Applications receiving C2C messages must not implement schema validation on the received messages;

(b) When receiving a C2C message the application processing the body of that message must not stop processing well-formed XML content, or signal an error, when either:

(i) An element contains an enumerated value that the application does not understand. The application must use either a default value or treat the element value as undefined.

(ii) The message contains elements that the application does not understand. Elements that the application does not understand must be ignored and the application must signal a warning.

Ed 3 / Rev 1 23



Invalid XML messages are rejected by the RMS ESB with corresponding data validity error-code.

4.4 SECURITY

(a) The interface node equipment must share an IP network DMZ with other government and private organisations, so that the C2C interface and OMCS system provide security to exclude unauthorised access commensurate with that environment.

(b) The Motorway must provide a secure means for OMCS Users and Systems to connect and authenticate to the system, including specific permissions per users for access to ITS devices.

(c) The OMCS must be segregated from:

(i) the Motorway’s corporate or business computing network;

(ii) the World Wide Web.

(d) Do not hard-code USERNAME and PASSWORD anywhere within the system.

(e) Provide a System User account to RMS for security authorisation.

(f) Encryption and replay protection is provided by Transport Layer Security offered at RMS endpoints as:

(i) SSL Version 3; or

(ii) TLS.

(g) For Device Control Services, authentication must be via X509 Binary Security Token in accordance with (Oasis 200401 and RMS A3410742).

(h) Authentication for services other than Device Control must be via WS-Security Username Token in accordance with (Oasis 200401 and RMS A3410742).

4.5 INTERFACE COMPUTING RESOURCES

(a) Scale computing resources for processing the message volumes and frequencies as per the functional requirements of the OMCS and the C2C Interface.

(b) Data processing of C2C background tasks such as traffic data aggregation, travel time calculations and system reporting must not detract from the real time performance of the OMCS functionality.

4.6 TIME SOURCE

(a) Synchronise the OMCS to a Network time server using NTP:

(i) RMS will provide an NTP source within the RMS network available for use by the OMCS.

(b) The Motorway must time stamp all messages.

(c) Synchronise timestamps to the Network Time Server.

(d) All inter-system communications must use UTC. This includes all DateTime types in C2C messages.

24 Ed 3 / Rev 1



4.7 NON INVASIVENESS

(a) The operation of the C2C Interface must not place undue burden on the OMCS operator to the detriment of their traffic management duties.

(b) The operator must be alerted (via system alarms, alerts or notifications) when communications to other Control Centres are entering or leaving “degraded mode operations”.

(c) The Motorway must suppress ongoing or individual message failures from being passed to the operator where degraded mode operation for that message class is current.

4.8 OMCS MESSAGE PROCESSING TIMES

RMS and OMCS are each running ‘near real time’ control systems often with some safety related functions where the systems interact with the road network and the operators in a timely manner. Apply measures to ensure system performance response times are met.

Commit times are the time between the OMCS internally detecting or generating an event (an incident or change of device setting etc) generating the required message, and committing that message to the C2C service end-point for publishing.

Receipt times are taken as the time between the message from other nodes being available at the web services end-point, and the OMCS sending a receipt/acknowledge for that messages.

These times must be as follows:

(a) Commit times must be less than one second;

(b) Receipt times must be less than one second.

Test the commit and receipt message processing times and measure them under normal operating conditions for the OMCS system.

4.9 ACKNOWLEDGE PROCESSING TIMES

(a) Where an acknowledge is required from another Control Centre for a message, the OMCS must expect that acknowledge within five seconds:

(i) Where no acknowledgement for incident or device messages is received within five seconds, or where an error is returned, the OMCS must retry before deeming the interface unavailable.

(b) The OMCS must retry failed messages within 60 seconds, at intervals > five seconds.

(c) Where channel failure is current, the OMCS must suppress or otherwise manage any acknowledge processing errors to avoid ongoing distracting alarms to the operator, while invoking the Center Active polling as per Clause 3.1(d).

4.10 RELIABILITY AND AVAILABILITY

The interface system availability is defined for interface functionality as delivered by hardware and software. This includes software applications connecting to the interface (the OMCS internal communications tasks), Motorway’s Client Node Application software, and any hardware on which it runs, but excludes communications channel (optic fibre network) failure between participating entities

Ed 3 / Rev 1 25



(channel failure is covered by a separate Service Level Availability agreement). In any event, the interface must continue to operate in a “degraded mode” during failure of the communications channel.

(a) The Interface Node must provide a high degree of availability, as the service can carry mission critical network information;

(b) Any interface specific hardware must have an MTBF figure of 46900 hours or greater;

(c) Any interface specific hardware must have an MTTR figure of 4 hours or less;

(d) The availability of all Motorway’s node interface functions must be greater than 99.95% when calculated as follows:

Availability = (MTBF - MTTR) / MTBF, where:

MTBF = Mean Time Between Failures;

MTTR = Mean Time to Repair.

(e) The calculated availability must include both planned and unplanned outages;

(f) For the purpose of this Clause, the Mean Time To Repair must include all time between system or device failure and the successful return to service of the affected device(s), including any mobilisation of repair crews and spares.

4.11 SERVICE PRIORITY

The OMCS may process messages or services either decoupled with no inter-independence, or otherwise in priority order of:

(a) Incident (new, update, clearance);

(b) Device change/state;

(c) Device remote control;

(d) Device fault;

(e) Traffic;

(f) Environmental (Weather);

(g) Inventory;

(h) Configuration (New/Changed Device).

4.12 INTERFACE MANAGEMENT, DIAGNOSTICS AND LOGS

(a) The OMCS must identify and log when the communications channel and/or discrete single services to RMS have failed and subsequently again on recovery.

(b) The OMCS operator must be alerted on interface failure and recovery to be aware of the connection state between OMCS and other nodes.

(c) The OMCS must provide transaction logs of interactions with RMS, including system diagnostics and error messages for test, commission, diagnostics and audit trail purposes.

(d) The OMCS must be capable of being configured to log the xml content of any SOAP messages sent or received, including the headers, in an unencrypted human readable format without causing any interruption to C2C services. This can be implemented as a dynamic configuration or as a runtime configurable option.

26 Ed 3 / Rev 1



(e) Logs must be stored for a minimum of 3 months before archiving.

(f) The OMCS must provide diagnostics information on resource utilisation to monitor the capability of the system to meet the requirements for timely delivery.

(g) Error messages logged on failures must be context specific and sufficiently meaningful to allow ease of diagnosis of the error.

4.13 PERSISTENCE

The Motorway Node configuration settings, message caches and logs must be persistent over failure and restart of the OMCS.

5 INSTALLATION AND COMMISSIONING

5.1 DEVELOPMENT ENVIRONMENT

(a) Test the Motorway node initially as a sub-system to the Enterprise Service Bus without connection through to any other participating node (RMS or other Motorways), using a test harness (to be provided by RMS) on the Enterprise Service Bus (ESB).

(b) Add messages to the Interface and verify reply from the Test Harness locally (within the Motorway node).

(c) Include in the Motorway’s development testing as a minimum verification of;

(i) time synchronisation;

(ii) time performance;

(iii) all one way (no acknowledgement) messages from all inventory devices;

(iv) Messages expecting an acknowledge eg Incidents (but not being provided one during this test stage);

(v) OMCS – interface transaction logs;

(vi) Intra-node failure and recovery.

5.2 FACTORY ACCEPTANCE TESTING (FAT)

(a) Submit test procedures prior to commencing testing.

HOLD POINT

Process Held: Factory Acceptance Testing (FAT).

Submission Details: Test Plans and Test Cases.


(b) Carry out the Interface Factory Acceptance Testing to:

Ed 3 / Rev 1 27



(i) ensure that initial deployment to the live site does not adversely impact live operations;

(ii) demonstrate all functionality to the extent possible within an off-site environment;

(iii) submit test results at the conclusion of FATs.

(c) Carry out point to point testing with the RMS ESB SIT environment using a test harness (provided by RMS) on the ESB.

HOLD POINT

Process Held: Commencement of installation of the Interface on site.

Submission Details: Records of FAT verifying that the Interface has been integrated with the RMS ESB.


5.3 INSTALLATION

(a) Install and integrate the Interface with the live site initially in a development environment isolated from the live production environment.

(b) Apply measures to ensure that initial deployment to the live site does not adversely impact live operations.

(c) Connectivity shakedown testing between OMCS and RMS must be completed prior to the scheduling of the live deployment. This testing must include verification of the correct installation of all security certificates and endpoint configurations.

5.4 FUTURE DEVICES AND SYSTEMS

Where the staged deployment of the various ITS site devices and systems renders some systems not available for verification of the Interface functional requirements, a Site Acceptance Test or Type Test with simulated devices or sub-systems will be acceptable.

5.5 SYSTEMS INTEGRATION TEST (SIT)

HOLD POINT

Process Held: System Integration Test (SIT).

Submission Details: Test Plans, Test Cases.


(a) Carry out Systems Integration testing between the Motorway and RMS’ nominated Systems Integrator.

28 Ed 3 / Rev 1



(b) Testing must verify end-to-end operation of all message flows to and from all Motorway’s devices between the Motorway’s and RMS’s respective operator-user interfaces.

(c) Inspect, demonstrate or verify all functional and non-functional requirements.

(d) Subscription messages to simulated RMS Incidents and Devices may only be available at this time through a test harness (provided by RMS).

5.6 USER ACCEPTANCE TEST (UAT)

HOLD POINT

Process Held: User Acceptance Test (UAT).

Submission Details: Test Plans, Test Cases.


(a) Demonstrate testing of functionality to end users (operators) before entering the system into service and entering the warranty period.

(b) Tested Functionality must be geared towards end user-interactions and end user-scenarios.

(c) Tested Functionality must be sample based, with all types of messages being tested to and from select devices.

(d) Tested Functionality must include all relevant message types to and from all other nodes with which the Motorway will communicate via the C2C interface in the course of its operations.

(e) Subscription messages to simulated RMS Incidents and Devices may only be available at this time through a test harness (provided by RMS).

5.7 PRODUCTION SHAKEDOWN TEST (PST)

(a) Carry out connectivity testing between the Motorway’s Production OMCS and RMS Production ESB.

(b) Testing must confirm successful transmission of all Security Profile message types to be used between RMS and the Motorway’s OMCS in both directions.

(c) Testing must confirm receipt of expected response messages to all of the messages transmitted in Clause 5.7(b)

Ed 3 / Rev 1 29



5.8 PRODUCTION VERIFICATION TEST (PVT)

HOLD POINT

Process Held: Production Verification Testing.

Submission Details: Records of SIT as per Clause 5.5, UAT as demonstrated to end users as per Clause 5.6 and PST as per Clause 5.7.


(a) Carry out PVT testing between the Motorway’s Production OMCS and all other C2C nodes with which it is required to communicate.

(b) Verify that all required C2C services are operational between the OMCS and all other C2C nodes by using realistic operational scenarios.

(c) Visually verify that devices on the motorway are set as expected and the status updates accordingly when controlled via the C2C Interface.

HOLD POINT

Process Held: Entering the system into service.

Submission Details: Records of PVT as per Clause 5.8.


6 OPERATIONS AND MAINTENANCE

6.1 MAINTAINABILITY AND SUPPORT REQUIREMENTS

(a) Provide maintenance, service and support agreements covering the Interface (hardware and software) to enable the MTBF and MTTR figures specified.

(b) Include in the support agreement:

(i) front-line telephone technical support;

(ii) secure remote-access service;

(iii) holding of any essential hardware spares, software installation disks and any relevant procedures.

(c) Where possible, the system must comprise openly available hardware and software that can be readily procured from specifications without requiring any special dispensation.

(d) Submit exceptions to this to RMS for acceptance before proceeding with equipment supply.

(e) Procure systems components from established vendors with certainty of on-going supply.

30 Ed 3 / Rev 1



6.2 SERVICE CONTRACTS

Provide documentation in terms of “Service Contracts” to describe the software contract and access mechanisms of the service.

Develop and maintain these service contract documents throughout the course of the systems integration (of the Motorway’s node to the RMS ESB) and in sufficient detail to support planning, design, testing and migration from development and test environments to production and Business-As-Usual support.

The Service Contracts must be completed for each C2C web service implemented.

RMS will provide the RMS service contract template and the equivalent (symmetric) RMS service contract document(s).

HOLD POINT

Process Held: Entering the system into service.

Submission Details: Service Contracts.


6.3 OPERATIONS AND MAINTENANCE MANUAL REQUIREMENTS

(a) Supply all User Documentation pertaining to the functions delivered.

(b) All User Documentation must give clear, concise instructions including HMI screen-shots where applicable.

(c) Systems User Documentation must instruct the Systems User on how to configure the Interface to provide the specified functional requirements for each Motorway connection.

(d) Operator User Documentation must instruct the Control Room Operator/User on how to navigate to and operate the specified functional requirements.

(e) Maintenance User documentation must instruct the maintainer on the steps necessary to assure on-going operation.

6.4 TRAINING REQUIREMENTS

Training courses or training notes must be offered to accompany the Interface User Documentation.

Ed 3 / Rev 1 31



ANNEXURES TS917/A TO TS917/B – (NOT USED)

ANNEXURE TS917/C – SCHEDULES OF HOLD POINTS AND IDENTIFIED RECORDS

Refer to Clause 1.3.3.

C1 SCHEDULE OF HOLD POINTS

Clause Description

3.2 TMCS Incident data element mapping

3.7 Concept of Operations

3.23 Complete TMCS Device Inventory

4.2 Software Requirements Specification (SRS), Software Interface Description

4.3 TMCS data element mapping

5.2 FAT Test Plans and Test Cases

5.2 Records of FAT

5.5 SIT Test Plans and Test Cases

5.6 UAT Test Plans and Test Cases

5.8 Records of SIT, UAT and PST

5.8 Records of PVT

6.2 Service Contracts

C2 SCHEDULE OF IDENTIFIED RECORDS

The records listed below are Identified Records for the purposes of RMS D&C Q6 Annexure Q/E.

Clause Description of Identified Record

3.2 TMCS data element mapping

3.23 Configuration Information relating to Motorway/Tunnel to be provided to RMS identifying: • traffic sensor sections • device coordinates

4.2 Software Requirements Specification (SRS)

4.2 Software Interface Description

5.1, 5.5, 5.6, 5.7 Tests Plans and Test Cases

5.1, 5.6, 5.7, 5.8 Records of tests

32 Ed 3 / Rev 1



Clause Description of Identified Record

6.2 Service Contract for each C2C web service implemented and Operational Support Management

ANNEXURES TS917/D TO TS917/L – (NOT USED)

Ed 3 / Rev 1 33



ANNEXURE TS917/M – REFERENCED DOCUMENTS Refer to Clause 1.3.6.

RMS Specifications

RMS D&C Q6 Quality Management System (Type 6)

RMS D&C TS901 OMCS Overview and General Requirements

RMS D&C TS911 OMCS Requirements - Motorway Control Centre

RMS D&C TS912 OMCS Requirements - Traffic Management and Control System

RMS D&C TS913 OMCS Requirements - Plant Management and Control System

RMS D&C TS914 OMCS Requirements - Electrical Power Supply and Distribution

RMS D&C TS915 OMCS Requirements - Motorway Network Communications System

RMS D&C TS916 OMCS Requirements - Electronic Toll Collection System

RMS D&C TS918 OMCS Requirements - Road Tunnel and Underpass Lighting

MS-TS-001 C2C Interface Design Document, Version 1.0, October 2013

TSI-SP-003 Communications protocol For Roadside Devices, Version 2.1, June 2008

RMS Publications

A3410742 Security implementation guide, Version 1.1, April 2016

Other Documents

FHWA-HOP-06-112 US Dot − Regional ITS Architecture Guidance, Version 2.0, July 2006

ISO 24097-1 ITS - Using web services for ITS service delivery — Part 1: Realization of interoperable web services, Version 1.0, Sep 2009

AASHTO-ITE TM 2.1 Standards for Traffic Management Center-to-Center Communications, Version 3.0, November 2008

NTCIP 2306 NTCIP − Application Profile for XML Message encoding and Transport in ITS Center-to-Center Communications, Version 1.0, Dec 2008.

NTCIP 9001 NTCIP − The NTCIP Guide, Version 04, July 2009

NTCIP 9010 NTCIP − XML in ITS Center-to-Center Communications, Verion 01, Nov 2004

Oasis 200401 Oasis – WS-Security, Version 1.0, 2004

SOAP 1.2 W3C − Simple Object Access Protocol (SOAP), Version 1.2, June 2003

TS003.002 UTMC − Framework Technical Specification, 2008

WSDL 1.1 W3C − Web Services Description Language (WSDL), Version 1.1, Mar 2001

XML 1.0 W3C − Extensible Markup Language (XML), Version 1.0, Feb 2004

34 Ed 3 / Rev 1