ITS Standards User Group to fast-tracks process
Introduction
At a recent ITS SA members meeting, the importance of national standards was discussed. It
was agreed that in the light of the current lack of standards (and the seemingly lack of an
inclusive and sustainable process to formally adopt such standards) it would be desirable for
some of the major government organisations actively involved in planning, procuring and
implementing ITS projects to “informally” agree on various relevant standards.
To this end, ITS South Africa will call together a ITS Standards User Group.
This document sets out the benefits and proposed process to informally agree on these
standards.
Benefits of National Standards
The following are some of the benefits of adopting a set of national standards for ITS:








Interoperability – a national standard would enable interoperability of devices within a
network of systems. Examples of this are:
o The EMV Smartcard that has been specified by the National Department of
Transport as the standard to be adopted as the fare payment method for Public
Transport within South Africa. The Smartcards issued from various banks and
Municipality’s should be interoperable on other EMV Compliant system
throughout the country.
o SANRAL’s Freeway management system that intersects major city freeway
management systems.
o Future communications between vehicle–to–vehicle and vehicle–to–
infrastructure will require common standards.
Data Structures are common to allow for comparisons and benchmarking to be conducted
nationally and internationally.
Training can be standardised and shared with other cities. Training institutions will have
access to a broader market base for the training.
Creates access to a broader base of skills across the country.
Development and implementation costs should be lower by adopting a national standard
however this must align to an international standard or else products will need to be
customised, which pushes costs up.
Ease of integration of previously disparate ITS modules - e.g. traffic signals, Freeway
Management, APTMS.
Improves procurement efficiencies, particularly within Government, as there can be no
challenges regarding the technical specifications if they are based on a national standard.
Allows for redundancy and a reduced need for duplication, for example SANRAL could be
utilised as a backup for the various Metro’s TMCs and vice versa.


Sharing work and innovation among Government Department.
Promotes fair competition and an open market if aligned to a well-known international
standard.
Process
The following process is proposed. It is desirable for this process to be as quick and costeffective as possible.

As agreed at an ITS SA members meeting on 5 February 2015, the ETA has already appoint
a team of ITS consultants to identify DRAFT appropriate standards for relevant areas.
Importantly, these appoints need to be:
o A “quick fix” – i.e. alignment with international standards or building on what is
already in place and not a complete redevelopment of standards’
o Budgets to be kept to a minimum

Initial meeting in late October or early November 2015 is required with:
o SANRAL
o 4 to 5 Large Metros
o Chair of SABS/TC204
The objective of the meeting will be to:
 confirm the process outlined in this document,
 confirm the need to “informally” adopt some standards that will give each
organization some direction
 The draft report will be presented which proposes standards for select ITS
areas
 Agree on standards, or propose amendments, or propose areas for
further research

If timeframes allow, the draft proposal will be circulated to all parties for review before
the above mentioned meeting.

A final meeting to table amendments in early 2016. If there is a large degree of consensus
at the 2015 meeting, it may not be necessary to meet again. Rather, the standards can be
circulated for comment and adoption.
Sectors in which Adoption of Standards should be Prioritised
ROADS
Traffic Signals
Freeway and Arterial Management
CCTV – Traffic Management and Urban Surveillance
PUBLIC TRANSPORT
Schedule Planning
APTMS/AVL: Monitoring and Control Systems
APTMS: Business Intelligence/Reporting
ATIS: Traveller Information and Journey Planning
Fare Collection Systems
Available and most Widely Used Standards – Research Findings
ROADS
Traffic Signals
SANS 1547: Ed. 1.04 (2009) Traffic Signal Controllers: Describes the characteristics of traffic signal
controllers.
TR2500 (formerly TR2210A/MCE0141): UK Highway Agency Specification for Traffic Signal
Controllers.
TR2029 (2008): NMCS Inductive Loop Detector Cable
TR2512 (2005): Performance Specification or Below Ground Vehicle Detection Equipment
UTMC: The Urban Traffic Management Control programme

The UTMC Framework Technical Specification TS003 presents the core technical standards
recommended for use by Traffic Managers in their systems.

