CEN/TS 15531-1:2007

SLOVENSKI STANDARD
01-februar-2009
-DYQLSUHYR]9PHVQLN]DLQIRUPLUDQMHYUHDOQHPþDVX]DSRWUHEHGHORYDQMD
MDYQHJDSUHYR]DGHO2NYLULQVNODGQRVW
Public transport - Service interface for real-time information relating to public transport
operations - Part 1: Context and framework
Öffentlicher Verkehr - Dienstleitungsschnittstelle für zeitnahe Informationen zum Betrieb
des öffentlichen Verkehrs - Teil 1: Rahmen und Gerüst
Ta slovenski standard je istoveten z: CEN/TS 15531-1:2007
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 15531-1
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
July 2007
ICS 35.240.60
English Version
Public transport - Service interface for real-time information
relating to public transport operations - Part 1: Context and
framework
Öffentlicher Verkehr - Dienstleitungsschnittstelle für
zeitnahe Informationen zum Betrieb des öffentlichen
Verkehrs - Teil 1: Rahmen und Gerüst
This Technical Specification (CEN/TS) was approved by CEN on 23 October 2006 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2007 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15531-1:2007: E
worldwide for CEN national Members.

Contents Page
Foreword.4
Introduction .5
1 Scope .6
1.1 Interfaces Specified by this Technical Specification.6
1.1.1 Business Context.6
1.1.2 SIRI Communications.6
1.1.3 SIRI Functional Services.7
1.2 Use of the SIRI standard .7
1.3 Limitations on SIRI and Possible Future Developments.8
2 Normative references .9
3 Terms and definitions .9
3.1 Transport Related Terms .9
3.2 Communications & Software Concepts .19
3.3 Types of Reference Data Used in SIRI.27
3.3.1 General.27
3.3.2 Date and time format .28
3.3.3 Location coordinate system .28
3.3.4 National language of text elements .29
3.3.5 Participant (information provider) identification .30
3.3.6 Participant pair identification (service participant pair code).30
3.3.7 Point and place references .31
3.3.8 Vehicle journey references .32
3.3.9 Line, and direction references.33
3.3.10 Stop sequence references and circular journeys .34
3.3.11 Schedule version references.36
3.3.12 Product category references .36
3.3.13 Vehicle and stop feature references.41
3.3.14 Service features .42
3.3.15 Situation references .44
3.3.16 Summary of Data Reference Scopes.44
3.3.17 Transmodel Compliant Models .45
3.3.18 Modelling Vehicle Journeys in SIRI .46
4 Symbols and abbreviations .53
4.1 General.53
4.2 Representation of XML model elements in Text.54
4.3 Representing Relationships in SIRI.54
4.4 Notation for XML model structures of SIRI messages.55
4.4.1 General.55
4.4.2 Organisational Group label.56
4.4.3 Element Name .56
4.4.4 Multiplicity & Choice (Min:Max).56
4.4.5 Data Type.57
4.4.6 Description .57
4.5 Notation for Diagrams .57
Annex A (informative) Checklist for Implementing SIRI.58
A.1 Usage of the DSRC application layer.58
A.2 Legal and Commercial Issues .58
A.3 Functional Aspects.58
A.3.1 Main Scope.58
A.3.2 Service Configuration .59
A.3.3 Reference data.59
A.3.4 Error Handling .60
A.4 Operational Aspects.60
A.4.1 Systems Management.60
A.4.2 Provisioning.60
Annex B (informative) Business Context.62
B.1 Purpose of This Section .62
B.2 Business Model .63
B.2.1 Passenger Transport Operations .63
B.2.2 Organisations .65
B.3 Use of information in Public Transport.65
B.3.1 Overview.65
B.3.2 Data Ownership .65
B.3.3 Temporal Considerations .68
B.3.4 Information Security.68
B.3.5 Regulatory Issues.69
B.4 Use Cases for this Technical Specification.69
B.4.1 Introduction.69
B.4.2 Use Case: Provision of Service Information to Passengers.70
B.4.3 Use Case: Journey Planning.71
B.4.4 Use Case: Facilitating Connections for Passengers .72
B.4.5 Use Case: Fleet and Network Management.73
B.4.6 Use Case: General Business Communications .73
B.5 SIRI System Model .74
B.5.1 Modularisation .74
B.5.2 PT Infrastructure Management Module.74
B.5.3 Transport Infrastructure Management Module.74
B.5.4 PT Scheduling Module.75
B.5.5 PT Integration Module.75
B.5.6 Traffic Management Control Centre .75
B.5.7 PT Operational Control .76
B.5.8 PT Journey Planner.77
B.5.9 Passenger Information.77
Annex C (informative) Background and Mapping of Some Current Implementations to SIRI .78
C.1 Introduction.78
C.2 SIRI origins.78
C.2.1 VDV453/VDV454.78
C.2.2 TRIDENT .78
C.2.3 RTIG-XML .79
C.2.4 CEN TC278 WG3 SG7.80
C.3 Deployment Example – Berlin.81
C.4 Deployment Example – Hamburg .82
C.5 Deployment Example – West Yorkshire.82
C.6 Deployment Example – Czech Republic .83
C.7 Deployment Example – Copenhagen .84
C.8 Deployment example – Île-de-France .85
Bibliography.87

