SIST-TP CEN/TR 12896-9:2019

Public transport - Reference data model - Part 9: Informative documentation

A Technical Report with informative and didactical material to users.

Öffentlicher Verkehr - Datenreferenzmodell - Teil 9: Informative Dokumentation

Transport public - modèle de données de référence - part 9 : Document informatif

Javni prevoz - Referenčni podatkovni model - 9. del: Informativna dokumentacija

Tehnično poročilo z informativnim in didaktičnim gradivom za uporabnike.

General Information

• Status: Published
• Publication Date: 29-Sep-2019
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 04-Sep-2019
• Due Date: 09-Nov-2019
• Completion Date: 30-Sep-2019
• Directive: 2010/40/EU - Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport Text with EEA relevance
• Ref Project: CEN/TR 12896-9:2019 - Public transport - Reference data model - Part 9: Informative documentation

Relations

• Replaces: SIST-TP CEN/TR 12896-9:2016 - Public transport - Reference data model - Part 9: Informative documentation
• Effective Date: 01-Nov-2019

Standards Content (Sample)

SLOVENSKI STANDARD
01-november-2019
Nadomešča:
SIST-TP CEN/TR 12896-9:2016
Javni prevoz - Referenčni podatkovni model - 9. del: Informativna dokumentacija
Public transport - Reference data model - Part 9: Informative documentation
Ãffentlicher Verkehr - Datenreferenzmodell - Teil 9: Informative Dokumentation
Ta slovenski standard je istoveten z: CEN/TR 12896-9:2019
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 12896-9
TECHNICAL REPORT
RAPPORT TECHNIQUE
August 2019
TECHNISCHER BERICHT
ICS 35.240.60 Supersedes CEN/TR 12896-9:2016
English Version
Public transport - Reference data model - Part 9:
Informative documentation
Öffentlicher Verkehr - Datenreferenzmodell - Teil 9:
Informative Dokumentation
This Technical Report was approved by CEN on 5 August 2019. It has been drawn up by the Technical Committee CEN/TC 278.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 12896-9:2019 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
1 Introduction . 5
2 Complete Data Dictionary . 6
2.1 Introduction . 6
2.2 Data Dictionary . 6
2.2.1 Transmodel v6.0 . 6
3 Overview of Transmodel . 1191
3.1 Transmodel Parts and Packages. 1191
3.1.1 General Structure . 1191
3.1.2 Model Parts in Relation to Different Transportation Stages . 1191
3.1.3 Common Concepts . 1192
3.1.4 Packages Specific to Public Transport Planning and Operation . 1195
4 Dependency Diagrams . 1197
4.1 Model and Package Dependencies . 1197
4.1.1 Introduction . 1197
4.1.2 Motivation . 1197
4.1.3 High-level Dependencies for Transmodel . 1198
4.2 Transmodel All Parts – High-level Package Dependencies . 1198
4.3 Part 1 High-level Package Dependencies . 1198
4.4 Part 1 Model Dependencies . 1199
4.4.1 Part 1 High-level Package Dependencies . 1199
4.4.2 Part 1 Packages and Dependencies . 1199
4.4.3 Part 1 Version & Validity Model Dependencies . 1200
4.4.4 Part 1 Generic Framework Model Dependencies . 1201
4.4.5 Part 1 Reusable Component Model Dependencies . 1202
4.4.6 Part 1 Reusable Equipment Model Dependencies . 1202
4.4.7 Part 1 Explicit Frames Model Dependencies . 1203
4.4.8 Part 1 Additional Framework Model Dependencies . 1204
4.4.9 Part 1 Additional Reusable Component Model Dependencies . 1205
4.5 Part 2 Model Dependencies . 1206
4.5.1 Part 2 High-level Package Dependencies . 1206
4.5.2 Part 2 Packages and Dependencies . 1207
4.5.3 Part 2 Network Model Dependencies . 1208
4.5.4 Part 2 Fixed Object General Model Dependencies . 1208
4.5.5 Part 2 Fixed Object Equipment Model Dependencies . 1209
4.5.6 Part 2 Local Service Model Dependencies . 1210
4.5.7 Part 2 Tactical Planning Model Dependencies . 1211
4.5.8 Part 2 Tactical Planning Assignment Model Dependencies . 1212
4.5.9 Part 2 Infrastructure Frame Model Dependencies . 1213
4.5.10 Part 2 Site Frame Model Dependencies . 1214
4.5.11 Part 2 Service Frame Model Dependencies . 1215
4.6 Part 3 Model Dependencies . 1216
4.6.1 Part 3 High-level Package Dependencies . 1216
4.6.2 Part 3 Packages and Dependencies . 1217
4.6.3 Part 3 Timing Information Model Dependencies . 1218
4.6.4 Part 3 Other Model Dependencies . 1218
4.6.5 Part 3 Timetable Frame Model Dependencies . 1219
4.7 Part 4 Model Dependencies . 1220
4.7.1 Part 4 High-level Package Dependencies . 1220
4.7.2 Part 4 Packages and Dependencies . 1221
4.8 Part 5 Model Dependencies . 1222
4.8.1 Part 5 High-level Package Dependencies . 1222
4.8.2 Part 5 Packages and Dependencies . 1223
4.8.3 Part 5 Fare Structure Model Dependencies . 1223
4.8.4 Part 5 Access Right Model Dependencies . 1224
4.8.5 Part 5 Usage Parameter Model Dependencies . 1225
4.8.6 Part 5 Sales Description Model Dependencies . 1226
4.8.7 Part 5 Sales Transaction Model Dependencies . 1227
4.8.8 Part 5 Explicit Frames Model Dependencies . 1228
4.8.9 Part 5 Sales Event Model Dependencies . 1229
4.8.10 Part 5 Control & Validation Model Dependencies . 1230
4.9 Part 6 Model Dependencies . 1231
4.9.1 Part 6 High-level Package Dependencies . 1231
4.9.2 Part 6 Trip Description Model Dependencies . 1232
4.9.3 Part 6 Trip Query Model Dependencies . 1233
4.10 Part 7 Model Dependencies . 1233
4.10.1 Part 7 High-level Package Dependencies . 1233
4.11 Part 8 Model Dependencies . 1234
Annex A Model Evolution . 1235