The UTMC Objects Registry TS004 presents a standardised set of data structures associated
with traffic management, in several forms including UML data model, XML schema, SNMP
MIBs, some IDL scripts for CORBA based systems, and tabular representation (originally
designed for database designers).
NTCIP 1201 & 1202
UTC: SCOOT vs SCATS
MCE 0360 : UK UTC Functional Specification
SARTSM
Freeway and Arterial Management
Communications
NTCIP:
National Transportation Communications for ITS Protocol (NTCIP) (http://www.ntcip.org).
NTCIP is a family of standards which define communications for computer control centre-to-field
devices, and computer control centre-to-control centre, used in Intelligent Transportation Systems.
These standards are listed in the NTCIP Guide, NTCIP 9001 V4.
The primary objective in adopting such standards is to ensure interoperability of devices
(independent of vendor) and to protect against early obsolescence of systems. NTCIP compliance is
generally dealt with in the following way on a project by project basis:






Determination of appropriate NTCIP standards.
Definition of the Project requirements within a particular standard (NTCIP specification
provides a Protocol Requirement List (PRL) which is a checklist of mandatory + optional
requirements and parameters).
Selection of appropriate manufacturers’ extensions.
Mapping of functions to NTCIP features and manufacturers’ extensions.
Consideration of implementation alternatives.
Specification of conformance and functional tests to be conducted.
This approach is consistent with the NTCIP Guide (NTCIP 9001 V4) which states that a simple
statement in tenders that the system should be NTCIP compliant is not sufficient. .
NTCIP is extensively use in the US and has been widely adopted for all FMS systems implemented in
South Africa.
Variable Message Signs
European Standard EN12966-1: 2004 Vertical Road Signs Part 1: Variable Message Signs
Deals with materials, visual performance, physical performance and test methods for variable
message signs. Has also been adopted as a British Standard.
SARTSM Vol 1 Chapter 9 Variable Message Signs
Deals with both Electromechanical and Electrical/Electronic VMS
Last updated in 1997.
Extent of 9.1.10 Design Considerations for Electrical and Electronic VMS is limited.
RTA (Australia) “Guidelines for the Location and Placement of Variable Message Signs” provides
useful additional guidelines to general signage guidelines in SARTSM
Traffic Detectors
Queensland (Au) Transport and Main Roads Specifications: MRTS204 Vehicle Detectors
Weather Stations
Standards for accuracy/performance
Standards for materials/manufacture
CCTV – Traffic Management and Urban Surveillance
Video Compression H.264, MPEG 4
PTZ Control
ONVIF
PUBLIC TRANSPORT
Schedule Planning
APTMS/AVL: Monitoring and Control Systems
APTMS: Business Intelligence
ATIS: Traveller Information and Journey Planning
Fare Collection Systems (excluded from these terms of reference)
Transmodel (formally CEN TC278, Reference Data Model For Public Transport, EN12896) is the CEN
European Reference Data Model for Public Transport Information; it provides an abstract model of
common public transport concepts and data structures that can be used to build many different
kinds of public transport information system, including for timetabling, fares, operational
management, real time data, journey planning etc.
GTFS: General (Google) Transit Feed Specification: GTFS defines a common format for public
transportation schedules along with geographic data. It was spearheaded by Google and a group of
developers. The goal was integration with Google Maps, so users could find public transit options
when trying to get from point a to b.
SIRI: Service Interface for Real Time Information specifies a European interface standard for
exchanging information about the planned, current or projected performance of real-time public
transport operations between different computer systems. SIRI has been created by equipment
suppliers, transport authorities, transport operators and transport consultants from eight European
countries (CZ, D, DK, F, NO, SE, UK) with the backing of VDV in Germany, the Direction des
Transports Terrestres of the French Ministry for Transport, and RTIG in the UK, and building on the
work of the EU Trident project. The workgroup was convened by CEN TC278 WG3, it was organised
by VDV (D) with editorship provided by RTIG (UK) and Transmodel expertise by France.
SIRI provides specific protocols for the following functional services:








Production Timetable [PT] Service: To send daily information on the operational timetable
and associated vehicle running information.
Estimated Timetable [ET] Service: To send real-time information on timetable, including
changes based on the production service and on actual running conditions.
Stop Timetable [ST] Service: To provide a stop-centric view of timetabled vehicle arrivals and
departures at a designated stop.
Stop Monitoring [SM] Service: To send real-time arrival & departure information relating to
a specific stop.
Vehicle Monitoring [VM] Service: To send real-time information on the movement and
predicted movement of vehicles.
Connection Timetable [CT] Service: To send an operational timetable for a service feeding an
interchange, in order to inform departing services of the possible need to wait for
connecting passengers.
Connection Monitoring [CM] Service: To send real-time information on the running of a
service inbound to an interchange, in order to advise departing services of the need to wait
for connecting passengers. This can also be used to send real-time information to assist
passengers in planning their onward journey following a connection.
General Message [GM] Service: To exchange informative messages between participants
The table below lists the different SIRI Functional Services and their RTIG (Real-Time Interest Group
(UK)) and VDV equivalents:
SIRI vs GTFS & GTFS-RT:
GTFS-real-time provides a subset of functions equivalent to certain SIRI services. The GTFS-real-time
and SIRI services can be regarded as interoperable, that is it should be possible to create adaptors to
transform data from a feed in one protocol to a feed in the other protocol. SIRI services are designed
for operational systems and contain main additional elements which are not present in the GTFS
feeds. The GTFS services are optimised for the distribution of a subset of data of interest to the
passenger. The broad correspondences are shown in the following table.
Operational implementation using SIRI (e.g. Trapeze and Prodata): Provision of real time service
information from different vehicle tracking and management systems.
SIRI and GTFS with GTFS-RT should be seen as two competing but interoperable open data feed
standards. An AVL system should be able to export data in both formats.
GTFS can also be supported by simply creating a file in the correct GTFS format. CoCT has already
done this in the past and has the information available in Google Maps. This is only for the static
schedule information.
Some transport agencies are making route and schedule information available on their API's in both
SIRI and GTFS & GTFS-RT formats. At this point in time it seems that GTFS & GTFS-RT is more popular
than SIRI, at least in the USA.
SIRI has as its main focus is in the exchange of data between transport agencies and/or AVL systems
with the added ability to also provide both static and real time schedule information through an API.
GTFS and GTFS-RT are primarily focused on the public transport user.
TCIP: Transit Communications Interface Profiles (TCIP) (http://www.aptatcip.com/).
TCIP is an American Public Transportation Association (APTA) Standard that provides a library of
information exchange building blocks, to allow transit agencies and transit suppliers to create
standardized tailored interfaces. APTA TCIP is based on the earlier TCIP work performed by ITE,
AASHTO, and NEMA and published as the NTCIP 1400-series standards. APTA TCIP extended the
NTCIP Standards to include a Concept of Operations, Model Architecture, Dialog Definitions, and a
rigorous, modular approach to conformance.