M/456 - Vapour recovery equipment

The main objective of this WI is to define a SIRI Passenger Real-Time Information European profile:
•   To identify a minimum subset of SIRI with codification rules and constraints for a European level plug and play exchange of real-time passenger information data between organisations at a European level
•   To reflect already existing NeTEx profiles defined at national level (Norway, France, Sweden, etc.).
•   To maintain a relevant real-time information dataset, as small and simple as possible, to ensure interoperability is maximised while at the same time enabling exchange of supplementary national real-time data that will not interfere with the core international dataset
•   To complement the EPIP (NeTEx European Passenger Information Profile) with real-time passenger information
•   To establish quality assessment procedures for implementing validation and quality assessment tools - including compliance checking rules - necessary to fulfil the requirement of the Commission
This profile will complement the NeTEx Passenger information profile and NeTEx Accessibility profile (under drafting) in order to get a set of consistent European profiles fulfilling the requirements of the Priority Action "A" of the ITS Directive.

The main objective of this WI is to define a SIRI Passenger Real-Time Information European profile:
•   To identify a minimum subset of SIRI with codification rules and constraints for a European level plug and play exchange of real-time passenger information data between organisations at a European level
•   To reflect already existing NeTEx profiles defined at national level (Norway, France, Sweden, etc.).
•   To maintain a relevant real-time information dataset, as small and simple as possible, to ensure interoperability is maximised while at the same time enabling exchange of supplementary national real-time data that will not interfere with the core international dataset
•   To complement the EPIP (NeTEx European Passenger Information Profile) with real-time passenger information
•   To establish quality assessment procedures for implementing validation and quality assessment tools - including compliance checking rules - necessary to fulfil the requirement of the Commission
This profile will complement the NeTEx Passenger information profile and NeTEx Accessibility profile (under drafting) in order to get a set of consistent European profiles fulfilling the requirements of the Priority Action "A" of the ITS Directive.

The Technical Specification will be adapted in the following way:
•   OJP will be realigned with the latest Transmodel version and NeTEx issues, where appropriate (e.g.
        New Modes)
•   The integration of new modes especially the conceptual equivalency to major multi-modal standards
        shall be studied and if necessary, adaptions to OJP occur. The idea is to study OSDM, TOMP, TRIAS
        and GBFS/GOFS. The interactions should be smooth. Interaction between OJP and distribution
        features will be settled.
•   OJP is extended as far into the distribution area as it is considered a good idea. For the actual
        booking and purchase steps, OSDM, TOMP, TRIAS and/or GOFS are to be used. The line we think to
        draw is: booking. OJP should not transfer personalized information. This results in the following
        proposed adaptions to fit OJP into a full MaaS roaming environment:
o   An availability request (with response)
o   Token/id handling for trips and trip legs (for hand-over) and pushed information during trips. We will
        need to model bookable items on some level.
o   OJPFare needs to be extended/adapted.
o   TripInfoRequest and -Response need to be updated to reflect, information about trips and trip legs
        and not only vehicle and journey.
•   All work prepared under the heading OJP 1.1 will be finalised.
•   EPIAP (Accessibility) minimal profile will be used to verify that the trip planning can make use of it.
•   The provision of an OpenAPI and REST/JSON derived directly from the XSD shall be studied
        (eventually using a converter).

The Technical Specification will be adapted in the following way:
•   OJP will be realigned with the latest Transmodel version and NeTEx issues, where appropriate (e.g.
        New Modes)
•   The integration of new modes especially the conceptual equivalency to major multi-modal standards
        shall be studied and if necessary, adaptions to OJP occur. The idea is to study OSDM, TOMP, TRIAS
        and GBFS/GOFS. The interactions should be smooth. Interaction between OJP and distribution
        features will be settled.
•   OJP is extended as far into the distribution area as it is considered a good idea. For the actual
        booking and purchase steps, OSDM, TOMP, TRIAS and/or GOFS are to be used. The line we think to
        draw is: booking. OJP should not transfer personalized information. This results in the following
        proposed adaptions to fit OJP into a full MaaS roaming environment:
o   An availability request (with response)
o   Token/id handling for trips and trip legs (for hand-over) and pushed information during trips. We will
        need to model bookable items on some level.
o   OJPFare needs to be extended/adapted.
o   TripInfoRequest and -Response need to be updated to reflect, information about trips and trip legs
        and not only vehicle and journey.
