EN 15531-2:2015

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.GHORYDQMDÖffentlicher Verkehr - Serviceschnittstelle für Echtzeitinformationen bezogen auf Operationen im öffentlichen Verkehr - Teil 2: KommunikationsstrukturTransport public - Interface de service pour les informations en temps réel relatives aux opérations de transport public - Partie 2 : Infrastructure des communicationsPublic transport - Service interface for real-time information relating to public transport operations - Part 2: Communications35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and tradeICS:Ta slovenski standard je istoveten z:EN 15531-2:2015SIST EN 15531-2:2015en,fr,de01-december-2015SIST EN 15531-2:2015SLOVENSKI
STANDARDSIST-TS CEN/TS 15531-2:20091DGRPHãþD

EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15531-2
August 2015 ICS 35.240.60 Supersedes CEN/TS 15531-2:2007English Version
Public transport - Service interface for real-time information relating to public transport operations - Part 2: Communications Transport public - Interface de service pour les informations en temps réel relatives aux opérations de transport public - Partie 2 : Infrastructure des communications
Öffentlicher Verkehr - Serviceschnittstelle für Echtzeitinformationen bezogen auf Operationen im öffentlichen Verkehr - Teil 2: Kommunikationsstruktur This European Standard was approved by CEN on 20 June 2015.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, 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:
Avenue Marnix 17,
B-1000 Brussels © 2015 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 15531-2:2015 ESIST EN 15531-2:2015

Figure 1 — Request / Response Interaction Request/response allows for an efficient transmission of data on-demand from the Consumer, and is extremely easy to implement using commodity internet software components. 5.1.3 Publish/Subscribe Pattern The Publish/Subscribe interaction (see Figure 2) allows for the asynchronous detection of real-time events by a producer service, whose role is to generate and send notifications to one or more interested consumers. In the Publish/Subscribe interaction, the Subscriber client sends a request message to the Notification Producer of a SIRI Functional Service to create a Subscription, which may or may not be granted. The Subscriber expresses its specific interests through Topic and Subscription Policy parameters, and receives an acknowledgement that this has been created, or an error condition. Once a Subscription exists, the service, acting as the Notification Producer, uses it to determine when to send a notification to a consumer after a Situation, i.e. event is detected. The incoming event notification to be published is matched against the interests expressed by the Topic and other filter parameters of the Subscription and if satisfied, a notification message is sent to the Consumer. The actual Notification Message Delivery may be made either as a one-step Direct Delivery to a Notification Consumer, or as a two-step SIRI Fetched Delivery, with separate message pairs first to notify and then to deliver the payload. In SIRI, the Subscriber and Consumer roles are normally implemented by the same client service, although they are logically separate. Every Consumer shall know its Subscriber so that they can interact to handle recovery from service failures. Subscriptions for different types of SIRI Functional Service are managed separately. A Subscriber may add different Subscriptions at different times. A Subscription Request includes an Initial Termination Time indicating the desired duration i.e. lease of the individual Subscription. The subscription will only be granted if this can be met, otherwise an error will be returned. Subscriptions have a life span as specified by the Subscriber, and will be terminated by the Notification Producer service when they reach their expiry time. Subscribers may terminate their own existing Subscriptions before their predefined expiry time through a Subscription Manager. The Subscription Manager is subordinate to the Notification Producer, and in SIRI implementations, is normally provided by the same entity, although logically distinct. Each Subscription Manager knows its associated Notification Producer, and vice versa. Although the Notification Producer is the factory for creating new subscriptions, it does not manage them once created; rather this is done by the SIST EN 15531-2:2015