Foreword
This document (CEN/TS 15531-1:2007) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, the secretariat of which is held by NEN.
This presents Part 1 of the European Technical Specification known as “SIRI”. SIRI provides a framework for
specifying communications and data exchange protocols for organisations wishing to exchange Real-time
Information (RTI) relating to public transport operations.
SIRI is presented in three parts:
• Context and framework, including background, scope and role, normative references, terms and
definitions, symbols and abbreviations, business context and use cases (Part 1).
• The mechanisms to be adopted for data exchange communications links (Part 2).
• Data structures for a series of individual application interface modules (Part 3).
The XML schema can be downloaded from http://www.siri.org.uk/, along with available guidance on its use,
example XML files, and case studies of national and local deployments.
It is recognised that SIRI is not complete as it stands, and there will be a substantial amount of work required
to continue to develop SIRI over the coming years. It is therefore intended that a SIRI Management Group
should continue to exist, at European level, based on the composition of SG7.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification: Austria, Belgium, Bulgaria, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and United Kingdom.
Introduction
Public transport services rely increasingly on information systems to ensure reliable, efficient operation and
widely accessible, accurate passenger information. These systems are used for a range of specific purposes:
setting schedules and timetables; managing vehicle fleets; issuing tickets and receipts; providing real-time
information on service running, and so on.
This Technical Specification specifies a Service Interface for Real-time Information (SIRI) about Public
Transport. It is intended to be used to exchange information between servers containing real-time public
transport vehicle or journey time data. These include the control centres of transport operators and information
systems that utilise real-time vehicle information, for example, to deliver services such as travel information.
Well-defined, open interfaces have a crucial role in improving the economic and technical viability of Public
Transport Information Systems of all kinds. Using standardised interfaces, systems can be implemented as
discrete pluggable modules that can be chosen from a wide variety of suppliers in a competitive market, rather
than as monolithic proprietary systems from a single supplier. Interfaces also allow the systematic automated
testing of each functional module, vital for managing the complexity of increasing large and dynamic systems.
Furthermore, individual functional modules can be replaced or evolved, without unexpected breakages of
obscurely dependent function.
This Technical Specification will improve a number of features of public transport information and service
management:
• Interoperability – the Technical Specification will facilitate interoperability between information processing
systems of the transport operators by: (i) introducing common architectures for message exchange; (ii)
introducing a modular set of compatible information services for real-time vehicle information; (ii) using
common data models and schemas for the messages exchanged for each service; and (iv) introducing a
consistent approach to data management.
• Improved operations management – the Technical Specification will assist in better vehicle management
by (i) allowing the precise tracking of both local and roaming vehicles; (ii) providing data that can be used
to improve performance, such as the measurement of schedule adherence; and (iii) allowing the
distribution of schedule updates and other messages in real-time.
• Delivery of real-time information to end-users – the Technical Specification will assist the economic
provision of improved data by; (i) enabling the gathering and exchange of real-time data between VAMS
systems; (ii) providing standardised, well defined interfaces that can be used to deliver data to a wide
variety of distribution channels.
Technical advantages include the following:
• Reusing a common communication layer for all the various technical services enables cost-effective
implementations, and makes the Technical Specification readily extensible in future.
1 Scope
1.1 Interfaces Specified by this Technical Specification
1.1.1 Business Context
Real-time information may be exchanged between a number of different organisations, or between different
systems belonging to the same organisation. Key interfaces include the following:
• Between public transport vehicle control centres – generally, for fleet and network management.
• Between a control centre and an information provision system – generally, to provide operational
information for presentation to the public.
• Between information provision systems – generally, sharing information to ensure that publicly available
information is complete and comprehensive.
Annex B describes the business context for SIRI in more detail.
SIRI is intended for wide scale, distributed deployment by a wide variety of installations. In such
circumstances it is often not practical to upgrade all the systems at the same time. SIRI therefore includes a
formal versioning system that allows for the concurrent operation of different levels at the same time and a
disciplined upgrade process.
In this general framework, SIRI defines a specific set of concrete functional services. The services separate
the communication protocols from the message content (‘functional services’). This allows the same functional
content to be exchanged using different transport mechanisms, and different patterns of exchange. Figure 1
below shows this diagrammatically.
1.1.2 SIRI Communications
SIRI provides a coherent sent of functional services for exchanging data for different aspects of PT operation.
A common data model, based on TransModel 5.1, is used across all services.