•   All work prepared under the heading OJP 1.1 will be finalised.
•   EPIAP (Accessibility) minimal profile will be used to verify that the trip planning can make use of it.
•   The provision of an OpenAPI and REST/JSON derived directly from the XSD shall be studied
        (eventually using a converter).

This document specifies an additional SIRI functional service to exchange information about Control Actions, between monitoring systems and servers containing real-time public transport vehicle or journey time data. These include the control centres of transport operators, as well as information systems that deliver passenger travel information services. As for Transmodel, public transport modes include new modes of transport (vehicle sharing, vehicle pooling, etc.).
This document describes the SIRI Control Action service, one of a modular set of services for the exchange of Real-time information. The Control Action service (SIRI-CA) is concerned with the exchange of information about decision made concerning the real-time management of the operation of a transport system as performed by operators while operating the services.

This document is a profile of the CEN/TS 16614 series. It focuses on information relevant to feed the necessary accessibility passenger information services and excludes operational and fares information. It is based directly on EPIP (CEN/TS 16614-4).
This European Passenger Information Accessibility Profile (EPIAP) for NeTEx is for exchanging passenger information; it describes how to extend EPIP (the European Passenger Information Profile) with additional information (including a minimal set) to feed the necessary accessibility passenger information services in a European wide and multimodal context. EPIAP especially formulates a mandatory minimal implementation that needs to be filled in by everybody to deliver the necessary information for an assessment of the accessibility of site(s), vehicles and on vehicle-site interaction for impaired persons. The minimal level allows an assessment and contains the information to produce PRM TSI if necessary. It will also cover what the current legislation usually warrants. It then describes how additional information must be provided if an organisation decides to provide it (e.g. the information of the full DELFI+ standard in Germany).
EPIP does not reflect part 5 (New Modes) yet. However, EPIAP takes it into account. EPIP will have to be adapted accordingly.
For EPIAP to be of use, the EC needs to declare the minimal level of EPIAP as mandatory.

This document specifies an additional SIRI functional service to exchange information about Control Actions, between monitoring systems and servers containing real-time public transport vehicle or journey time data. These include the control centres of transport operators, as well as information systems that deliver passenger travel information services. As for Transmodel, public transport modes include new modes of transport (vehicle sharing, vehicle pooling, etc.).
This document describes the SIRI Control Action service, one of a modular set of services for the exchange of Real-time information. The Control Action service (SIRI-CA) is concerned with the exchange of information about decision made concerning the real-time management of the operation of a transport system as performed by operators while operating the services.

