WP 4 Urban traffic coordination – Situation and eco-aware driving assist

Cristofer Englund Viktoria Swedish ICT

WP4 Overview Duration: M1 – M36 (all tasks) Effort: 53 PMs Task 4.1: Urban Traffic Coordination Scenario Investigation and Requirements Analysis •  Viktoria, Cefriel, Thales, Tirasa, UDA

Task 4.2: Urban Traffic Coordination Services Implementation and Choreography Development •  Viktoria, Cefriel, Inria, Thales, Tirasa, UDA

Task 4.3: Urban Traffic Coordination Choreography Deployment and Assessment •  Viktoria, Cefriel, Inria, Thales, Tirasa, UDA

Task 4.4: Urban Traffic Coordination Business Model •  Viktoria

2 11 Feb 2016

WP4 Deliverables

ü  D4.1: Urban Traffic Coordination Scenario Definition and Requirements (Viktoria) – M6

•  D4.2: Urban Traffic Coordination Initial application prototyping (Viktoria) – M24

•  D4.3: Urban Traffic Coordination Deployment and Demonstration (Viktoria) – M36

•  D4.4: Urban Traffic Coordination Business models (Viktoria) – M36

3 11 Feb 2016

11 Feb 2016 4

Transport challenges

l  Growing mobility and congestion l  Increasing emission from transport sector l  Traffic safety l  Urbanization l  High expectations on information availability, timing, accuracy

Source: peakoil.com

Source: WHO

Over 1.2 million people die each year on the world’s roads, and between 20 and 50 million suffer non-fatal injuries

+ 40% CO2 emissions since 1992 from transport, while decreasing from other areas Sweden aim for fossil free transport system in 2030 in Sweden. Today 95%.

5

Opportunities

•  Cooperative intelligent transport systems (C-ITS) •  Connected vehicles •  Ubiquitous connectivity – Networked society •  Cloud computing •  Open data

11 Feb 2016

6

Services and Things in the FI domain •  Multiple services

•  Real time traffic information •  Map information •  Routing/Navigation information •  Road infrastructure information •  …

•  Multiple domains •  Public authorities •  Commercial data providers •  Open data •  Crowd data •  …

11 Feb 2016

Challenges with services and things

11 Feb 2016

Middleware protocols SOAP

REST

CoAP MQTT

MQTT-S

XMPP

Issues

Security: We want to have secure communication between services

Heterogeneity: No single choice on middleware protocols, depending on stakeholders

Interoperability: Different protocols need to be able to communicate with each other, critical in IoT

Strong competition between protocols

Solutions

Security filters

Binding components

Adaptors

7

Scenario description – Situation and eco-aware driving assist (SEADA)

Situa&on)and)Eco-Aware)Travel)Speed)Advisory)SEATSA)

!CWARP)

Conges&on)Warning)&)Route)re-Planning)

Accident)Warning)&)Route)re-Planning)

AWARP)

Extreme)Road)Situa&on)Warning)&)Route)re-Planning)

!ERWARP)

Traffic-based)events)

Green)Light)Op&mized)Speed))Advisory))GLOSA)

BOWARP)

Bridge)Open)Warning)&)Route)re-Planning)

!

Loca&on-based)events)

Origin)

Upon)traffi

c)events)

Approaching)loca&ons)

Situa&on)and)Eco-Aware)Route)Planning)SEARP)

Dest)

New)route))needed?)

Y)N)

To develop highly responsive situation and eco-aware information to improve driving experiences and reduce CO2 emission.

11 Feb 2016 8

Scenario description – Situation and eco-aware driving assist (SEADA)

l  WP 4: Use Case Urban Traffic Coordination (UTC)

-  Design with respect to security and requirements

-  Situation-aware and eco-friendly driving guidance

-  improved driving comfort, -  traffic efficiency, -  emission reduction

-  Define eco-driving

-  Develop situation- and eco-aware driving application

-  Business models for eco-driving

-  How can eco-driving be integrated C-ITS

11 Feb 2016 9

ORCHESTRATION vs CHOREOGRAPHY

•  Centralized - Orchestration •  Services interact only with the central

service •  Difficult to coordinate

multiple domain services •  Less flexible •  Less scalable

•  Distributed- Choreography •  Peer-to-peer service interaction •  Straighforward to coordinate

multiple domain services •  Flexible to change coordination logic •  Scalable service coordination •  Facing future C-ITS system

Centralservice

!

applica5onboundary

11 Feb 2016 10

11

CHOReVOLUTION features

•  Easy choreography specification based on BPMN2 •  Reusability of existing services and things •  Automatic choreography synthesis and enactment •  Interoperability between different service protocols •  Deals with services and things •  Cloud deployment for straightforward application execution

An all-in-one platform for service-choreography-based application development is very promising in future connected and automated transport system.

11 Feb 2016

Traffic related services

•  Eco-driving

-  Mathematical model for evaluating eco-friendliness of routes based on geo-information and real-time traffic information

•  BOWARP – Bridge Opening Warning & Route re-planning

-  Building web-service based on API from City of Gothenburg •  GLOSA – Green Light Optimal Speed

-  Mathematical model of the traffic light status -  Building web-service based on Public Transport API of the

bus status -  Time-To-Red modelling

11 Feb 2016 12

Estimate Time-To-Red – based on bus position

Regnbågsgatan Stop t1

Pumpgatan Stop t2

Frihamnen Stop t3

11 Feb 2016

Traffic light

Time-To-Red = f(t1,t2,t3)

13

14