Figure 1 — Structure of SIRI: a set of optional service interface specifications using a common
communications layer
A communication layer defines common procedures for the requesting and exchanging of data. Within SIRI,
the same general communication protocols are used for all the different concrete functional interfaces, and
specify a common infrastructure for message referencing, error handling, reset behaviour and so forth. The
communications layer is defined in Part 2 of the SIRI document set.
To allow the most efficient use to be made of bandwidth and processing capacity, the SIRI communications
architecture supports several different patterns of interaction. SIRI supports both request/response and
publish/subscribe protocols between servers, allowing applications both to pull or to push data.
The SIRI publish/subscribe pattern of interaction follows the paradigm described in the W3C candidate
standard ‘Publish-Subscribe Notification for Web Services (WS-PubSub)’. SIRI uses the same separation of
concerns, and a similar terminology for Publish/Subscribe concepts as is used in WS-PubSub.
For the delivery of data in response to both requests and subscriptions, SIRI supports two common patterns of
message exchange as realised in existent national systems:
• One-step ‘direct’ delivery: allowing the simple rapid delivery of data
• Two-step ‘fetched’ delivery: allowing a more optimised use of limited resources.
1.1.3 SIRI Functional Services
SIRI provides specific protocols for the following functional services, defined in Part 3 of the SIRI document
set:
• 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.
1.2 Use of the SIRI standard
As a framework standard, it is not necessary for individual systems or specifications to implement the whole of
the SIRI standard. Specifically it is intended that individual national bodies may adopt consistent subsets of
the standard. However, it should be possible to describe (for those elements of systems, interfaces and
specifications which fall within the scope of SIRI):
• The aspects of SIRI that they have adopted.
• The aspects of SIRI that they have chosen not to adopt.
In other words, there is no global statement of which elements are mandatory and which optional (except for
key fields which are clearly always mandatory).
SIRI is a modular and expandable standard, and the modules included in this version are only a subset of
what might potentially be included. Specifically, the current issue of the SIRI specification excludes the
following:
• Interfaces between central systems and individual end-devices – on-bus systems, on-street signs,
consumer devices etc.
• Interfaces with traffic management systems.
• Control action functions, e.g. instructions to a vehicle to change its running.
• Data relating to events and situations – in SIRI this is passed via the GeneralMessage service.
• Functionality of systems – SIRI only specifies the interfaces between servers.
The potential for SIRI to be expended to encompass additional services, including some of those cited here, is
being actively investigated at present.
Guidance on the implementation and use of SIRI is not part of the specification. It is a matter for individual
users and national groupings to provide advice and guidance on how SIRI may be used in support of local
practices.
Note also that the SIRI communications layer does not specify the bearer technologies to be used. It has been
specifically developed to be ‘technology independent’ in this regard, so that local implementations can select
the most cost-effective services for their projects.
Of course different technologies have different characteristics, and this may have an impact on the way that
SIRI is used in practice. For example, the latency (time delay imposed by the communications network) of a
service such as public GPRS is much higher than that on a dedicated, broadband fixed link using DSL.
Therefore, systems based on GPRS will need to use a much higher value for some or all of the hysteresis
parameters.
1.3 Limitations on SIRI and Possible Future Developments
The developers of this technical specification recognise that there is continual development in the business
practice of the public transport industry, and that SIRI must continue to evolve to fulfil its needs. Specifically,
there is scope for additional elements to be included in two places:
• Communications (SIRI Part 2). New mechanisms of data communication are constantly becoming
available, in particular for areas such as information security and data discovery. SIRI is intended to be in
line with prevailing information systems industry practice and Part 2 aims to retain flexibility in use of
communications technologies.
• Applications (SIRI Part 3). This technical specification is based on a specific set of interfaces,
representing a subset of practical needs among participant countries. However, new models of business
cooperation may arise which necessitate additional application interface specifications. Part 3 is not
intended to be a complete set of interfaces and additional modules might be required in future.
• Architectural detail. This technical specification is based on a very high-level decomposition of public
transport operations, and implements only the most common interfaces. This may not fulfil all the needs of
an implementer; for example, Scandinavia and the UK both have a relatively high degree of organisational
disaggregation, and as a result may need standardisation on what would be ‘internal’ interfaces elsewhere
in Europe.
CEN welcomes input from users of this Technical Specification as to where SIRI needs extension or
refinement.
Additional Information about the relation between SIRI and Transmodel has been produced by a
Transmodel compliance study. It can be found at www.siri.org.uk:

• A table describing the exact mapping of each SIRI element to the corresponding Transmodel object.
• An extract of the Transmodel objects underlying SIRI Services.
• A UML Schema definition.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
EN 12896, Road transport and traffic telematics - Public transport - Reference data model
CEN/TS 13149-6, Public transport - Road vehicle scheduling and control systems - Part 6: CAN message
content
ISO 8601, Data elements and interchange formats – Information interchange – Representation of dates and
times
ISO 639-1, Codes for the representation of names of languages - Part 1: Alpha-2 code
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1 Transport Related Terms
This section includes terms for both PT entities and properties of PT entities used in SIRI. For each term, it is
indicated whether the term derives from TransModel (EN 12896 version 5.0) or whether the term is specific to
SIRI.
3.1.1
BEARING – SAE J1939/71 (CEN/TS 13149-6)
the heading of the vehicle in degrees expressed as a floating point number: compliant to SAE J1939/71
(Compatible with CEN/TS 13149-6)
3.1.2
BLOCK – TransModel
the work of a vehicle from the time it leaves a PARKING POINT after parking until its next return to park at a
PARKING POINT. Any subsequent departure from a PARKING POINT after parking marks the start of a new
BLOCK. The period of a BLOCK has to be covered by DUTIES.
3.1.3
CALL ACTIVITY – SIRI
the activity a passenger may undertake when a Vehicle calls at a stop; Boarding, Alighting, or Pass Through
3.1.4
CALL – SIRI
a visit by a VEHICLE to a specific STOP POINT as it follows the JOURNEY PATTERN of its VEHICLE
JOURNEY to achieve a set of planned and estimated PASSING TIMEs. A VEHICLE may make more than
one Call to the same stop in the course of a JOURNEY: different calls may typically be distinguished by a Visit
Number count. The Call may have real time data associated with it.
A SIRI Call may be regarded as a useful optimisation of a more normalised set of structures that are
articulated separately in TransModel. Call combines the TransModel elements of POINT IN JOURNEY
PATTERN in with ESTIMATED PASSING TIME, OBSERVED PASSING TIME, & TARGET PASSING TIME,
along with real time elements and other stop properties pertaining to the visit. Note that SIRI segregates all
elements pertaining to arrival from those pertaining to departure, again facilitating the validation and
implementation of actual systems.
3.1.5
CHANGE OF JOURNEY PATTERN – TransModel
a CONTROL ACTION consisting in assigning a new JOURNEY PATTERN (and the ROUTE supporting it) to a
DATED VEHICLE JOURNEY
3.1.6
CLEARDOWN – SIRI
the act of removing a Stop Visit from a DISPLAY once a vehicle has arrived at a stop. For improved latency,
‘Direct Cleardown’ may often be done by direct wireless communication between the approaching vehicle and
the stop display equipment, as well as by the regular back-end communication between the Stop Monitoring
producer server and the Stop Monitoring Consumer entity of the client system driving the stop display.
A separate Cleardown identifier may be associated with each Stop Visit for this purpose, which can be used to
reconcile the previous Stop Visit with the arriving vehicle; typically this will be a short numeric code designed
to be efficient for communication over a radio channel of restricted capacity.
3.1.7
CONNECTION ACTIVITY – SIRI
a change to the planned arrival to, or departure from, a connection link for a vehicle journey that is material to
passengers intending to make a planned interchange. Events may include a delayed arrival of the feeder, a
decision to prolong the wait by the distributor vehicle, a change of the distributor departure point, or
cancellation of either of the feeder or distributor journeys.
3.1.8
CONNECTION PROTECTION – SIRI
the coordination of inbound feeder and outbound distributor journeys at an interchange so as to maximise the
chances of passengers achieving their journeys. Involves the exchange of information between feeder and
distributor to inform dispatchers and passengers of the current situation, and the delaying of distributor
vehicles so as to honour GUARANTEED CONNECTIONS.
3.1.9
CONNECTION LINK – TransModel
the physical (spatial) possibility for a passenger to change from one public transport vehicle to another to
continue a trip. Different transfer times may be necessary to cover interchange over a given connection link,
depending on the kind of passenger.
In SIRI, a Feeder service may arrive at one STOP POINT in the CONNECTION LINK, and the Distributor may
leave from the same or a different stop in the CONNECTION LINK.
The interchange duration, i.e. transfer time is the time needed to go from stop point to stop point across a
CONNECTION LINK. In SIRI, it does not include time needed to board or alight. Several different types of
interchange duration may be specified.
3.1.10
CONNECTION MONITORING – SIRI
the monitoring of the real-time arrivals and departures at an interchange for changes against the planned
schedule
3.1.11
CONTROL ACTION – TransModel
an action resulting from a decision taken by the controller causing an amendment of the operation planned in
the PRODUCTION PLAN
3.1.12
CONTROL CENTRE – SIRI
a Control Centre is an ORGANISATIONAL UNIT that manages a network or networks of vehicles and their
attendant real-time systems, and corresponding specifically to a SIRI Service Participant. Each Control Centre
has a uniquely identifier, (the Control Centre Code), which provides a scope (i.e. unique namespace) for all
non-global data references, such as stop identifiers, vehicle identifiers, etc. Within a Control centre, references
must be unique. VEHICLES and JOURNEYS within the span of control of a given Control Centre are Local;
VEHICLES and JOURNEYS within the span of control of an external Control Centre are Foreign.
3.1.13
COUPLED JOURNEY – TransModel
a complete journey operated by a coupled train, composed of two or more VEHICLE JOURNEYs remaining
coupled together all along a JOURNEY PATTERN. A COUPLED JOURNEY may be viewed as a single
VEHICLE JOURNEY.
3.1.14
COURSE OF JOURNEY– TransModel
a part of a BLOCK, composed of consecutive VEHICLE JOURNEYs defined for the same DAY TYPE, all
operated on the same LINE. Also sometimes termed a Run.
3.1.15
DATA SYSTEM – TransModel
the origin of operational data referring to one single responsibility. References to a data system are useful in
an interoperated computer system.
For SIRI, this entails in particular specific systems for assigning unique identifiers to relevant entities such as
STOP POINTS or JOURNEYS, about which messages are to be exchanged, and which can be matched to
the locally known entities identified by the respective internal operating data. The DATA SYSTEM must be
mutually agreed between CLIENT and SERVER. A DATA SYSTEM has both a data model to describe the
entities and their relationships, and a Namespace to describe the unambiguous set of identifier values.
3.1.16
DATED VEHICLE JOURNEY – TransModel
a particular journey of a vehicle on a particular OPERATING DAY, including all modifications decided by the
control staff
3.1.17
DELAYED – SIRI
a categorisation of a VEHICLE JOURNEY for presentation as being late and subject to significant uncertainty
caused either by a Disturbance to the transport network or a problem with the VEHICLE itself
3.1.18
DESTINATION DISPLAY – TransModel (with clarification)
an advertised destination of a specific JOURNEY PATTERN, usually displayed on a headsign or at other on-
board locations.
In SIRI, different values for DESTINATION DISPLAY may be used in the dated timetable, the real-time table,
or on individual calls to support stop centric and vehicle centric presentations of information to the customer. If
not specified on an individual Call element, the DESTINATION DISPLAY will be inherited from the most recent
previous Call element. If there are no values on previous calls, it will be inherited from the DATED VEHICLE
JOURNEY destination displays.
3.1.19
DIRECTION – TransModel
a classification for the general orientation of ROUTEs
3.1.20
DISTRIBUTOR – SIRI
the role of the outgoing VEHICLE from a TARGETED INTERCHANGE, which picks up passengers from a
CONNECTION LINK who have transferred from a Feeder Service. Sometimes also called a Fetcher.
3.1.21
DISTRIBUTOR DEPARTURE – SIRI
the departure of an outgoing distributor VEHICLE JOURNEY from a CONNECTION LINK
3.1.22
EARLY – SIRI
a categorisation used in data presentations to indicate that the vehicle has been classified as Early against
some criteria. The status of Early will be derived from the real-time progress data. This term should be
contrasted with SCHEDULE DEVIATION which specifies the deviation from schedule in seconds.
3.1.23
ESTIMATED PASSING TIME – TransModel
time data, calculated from the latest available input, about when a public transport vehicle will pass a
particular POINT IN JOURNEY PATTERN on a specified MONITORED VEHICLE JOURNEY. These are
mainly used to inform passengers about expected times of arrival and/or departure, but may also be used for
monitoring and re-planning. See also OBSERVED (ACTUAL) PASSING TIME, TARGET (AIMED) PASSING
TIME and TIMETABLED PASSING TIME.
3.1.24
EVENT – TransModel
an EVENT may be raised in response to the disturbance and over the lifetime of the EVENT one of more
CONTROLLER ACTIONS and messages may then be associated with it.
In SIRI, the EVENT is generally avoided in favour of more specific terms for entities
3.1.25
FEEDER – SIRI (Informal TransModel term)
the role of the incoming VEHICLE to and VEHICLE JOURNEY at a TARGETED INTERCHANGE, which feeds
passengers to an arrival STOP POINT having a CONNECTION LINK to a departure STOP POINT from where
they will board a Distributor Service. A VEHICLE may perform both feeder and distributor roles at the same
time, that is, both set down passengers to transfer to other services, and board passengers from other
services.
3.1.26
FEEDER ARRIVAL – SIRI
the arrival of an incoming feeder VEHICLE JOURNEY to a CONNECTION LINK
3.1.27
FOREIGN VEHICLE – SIRI (Informal TransModel Term)
a given ORGANISATIONAL UNIT, i.e. SIRI Control Centre system, manages its own set of Local VEHICLES
and VEHICLE JOURNEYS, for which it is responsible for provisioning and updating the data. It may also need
to manage data for Foreign VEHICLES and VEHICLE JOURNEYS, whose data is originated by a different
Control Centre. A Foreign Vehicle is thus a local VEHICLE from one Control Centre that is Roaming into the
area managed by another Control Centre.
3.1.28
HEADWAY INTERVAL – SIRI
for Frequency based services, the interval between vehicles may be TIMETABLED, AIMED, ESTIMATED or
ACTUAL
3.1.29
HEADWAY SERVICE – SIRI
a frequent service whose time of departure is normally shown to the public as ‘every n minutes’ rather than a
fixed time
3.1.30
INCIDENT –TransModel term
an unforeseen EVENT influencing the operation of the network
In SIRI, progression of an Incident is represented by a Situation.
3.1.31
IN CONGESTION – SIRI
the status of a vehicle stuck in a traffic jam causing its journey to be delayed and subject to non-deterministic
factors; any predictions are likely to be inaccurate
3.1.32
IN PANIC – SIRI
the status of a vehicle with an active Panic Alarm indicating a security or other incident that is likely to delay
the journey according to non-deterministic factors; any predictions are likely to be inaccurate
3.1.33
JOURNEY CANCELLATION – TransModel
a CONTROL ACTION consisting in deleting a DATED VEHICLE JOURNEY from the latest valid plan
3.1.34
JOURNEY CREATION – TransModel
a CONTROL ACTION consisting in adding a completely new DATED VEHICLE JOURNEY to the latest valid
plan
3.1.35
JOURNEY MEETING – TransModel
a time constraint for one or several SERVICE JOURNEYs fixing interchanges between them and/or an
external event (e.g. arrival or departure of a feeder line, opening time of the theatre, etc.)
3.1.36
JOURNEY PATTERN – TransModel
an ordered list of STOP POINTs and TIMING POINTs on a single ROUTE, describing the pattern of working
for public transport vehicles. A JOURNEY PATTERN may pass through the same POINT more than once.
The first point of a JOURNEY PATTERN is the origin. The last point is the destination. Every VEHIC
...