This document is a profile of the CEN/TS 16614 series. It focuses on information relevant to feed the necessary accessibility passenger information services and excludes operational and fares information. It is based directly on EPIP (CEN/TS 16614-4).
This European Passenger Information Accessibility Profile (EPIAP) for NeTEx is for exchanging passenger information; it describes how to extend EPIP (the European Passenger Information Profile) with additional information (including a minimal set) to feed the necessary accessibility passenger information services in a European wide and multimodal context. EPIAP especially formulates a mandatory minimal implementation that needs to be filled in by everybody to deliver the necessary information for an assessment of the accessibility of site(s), vehicles and on vehicle-site interaction for impaired persons. The minimal level allows an assessment and contains the information to produce PRM TSI if necessary. It will also cover what the current legislation usually warrants. It then describes how additional information must be provided if an organisation decides to provide it (e.g. the information of the full DELFI+ standard in Germany).
EPIP does not reflect part 5 (New Modes) yet. However, EPIAP takes it into account. EPIP will have to be adapted accordingly.
For EPIAP to be of use, the EC needs to declare the minimal level of EPIAP as mandatory.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V6 (EN 12896 series) and SIRI (CEN/TS 15531-4/-5 and EN 15531-1/-2/-3) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   Many NeTEx concepts are taken directly from Transmodel; the definitions and explanation of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptions in order to fit the NeTEx context.
Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional requirements that apply specifically to air transport.
1.3   Compatibility with existing standards and recommendations
Concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train composition and facilities; planned passing times; timetable versions and validity conditions.
In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) - TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.
As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (The Netherlands) and NOPTIS (Nordic Public Transport Interface Standard).
The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information) based on Transmodel V5.1 (EN 12986), IFOPT (CEN/TS 28701) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3 ) and supports information exchange of relevance to public transport services for passenger information and AVMS systems.
NOTE   Many NeTEx concepts are taken directly from Transmodel and IFOPT; the definitions and explanation of these concepts are extracted directly from the respective standards and reused in NeTEx, sometimes with further adaptions in order to fit the NETEx context.
The data exchanges targeted by NeTEx are predominantly oriented towards passenger information and also for data exchange between transit scheduling systems and AVMS (Automated Vehicle Monitoring Systems). However it is not restricted to these purposes, and NeTEx can provide an effective solution to many other use cases for transport exchange.
1.2   Transport modes
Most public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tram-way, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional provisions that apply especially to air transport.
1.3   Compatibility with existing standards and recommendations
The concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train com-position and facilities; planned passing times; timetable versions and validity conditions.
In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) – TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.
As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (Netherland) and NOPTIS (Nordic Public Transport Interface Standard).
The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information) based on Transmodel V5.1 (EN 12986), IFOPT (CEN/TS 28701) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3 ) and supports information exchange of relevance to public transport services for passenger information and AVMS systems.
NOTE   Many NeTEx concepts are taken directly from Transmodel and IFOPT; the definitions and explanation of these concepts are extracted directly from the respective standards and reused in NeTEx, sometimes with further adaptions in order to fit the NETEx context.
The data exchanges targeted by NeTEx are predominantly oriented towards passenger information and also for data exchange between transit scheduling systems and AVMS (Automated Vehicle Monitoring Systems). However it is not restricted to these purposes, and NeTEx can provide an effective solution to many other use cases for transport exchange.
1.2   Transport modes
Most public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tram-way, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional provisions that apply especially to air transport.
1.3   Compatibility with existing standards and recommendations
The concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train com-position and facilities; planned passing times; timetable versions and validity conditions.
In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) – TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.
As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (Netherland) and NOPTIS (Nordic Public Transport Interface Standard).
The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V5.1 (EN 12986), IFOPT (EN 28701) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3 ) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   NeTEx is a refinement and an implementation of Transmodel and IFOPT; the definitions and explanations of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptations in order to fit the NeTEx context. Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2   Fares scope
This Part3 of NeTEx, is specifically concerned with the exchange of fare structures and fare data, using data models that relate to the underlying network and timetable models defined in Part1 and Part2 and the Fare Collection data model defined in Transmodel V51. See the use cases below for the overall scope of Part3. In summary, it is concerned with data for the following purposes:
(i)   To describe the many various possible fare structures that arise in public transport (for example, flat fares, zonal fares, time dependent fares, distance-based fares, stage fares, pay as you go fares, season passes, etc., etc.).
(ii)   To describe the fare products that may be purchased having these fare structures and to describe the conditions that may attach to particular fares, for example if restricted to specific groups of users, or subject to temporal restrictions. These conditions may be complex.
(i)   To allow actual price data to be exchanged. Note however that NeTEx does not itself specify pricing algorithms or how fares should be calculated. This is the concern of Fare Management Systems. It may be used may be used to exchange various parameters required for pricing calculations that are needed to explain or justify a fare.
(iii)   To include the attributes and the text descriptions necessary to present fares and their conditions of sale and use to the public.
NeTEx should be regarded as being ‘upstream’ of retail systems and allows fare data to be managed and integrated with journey planning and network data in public facing information systems. It is complementary to and distinct from the ‘downstream’ ticketing and retail systems that sell fares and of the control systems that validate their use. See ‘Excluded Use Cases’ below for further information on the boundaries of NeTEx with Fare Management Systems.
1.3   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports, air journeys, and air fares, but there has not been any specific consideration of any additional requirements that apply specifically to air transport.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V6 (EN 12896 series) and SIRI (CEN/TS 15531-4/-5 and EN 15531-1/-2/-3) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   Many NeTEx concepts are taken directly from Transmodel; the definitions and explanation of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptions in order to fit the NeTEx context.
Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional requirements that apply specifically to air transport.
1.3   Compatibility with existing standards and recommendations
Concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train composition and facilities; planned passing times; timetable versions and validity conditions.
In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) - TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.
As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (The Netherlands) and NOPTIS (Nordic Public Transport Interface Standard).
The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V5.1 (EN 12986), IFOPT (EN 28701) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3 ) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   NeTEx is a refinement and an implementation of Transmodel and IFOPT; the definitions and explanations of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptations in order to fit the NeTEx context. Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2   Fares scope
This Part3 of NeTEx, is specifically concerned with the exchange of fare structures and fare data, using data models that relate to the underlying network and timetable models defined in Part1 and Part2 and the Fare Collection data model defined in Transmodel V51. See the use cases below for the overall scope of Part3. In summary, it is concerned with data for the following purposes:
(i)   To describe the many various possible fare structures that arise in public transport (for example, flat fares, zonal fares, time dependent fares, distance-based fares, stage fares, pay as you go fares, season passes, etc., etc.).
(ii)   To describe the fare products that may be purchased having these fare structures and to describe the conditions that may attach to particular fares, for example if restricted to specific groups of users, or subject to temporal restrictions. These conditions may be complex.
(i)   To allow actual price data to be exchanged. Note however that NeTEx does not itself specify pricing algorithms or how fares should be calculated. This is the concern of Fare Management Systems. It may be used may be used to exchange various parameters required for pricing calculations that are needed to explain or justify a fare.
(iii)   To include the attributes and the text descriptions necessary to present fares and their conditions of sale and use to the public.
NeTEx should be regarded as being ‘upstream’ of retail systems and allows fare data to be managed and integrated with journey planning and network data in public facing information systems. It is complementary to and distinct from the ‘downstream’ ticketing and retail systems that sell fares and of the control systems that validate their use. See ‘Excluded Use Cases’ below for further information on the boundaries of NeTEx with Fare Management Systems.
1.3   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports, air journeys, and air fares, but there has not been any specific consideration of any additional requirements that apply specifically to air transport.