European foreword
This document (CEN/TR 12896-9:2019) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TR 12896-9:2016.
The Transmodel v6 series is composed of the following documents:
 Public transport - reference data model - Part 1: Common Concepts;
 Public transport - reference data model - Part 2: Public Transport Network;
 Public transport - reference data model - Part 3: Timing Information and Vehicle Scheduling;
 Public transport - reference data model - Part 4: Operations Monitoring and Control;
 Public transport - reference data model - Part 5: Fare Management;
 Public transport - reference data model - Part 6: Passenger Information;
 Public transport - reference data model - Part 7: Driver Management; and
 Public transport - reference data model - Part 8: Management Information and Statistics.
Together these create version 6 of the European Standard EN 12896, known as “Transmodel”, and thus
replace EN 12896:2006, known as “Transmodel v5.1”.
This informative document provides supplementary information to that contained in the formal
European Standard to help those implementing the Standard.
Introduction
This document documents further information related to parts 1 to 8 of version 6 of the "Public Transport
– Reference Data Model" (Transmodel v6.0) European Standard, EN 12896. This information is
particularly useful for those who need additional guidance as regards Transmodel structure and/or
intend to implement sub-models. The various sections of the document provide:
 A Complete Data Dictionary (merging and extending the information contained in each separate Part
of the Standard that has been published to date) [section 2];
 An overview of the whole of Transmodel to provide an understanding of how the model is structured
[section 3]
 An explanation of how each component model links with other components [section 4]
 An Annex providing a table which shows the evolution of the terms used in Transmodel v6.0 from