Route planning: Choreography diagram

Figure 4.3: WP4 Choreography Specification

Figure 4.4: WP4 Traffic Estimation Sub-Choreography Specification

BS-MAP represents a service that supports ND while accessing digital maps. Map informationcan be both local and on-demand through Internet access. BS-MAP is used for accessing theGoogle Maps and NOKIA HERE Maps services.

TRVC represents one of the services offered by Trafikverket1 (the Swedish national road ad-ministration) that allows for collecting route-related information (e.g., traffic load, road conditions,accidents, etc.) from different sources.

DTS-TRV-ACC represents a service that provides up-to-date accident related information.

The choreography is triggered by the driver upon inserting both origin and destination through theNavigation Device (ND). After receiving origin and destination information from ND, the BS-MAP ser-vice invokes in parallel the services DTS-GOOGLE and DTS-HERE (see the parallel branch repre-sented as an rhombus marked with a “+” with two outgoing arrows). These services both serves toretrieve available routes from the origin to the destination. When done, the related parallel flows arejoined to synchronize on the production of the set of available routes (see the merging branch repre-sented as an rhombus marked with a “+” with two incoming arrows). Upon receiving the set of availableroutes, BS-MAP determines if they are enough (see the conditional branching represented as a rhom-bus marked with a “x”): (i) in the positive case, it triggers the (simplified version of the) Traffic Estimationsub-choreography to estimate the traffic situation by checking the presence of accidents along the deter-mined routes (see Figure 4.4); (ii) in the negative case, the BS-MAP service re-invokes DTS-GOOGLEand DTS-HERE to determine other routes. When traffic information is calculated for each route, theseare displayed into the ND in order to suggest the most eco-friendly routes to the Driver. Then, thesimplified version of the choreography we are considering here terminates.

For the sake of presentation, in Figure 4.3, input/output messages of tasks are not shown althoughthey are internally handled by the CHOReVOLUTION synthesis processor according to their XMLSchema type definition in the WSDL. For instance, considering the first task labeled with “Send Ori-gin and Destination”, the XML Schema type of the input message is as follows:

Listing 4.1: Type structure of the input message of the “Send Origin and Destination” task<xsd:schema version= ” 1.0 ” targetNamespace= ” h t t p : / / cho revo lu t i on . d is im . univaq . i t / ”>

<xsd:complexType name= ” sendOrig inAndDest inat ionRequest ”>

1http://www.trafikverket.se/en/

CHOReVOLUTIONH2020-644178 14

Figure 4.3: WP4 Choreography Specification

Figure 4.4: WP4 Traffic Estimation Sub-Choreography Specification

BS-MAP represents a service that supports ND while accessing digital maps. Map informationcan be both local and on-demand through Internet access. BS-MAP is used for accessing theGoogle Maps and NOKIA HERE Maps services.

TRVC represents one of the services offered by Trafikverket1 (the Swedish national road ad-ministration) that allows for collecting route-related information (e.g., traffic load, road conditions,accidents, etc.) from different sources.

DTS-TRV-ACC represents a service that provides up-to-date accident related information.

The choreography is triggered by the driver upon inserting both origin and destination through theNavigation Device (ND). After receiving origin and destination information from ND, the BS-MAP ser-vice invokes in parallel the services DTS-GOOGLE and DTS-HERE (see the parallel branch repre-sented as an rhombus marked with a “+” with two outgoing arrows). These services both serves toretrieve available routes from the origin to the destination. When done, the related parallel flows arejoined to synchronize on the production of the set of available routes (see the merging branch repre-sented as an rhombus marked with a “+” with two incoming arrows). Upon receiving the set of availableroutes, BS-MAP determines if they are enough (see the conditional branching represented as a rhom-bus marked with a “x”): (i) in the positive case, it triggers the (simplified version of the) Traffic Estimationsub-choreography to estimate the traffic situation by checking the presence of accidents along the deter-mined routes (see Figure 4.4); (ii) in the negative case, the BS-MAP service re-invokes DTS-GOOGLEand DTS-HERE to determine other routes. When traffic information is calculated for each route, theseare displayed into the ND in order to suggest the most eco-friendly routes to the Driver. Then, thesimplified version of the choreography we are considering here terminates.

For the sake of presentation, in Figure 4.3, input/output messages of tasks are not shown althoughthey are internally handled by the CHOReVOLUTION synthesis processor according to their XMLSchema type definition in the WSDL. For instance, considering the first task labeled with “Send Ori-gin and Destination”, the XML Schema type of the input message is as follows:

Listing 4.1: Type structure of the input message of the “Send Origin and Destination” task<xsd:schema version= ” 1.0 ” targetNamespace= ” h t t p : / / cho revo lu t i on . d is im . univaq . i t / ”>

<xsd:complexType name= ” sendOrig inAndDest inat ionRequest ”>

1http://www.trafikverket.se/en/

CHOReVOLUTIONH2020-644178 14

11 Feb 2016

Route planning: Alternative routes

11 Feb 2016 15

Route planning: Traffic information

11 Feb 2016 16

Route planning: Traffic-based events

11 Feb 2016 17

Conclusion and next step

•  WP4 main achievments in the period:

-  D4.1 delivered on time -  Created choreographies for the use-case -  Re-used a number of services for route generation and traffic-

related information •  Continue experimenting with the Chorevolution studio

-  Evaluate and give feedback, for continous development, of the Chorevolution studio

-  Incremental development to add funcitonallity of the use-case

11 Feb 2016 18

THANK YOU