This European Standard specifies the test methods for verification of vapour recovery systems at service stations (Stage II).
This European Standard does not specify the test method for the air and vapour tightness testing of the vapour recovery systems at service stations.

This European Standard specifies the measurement and test methods for the efficiency assessment of petrol vapour recovery systems for service stations (Stage II).

This European Standard specifies the test methods for verification of vapour recovery systems at service stations (Stage II).
This European Standard does not specify the test method for the air and vapour tightness testing of the vapour recovery systems at service stations.

This European Standard specifies the measurement and test methods for the efficiency assessment of petrol vapour recovery systems for service stations (Stage II).

This Standard defines an additional data concept that may be transferred as an ‘optional additional data concept’ as defined in EN 15722 eCall MSD, that may be transferred from a goods carrying vehicle to a PSAP in the event of a crash or emergency via an eCall communication session. Two variants are provided, one (schema A) for use where information about the goods (ADR classified or not) is known in the eCall device; the second variant (schema B) is for use where such information is to be fetched from elsewhere.
NOTE: This Standard is complementary and additional to EN 15722; and contains as little redundancy as possible.
The communications media protocols and methods for the transmission of the eCall message are not specified in this Standard. Its contents are independent of the protocols and methods used.
Other additional data concepts may also be transferred, and any such data concepts should be registered using a data registry as defined in EN ISO 24978. See www.esafetydata.com for an example.

This Standard defines an additional data concept that may be transferred as an ‘optional additional data concept’ as defined in EN 15722 eCall MSD, that may be transferred from a goods carrying vehicle to a PSAP in the event of a crash or emergency via an eCall communication session. Two variants are provided, one (schema A) for use where information about the goods (ADR classified or not) is known in the eCall device; the second variant (schema B) is for use where such information is to be fetched from elsewhere.
NOTE: This Standard is complementary and additional to EN 15722; and contains as little redundancy as possible.
The communications media protocols and methods for the transmission of the eCall message are not specified in this Standard. Its contents are independent of the protocols and methods used.
Other additional data concepts may also be transferred, and any such data concepts should be registered using a data registry as defined in EN ISO 24978. See www.esafetydata.com for an example.

This document specifies the "Fast Service Announcement Protocol" (FSAP).
FSAP is in support of locally advertised ITS services uniquely identified by an ITS application identifier (ITS-AID).
This document specifies message formats and related basic protocol procedures by reference to ISO/TS 16460:2016, and further related protocol requirements for operation of FSAP in the context of an ITS station specified in ISO 21217:2014.

This document specifies the "Fast Service Announcement Protocol" (FSAP).
FSAP is in support of locally advertised ITS services uniquely identified by an ITS application identifier (ITS-AID).
This document specifies message formats and related basic protocol procedures by reference to ISO/TS 16460:2016, and further related protocol requirements for operation of FSAP in the context of an ITS station specified in ISO 21217:2014.

This document defines new modes in a reference data model, in order to allow integration of these modes into urban multimodal travel services (e.g. trip planning systems).

This document defines new modes in a reference data model, in order to allow integration of these modes into urban multimodal travel services (e.g. trip planning systems).