{"id":583,"date":"2020-02-17T05:20:03","date_gmt":"2020-02-17T05:20:03","guid":{"rendered":"http:\/\/itsreferencehandbook.albrechtconsult.com\/?page_id=583"},"modified":"2020-02-17T05:25:42","modified_gmt":"2020-02-17T05:25:42","slug":"forecast-and-realtime-event-information-2","status":"publish","type":"page","link":"https:\/\/itsreferencehandbook.albrechtconsult.com\/?page_id=583","title":{"rendered":"SRTI &#8211; Forecast and Realtime Event Information"},"content":{"rendered":"<h4><strong>Service Definition<\/strong><\/h4>\n<p>\u201cForecast and Realtime Event Information\u201d are defined as the provision of information about both expected and unexpected Events to road users on identified segments of the road network and interfaces. This predictive or real-time event information could be provided on-trip and pre-trip using different information channels, accessible by the road user via different end-user devices. The service may comprise common information as well as individual (personalised, on-demand) information.<\/p>\n<p><span lang=\"EN-GB\">\u201cEvents\u201d are defined as &#8211; expected or unexpected \u2013 abnormal situations which may lead to adverse effects on the road as regards to traffic safety, efficiency and environmental effects.<\/span><\/p>\n<h4><strong>Functional Requirements<\/strong><\/h4>\n<h5><strong>Functional architecture<\/strong><\/h5>\n<p>The function of the service is to provide forecast and real-time event information to road users either pre-trip or on-trip. This may be demand responsive or led by the information providers. In Europe, both private and public information providers are involved in this information provision (see organisational requirements).<\/p>\n<p>The following figure shows the typical functional architecture of a \u201c<span style=\"display: inline !important; float: none; background-color: #ffffff; color: #141412; cursor: text; font-family: 'Source Sans Pro',Helvetica,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;\">Forecast and Realtime Event Information<\/span>\u201d. The vertical lines drawn between sub-function 1, 2 and 3 show, where it is appropriate to segment the whole functionality of the service into at most three sub-functions:<\/p>\n<figure id=\"attachment_187\" aria-describedby=\"caption-attachment-187\" style=\"width: 945px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-187 size-full\" src=\"http:\/\/itsreferencehandbook.albrechtconsult.com\/wp-content\/uploads\/2020\/02\/Fig_23.png\" alt=\"\" width=\"945\" height=\"352\" srcset=\"https:\/\/itsreferencehandbook.albrechtconsult.com\/wp-content\/uploads\/2020\/02\/Fig_23.png 945w, https:\/\/itsreferencehandbook.albrechtconsult.com\/wp-content\/uploads\/2020\/02\/Fig_23-300x112.png 300w, https:\/\/itsreferencehandbook.albrechtconsult.com\/wp-content\/uploads\/2020\/02\/Fig_23-768x286.png 768w\" sizes=\"auto, (max-width: 945px) 100vw, 945px\" \/><figcaption id=\"caption-attachment-187\" class=\"wp-caption-text\">Figure 23: Functional architecture of the service and decomposition in three sub-functions<\/figcaption><\/figure>\n<p><u>Functional requirement:<\/u><\/p>\n<ul>\n<li><strong>FR1<\/strong>: Functional decomposition into sub-functions with the provision of interfaces <span style=\"color: #bd0808;\"><strong>must<\/strong> <\/span>be carried out to enable interoperability in cases that the service is carried out by more than one organisation<\/li>\n<\/ul>\n<p><u>Functional Advice<\/u><u>:<\/u><\/p>\n<p style=\"padding-left: 40px;\">Functional decomposition is recommended in any case to be prepared to involve yet further parties as may be the case in the future<\/p>\n<h5><strong>Functional decomposition<a href=\"#_ftn1\" name=\"_ftnref1\">[1]<\/a> and interfaces<\/strong><\/h5>\n<p><a href=\"#_ftnref1\" name=\"_ftn1\">[1]<\/a> The ITS service is &#8222;distributed&#8220; over more than one administration (cross-border, cross-regional) for operation, i.e. different road operators and other parties are involved, providing &#8222;logical sub-functions&#8220;. Between the distributed functions interoperability must be guaranteed by properly specified interfaces.<\/p>\n<h6><strong>Sub-function 1 \u201cData collection\u201d<\/strong><\/h6>\n<p>Devices, tools and methodologies for traffic data collection are not covered by this deployment guideline. They depend amongst other things on the particular data collection system used and are left to the operator to select.<\/p>\n<p><strong>Note:<\/strong> &#8222;Data collection&#8220; is not only done by automatic data collection systems. &#8222;Events&#8220; are also announced\/signalled by so called non-technical sources such as police, fire brigades, local authorities, road users as well as &#8222;generated&#8220; by actions of the road operator.<\/p>\n<p><u>Functional requirements:<\/u><\/p>\n<ul>\n<li><strong>FR2<\/strong>: All data and information collected\/signalled\/generated by both automatic and non-technical sources\/road operator actions <strong><span style=\"color: #bd0808;\">must<\/span> <\/strong>contain:\n<ul>\n<li>where applicable, a location code and<\/li>\n<li>a time stamp.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p style=\"padding-left: 40px;\">The geographical basis of the location code should be left to the road operator to define, anyway the model of Information provision must respect DATEX II location reference and time stamp models.<\/p>\n<ul>\n<li><strong>FR3<\/strong>: Beneath real time data also historic data <span style=\"color: #bd0808;\"><strong>should<\/strong> <\/span>be used to generate Safety-Related &amp; Real-Time Traffic Information.<\/li>\n<\/ul>\n<h6><strong>Sub-function 2 \u201cData fusion and processing\u201d<\/strong><\/h6>\n<p><strong>Note<\/strong>: &#8222;Data fusion and procession&#8220; includes \u201cdata validation and certification\u201d.<\/p>\n<p>Within Europe different methodologies exist to aggregate collected data and other input information for <span style=\"display: inline !important; float: none; background-color: #ffffff; color: #141412; cursor: text; font-family: 'Source Sans Pro',Helvetica,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;\">Forecast and Realtime Event Information<\/span>. These methodologies are not covered by the present guideline and are left to the operator to select. They depend amongst others on the particular data fusion and processing system used and particular traffic model applied.<\/p>\n<p><u>Functional requirements:<\/u><\/p>\n<ul>\n<li><strong>FR4:<\/strong> Source, scope and quality (based on a quality model to be defined) of data provided by content owners<a href=\"#_ftn1\" name=\"_ftnref1\">[1]<\/a> to content providers <span style=\"color: #ff0000;\"><strong>must<\/strong> <\/span>be defined by the partners and must be part of data interface description.<\/li>\n<li><strong>FR5<\/strong>: The quality of the data <strong><span style=\"color: #ff0000;\">should<\/span> <\/strong>not only be defined but should also be in line with the EU-EIP Quality Package<\/li>\n<\/ul>\n<h6><strong>Sub-function 3 \u201cInformation provision\u201d<\/strong><\/h6>\n<p>Information provision is carried out by different service providers in accordance with specific business models. The information provision to the road user on end-user devices has to be done using various information channels. When providing customer-oriented <span style=\"display: inline !important; float: none; background-color: #ffffff; color: #141412; cursor: text; font-family: 'Source Sans Pro',Helvetica,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;\">Forecast and Realtime Event Information<\/span> services, the users&#8216; benefit can be increased by providing information in combination with additional traffic information (i.e. see TMS-DG07 &#8211; Traffic Management for corridors and networks)<\/p>\n<p><u>Functional requirements:<\/u><\/p>\n<ul>\n<li><strong>FR6<\/strong>: All stakeholders and partners involved in the value chain of Safety-Related &amp; Real-Time Traffic Information service <strong><span style=\"color: #bd0808;\">should<\/span> <\/strong>formally agree and accept under which conditions information can be disseminated to the end user, for example:\n<ul>\n<li>without any restrictions whatsoever<\/li>\n<li>tied to the conditions of an appropriate partnership agreement<\/li>\n<\/ul>\n<\/li>\n<li><strong>FR7<\/strong>: Underlying the information provision (information channels and end user devices), where applicable, the area (territory) and locations of information dissemination <strong><span style=\"color: #bd0808;\">should<\/span> <\/strong>be defined in relation to the media used<\/li>\n<\/ul>\n<h4><strong>Interface Requirements<\/strong><\/h4>\n<p><strong>Note<\/strong>: If the <span style=\"display: inline !important; float: none; background-color: #ffffff; color: #141412; cursor: text; font-family: 'Source Sans Pro',Helvetica,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;\">Forecast and Realtime Event Information<\/span> is &#8222;distributed&#8220; over more than one administration (cross-border, cross-regional) for operation, i.e. different road operators and other parties are involved, providing &#8222;logical sub-functions&#8220;, interoperability between the distributed functions must be guaranteed by properly specified interfaces.<\/p>\n<p><u>Interface requirement interface 1:<\/u><\/p>\n<ul>\n<li><strong>FR8<\/strong>: To enable interoperability between all involved parties the sub-functions &#8222;data collection and &#8222;data fusion and processing&#8220; and <strong><span style=\"color: #ff0000;\">must<\/span> <\/strong>&#8211; depending on the used data type for the automatic event detection require\/provide an interface 1 with at least one or several of the following information structures:\n<ul>\n<li>traffic volume and speed, occupation rate (e. g. collected by loops, radar, video\u2026)<\/li>\n<li>trajectories (travel time per itinerary e. g. collected by APNR &#8211; automatic number plate recognition, video\u2026)<\/li>\n<li>travel time (e. g. collected by FCD, Navigation Systems, Phone Data, \u2026)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><u>Interface requirement interface 2:<\/u><\/p>\n<ul>\n<li><strong>FR9<\/strong>: To enable interoperability between all involved parties the sub-functions &#8222;data fusion and processing&#8220; and &#8222;information provision&#8220; <strong><span style=\"color: #ff0000;\">must<\/span> <\/strong>require\/provide an interface 2 with the following event information structure (if no information is available for an element, value can be left void):\n<ul>\n<li>(estimated) impact on traffic situation<\/li>\n<li>start and estimated end (date, time)<\/li>\n<li>position (location code) and estimated spatial dimension<\/li>\n<li>type, cause (optional)<\/li>\n<li>comment (free text)<\/li>\n<li>information source<\/li>\n<li>means of information provision<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><u>Interface advice interface 2:<\/u><\/p>\n<p>In order to provide efficient and adapted information when needed and also to prevent from disseminating counterproductive information additionally event-based information and official traffic management plans should be provided, which are covered by other Deployment Guidelines TMS-DG07 &#8222;Traffic management for corridors and networks&#8220;)<\/p>\n<h4><strong>Organisational Requirements<\/strong><\/h4>\n<p><strong>Organisational Architecture\/Business Model<\/strong><\/p>\n<p>A general overarching description of the key actors, their roles in the value chain and the related conditions for TIS-service provision is outlined in the\u00a0<a href=\"http:\/\/itsreferencehandbook.albrechtconsult.com\/?page_id=330\">SRTI &amp; RTTI \u2013 Key actors in the information value chain<\/a>.<\/p>\n<p>Harmonisation focus of the chapter: \u201cInteroperability on the organisational level\u201d. The chapter should comprise at least on illustration of the organisational architecture\/structure of the service (block-diagram style) in a way that the typical main organisational roles (of the service value chain) are depicted and identifiable.<\/p>\n<p><strong>Note:<\/strong> Even though partners involved in the service can be either public or private road organisations as well as public or private service providers, who are legally autonomous in varying degrees and in the international context sometimes even work on different national laws, it is not required to define organisational aspects on a legal and binding basis.<\/p>\n<p><u>Organisational advice:<\/u><\/p>\n<p>Where different autonomous parties are involved, clear definitions of organisational aspects are a crucial precondition for a successful implementation of a &#8222;Forecast and real-time event information service&#8220;. These definitions are documented in the form of e.g. a \u201cCommon partner arrangement\u201d or a \u201cMoU &#8211; Memorandum of understanding\u201d which establish the roles and responsibilities of the respective parties to any co-operation and be agreed by all parties\/partners involved.<\/p>\n<p><u>Organisational requirements:<\/u><\/p>\n<ul>\n<li><strong>OR1<\/strong>: The organisational and operational structure of the service as well as the role of each public organisation\/body and its exact responsibility and task in the chain <strong><span style=\"color: #ff0000;\">must<\/span> <\/strong>be compliant with the National Access Points across Europe, within the scope of the implementation of the delegated acts adopted under Directive 2010\/40\/EU.<\/li>\n<li><strong>OR2<\/strong>: All necessary organisational aspects for successful implementation of a &#8222;SRTI &amp; RTTI Service&#8220; <strong><span style=\"color: #ff0000;\">must<\/span> <\/strong>be documented and agreed by all involved parties\/partners to fix the cooperation.<\/li>\n<li><strong>OR3<\/strong>: All necessary collaboration processes\/workflows and interfaces <strong><span style=\"color: #ff0000;\">must<\/span> <\/strong>be described.<\/li>\n<li><strong>OR4<\/strong>: The information provision <strong><span style=\"color: #ff0000;\">should<\/span> <\/strong>be in accordance with any management plans (TMP, see TMSDG07) which are in operation of the road authorities or traffic management centres.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Service Definition \u201cForecast and Realtime Event Information\u201d are defined as the provision of information about both expected and unexpected Events to road users on identified segments of the road network and interfaces. This predictive or real-time event information could be provided on-trip and pre-trip using different information channels, accessible by the road user via different&#8230;<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-583","page","type-page","status-publish","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=\/wp\/v2\/pages\/583","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=583"}],"version-history":[{"count":5,"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=\/wp\/v2\/pages\/583\/revisions"}],"predecessor-version":[{"id":588,"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=\/wp\/v2\/pages\/583\/revisions\/588"}],"wp:attachment":[{"href":"https:\/\/itsreferencehandbook.albrechtconsult.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=583"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}