the previous Transmodel v5.1 and IFOPT European Standards [Annex A]
1 Scope
The standards provides informative and didactical material to users.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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-1: 2016, Public transport - Reference data model - Part 1: Common concepts
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 12896-1: 2016 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
4 Complete Data Dictionary
4.1 Introduction
The sections which follow show the complete data dictionary for Transmodel v6.0. Each term is defined
only once and the relevant Transmodel part and package are indicated immediately after each term and
before the definition.
The Data Types shown in the tables in this section are not mandatory.
4.2 Data Dictionary
4.2.1 Transmodel v6.0
4.2.1.1 ABSENCE
(Part 7 - Driver Management (DM)::PD Personnel Disposition MODEL::DM Driver Assignment
MODEL::ABSENCE)
An ABSENCE represents an actual absence of an EMPLOYEE from work on a particular OPERATING DAY
for a specified time.
Table 1 — ABSENCE — Relations
Source Target
ABSENCE LOG ENTRY
Relation type: Generalization
ABSENCE OPERATING DAY
Role: on Role: of
Cardinality: 0.* Cardinality: 1
Relation type: Association
EMPLOYEE ABSENCE
Role: in Role: for
Cardinality: 1 Cardinality: *
Relation type: Association
TYPE OF ABSENCE ABSENCE
Role: classifying Role: classified as
Cardinality: 1 Cardinality: 0.*
Relation type: Association
Table 1 — ABSENCE — Attributes
Classifi- Name Type cardinality Description
cation
::> ::> LOG ENTRY ::> ABSENCE inherits from LOG ENTRY
Order positiveInteger 1:1 Order of ABSENCE during OPERATING DAY.
StartTime time 0:1 Start time of ABSENCE.
EndTime time 0:1 End time of ABSENCE.
«UID» Id 1:1 Identifier of ABSENCE.
4.2.1.2 ACCESS
(Part 1 - Common Concepts (CC)::CC Generic Framework MODEL::CC Generic Place MODEL::ACCESS )
The physical (spatial) possibility for a passenger to access or leave the public transport system. This link
may be used during a trip for:- the walking movement of a passenger from a PLACE (origin of the trip) to
a SCHEDULED STOP POINT (origin of the PT TRIP), or- the walking movement from a SCHEDULED STOP
POINT (destination of the PT TRIP) to a PLACE (destination of the trip).
Table 2 - ACCESS – Relations
Source Target
ACCESS SITE FRAME
Cardinality: 0.*
Relation type: Aggregation
ACCESS TRANSFER
Relation type: Generalization
ACCESS END ACCESS
Role: start of Role: from
Cardinality: 1 Cardinality: 0.*
Relation type: Association
ACCESS LEG ACCESS
Role: using Role: according to
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
ACCESS END ACCESS
Role: end of Role: to
Cardinality: 1 Cardinality: 0.*
Relation type: Association
Table 3 - ACCESS – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> TRANSFER ::> ACCESS inherits from TRANSFER
«UID» Id AccessIdType 1:1 Identifier of ACCESS link.
4.2.1.3 ACCESS END
(Part 1 - Common Concepts (CC)::CC Generic Framework MODEL::CC Generic Place MODEL::ACCESS
END)
Origin or destination end of an ACCESS link. May indicate a POINT and/or PLACE.
Table 4 - ACCESS END – Relations
Source Target
ACCESS END PLACE
Role: a view of Role: viewed as
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
ACCESS END ACCESS
Role: start of Role: from
Cardinality: 1 Cardinality: 0.*
Relation type: Association
ACCESS END POINT
Role: a view of Role: viewed as
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
ACCESS END ACCESS
Role: end of Role: to
Cardinality: 1 Cardinality: 0.*
Relation type: Association
Table 5 - ACCESS END – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ::> ACCESS END doesn't inherit from another class
4.2.1.4 ACCESS LEG
(Part 6 - Passenger Information (PI)::TD Trip Description MODEL::TD Passenger Trip MODEL::ACCESS
LEG)
A part of a TRIP PATTERN corresponding to the movement of a passenger when not on a public transport
vehicle, from an origin PLACE to a SCHEDULED STOP POINT, or a SCHEDULED STOP POINT to a
destination PLACE. May reference an ACCESS.
Table 6 - ACCESS LEG – Relations
Source Target
ACCESS LEG Note
Relation type: NoteLink
ACCESS LEG ACCESS
Role: using Role: according to
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
ACCESS LEG LEG
Relation type: Generalization
Table 7 - ACCESS LEG – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> LEG ::> ACCESS LEG inherits from LEG
«UID» id AccessLegIdType 1:1 Identifier of ACCESS LEG.
4.2.1.5 ACCESS MODE
(Part 1 - Common Concepts (CC)::CC Reusable Components MODEL::CC Transport Mode MODEL::ACCESS
MODE)
A characterisation of the passenger movement according to the means of transport different from public
transport (e.g. walk, bicycle, etc)
Table 8 - ACCESS MODE – Relations
Source Target
ACCESS MODE Note
Relation type: NoteLink
ACCESS MODE MODE
Relation type: Generalization
TRIP ACCESS CONSTRAINT ACCESS MODE
Role: limit to Role: determining
Cardinality: 0.* Cardinality: 0.*
Relation type: Association
NAVIGATION PATH ACCESS MODE
Role: accessed by Role: for
Cardinality: 0.* Cardinality: 0.*
Relation type: Association
SITE ELEMENT ACCESS MODE
Role: accessed by Role: for
Cardinality: 0.* Cardinality: 0.*
Relation type: Association
Note ACCESS MODE
Relation type: NoteLink
Table 9 - ACCESS MODE – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> MODE ::> ACCESS MODE inherits from MODE
«UID» Id 1:1 Identifier of ACCESS MODE.
4.2.1.6 ACCESS RIGHT IN PRODUCT
(Part 5 - Fare Management (FM)::AR Access Rights Description MODEL::AR Types of Fare Product MODEL
::ACCESS RIGHT IN PRODUCT)
A VALIDABLE ELEMENT as a part of a PRE-ASSIGNED FARE PRODUCT, including its possible order in the
set of all VALIDABLE ELEMENTs grouped together to define the access right assigned to that PRE-
ASSIGNED FARE PRODUCT.
Table 10 - ACCESS RIGHT IN PRODUCT – Relations
Source Target
ACCESS RIGHT IN PRODUCT VALIDABLE ELEMENT
Role: a view of Role: viewed as
Cardinality: 0.* Cardinality: 1
Relation type: Association
ACCESS RIGHT IN PRODUCT FARE ELEMENT IN SEQUENCE
Relation type: Generalization
ACCESS RIGHT IN PRODUCT PRE-ASSIGNED FARE PRODUCT
Role: included in Role: composed of
Cardinality: 1.*
Relation type: Aggregation
Table 11 - ACCESS RIGHT IN PRODUCT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> FARE ELEMENT IN ::> ACCESS RIGHT IN PRODUCT inherits from FARE
SEQUENCE ELEMENT IN SEQUENCE
«UID» id AccessRightInProductIdTy 1:1 Identifier of ACCESS RIGHT IN PRODUCT.
pe
4.2.1.7 ACCESS RIGHT PARAMETER ASSIGNMENT
(Part 5 - Fare Management (FM)::AR Access Rights Description MODEL::AR Access Right Parameters
MODEL ::AR Access Right Parameter Assignment MODEL::ACCESS RIGHT PARAMETER ASSIGNMENT)
The assignment of a fare collection parameter (referring to geography, time, quality or usage) to an
element of a fare system (access right, validated access, control mean, etc.).
Table 12 - ACCESS RIGHT PARAMETER ASSIGNMENT – Relations
Source Target
ACCESS RIGHT PARAMETER SCOPING VALIDITY PARAMETER
ASSIGNMENT
Role: assigned to
Role: for
Cardinality: 0.*
Relation type: Association
ACCESS RIGHT PARAMETER ACCESS RIGHT PARAMETER
ASSIGNMENT ASSIGNMENT
Role: including Role: included in
Relation type: Association Cardinality: 0.*
ACCESS RIGHT PARAMETER TEMPORAL VALIDITY PARAMETER
ASSIGNMENT
Role: assigned to
Role: for
Cardinality: 0.*
Relation type: Association
ACCESS RIGHT PARAMETER TRIP FARE REQUEST FILTER
ASSIGNMENT
Role: limit to
Role: limiting
Cardinality: 0.*
Relation type: Aggregation
ACCESS RIGHT PARAMETER USAGE PARAMETER
ASSIGNMENT
Role: assigned to
Role: for
Cardinality: 0.*
Cardinality: 0.*
Relation type: Association
ACCESS RIGHT PARAMETER FARE EASEMENT PARAMETER
ASSIGNMENT CHANGE
Role: replacement Role: eased by
Cardinality: 0.*
Relation type: Aggregation
ACCESS RIGHT PARAMETER FARE EASEMENT PARAMETER
ASSIGNMENT CHANGE
Role: normal Role: eases
Source Target
Cardinality: 0.1
Relation type: Aggregation
ACCESS RIGHT PARAMETER ASSIGNMENT
ASSIGNMENT
Relation type: Generalization
ACCESS RIGHT PARAMETER ComparisonOperatorEnum
ASSIGNMENT
Relation type: Dependency
ACCESS RIGHT PARAMETER FARE FRAME
ASSIGNMENT
Cardinality: *
Relation type: Aggregation
ACCESS RIGHT PARAMETER TYPE OF ACCESS RIGHT ASSIGNMENT
ASSIGNMENT
Role: a classification for
Role: classified as
Cardinality: 0.1
Cardinality: 0.*
Relation type: Association
ACCESS RIGHT PARAMETER LogicalOperatorEnum
ASSIGNMENT
Relation type: Dependency
ACCESS RIGHT PARAMETER FARE SECTION
ASSIGNMENT
Role: assigned to
Role: for
Cardinality: 0.1
Cardinality: *
Relation type: Association
ACCESS RIGHT PARAMETER ACCESS RIGHT PARAMETER
ASSIGNMENT ASSIGNMENT
Role: including Role: included in
Relation type: Association Cardinality: 0.*
Source Target
CONTROL PARAMETER ASSIGNMENT ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: Generalization
Note ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: NoteLink
VALIDATION PARAMETER ACCESS RIGHT PARAMETER
ASSIGNMENT ASSIGNMENT
Relation type: Generalization
Note ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: NoteLink
Note ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: NoteLink
DEVICE PARAMETER ASSIGNMENT ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: Generalization
Note ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: NoteLink
VALIDITY PARAMETER ASSIGNMENT ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: Generalization
Note ACCESS RIGHT PARAMETER
ASSIGNMENT
Relation type: NoteLink
Table 13 - ACCESS RIGHT PARAMETER ASSIGNMENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ASSIGNMENT ::> ACCESS RIGHT PARAMETER ASSIGNMENT inherits
from ASSIGNMENT
«UID» id AccessRightParameterAssi 1:1 Identifier of ACCESS RIGHT PARAMETER
gnmentIdType ASSIGNMENT.
IsAllowed boolean 0:1 Whether the specified assignments are allowed
(true) or not (false).
Name MultilingualString 0:1 Name of ACCESS RIGHT PARAMETER ASSIGNMENT.
Description MultilingualString 0:1 Description of ACCESS RIGHT PARAMETER
ASSIGNMENT.
ValidityParamete LogicalOperatorEnum 0:1 Operator to use to combine Validity Parameter
rGroupingType elements.
ValidityParamete ComparisonOperatorEnum 0:1 Nature of comparison with assignment values
rAssignmentType
4.2.1.8 ACCESS SPACE
(Part 2 - Public Transport Network Topology (NT)::FO Fixed Object MODEL ::NT Stop Place
MODEL::ACCESS SPACE)
A passenger area within a STOP PLACE such as a concourse or booking hall, immigration hall or security
area that is accessible by passengers, but without a direct access to vehicles. Direct access to a VEHICLE
is always from a QUAY and/or BOARDING POSITION. An ACCESS SPACE may be a Room, Hall, Concourse,
Corridor, or bounded open space within a STOP PLACE.
Table 14 - ACCESS SPACE – Relations
Source Target
ACCESS SPACE ACCESS SPACE
Cardinality: 0.* Cardinality: 1
Relation type: Association
ACCESS SPACE STOP PLACE
Role: in Role: containing
Cardinality: 0.*
Relation type: Aggregation
ACCESS SPACE STOP PLACE SPACE
Relation type: Generalization
Source Target
ACCESS SPACE TYPE OF PASSAGE
Role: classified as Role: a classification for
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
ACCESS SPACE ACCESS SPACE
Cardinality: 0.* Cardinality: 1
Relation type: Association
Table 15 - ACCESS SPACE – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> STOP PLACE SPACE ::> ACCESS SPACE inherits from STOP PLACE SPACE
«UID» Id AccessSpaceIdType 1:1 Identifier of ACCESS SPACE.
AccessSpaceType AccessSpaceTypeEnum 0:1 Type of ACCESS SPACE.
4.2.1.9 ACCESS ZONE
(Part 2 - Public Transport Network Topology (NT)::FO Fixed Object MODEL ::NT Site MODEL::ACCESS
ZONE)
A ZONE for which the duration to cover any ACCESS link to a particular SCHEDULED STOP POINT is the
same.
Table 16 - ACCESS ZONE – Relations
Source Target
ACCESS ZONE ZONE
Relation type: Generalization
SITE ACCESS ZONE
Role: a reference for Role: referenced by
Cardinality: 0.1 Cardinality: 0.*
Relation type: Association
Table 17 - ACCESS ZONE – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ZONE ::> ACCESS ZONE inherits from ZONE
«UID» Id AccessZoneIdType 1:1 Identifier of ACCESS ZONE.
4.2.1.10 ACCESSED FARE STRUCTURE ELEMENT
(Part 5 - Fare Management (FM)::FC Validation and Control MODEL::FC Access Right Validation
MODEL::ACCESSED FARE STRUCTURE ELEMENT)
A validated use of a FARE STRUCTURE ELEMENT, composed of CONTROLLED ACCESSes.
Table 18 - ACCESSED FARE STRUCTURE ELEMENT – Relations
Source Target
ACCESSED FARE STRUCTURE FARE STRUCTURE ELEMENT
ELEMENT
Role: consumed by
Role: validated as
Cardinality: 1
Cardinality: 0.*
Relation type: Association
VALIDATED ACCESS ACCESSED FARE STRUCTURE
ELEMENT
Role: composed of
Role: included in
Relation type: Association
Cardinality: 1.*
VALIDATION PARAMETER ACCESSED FARE STRUCTURE
ASSIGNMENT ELEMENT
Role: specifying Role: specified by
Cardinality: 0.*
Relation type: Association
CONTROLLED ACCESS ACCESSED FARE STRUCTURE
ELEMENT
Role: included in
Role: composed of
Cardinality: 0.*
Relation type: Association
Table 19 - ACCESSED FARE STRUCTURE ELEMENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ::> ACCESSED FARE STRUCTURE ELEMENT doesn't
inherit from another class
«UID» Id AccessedFareStructureEle 1:1 Identifier of ACCESSED FARE STRUCTURE
mentIdType ELEMENT.
4.2.1.11 ACCESSIBILITY ASSESSMENT
(Part 1 - Common Concepts (CC)::CC Generic Framework MODEL::CC Generic Accessibility
MODEL::ACCESSIBILITY ASSESSMENT)
The accessibility characteristics of an entity used by passengers such as a STOP PLACE, or a STOP PLACE
COMPONENT. Described by ACCESSIBILITY LIMITATIONs, and/or a set of SUITABILITies
Table 20 - ACCESSIBILITY ASSESSMENT – Relations
Source Target
ACCESSIBILITY ASSESSMENT MONITORED FACILITY
Role: describing Role: normally having
Cardinality: 0.1 Cardinality: 0.1
Relation type: Association
ACCESSIBILITY ASSESSMENT LINE
Role: characterising Role: characterised by
Cardinality: 0.1 Cardinality: 0.1
Relation type: Association
ACCESSIBILITY ASSESSMENT SITE ELEMENT
Role: characterising Role: characterised by
Cardinality: 0.1 Cardinality: 0.1
Relation type: Aggregation
ACCESSIBILITY ASSESSMENT FACILITY CONDITION
Role: implicated by Role: implicating
Cardinality: 0.1 Cardinality: 0.1
Relation type: Association
Source Target
ACCESSIBILITY ASSESSMENT PT RIDE LEG
Role: characterising Role: characterised by
Cardinality: 0.1
Relation type: Aggregation
ACCESSIBILITY ASSESSMENT PATH LINK
Role: characterising Role: characterised by
Cardinality: 0.* Cardinality: 0.1
Relation type: Aggregation
ACCESSIBILITY ASSESSMENT AVAILABILITY CONDITION
Role: determined by Role: determining
Cardinality: 0.* Cardinality: 0.*
Relation type: Association
ACCESSIBILITY ASSESSMENT PT CONNECTION LEG
Role: characterising Role: characterised by
Cardinality: 0.1
Relation type: Aggregation
TRIP ACCESSIBILITY ASSESSMENT
Role: characterised by Role: characterising
Cardinality: 0.1 Cardinality: 0.1
Relation type: Association
ACCESSIBILITY LIMITATION ACCESSIBILITY ASSESSMENT
Role: determining Role: limited by
Cardinality: 0.*
Relation type: Aggregation
VALIDITY CONDITION ACCESSIBILITY ASSESSMENT
Role: determining Role: determined by
Cardinality: 0.* Cardinality: 0.*
Source Target
Relation type: Aggregation
ACTUAL VEHICLE EQUIPMENT ACCESSIBILITY ASSESSMENT
Role: for Role: suitable
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
NAVIGATION PATH ACCESSIBILITY ASSESSMENT
Role: characterised by Role: characterising
Cardinality: 0.1 Cardinality: 0.*
Relation type: Association
CALL ACCESSIBILITY ASSESSMENT
Relation type: Dependency
SUITABILITY ACCESSIBILITY ASSESSMENT
Role: determining Role: convenient for
Cardinality: 0.*
Relation type: Aggregation
JOURNEY ACCESSIBILITY ASSESSMENT
Role: characterised by Role: characterising
Cardinality: 0.1 Cardinality: 0.1
Relation type: Association
TRIP MOBILITY FILTER ACCESSIBILITY ASSESSMENT
Role: limit to Role: determining
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
DATED CALL ACCESSIBILITY ASSESSMENT
Relation type: Dependency
TRANSFER TIME ACCESSIBILITY ASSESSMENT
Role: timing Role: assuming
Source Target
Cardinality: 0.* Cardinality: 0.1
Relation type: Association
Table 21 - ACCESSIBILITY ASSESSMENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ::> ACCESSIBILITY ASSESSMENT doesn't inherit from
another class
«UID» Id AsssesmentIdType 1:1 Identifier of ACCESSIBILITY ASSESSMENT.
MobilityImpaired boolean 0:1 Whether the overall assessment is that there is
Access Access for Mobility Impaired users.
4.2.1.12 ACCESSIBILITY LIMITATION
(Part 1 - Common Concepts (CC)::CC Generic Framework MODEL::CC Generic Accessibility
MODEL::ACCESSIBILITY LIMITATION)
A categorisation of the accessibility characteristics of a SITE, e.g. a STOP PLACE or a STOP PLACE
COMPONENT to indicate its usability by passengers with specific needs, for example, those needing
wheelchair access, step-free access or wanting to avoid confined spaces such as lifts. A small number of
well-defined categories are used that are chosen to allow the consistent capture of data and the efficient
computation of routes for different classes of user.
Table 22 - ACCESSIBILITY LIMITATION – Relations
Source Target
ACCESSIBILITY LIMITATION ACCESSIBILITY ASSESSMENT
Role: determining Role: limited by
Cardinality: 0.*
Relation type: Aggregation
ACCESSIBILITY LIMITATION TYPE OF ACCESSIBILITY LIMITATION
Role: classified by Role: a classification for
Cardinality: 0.* Cardinality: 1
Relation type: Association
Table 23 - ACCESSIBILITY LIMITATION – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ::> ACCESSIBILITY LIMITATION doesn't inherit from
another class
«UID» Id LimitationIdType 1:1 Identifier of ACCESSIBILITY LIMITATION.
WheelchairAccess LimitationStatusEnum 0:1 Whether there is Access for Wheelchair users.
StepFreeAccess LimitationStatusEnum 0:1 Whether there is Step Free Access.
EscalatorFreeAcce LimitationStatusEnum 0:1 Whether there is Escalator Free Access.
ss
LiftFreeAccess LimitationStatusEnum 0:1 Whether there is Lift Free Access.
AudibleSignsAvail LimitationStatusEnum 0:1 Whether there are Audible Signs.
able
VisualSignsAvaila LimitationStatusEnum 0:1 Whether there are Visual Signs.
ble
4.2.1.13 ACCOMODATION
(Part 1 - Common Concepts (CC)::CC Reusable Components MODEL::CC Facility
MODEL::ACCOMODATION)
A combination of accommodation characteristics available on a service, e.g. "First Class Couchette with
shower and 2 bunks".
Table 24 - ACCOMODATION – Relations
Source Target
ACCOMODATION SERVICE FACILITY SET
Relation type: Generalization
Table 25 - ACCOMODATION – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> SERVICE FACILITY SET ::> ACCOMODATION inherits from SERVICE FACILITY
SET
FareClass FareClassEnum 0:1 FARE CLASS of ACCOMMODATION.
AccommodationF AccommodationFacilityEn 0:1 Type of accommodation Facility in
acility um ACCOMMODATION.
Name MultilingualString 0:1 Name of ACCOMMODATION.
CouchetteFacility CouchetteFacilityEnum 0:1 Toilet Facility in ACCOMMODATION.
Classifi- Name Type cardinality Description
cation
ShowerFacility SanitaryFacilityEnum 0:1 Shower Facility in ACCOMMODATION.
ToiletFacility SanitaryFacilityEnum 0:1 Toilet Facility in ACCOMMODATION
«UID» Id 1:1 Identifier of ACCOMODATION.
Gender GenderLimitationEnum 0:1
BerthType BerthTypeEnum 0:1 Berth levels in compartment
NuisanceFacility NuisanceFacilityEnum 0:* Nuisance Facility in ACCOMMODATION
4.2.1.14 ACCOUNT AUTO RENEWAL EVENT
(Part 5 - Fare Management (FM)::ST Customer & Sales Transaction MODEL::SE Sales Event MODEL::SE
Customer Purchase MODEL::SE Account Sales Event MODEL::ACCOUNT AUTO RENEWAL EVENT)
The detection by an ABT System that a renewable product such as a pass needs to be renewed. Depending
on configuration may trigger either an automatic renewal or a notice to the customer.
Table 26 - ACCOUNT AUTO RENEWAL EVENT – Relations
Source Target
ACCOUNT AUTO RENEWAL EVENT ACCOUNT SALES EVENT
Relation type: Generalization
ACCOUNT AUTO RENEWAL EVENT FARE PRODUCT RENEWAL ENTRY
Role: triggering Role: recording
Cardinality: 0.1 Cardinality: 1
Relation type: Association
Table 27 - ACCOUNT AUTO RENEWAL EVENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ACCOUNT SALES EVENT ::> ACCOUNT AUTO RENEWAL EVENT inherits from
ACCOUNT SALES EVENT
«UID» id AccountAutoRenewalEvent 1:1 Identifier of ACCOUNT AUTO RENEWAL EVENT.
IdType
4.2.1.15 ACCOUNT AUTO TOP UP EVENT
(Part 5 - Fare Management (FM)::ST Customer & Sales Transaction MODEL::SE Sales Event MODEL::SE
Customer Purchase MODEL::SE Account Sales Event MODEL::ACCOUNT AUTO TOP UP EVENT)
The detection by an ABT System that the account balance has fallen below a threshold which needs to be
topped up using a preset payment method and increment.
Table 28 - ACCOUNT AUTO TOP UP EVENT – Relations
Source Target
ACCOUNT AUTO TOP UP EVENT MEDIA RECHARGE PURCHASE ENTRY
Role: triggering Role: recording
Cardinality: 0.1 Cardinality: 1
Relation type: Association
ACCOUNT AUTO TOP UP EVENT ACCOUNT SALES EVENT
Relation type: Generalization
Table 29 - ACCOUNT AUTO TOP UP EVENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ACCOUNT SALES EVENT ::> ACCOUNT AUTO TOP UP EVENT inherits from
ACCOUNT SALES EVENT
«UID» id AccountAutoTopUpEventId 1:1 Identifier of ACCOUNT AUTO TOP UP EVENT.
Type
4.2.1.16 ACCOUNT AWARD REFUND EVENT
(Part 5 - Fare Management (FM)::ST Customer & Sales Transaction MODEL::SE Sales Event MODEL::SE
Customer Purchase MODEL::SE Account Sales Event MODEL::ACCOUNT AWARD REFUND EVENT)
The detection by an ABT System that a refund needs to be awarded, for example because guaranteed
performance targets have not been met
Table 30 - ACCOUNT AWARD REFUND EVENT – Relations
Source Target
ACCOUNT AWARD REFUND EVENT TRAVEL COMPENSATION ENTRY
Role: triggering Role: recording
Cardinality: 0.1 Cardinality: 1
Relation type: Association
Source Target
ACCOUNT AWARD REFUND EVENT ACCOUNT SALES EVENT
Relation type: Generalization
Table 31 - ACCOUNT AWARD REFUND EVENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ACCOUNT SALES EVENT ::> ACCOUNT AWARD REFUND EVENT inherits from
ACCOUNT SALES EVENT
«UID» id AccountAwardRefundEven 1:1 Identifier of ACCOUNT AWARD REFUND EVENT.
tIdType
4.2.1.17 ACCOUNT DETECT ELIGIBILITY CHANGE EVENT
(Part 5 - Fare Management (FM)::ST Customer & Sales Transaction MODEL::SE Sales Event MODEL::FE
Account Security MODEL::FM FE Account Security Event MODEL::ACCOUNT DETECT ELIGIBILITY
CHANGE EVENT)
The detection by an ABT System of a change in the eligibility of a user for a product they currently own,
requiring an adjustment of some sort.
Table 32 - ACCOUNT DETECT ELIGIBILITY CHANGE EVENT – Relations
Source Target
ACCOUNT DETECT ELIGIBILITY CUSTOMER ELIGIBILITY
CHANGE EVENT
Role: detected from
Role: detect as
Cardinality: 1
Cardinality: 0.*
Relation type: Association
ACCOUNT DETECT ELIGIBILITY ACCOUNT SECURITY EVENT
CHANGE EVENT
Relation type: Generalization
ACCOUNT DETECT ELIGIBILITY CEASES TO BE ELIGIBLE ENTRY
CHANGE EVENT
Role: recording
Role: triggering
Cardinality: 1
Cardinality: 0.1
Relation type: Association
BECOMES ELIGIBLE ENTRY ACCOUNT DETECT ELIGIBILITY
CHANGE EVENT
Source Target
Role: recording Role: triggering
Cardinality: 1 Cardinality: 0.1
Relation type: Association
Table 33 - ACCOUNT DETECT ELIGIBILITY CHANGE EVENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ACCOUNT SECURITY ::> ACCOUNT DETECT ELIGIBILITY CHANGE EVENT
EVENT inherits from ACCOUNT SECURITY EVENT
«UID» id AccountDetectEligibilityCh 1:1 Identifier of ACCOUNT DETECT ELIGIBILITY
angeActionIdType CHANGE EVENT.