Figure 2 — Simple Publish/Subscribe Interaction Subscriptions are a stateful resource: they need a unique identifier that can be used by Subscriber, Producer and Consumer to refer to the same subscription on different occasions. They will each hold their own representation of the subscription. In SIRI this identifier is issued by the Subscriber. Publish/Subscribe allows for an efficient regular event driven exchange of updates to data. It requires a more elaborate implementation, with the holding of state by both participants and the dedication of computing resources to run the notification production. 5.1.4 Publish/Subscribe with Broker Pattern The WS-PubSub architecture also allows for the logical separation of the concerns of Publishing and Notification Production, and in its fully articulated form, has a separate Publisher role that is a subordinate constituent of the Notification Producer service (see Figure 3). The Publisher produces notifications of any significant situations, i.e. events. For a real-time service, the Publisher monitors the real-time data and if a change has occurred, it produces a notification. The Notification Producer then matches the Notification with the interests and policies expressed by Subscribers and despatches the notification delivery to the Notification Consumer indicated by the Subscription. It is possible to have more than one Notification Producer sitting between the Publisher and the Consumer, either to carry out successive types of filtering and processing of the notifications, or for scalability. WS-PubSub distinguishes between direct notification – where the notification message from the Publisher is delivered unchanged, and brokered notification – where the Notification Producer filters and also possibly transforms the message. Both brokered (e.g. for SIRI Stop Monitoring) and unbrokered (e.g. for SIRI General Message) mediation occurs in different SIRI Functional Services. SIST EN 15531-2:2015

Figure 3 — Brokered Publish/Subscribe Interaction Further Subscription and Subscriber filtering tasks, in particular the enforcement of SIRI Access controls, are implemented by the Notification Producer, not the Publisher. 5.1.5 Request/Response – Compound Requests Multiple requests for a single SIRI Functional Service may be included in a single Data Request/Response interaction: each request may cover different topics and policies (Figure 4).
Figure 4 — Request/Response: Compound Requests SIST EN 15531-2:2015

Figure 5 — Publish/Subscribe: Compound Subscriptions 5.2 Delivery Patterns 5.2.1 Introduction Services return notifications and Situation content to the Consumer using Delivery messages. In real-time applications, it is important to be able to optimise systems to ensure rapid delivery, and SIRI supports two different message pattern variations for making a delivery, that in principle can be used interchangeably: these are; (i) Direct Delivery, and; (ii) Fetched Delivery. The choice of delivery patterns may be pre-configured, or if the implementation supports both methods, be specified as a parameter on the request. For systems that support dynamic choice, if the SIRI implementation does not support the requested delivery method for a specific service type, an error message will be returned. 5.2.2 Direct Delivery In Direct Delivery, the payload is sent as the content of a single message to the Consumer Client (Figure 6). For a Request/Response this will be the requestor. For a subscription this will be the Notification Consumer as indicated on the Subscription (i.e. the notification and the delivery are the same message.).
Figure 6 — One Step Direct Delivery In Direct Delivery, the burden of holding and queuing messages is distributed to the client, with some advantages for scaling, as the central server needs neither retain data, nor allocate computation resource to service the additional data supply steps. The interaction is simpler, with fewer messages being exchanged, SIST EN 15531-2:2015

Figure 7 — Fetched Delivery Fetched Delivery is a stateful pattern of interaction in its own right – requiring the ability of both parties to refer to the data update by a reference that persists for its currency. In this case the reference is issued by the Producer. Whether the identifier needs to be exposed to the Consumer depends on the mediation model (see later): if all updates are aggregated through a single subscriber channel, then there is only one data set to fetch, and an explicit reference is not needed Fetched Delivery allows the Consumer to defer the sending of the full payload until it is ready to process it: if in the meantime the Situation has changed further, and a new notification message has arisen, only the latest update need be exchanged. This can give a more efficient use of bandwidth for applications that are bandwidth constrained. In addition, notifications are small messages that can typically be examined using less computational resource than a full delivery message containing a payload, so if the majority of updates are discarded (i.e. never fetched); the processing load on the Consumer may be less. Similarly, the storage requirement on the Consumer to queue small notification messages for Fetched Delivery is less than the storage requirement to queue larger payload messages for Direct Delivery (but larger on the Notification Producer to retain it until fetched). As a trade-off, there is additional computational and communication overhead required to conduct the extra interactions of fetched data supply messages, and also an additional latency to carry it out (in particular a fourfold communication overhead). SIST EN 15531-2:2015