4.2.1.18 ACCOUNT DETECT NO CHECK IN EVENT
(Part 5 - Fare Management (FM)::FC Validation and Control MODEL::FE Control & Validation Event
MODEL::FE Account Processing MODEL::FE Account Processing Event MODEL::ACCOUNT DETECT NO
CHECK IN EVENT)
The detection that a passenger has failed to check in at the beginning of a trip. This may be triggered by
a subsequent check out or by back office processes looking for unmatched check in and check out events
within a specified window.
Table 34 - ACCOUNT DETECT NO CHECK IN EVENT – Relations
Source Target
ACCOUNT DETECT NO CHECK IN ACCOUNT PROCESSING EVENT
EVENT
Relation type: Generalization
ACCOUNT DETECT NO CHECK IN PASSENGER WAY POINT ENTRY
EVENT
Role: clue for
Role: deduced from
Cardinality: 0.*
Cardinality: 0.1
Relation type: Association
NO CHECK IN DETECTED ENTRY ACCOUNT DETECT NO CHECK IN
EVENT
Role: recorded as
Role: triggering
Cardinality: 0.1
Cardinality: 0.*
Relation type: Association
Source Target
PASSENGER CHECK OUT ENTRY ACCOUNT DETECT NO CHECK IN
EVENT
Role: clue for
Role: deduced from
Cardinality: 1
Cardinality: 1
Relation type: Association
Table 35 - ACCOUNT DETECT NO CHECK IN EVENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ACCOUNT PROCESSING ::> ACCOUNT DETECT NO CHECK IN EVENT inherits
EVENT from ACCOUNT PROCESSING EVENT
«UID» id AccountDetectNoCheckInE 1:1 Identifier of ACCOUNT DETECT NO CHECK IN
ventIdType EVENT.
4.2.1.19 ACCOUNT DETECT NO CHECK OUT EVENT
(Part 5 - Fare Management (FM)::FC Validation and Control MODEL::FE Control & Validation Event
MODEL::FE Account Processing MODEL::FE Account Processing Event MODEL::ACCOUNT DETECT NO
CHECK OUT EVENT)
The detection that a passenger has failed to check out at the end of a trip. This may be triggered by a
subsequent check in on a new journey or by back office processes looking for unmatched check in and
check out events within a specified window.
Table 36 - ACCOUNT DETECT NO CHECK OUT EVENT – Relations
Source Target
ACCOUNT DETECT NO CHECK OUT ACCOUNT PROCESSING EVENT
EVENT
Relation type: Generalization
NO CHECK OUT DETECTED ENTRY ACCOUNT DETECT NO CHECK OUT
EVENT
Role: recording
Role: triggering
Cardinality: 0.1
Cardinality: 0.*
Relation type: Association
PASSENGER CHECK IN ENTRY ACCOUNT DETECT NO CHECK OUT
EVENT
Role: clue for
Role: deduced from
Cardinality: 1
Cardinality: 1
Relation type: Association
Table 37 - ACCOUNT DETECT NO CHECK OUT EVENT – Attributes
Classifi- Name Type cardinality Description
cation
::> ::> ACCOUNT PROCESSING ::> ACCOUNT DETECT NO CHECK OUT EVENT inherits
...