Figure 8 — Fetched Delivery for Publish/Subscribe For completeness, we note that Fetched Delivery can also be used for the delivery of responses in a Request/Response interaction (Figure 9). 5.2.4 Data Horizon for Fetched Delivery For Fetched Delivery, implementations may vary as to how long the data notified as ready will still be available to be fetched. At a minimum the most recent update shall be available until it is stale, i.e. has reached the end of its currency time, or is superseded by another update. Some implementations may choose to keep previous updates available within a longer data horizon, for example the current day, and support historic access to a log of previous updates. For further considerations as to the contents of fetched delivery, see discussion of Mediation Behaviour below. SIST EN 15531-2:2015

Figure 9 — Fetched Delivery for Request/Response 5.2.5 Get Current Message The SIRI Data Supply Request may be used by itself without a previous notification to get the current data. This corresponds to the WS-PubSub capability of ‘Get Current Message’, which allows a Consumer to get the current messages published for a given subscription. In normal WS-PubSub usage this is a non-destructive read: the current data can be reread many times, provided the data is still relevant. The SIRI Data Supply Request has a parameter which can be used to optimise usage: ‘return latest’ i.e. whether to return only the most recent update for the subscription. (Return latest is in fact the default; the opposite, ‘return all’ has to be explicitly specified on a request.) ‘Return latest’ cannot be repeated to obtain the same data, since once delivered, a new latest time will be held for the subscription. In SIRI one of the mediations carried out by the Notification Producer (see later below) is to aggregate the individual subscriptions of a particular subscriber into a Subscription Channel. In effect, for each subscriber for each service, the Notification Producer keeps a Subscription channel or Filter: all subscriptions from the Subscriber are normally assigned to the Subscription Filter. This means that a SIRI Get Current Message request may need to indicate whether to return; (i) the latest data for a specific Subscription (the normal WS-PubSub interpretation); (ii) the latest data for a particular Subscriber Filter (i.e. group of subscriptions belonging to a single subscriber); or (iii) the latest data for a particular Subscriber (i.e. group of all the Subscriber Filters belonging to a particular Subscriber). Support of ‘return latest’ is a required SIRI Feature. Support for Get Current Message with ‘return all’ is a required feature of WS-PubSub: a SIRI implementation will need to support it in order to be able to return a full data set to new subscribers who have just joined. 5.2.6 Multipart Despatch of a Delivery If the amount of data to be delivered is large, some implementations allow the Producer to break the data supply step up into multiple messages, which the Consumer can then assemble into a single update (Figure 10). This has further implications for any recovery processes and is discussed in more detail later. SIST EN 15531-2:2015

Figure 10 — Multipart Delivery 5.2.7 Multipart Despatch of a Fetched Delivery – MoreData The data for a single subscription shall be completely included within a single Delivery. Data for a Fetched Delivery may only be split into separate messages if it is for different subscriptions for the same subscriber. For multipart despatch, on the Service Delivery message the MoreData element indicates whether the content of a DataSupplyResponse contains all the updated data, or whether for implementation reasons, the transmission has been split into several sub-messages, requiring retrieval by the consumer with a series of chained data DataSupplyRequests; see Figure 11. Each Data Supply Delivery response message in the chain indicates that there is further data by means of a MoreData value of “true”; in the last data supply response message, the MoreData element is set to “false”.
Figure 11 — Fetched Multipart Delivery SIST EN 15531-2:2015

Figure 12 — Mediation: Update Tracking and sensitivity threshold for Direct Delivery In a Fetched Delivery interaction, there may be a delay between the despatch of a Notification that a new update exists to the Consumer and the despatch of the Data Delivery message – which occurs only in response to an explicit Data Supply request from the Consumer. In the meantime, further situations may occur in the interim, giving rise to further notifications from the Publisher to the Notification Producer (but not to the Consumer – the Notification Producer also retains state that a notification has already been issued). The data delivery, when finally made, shall represent the most current position: the data supply message shall include all known subsequent data events that have taken place since the time of last data supply. This is shown in Figure 13 for a Fetched Delivery sequence. On subscription, the Producer checks if there is any current data (1.1, 1.2) according to the subscription topic and if so, sends a data ready notification (#1) to the Consumer. When the Consumer requests the data supply, the Producer recomputes the current data (1.1, 1.2) and sends it to the Consumer. The time (T1) of supply is recorded against the individual subscription. Subsequent notifications from the Publisher (2.1, 2.2) are filtered until the sensitivity threshold is exceeded, at whic
...