cooperative mobility systems and services for energy ......cooperative mobility systems and services...

Cooperative Mobility Systems and Services

for Energy Efficiency

Project supported by European Union DG INFSO ICT-2009-6.1, ICT for Clean and Efficient mobility

Project reference FP7-ICT-2009-4 IP Proposal - 247908

IP Manager Jean Charles Pandazis, ERTICO – ITS Europe Tel: +32 2 400 0714, E-mail: [email protected]

D4.2 Functional Architecture and System Specification

SubProject No. 4 SubProject Title ecoFreight & Logistics

Workpackage No. 4.3 Workpackage Title Architecture & System Specifications

Task No. 4.3.2 Task Title Specification of the architecture

Authors Guillaume Vernet, Johannes Stille, Florian Krietsch, Norddin El Ghouti, Fabrizio Gatti, Philipp Themann

Dissemination level PU/PP/RE/CO

PP

File Name 110315-DEL_SP4_D4.2_ArchSysSpec

Due date 30 November 2010

Delivery date 15 March 2011

Abstract This document contains the architecture and system specification of SP4 ecoFreight & Logistics applications. It also describes the interdependencies towards other SPs and how the architecture design covers the use cases and requirements defined in deliverable D4.1.

This document is the basis for the development of the three SP4 applications in the WP4 phase. After their implementations, ecoTourPlanning, Truck ecoNavigation and ecoDriverCoaching will be documented in resp. deliverables D4.3, D4.4 and D4.5

D4.2 - Functional Architectureand System Specification

14-03-2011 II Version 1.0

Control sheet

Version history

Version Date Main author Summary of changes

0.1 09-11-2010 Guillaume Vernet Initial content

0.2 09-02-2011 Guillaume Vernet Integration of documentation for each application

0.3 11-02-2011 Guillaume Vernet Updates in Section 5 and 6

0.4 15-02-2011 Guillaume Vernet Editorial updates, added overview of SP4 ITS stations

0.5 16-02-2011 Florian Krietsch Updates in section 3 and 5

0.6 18-02-2011 Florian Krietsch Updates in section 5 and Annex C

0.7 21-02-2011 Guillaume Vernet Last updates (sections 5 & 6) and editorial updates

0.8 08-03-2011 Guillaume Vernet Updates after peer reviews

1.0 14-03-2011 Guillaume Vernet Finalisation of deliverable

Name Date

Prepared Guillaume Vernet 14-03-2011

Reviewed Tijn Schmits, Matthias Mann 14-03-2011

Authorized J-Ch. Pandazis (ERTICO) 14-03-2011

Verified Quality Manager (ERTICO) 15-03-2011

Circulation

Recipient Date of submission

Project partners 15-03-2011

European Commission 15-03-2011


14-03-2011 3 Version 1.0

Table of Contents

TABLE OF CONTENTS ...........................................................................................3

LIST OF FIGURES ....................................................................................................5

LIST OF TABLES ......................................................................................................5

TERMS AND DEFINITIONS ...................................................................................6

IP TERMS AND DEFINITIONS ........................................................................................6 SP4 TERMS AND DEFINITIONS ....................................................................................7

1. SCOPE ...................................................................................................................8

1.1. IDENTIFICATION ................................................................................................8 1.2. SYSTEM OVERVIEW ...........................................................................................8 1.3. DOCUMENT OVERVIEW .....................................................................................8

2. REFERENCED DOCUMENTS .......................................................................10

3. SYSTEM-WIDE DESIGN DECISIONS ..........................................................11

3.1. ECOTOURPLANNING .......................................................................................11 3.2. TRUCK ECONAVIGATION ................................................................................12 3.3. ECODRIVER COACHING ..................................................................................15

4. SYSTEM ARCHITECTURAL DESIGN .........................................................18

4.1. ECOTOURPLANNING .......................................................................................18 4.1.1. Application Layer ....................................................................................18 4.1.2. Technology Layer ....................................................................................21

4.2. TRUCK ECONAVIGATION ................................................................................22 4.2.1. Application Layer ....................................................................................22 4.2.2. Technology Layer ....................................................................................23

4.3. ECODRIVERCOACHING ...................................................................................24 4.3.1. Application Layer ....................................................................................24 4.3.2. Technology Layer ....................................................................................26

5. INTERFACE DESIGN ......................................................................................28

5.1. ECOTOURPLANNING .......................................................................................28 5.2. TRUCK ECONAVIGATION ................................................................................29 5.3. ECODRIVERCOACHING ...................................................................................30 5.4. VEHICLE DATA ACCESS..................................................................................31 5.5. TRUCK PARKING AVAILABILITY DATA FROM SP5 ...........................................31 5.6. OVERVIEW OF SP4 INTERNAL INTERFACES .....................................................31

6. REQUIREMENTS TRACEABILITY .............................................................36

6.1. ECOTOURPLANNING .......................................................................................36 6.2. TRUCK ECONAVIGATION ................................................................................37 6.3. ECODRIVERCOACHING ...................................................................................39


14-03-2011 4 Version 1.0

APPENDIX A – OVERVIEW OF SP4 ITS STATIONS ......................................41

APPENDIX B – FLEET MANAGEMENT STANDARD .....................................42

APPENDIX C – TRANSFER DATABASE ............................................................43


14-03-2011 5 Version 1.0

List of Figures Figure 1: Relation between work packages ................................................................... 9 Figure 2: Business Layer - ecoTourPlanning ............................................................... 12 Figure 3: Business Layer - Truck ecoNavigation ........................................................ 13 Figure 4: Business Layer - ecoDriverCoaching, on-board focus ................................. 16 Figure 5: Business Layer - ecoDriverCoaching, backoffice focus .............................. 17 Figure 6: Application Layer – ecoTourPlanning ......................................................... 20 Figure 7: Technology Layer – ecoTourPlanning ......................................................... 22 Figure 8: Application Layer - Truck ecoNavigation .................................................... 23 Figure 9: Technology Layer - Truck ecoNavigation ................................................... 24 Figure 10: Application Layer - ecoDriverCoaching (pre-trip) .................................... 25 Figure 11: Application Layer - ecoDriverCoaching (on-trip) ...................................... 25 Figure 12: Application Layer - ecoDriverCoaching (post-trip) ................................... 26 Figure 13: Technology Layer – ecoDriverCoaching ................................................... 27 Figure 14: Overview of internal SP4 interfaces ........................................................... 32 Figure 15: Overview of SP4 logistics back office interfaces to vehicle and city logistics ........................................................................................................................ 34 Figure 16: Overview of SP4 ITS stations .................................................................... 41

List of Tables Table 1: Data objects required by ecoTourPlanning .................................................... 28 Table 2: Data objects produced by ecoTourPlanning .................................................. 28 Table 3: Data objects required by Truck ecoNavigation ............................................. 29 Table 4: Data objects produced y Truck ecoNavigation .............................................. 29 Table 5: Data objects required by ecoDriverCoaching ................................................ 30 Table 6: Data objects produced by ecoDriverCoaching .............................................. 30 Table 7: Requirement matrix - ecoTourPlanning ........................................................ 37 Table 8: Requirement matrix - Truck ecoNavigation .................................................. 38 Table 9: Requirement matrix - ecoDriverCoaching ..................................................... 40


14-03-2011 6 Version 1.0

Terms and definitions This section contains the terms and definitions used in this document.

IP terms and Definitions Term Abbr. Definition

component see 'configuration item'

computer software configuration item

CSCI a group of software treated as a single entity: operating systems, drivers, system software layers, databases, applications

configuration item CI a collective term used for referring to both CSCIs and HWCIs

data element an atomic unit of data that has precise meaning or precise semantics

data element assemblies

a collection of data elements, treated as a single entity: records, messages, files, arrays, displays, reports, etc.

database DB an organized collection of data for one or more uses

database management system

DBMS a set of computer programs that controls the creation, maintenance, and the use of a database

developer one who programs or designs the system to match the requirements of the project

ecoFVD ecoFVD Eco Floating Vehicle Data; cooperative messages sent by the vehicles. Described as part of ecoMessages in D2.5

ecoTSD ecoTSD Eco Traffic Situational Data; cooperative messages sent by the infrastructure. Described as part of ecoMessages in D2.5

eCoMove Dependency Layer

eDL a property of a configuration item, describing eCoMove cross‐SP development/use dependencies, related to The Three Layer Approach (TTLA)

hardware configuration item

HWCI a set of hardware treated as a single entity: processors, storage devices, network cards, radio antennas, GPS receivers

identifier a project unique code used for reference

inputs changes which are inserted into a system, which activate/modify a process

interface a point of interaction between two systems

outputs changes which exit a system, which activate/modify a process

privacy the ability of an individual or group to seclude information about themselves

security a degree of protection against danger, damage, loss, and criminal activity


14-03-2011 7 Version 1.0

service a set of related software functionalities, together with the policies that should control its usage

system a set of interacting or interdependent entities forming an integrated whole

system state a unique configuration of information in a program or machine

system mode see system state

user a person who uses a service provided by a system

SP4 Terms and Definitions Term Abbr. Definition

BO BO Backoffice

CAN CAN Controller‐Area Network: vehicle bus standard used by on‐board equipment to exchange data.

CFP CFP Carbon Footprint

DB DB Database

ecoRoute Output from ecoRouting, contains the actual sequence of road segments leading from a starting point to a destination

ecoTour Collection of ecoTrips with time and order constraints of multiple locations. Intermediate locations without additional time and location constraint (along the tour) are allowed and will be assigned to the appropriate ecoTrip.

ecoTrip Input for ecoRouting, consists of single starting point and single destination, with additional time constraints. Intermediate locations without additional time and location constraint (along the trip) are allowed.

FMS FMS Fleet Management System standard

HMI HMI Human‐Machine Interface

ITS ITS Intelligent Transport System

KPI KPI Key Performance Indicator

MPP MPP Most Probable Path; it is the sequence of road elements that the vehicle will probably pass in the near future, determined by selecting at each intersection the branch with highest probability

OB OB On‐board

OEM OEM Original Equipment Manufacturer; in the context of eCoMove it means vehicle manufacturers and automotive suppliers

Truck Heavy commercial vehicle with an operating weight exceeding 7.5 tonnes.

Work package WP Decomposition of project activities into work units.


14-03-2011 8 Version 1.0

1. Scope

1.1. Identification This document D4.2 “Functional architecture and system specifications” is part of sub-project 4 “ecoFreight & Logistics”. This sub-project focuses on companies that are transporting goods on the roads by means of heavy commercial vehicles.

1.2. System overview The SP4 system is composed of three applications:

o ecoTourPlanning: this application allows a transport planner to determine the most fuel-efficient ecoTours for all of his vehicles based on a given set of transport order to fulfil.

o Truck ecoNavigation: this application calculates the route to the next destination and guides the driver there. Thereby it considers the configuration / status of the vehicle and processes necessary traffic status information to determine the most efficient route in terms of time and fuel.

o ecoDriverCoaching: three components strive to achieve fuel efficiency in all trip phases. A driving simulator trains the driver in specific traffic situations (pre-trip); an on-board ecoDriver Coach supports the driver to drive in the most fuel-efficient way along the calculated route; an ecoFleet Business component in the backoffice provides post-trip analysis.

1.3. Document overview The purpose of this document is to describe the technical specifications of eCoMove components for SP 4 ecoFreight & Logistics. Architecture and technical specification belongs to work package 3 which follows the use cases and requirements definition from work package 2. The relationship between work packages and eCoMove V-model is described in the following picture.


14-03-2011 9 Version 1.0

WP 1.1IP Coordination

WP 2Use Cases &

Requirements

WP 3Architecture &Specifications

Field Trials & Validation

WP 6.3

Proof of Concept

WP 6.5

WP 1.2

Technical Development

WP 4

SP1

SP2

SP3

SP4

SP5

SP6

Validate requirements

WP 5Integration & Verification

Impact Assessment

WP 6.4

Dissemination & Exploitation

WP 1.1IP Coordination

WP 2Use Cases &

Requirements

WP 3Architecture &Specifications

Field Trials & Validation

WP 6.3Field Trials & Validation

WP 6.3

Proof of Concept

WP 6.5Proof of Concept

WP 6.5

WP 1.2

Technical Development

WP 4

SP1

SP2

SP3

SP4

SP5

SP6

Validate requirements

WP 5Integration & Verification

Impact Assessment

WP 6.4Impact Assessment

WP 6.4

Dissemination & Exploitation

Figure 1: Relation between work packages

Using the eCoMove modelling language based on Enterprise Architecture Archimate (see [eML]), this document, which template is based on JSTD-016 standard [JSTD16], will provide detailed descriptions of SP4 components on three levels:

o Business Layer: services realized by processes, used by actors with a certain behaviour

o Application Layer: services are described further down in terms of applications and functions

o Technology Layer: on which device or nodes components are deployed As such, it will serve as basis for application developers to implement the SP4 systems during the WP4 phase. Chapter 3, System-wide design decisions, describes the high level design of SP4s application with Business Layer diagrams. Chapter 4, System architectural design, continues the description of the application at a deeper level, analyzing internal services and processes in Application Layer diagrams. Technology Layer diagrams will show how components are deployed on the different ITS stations. Chapter 5, Interface Design, describes data objects produced and required by SP4 and identifying the links with other sub-projects. Chapter 6, Requirements traceability, links the requirements defined in WP2 deliverable [D4.1] and the design components from the SP4 applications. This will help the developer of a component to know which requirements his implementation has to fulfil.


14-03-2011 10 Version 1.0

2. Referenced documents Throughout this document references will be made to other eCoMove deliverables: Ref Document Version, date [D2.1] D2.1: eCoMove system concept, functionality,

requirements and use case description v6, Nov. 2010

[D4.1] D4.1: System description, use cases and system requirements

v8, Nov 2010

[D2.2] D2.2: High level architecture March 2011 [D3.2] D3.2: Functional architecture and specifications

for ecoSmartDriving & ecoTripPlanning March 2011

[D3.3] D3.3: Functional architecture and specifications for ecoMonitoring & ecoPostTrip

March 2011

[D5.2] D5.2: Functional architecture and System specifications

March 2011

[eML] eCoMove Modelling Language specifications v4, Nov. 2010 [D2.3] D2.3: eCoMove Communication platform

design specification To be published, April 2011

[D2.4] D2.4: eCoMove cooperative communication protocol specifications

To be published, March 2011

[D2.5] D2.5: Preliminary definition of ecoMessages To be published, March 2011

[D2.6] D2.6: ecoMap specifications To be published, April 2011

[D3.6] D3.6: ecoHMI To be published, Nov 2011

Future documentation of the SP4 applications: Ref Document Version, date [D4.3] D4.3: Cooperative ecoFleet Planning & Routing

application To be published, March 2012

[D4.4] D4.4: In-vehicle eco navigation system application


[D4.5] D4.5: Integrated truck driver coaching system proto


References to non eCoMove deliverables include: Ref Document Version, date [JSTD16] IEEE-JSTD-016 [FMS] FMS standard (Fleet Management System)

available from www.fms-standard.com v2, Sept 2010

[ETSI] ETSI EN 302 665 v1.1.1 Sept 2010

http://www.fms-standard.com/


14-03-2011 11 Version 1.0

3. System-wide design decisions

3.1. ecoTourPlanning The ecoTourPlanning business layer diagram describes the Truck ecoTourPlanning application and its interactions with other parts of SP4 as well as with other sub-projects. The Truck ecoTourPlanning has four core engine processes, see Figure 2: ecoTour Creation engine takes available and relevant information that influence infrastructure state and availability and calculates the most efficient tour station sequence for given transport orders and fulfilling given restrictions. Mission Authorization engine receives an authorization request from the tour creator and checks its conformance to the Local Authority policy requirements set through the “Defining Policy” functionality of the City Logistics system. As a result of this process the mission can be approved or not. In the second case the system highlights the policy parameters not fulfilled by the mission. ecoTour Realisation engine strives to execute the authorized route profile and informs the tour creator about events while mission execution and changes and deviations affecting the initial planned tour. This implies especially changes in sequence or cancelling of stop stations. Actually, these deviations might have great influence on the overall expected performance in terms of timing, fuel consumption and emission. At the backoffice side deviations and events have to be taken into account in order to provide the right and meaningful assessment in the post trip procedure. Carbon footprint calculation engine provides an initial carbon footprint estimate based on the initially available and relevant information which is used to find the most efficient route to destination. This process is further responsible for updating the expected carbon footprint estimate based on the received feedbacks from the field, which informs (or rather trigger) the dispatcher to reorganize the tour if needed. Finally, an assessment of the real carbon footprint can also be made possible if the truck can send back to the BO its final measured carbon footprint, which it can compare to the expected value taking into account e.g. the drivers comments as well as any other reported relevant events (from SP5 and/or city logistics).


14-03-2011 12 Version 1.0

Figure 2: Business Layer ‐ ecoTourPlanning

3.2. Truck ecoNavigation The ecoNavigation business layer diagram in Figure 3 describes Truck ecoNavigation and its interaction both with other parts of SP4 and with other SPs. Truck ecoNavigation has two core processes: Route Calculation takes all available information that might influence fuel usage and computes the most fuel efficient route to a given destination. Driver Guidance gives turn-by-turn instructions to the driver based on this route. There’s a set of auxiliary processes to collect the information relevant for fuel usage from various sources, these processes are continuously monitoring for changed data and may trigger a route recalculation. Another set of auxiliary processes distributes route information to other parts of the system as needed: to the ecoCooperativeHorizon (see [D3.2]), to the Traffic Management Centre (see [D5.2]), and to the Fleet Planning which in eCoMove is the ecoTourPlanning described above in Section 3.1. A last auxiliary process informs the driver when no route could be calculated or a route has been calculated that might be unusable or not legally useable.


14-03-2011 13 Version 1.0

Figure 3: Business Layer ‐ Truck ecoNavigation

Data objects exchanged with other parts of the system:

• Current Position The current position of the vehicle is used as starting point for route planning and it is used to decide what instructions need to be given to the driver. According to this diagram, the current position is retrieved from the ecoCooperativeHorizon (developed in SP3 and documented in [D3.2]) where it is available at least as starting point of the Most Probable Path; it would be possible to take the current position directly from a dedicated positioning


14-03-2011 14 Version 1.0

module instead. It also would be possible to use a position some distance ahead on the Most Probable Path (MPP) as a starting point to avoid the vehicle already having left the route when calculation is finished. This diagram expects to take the current position from the ecoCooperativeHorizon (where it is available at least as starting point of the MPP); it would be possible to take it directly from a dedicated positioning module instead.

• Trip Data (input from Fleet Planning) Trip information provided by Fleet Planning contains data to define a trip – at minimum a destination, optionally time constraints, a fuel/time trade-off, or an actual pre-planned route (which might be used for route calculation by just copying it). Data for a sequence of trips may be transferred.

• Vehicle Parameters (input) Information about the vehicle that is relevant for fuel consumption estimation. The list of parameters is yet TBD, as it depends on the fuel consumption estimation algorithm which will be a topic of research in eCoMove (work package 3.4.1 and 4.4.1). It might include items like vehicle weight and cross-section. This data may be retrieved from an interface to the vehicle hardware, from Fleet Planning, or from the driver. Deliverable [D4.4] will document what vehicle parameters are actually used.

• ecoRoute (output) The calculated route is provided to other parts of the system that might make use of it. Currently known are the ecoCooperativeHorizon (which will expect the vehicle to travel along the route – see [D3.2]), Traffic Management (which can use planned routes to estimate future road network loads – see [D5.2]), and Fleet Planning (which can check whether a route planned on-board is compatible with central planning – see the description of ecoTourPlanning above for the eCoMove implementation). If other parts of eCoMove wish to make use of the route, it will be made available to them as well.

• Map data Truck ecoNavigation makes use of both static and dynamic data from the ecoMap (developed in SP2, see [D2.2]). Static map data is used at many places in Truck ecoNavigation; both route calculation and driver guidance are based on it. Static map data can include historic traffic data which can be used to estimate fuel consumption in route calculation. Dynamic map data is used to estimate fuel consumption as well. This includes several types of data: The names used in this diagram are not final and might have to be changed, as the data will be defined by the ecoMessages and ecoMap tasks in SP2, see [D2.2] and future documentation in respectively [D2.5] and [D2.6]. Currently these types of dynamic data are expected to be used:

o Map-matched traffic information describes flow patterns and possibly incidents received via wide area communication sent by central services. This can be current data or predictions for a medium time scale (in the order of hours).

o Map-matched situational data describes local traffic situation received over short range communication. It can be current data or predictions for a short time


14-03-2011 15 Version 1.0

scales (seconds to minutes). The data might be received by V2I communications from roadside units, or it might be computed locally by the ecoSituationalModel (developed in SP2, see [D2.2]) from ecoFVD.

In any case, dynamic map data is not received by the Truck ecoNavigation directly from the data sources described above, but it is retrieved from the ecoMap which has the role of a distribution service for this data.

• Route advice This is information distributed by a traffic management centre containing recommendations what routes to take or not to take through specific parts of the road network. Details will be defined in SP5, see [D5.2] and future documentation.

• User input and output This is data exchanged with the user by means of the ecoHMI (developed in SP3, see [D3.2]). Data items include:

o Vehicle Parameters (input) See above.

o Trip Data (input) This is the destination to navigate to, but can also include restrictions on arrival time or a fuel/time trade-off setting.

o Route Warning (output) This is a warning to the driver that it may not be possible to follow the route to the destination.

o Driver Instructions (output) These are the actual instructions for driving manoeuvres.

3.3. ecoDriver Coaching The ecoDriverCoaching application has three main services on-board and one off-board. Figure 4 shows the business layer with focus on on-board while Figure 5 focuses on the backoffice side of the application. NB: the driving simulator that will be developed in SP4 is architecture-wise the same as a real vehicle and hence is not mentioned in the subsequent sections. Pre-trip vehicle status checker: When the driver enters his vehicle and before starting his trip, the status of the vehicle and all the fuel-affecting organs is checked (e.g. tyre pressure, spoiler position, energy consumers…). Where checks cannot be automated with sensors, the driver is reminded of the organ to check manually. On-trip ecoDriving advices: While the driver is driving towards its destination, the ecoSituationalModel service is used together with ecoCooperativeHorizon and vehicle data to assess the current driving situation. The system computes anticipation advices and correction advices. Based on the driver settings, these advices are handed over to the ecoHMI service to be presented to the driver. The reaction of the driver is analysed to update if necessary the parameters.


14-03-2011 16 Version 1.0

During the trip, continuous vehicle sensor data is used to compute key performance indicators of the driver’s driving behaviour (e.g. acceleration profile, break usage, fuel / ton * km). The ecoHMI component comes from SP3 and is described in [D3.3]. More documentation will be available after the implementation phase in [D3.6]. The ecoSituationalModel and ecoCooperativeHorizon are respectively documented in SP2 and SP3 architecture deliverables [D2.2] and [D3.2]. Post-trip profile evaluation (on-board): When the driver has finished his trip, he has the possibility to enter comments to explain any exceptional circumstances which happened during his trip and which can have cause irregularities in the driving profile. The driver is presented a direct feedback with his strong and weak points and tips on how to improve his eco-driving. His commented driver profile is sent to the backoffice ecoFleetBusiness service for evaluation.

Figure 4: Business Layer ‐ ecoDriverCoaching, on‐board focus


14-03-2011 17 Version 1.0

At the ecoFleetBusiness application, the evaluation service is realized by three meta-processes, which are depicted on the business layer diagram in Figure 5. Historical driving profile: Driving profiles from the whole fleet are received and stored for later use by the evaluation processes. Fleet manager evaluation service: Based on recent and historical driving profiles, the fleet manager can see the current performance and trends of his whole fleet or for individual drivers. This supports him in managing incentives for his drivers and aspects of driving that needs to be emphasised in the coaching. The settings of the on-board ecoDriverCoaching are updated accordingly on the vehicles of his fleet. Driver evaluation service: A driver can see his achievements in fuel efficient driving based on driving profiles of his previous trips. This gives him tailored advices on how to improve. His settings for the on-board coaching system are updated accordingly.

Figure 5: Business Layer ‐ ecoDriverCoaching, backoffice focus


14-03-2011 18 Version 1.0

4. System architectural design The following sections present the Application Layers and Technology Layers for the three SP4 applications. A combined overview of technology layers can be found in Appendix A – Overview of SP4 ITS stations. In the following sections, “ITS station” is the generic designation from the ETSI standard (see [ETSI]) and refers to a vehicle, a roadside unit or a central system depending on the prefix used (e.g. Central ITS station).

4.1. ecoTourPlanning

4.1.1. Application Layer

The application layer as depicted below closely reflects the business layer, where in order to ease the overview readings of the different interactions and exchanges that are taking place, all the involved engine processes are kept on the same graph, see Figure 6. The architecture diagram shown in Error! Reference source not found. depicts the application processes/components of the tour planning and execution system. In the BO the planning tool makes use of the traffic information from the SP5 ecoATS (see [D5.2]) to enrich its integrated distance matrix as well as the received transport orders, which are pre-processed in compliance with given user restrictions. The depicted diagram shows the “ecoTour creator” taking inputs from internal application processes such as “Time/CO2 ratio selector” and the “Transport order receiver” as well as from the external application process SP5 outbound information on “Traffic states & prediction”. The produced output by the “ecoTour creator” is forwarded internally to the “carbon footprint estimator” to estimate a CO2 emission for each tour, which is then externally forwarded to the “Mission authorizer” via a transfer database interface. In return, the “ecoTour creator” checks the feedback information provided by the “Mission authorizer” via the transfer database interface and send the ecoRoute information to the Truck ecoNavigation to perform the ecoTour in case the “mission authorization” is granted. NB: More information on the transfer database is available in Section 5.6 and in Appendix C – Transfer database. In the City Logistics the “mission authorizer” receives the authorisation request and checks the mission description against the requirements set through the “mission authority - parameters creator” and sends back to the “ecoTour creator” (via transfer database) a mission approval report upon which the authorization can be granted or not. Upon notification the “Truck ecoNavigation” executes the authorised ecoTour and continuously strives to stick to the planned path (i.e. tour stop sequence) and inform about any major deviation which might have influence on the originally expected performance in terms of timing, fuel consumptions as well as CO2 emission. During


14-03-2011 19 Version 1.0

execution, the “Truck ecoNavigation” regularly checks the most probable path “MPP” advice provided by the “ecoRoute Navigation” service onboard the vehicle against the actual state of the planned path “ecoTour status & updates” and thereby provide an update when necessary to manually adjust the ecoTour as well as notify the BO about the route change. In the BO the “ecoTour” agent retrieves throughout various information channels data that affects his trucks. When needed the agent can repeat the planning of the “tour station list” and then forward the ecoTour information to the application process, producing hereby an update of the carbon footprint estimation, while taking the initial estimate as a starting and default condition. Within the vehicle, the “OB driving profile calculator” continuously measures and calculates the real-time (RT) carbon footprint (CFP) based on the actual status of the ecoTour progress and consequently the RT-CFP results are continuously displayed locally on the OB-HMI and at the end of the ecoTour sent to the BO for assessment purposes. At the end of the ecoTour the “real carbon footprint provider” within the BO checks the expected value against the measured value reported from the vehicle via the transfer database and makes an assessment of the real carbon footprint. Finally, the “carbon footprint manager” stores the assessed carbon-footprint value locally on the BO and sends a copy to the TMC.

D4.2 - Functional Architecture and System Specification

Figure 6: Application Layer – ecoTourPlanning

14-03-2011 20 Version 1.0


14-03-2011 21 Version 1.0

4.1.2. Technology Layer

The Truck ecoTourPlanning itself is completely deployed in the back office (BO), however the components it needs to communicate with are partially deployed in the same BO and partially on logistics central systems as well as on the truck, see Figure 7. Application processes

• ecoTour Creator: responsible for creating the eco-friendly tour sequence • Carbon footprint calculator: calculates the carbon footprint • ecoTour set-points monitor: monitors the ecoTour status “info and updates” • ecoTour adjustor: perform the manual adjustment of the ecoTour • ecoTour checker: checks the actual status and updates of the ecoTour • Mission authorizer: agent authorizing missions in City Logistics schemes • Mission policy parameters creator: provide City Logistics policy parameters

database Facility processes

• Traffic state & prediction receiver: provides info and predictions about the traffic state

• Time/CO2 ratio selector: select a ratio trade off between CO2 and time • Transport order receiver: receive orders from the transport planner • Truck ecoNavigation: perform ecoTour • Driving profile calculator: calculates “OB” the driving profile of the driver


14-03-2011 22 Version 1.0

Truck ITS Station

BO Central ITS Station

3

Softw ExecPlatform

Softw ExecPlatform

4

1 2

Logistics Central ITS Station

Softw ExecPlatform

Facilities ecoDriverCoachingSystem VIS Code

Facilities BO CIS Code

BO ecoTourPlanning CIS Code

Time/CO2 ratio selector

Transport orders

receiver

Logistics ecoTourPlanning CIS Code

Missionauthorizer

1

2

3 4

ecoTrip

OriginDestinationConstraints

ecoTour Ordered collection of

Initially expected carbon footprint

indicator

Estimated value per actual ecoTour

Route update information

ETALast positionTimestampActive destinationReason for route change

Authorization flag

Yes or NoDetailed report and recommendations e.g. parameter not respected and required changes

Authorised mission

ecoTour info

Facilities Truck-ecoNavigation VIS Code

Truck ecoNavigation

ecoTour checker

ecoTour adjustor

ecoTour creator

ecoTour setpoints Feedback monitor

Carbon footprint estimator

Real carbon footprint providor

BO Carbon footprint manager

ecoCoaching

Mission policy parameters-

creator

TMC Central ITS Station

Softw ExecPlatform

TMC CIS Code

Traffic states & predictions

receiver

5 6

5 6

ecoMap data

Historicalpredictions

BO-Ego ecoMap data

Real Ego carbon footprint history data

Figure 7: Technology Layer – ecoTourPlanning

The messages interchanged between the ITS stations are defined in more detail in other work packages WP2.4.1 & WP2.4.2 dealing with the core technology, and therefore more and explicit information can be found in the following deliverables [D2.2], [D2.3] as well as [D2.4].

4.2. Truck ecoNavigation


The application layer closely reflects the business layer. Some closely related functions are planned to be provided together by one component; this particularly affects the Routing Engine which provides some auxiliary functions besides the route


14-03-2011 23 Version 1.0

calculation proper, and the distribution of route information to other parts of the eCoMove system. The only component introduced at this level is the Energy Consumption Estimator which calculates the energy consumption for a single road.

Figure 8: Application Layer ‐ Truck ecoNavigation


As shown in Figure 9, the Truck ecoNavigation itself is completely deployed in-vehicle, but needs to communicate both with components deployed in the same vehicle and with components deployed on central ITS stations. The messages exchanged between the ITS stations will be defined in detail as part of the technical design and development (work package 4.4) and documented in Deliverable [D4.4], so here just their existence is stated. Inside the truck, there will be at least two different execution environments, a Linux based one for the Communication Control Unit (defined by SP2, see [D2.2]) and a Windows based one (ADASRP) for the actual navigation. The assignment of other components to these platforms will be defined during the development phase (work package 4.4) and documented in Deliverable 4.4; while assignment of all application components to the Application Unit would be preferable, technical constraints may require the assignment of application components to the Communication Control Unit, as it is shown in the diagram for the ecoCooperativeHorizon and the ecoHMI (both from SP3, see [D3.2]). This diagram is in no way authoritative for the


14-03-2011 24 Version 1.0

assignment of these components though. Details of the message exchange between the two execution environments very much depend on the specifics of the environments and on the assignment of components to them, so these details will be defined only in the development phase (work package 4.4) and will be documented in Deliverable 4.4

Figure 9: Technology Layer ‐ Truck ecoNavigation

4.3. ecoDriverCoaching


From the previously described business layer diagrams (on-board and backoffice), the application layer diagrams are derived. For readability sake, they are split into 3 diagrams:

• Pre-trip (on-board) • On-trip (on-board) • Post-trip (on-board and off-board)

Within the pre-trip application layer diagram (Figure 10) the “sensors accessor” component interfaces with an OEM specific sensor data provider to extract vehicle status data. This data is fed to the vehicle status checker, which, based on its settings, derives the list of checks passed and organs to be checked. This is presented to the driver via the HMI manager.


14-03-2011 25 Version 1.0

Figure 10: Application Layer ‐ ecoDriverCoaching (pre‐trip)

In the on-trip phase, the same sensor data provider / accessors components retrieve vehicle data as e.g. speed, RPM, fuel consumption. Two services external to SP4 provide data needed by the driving profile calculator and the advice generator:

• ecoSituationalModel: indicates the forecasted behaviour of the surrounding environment (vehicle and infrastructure) and of the driver of ego vehicle. This is an SP2 service, described in more details in [D2.2].

• ecoCooperativeHorizon provider: indicates map information along the most probable path of the ego-vehicle. This is an SP3 service described in [D3.2].

The advice generator use this data to generator eco-driving advices based on the current settings (received from the backoffice and/or managed locally by the driver). The advices are presented to the driver via the HMI manager. The driving profile generator computes KPIs representative of the driving style and builds a driving profile, containing carbon foot print of the trip. This data object will be used in the post-trip phase (see next diagram) and is also sent to the ecoTourPlanning backoffice application for the carbon footprint of the mission.

Figure 11: Application Layer ‐ ecoDriverCoaching (on‐trip)


14-03-2011 26 Version 1.0

When the trip is over, a driving profile based on KPIs calculated during the trip is enhanced with driver comments. The interaction with the driver is made in two steps, both making use of the HMI manager:

• comment collection: driver input is retrieved • feedback display: driver is presented with feedback of his trip

The commented driver profile is sent from the vehicle to the ecoFleetBusiness application on the backoffice to “Driving Profile Receiver”. The component Driving Profile Analyzer use the database of driving profile to make reports for the whole fleet or a specific driver. Finally the “CoachingSystem Settings updater” component sends update setting to the in-vehicle ecoDriverCoach.

Figure 12: Application Layer ‐ ecoDriverCoaching (post‐trip)


The technology layer depicted in Figure 13 shows the physical mapping of components from Application Layers onto devices. The ecoDriverCoaching has only in-vehicle and backoffice components, nothing on the road side. FleetBusinesApplication is running on the backoffice (Central ITS station) with four components to receive and analyze the driving profile, display results and update remotely the in-vehicle settings. On the vehicle side, the distinction has been made between the core ecoDriverCoaching and facilities, which are shared functionality in the rest of the in-vehicle system. These facilities are the vehicle data access, HMI management, ecoCooperativeHorizon and ecoSituationModel.


14-03-2011 27 Version 1.0

Data exchanges in the responsibility of ecoDriverCoaching are:

• driving profile (1) and settings (2) between the vehicle and the backoffice. Foreseen technology used here is web services over long range communication (3G)

• vehicle data (3): data from FMS or OEM proprietary CAN messages will be made available in the software execution platform by the “Vehicle sensor data provider”.

Although in-vehicle ecoDriverCoaching will not directly exchange data with other vehicle or the infrastructure, it uses facilities that will (data objects 4 and 5 below). ecoFVD and ecoTSD are ecoMessages documented in [D2.5].

Figure 13: Technology Layer – ecoDriverCoaching


5. Interface Design

5.1. ecoTourPlanning

REQUIRES SP Diagram Author Requires Object Required From SP Reference Diagram Contact

ecoTourPlanning Krietsch, F. requires traffic state and prediction EcoATS SP5 EcoTourPlanning Matthias Mann

ecoTourPlanning Krietsch, F. requires Mission autorisation Mission Authorizer SP4 EcoTourPlanning F. Gatti

ecoTourPlanning Krietsch, F. requires Carbon footprint

post‐trip driving feedback (including carbon footprint) SP4 ecoDriverCoaching Vernet, G.

ecoTourPlanning Krietsch, F. requiresRoute update information (event based) Truck ecoNavigation SP4 Truck ecoNavigation Stille, J.

Table 1: Data objects required by ecoTourPlanning

PRODUCES SP Diagram Author Produces Object Delivered To SP2 Reference Diagram Contact

SP4 ecoTourPlanning Krietsch , F produces ecoTour Truck ecoNavigation SP4 Truck ecoNavigation Stille, J.

SP4 ecoTourPlanning Krietsch , F produces ecoTour Mission Authorizer SP4 Truck ecoNavigation Fabrizio Gatti

Table 2: Data objects produced by ecoTourPlanning

14-03-2011 28 Version 1.0


14-03-2011 29 Version 1.0

5.2. Truck ecoNavigation

REQUIRES SP Diagram Author Requires Object Required From SP2 Reference Diagram Contact

SP4 Truck ecoNavigation Stille, J. requires Static Map ecoMap SP2 ecoMap T'Siobbel, S.; Stille, J.

SP4 Truck ecoNavigation Stille, J. requires Map‐Matched Situational Data ecoMap SP2 ecoMap T'Siobbel, S.; Stille, J.

SP4 Truck ecoNavigation Stille, J. requires Map‐Matched Traffic Information ecoMap SP2 ecoMap T'Siobbel, S.; Stille, J.

SP4 Truck ecoNavigation Stille, J. requires Route Advice Traffic Management SP5Improve Network Usage Dowideitt, C.

SP4 Truck ecoNavigation Stille, J. requires Current Position ecoCooperativeHorizon SP3 ecoCooperativeHorizon Stille, J.

SP4 Truck ecoNavigation Stille, J. requires Vehicle Parameters ecoTourPlanning SP4 ecoTourPlanning Krietsch, F.

SP4 Truck ecoNavigation Stille, J. requires Trip Data ecoTourPlanning SP4 ecoTourPlanning Krietsch, F.

SP4 Truck ecoNavigation Stille, J. Requires Vehicle Parameters ecoHMI SP3

SP4 Truck ecoNavigation Stille, J. Requires Trip Data ecoHMI SP3

Table 3: Data objects required by Truck ecoNavigation


SP4 Truck ecoNavigation Stille, J. produces ecoRoute Traffic Management SP5 Improve Network Usage Dowideitt, C.

SP4 Truck ecoNavigation Stille, J. produces ecoRoute ecoCooperativeHorizon SP3 ecoCooperativeHorizon Stille, J.

SP4 Truck ecoNavigation Stille, J. produces ecoRoute ecoTourPlanning SP4 ecoTourPlanning Krietsch, F.

SP4 Truck ecoNavigation Stille, J. produces ETA ecoTourPlanning SP4 ecoTourPlanning Krietsch, F.

Table 4: Data objects produced y Truck ecoNavigation


14-03-2011 30 Version 1.0

5.3. ecoDriverCoaching

REQUIRES SP Diagram Author Requires Object Required From SP2 Reference Diagram Contact

SP4 ecoDriverCoaching Vernet,G. requires ecoSituationalData eSituationalModel SP2 eSituationalModel Philipp Themann

SP4 ecoDriverCoaching Vernet,G. requires ecoCooperativeHorizon ecoCooperativeHorizon SP3 ecoCooperativeHorizon Johannes Stille

SP4 ecoDriverCoaching Vernet,G. requires vehicle data vehicle sensors SP4 ecoDriverCoaching Vernet, G.

SP4 ecoDriverCoaching Vernet,G. requires ecoDriverCoaching settings ecoFleetBusiness SP4 ecoDriverCoaching Vernet, G.

Table 5: Data objects required by ecoDriverCoaching


SP4 ecoDriverCoaching Vernet, G. produces Driving Profile Fleet evaluation SP4 ecoDriverCoaching Vernet, G.

SP4 ecoDriverCoaching Vernet, G. produces Carbon footprint Carbon footprint SP4 ecoTourPlanning Kriestch, F.; El Ghouti N.

SP4 ecoDriverCoaching Vernet, G. produces ecoDriving advice ecoHMI SP3/4

Table 6: Data objects produced by ecoDriverCoaching


14-03-2011 31 Version 1.0

5.4. Vehicle Data Access All SP4 applications require access to vehicle sensors data. This will be achieved with an OEM specific vehicle gateway that feeds the eCoMove system with vehicle data. The actual gateway device is the responsibility of DAF and VTEC who will both equip one demonstrator truck. The vehicle data will be made available to components and applications within the eCoMove software execution platform via the Data Exchange facility service from SP2. When applicable the vehicle data inside the Data Exchange facility should follow standards like FMS. See [FMS] and Appendix B – Fleet Management Standard.

5.5. Truck parking availability data from SP5 The SP5 application ecoTruckParking (see [D5.2]) can deliver truck parking availability information. This data will inform in real time the status of a truck parking area on the motorway: closed, available, full. Although this does not directly answer one of SP4 use cases, parking availability information in advance can help reduce fuel consumption. Indeed a truck exiting the highway, traversing a parking area with no free space and accelerating to enter again the motorway is an evident fuel inefficiency. It has been decided to integrate this information on the vehicle side inside Truck ecoNavigation. In this way the driver can see parking availability together with his route guidance. The technical details on how the parking availability data will be inserted in the eCoMove system (ecoMap, TPEG, client/server) will be defined in the implementation phase and documented in [D4.4].

5.6. Overview of SP4 internal interfaces In the previous sections each application has been described in details with its Business Layer, Application Layer and Technology layer. The following diagram gives an overview of the SP4 components and their internal interfaces as a recap. Although the technical details of each interface will be defined in course of the implementation phase and are subject to changes, the interfaces are briefly described below. The interface numbering refers to the numbers in Figure 14. The final documentation will be available after the WP4 phase when applications are finalized in deliverables [D4.3], [D4.4] and [D4.5].


Figure 14: Overview of internal SP4 interfaces

14-03-2011 32 Version 1.0


14-03-2011 33 Version 1.0

Interface 1: Aim of interface 1 is the exchange of information on planned tours between logistics company back office and city logistics. Planned tours are a result of the ecoTourCreator in the logistics back office. As a result of the ecoTourCreator, planned tours are stored in a dedicated exchange database. Information exchange in interface 1 takes place bi-directionally (Logistics Company – city logistics and vice versa). The ecoTourCreator stores information needed for city logistics assessment of the specific tours with the status flag “ready to check” in the transfer database. City logistics mission controller checks the transfer database, (trigger needs to be specified). Depending on the policy provided by the policy manager, mission controller grants or denies access for the tour. The result is an update of the status flag in the transfer database. On top of the IT mechanism chosen to build this interaction, the data exchanged is describing the mission with all the information required by the authorization algorithm, implementing the policies adopted by Local Authorities. Parameters of interest, and still in evaluation phase, are: 1. Starting time of the planned tour 2. Expected ending time of the planned tour 3. Number of stations to be serviced along the way (only target included within the

urban area considered) 4. Load variation “charge/discharge” along the planned tour (only for target included

within the urban area considered) 5. Truck type (Hybrid, long-haul, etc…) 6. Truck “and Cargo” dimensions (size and weight) 7. Power class (engine settings) 8. Payload (cargo settings) 9. CO2 label and other parameters settings Interface 2: Aim of interface 2 is the exchange of information on planned and accepted (by city logistics) tours between Logistics Company back office and in-vehicle ecoNavigation client. Tours which have been accepted by the city logistics mission controller receive the status flag “ready for execution”. The content of the tour information stored in the transfer database remains the same. Thus city logistics mission controller and in-vehicle ecoNavigation both have the same data available. In case there is a tour with the flag “ready for execution” available which is meant to be executed by the specific vehicle (identification e.g. via plate), the ecoNavigation client pulls the information needed (e.g. stop station sequence, times) and executes the tour. In return the ecoNavigation client can store route update information in the transfer database, e.g. stop point reached, mission completed, GPS position etc. Thus the communication takes place bi-directional via the transfer database. Interface 3: Aim of interface 3 is the exchange of information on CO2 emissions between in-vehicle ecoDriverCoach and Logistics Company back office. This interface is unidirectional. Data recorded in the vehicle is stored in the transfer database for the specific tour either during execution or post trip.


Figure 15: Overview of SP4 logistics back office interfaces to vehicle and city logistics

Note: for more information on the transfer database, see also Appendix C – Transfer database.

14-03-2011 34 Version 1.0


14-03-2011 35 Version 1.0

Interface 4: This interface is internal to the ecoDriverCoaching and will allow the exchange of driving profiles and ecoDriverCoaching settings between the vehicle side and its backoffice counterpart. The foreseen technical solution to realise this interface is web services using SOAP protocol. The exact content of the data exchanged between the vehicle side and the backoffice side of the application are part of eCoMove research questions and will be further defined during the implementation phase. Current discussions foresee for driving KPIs:

• usage of accelerator pedal • usage of brake and retarder • usage of gearbox • anticipation • coasting • idling • load • number and types of advices shown and driver reaction to them

This will be further documented in Deliverable [D4.5] at the end of WP4.


6. Requirements traceability The following three sections contain the mapping between requirements defined in deliverable [D4.1] and architecture components presented above.

6.1. ecoTourPlanning Requirement Design

Application (Diagram) (optional) eML Concept BL|TL|AL

SP4-3-01 ecoTour Planning Pre-Trip Get tour planning info from BO database, TMC&SP5-ecoATs and fleet planner BL, AL

SP4-3-01 ecoTour Planning Pre-Trip Send planned tour information to fleet planner HMI AL SP4-3-02 ecoTour Planning Pre-Trip Get historic traffic data and mid term predictions from SP5-ecoATS BL, AL SP4-3-02 ecoTour Planning Pre-Trip Send historic traffic data and mid term predictions to BO fleet planner AL SP4-3-03 ecoTour Planning Pre-Trip Get transport order parameters from mission database BL, AL SP4-3-03 ecoTour Planning Pre-Trip Get initial time/CO2 constraint from database AL SP4-3-03 ecoTour Planning Pre-Trip Send automatically mapped tour info to BO fleet planner AL SP4-3-04 ecoTour Planning Pre-Trip Get trip data info for each planned tour from BO fleet planner AL SP4-3-04 ecoTour Planning Pre-Trip Send CO2 forecast for each planned tour to BO fleet planner AL SP4-3-05 ecoTour Planning Pre-Trip Get transport parameter info from mission order BL, AL SP4-3-05 ecoTour Planning Pre-Trip Get initial time/CO2 default values from database AL SP4-3-05 ecoTour Planning Pre-Trip Get traffic states and predictions from TMC BL, AL SP4-3-05 ecoTour Planning Pre-Trip Send planned tours information to fleet planner HMI AL SP4-3-06 ecoTour Planning Pre-Trip Get trip data info from BO fleet planner AL SP4-3-06 ecoTour Planning Pre-Trip Send trip data info request to City Logistics BL, AL

14-03-2011 36 Version 1.0


Requirement Design

Application (Diagram) (optional) eML Concept BL|TL|AL SP4-3-07 ecoTour Planning Pre-Trip Get trip-authorization info from City Logistics AL SP4-3-07 ecoTour Planning Pre-Trip Send trip-execution notification to TruckEcoNavigation BL, AL SP4-3-08 ecoTour Planning On-Trip Get traffic data updates from Traffic Management Centre (TMC) BL, AL SP4-3-08 ecoTour Planning On-Trip Get Trip Data updates from BO fleet planner AL SP4-3-08 ecoTour Planning On-Trip Send Trip Data updates to OB TruckEcoNavigation AL SP4-3-09 ecoTour Planning Post-Trip Get CO2 Data from BO carbon footprint estimator AL SP4-3-09 ecoTour Planning Post-Trip Get CO2 Data from OB carbon footprint calculator/measurement BL, AL SP4-3-09 ecoTour Planning Post-Trip Send actual CO2-performance data to fleet planner HMI AL

Table 7: Requirement matrix ‐ ecoTourPlanning

6.2. Truck ecoNavigation Requirement Design

Application (Diagram) (optional) eML Concept BL|TL|AL SP4-2-01 Truck ecoNavigation Get Trip Data from Tour Planning BL SP4-2-01 Truck ecoNavigation Get Trip Data from Back Office AL SP4-2-02 Truck ecoNavigation Get Trip Data from Tour Planning BL SP4-2-02 Truck ecoNavigation Get Trip Data from Back Office AL SP4-2-03 Truck ecoNavigation Get Trip Data from Tour Planning BL SP4-2-03 Truck ecoNavigation Get Trip Data from Back Office AL SP4-2-04 Truck ecoNavigation Get Trip Data from Driver BL, AL SP4-2-05 Truck ecoNavigation Off Route (Trigger) BL SP4-2-06 Truck ecoNavigation Calculate Route BL, AL

14-03-2011 37 Version 1.0


Requirement Design

Application (Diagram) (optional) eML Concept BL|TL|AL SP4-2-07 Truck ecoNavigation Calculate Route BL, AL SP4-2-08 Truck ecoNavigation Get Traffic Information, Get Situational Data BL, AL SP4-2-09 Truck ecoNavigation Get Situational Data BL, AL SP4-2-10 Truck ecoNavigation Get Route Advice BL, AL SP4-2-11 Truck ecoNavigation Calculate Route BL, AL SP4-2-12 Truck ecoNavigation Warn of Impossible Route BL, AL SP4-2-13 Truck ecoNavigation Calculate Route BL, AL SP4-2-14 Truck ecoNavigation Calculate Route BL, AL SP4-2-15 Truck ecoNavigation Get Vehicle Parameters from Fleet Planning, Get Vehicle

Parameters from Vehicle, Get Vehicle Parameters from Driver BL

SP4-2-15 Truck ecoNavigation Get Vehicle Parameters from Back Office, Get Vehicle Parameters from Vehicle, Get Vehicle Parameters from Driver

AL

SP4-2-16 Truck ecoNavigation Calculate Route BL, AL SP4-2-16 Truck ecoNavigation Estimate Link Energy Consumption AL SP4-2-17 Truck ecoNavigation Calculate Route BL, AL SP4-2-18 Truck ecoNavigation Calculate Route BL, AL SP4-2-19 Truck ecoNavigation Calculate Route BL, AL SP4-2-20 Truck ecoNavigation Data Available (Trigger) BL SP4-2-21 Truck ecoNavigation Calculate Route BL, AL SP4-2-22 Truck ecoNavigation Guide Driver BL SP4-2-22 Truck ecoNavigation Give Instructions AL SP4-2-23 Truck ecoNavigation Send ETA to Back Office, Send Route to Back Office BL, AL

Table 8: Requirement matrix ‐ Truck ecoNavigation

14-03-2011 38 Version 1.0


6.3. ecoDriverCoaching Requirement Design

Application (Diagram) (optional) eML Concept BL|TL|AL SP4-1B-01 ecoDriverCoaching - on-board Checklist verification BL SP4-1B-01 ecoDriverCoaching - pre-trip Vehicle Status Checker AL SP4-1B-02 Truck ecoNavigation Guide Driver BL SP4-1B-03 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-03 ecoDriverCoaching - on-trip Advice Generator AL SP4-1B-04 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-05 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-05 ecoDriverCoaching - on-trip Display Advices AL SP4-1B-06 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-06 ecoDriverCoaching - on-trip Receive & manage settings AL SP4-1B-06 ecoDriverCoaching - post-trip CoachingSystem settings updater AL SP4-1B-07 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-07 ecoDriverCoaching - on-trip Display Advices AL SP4-1B-08 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-08 ecoDriverCoaching - on-trip Driving Profile Calculator AL SP4-1B-10 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-10 ecoDriverCoaching - on-trip Display Advices AL SP4-1B-10 ecoDriverCoaching - on-board ecoDriving Advices BL SP4-1B-11 ecoDriverCoaching - on-trip Display Advices AL SP4-1B-12 ecoDriverCoaching - on-board Access Driving situation BL SP4-1B-13 ecoDriverCoaching - on-board ecoHMI BL

14-03-2011 39 Version 1.0


14-03-2011 40 Version 1.0

Requirement Design Application (Diagram) (optional) eML Concept BL|TL|AL

SP4-1B-13 ecoDriverCoaching - on-board ecoHMI AL SP4-1B-14 ecoDriverCoaching Driver Settings BL, AL SP4-1B-15 ecoDriverCoaching - on-board Situational data, ecoHorizon BL, AL SP4-1B-16 ecoDriverCoaching Driver Settings BL, AL SP4-1B-17 ecoDriverCoaching - post-trip CoachingSystem settings updater AL SP4-1B-18 ecoDriverCoaching - on-board Profile evaluation BL SP4-1B-18 ecoDriverCoaching - post-trip Driver comment handler, Feedback provider AL SP4-1B-19 ecoDriverCoaching - on-board Profile evaluation BL SP4-1B-19 ecoDriverCoaching - post-trip Driving profile sender AL SP4-1B-20 ecoDriverCoaching - on-board Profile evaluation BL SP4-1C-01 ecoDriverCoaching - backoffice Historical Driving profiles BL SP4-1C-01 ecoDriverCoaching - post-trip Driving profile receiver AL SP4-1C-03 ecoDriverCoaching - backoffice Fleet Manager evaluation service BL SP4-1C-03 ecoDriverCoaching - post-trip Analysis presenter AL SP4-1C-04 ecoDriverCoaching - backoffice Fleet Manager evaluation service BL SP4-1C-04 ecoDriverCoaching - post-trip Analysis presenter AL SP4-1C-07 ecoDriverCoaching - backoffice Driver evaluation service BL SP4-1C-07 ecoDriverCoaching - post-trip Analysis presenter AL SP4-1C-08 ecoDriverCoaching - backoffice Driver evaluation service BL SP4-1C-08 ecoDriverCoaching - post-trip Analysis presenter AL SP4-1C-09 ecoDriverCoaching - backoffice Historical Driving profiles BL

Table 9: Requirement matrix ‐ ecoDriverCoaching


14-03-2011 41 Version 1.0

Appendix A – Overview of SP4 ITS stations The following Technology Layer diagram shows how SP4 design components maps to ITS stations.

Figure 16: Overview of SP4 ITS stations


Appendix B – Fleet Management Standard FMS is a standard within major truck manufacturers to give third parties access to vehicle data. The following picture gives an overview of messages defined in FMS standard v2. More information can be found at www.fms-standard.com.

14-03-2011 42 Version 1.0

http://www.fms-standard.com/


14-03-2011 43 Version 1.0

Appendix C – Transfer database NB: the following description comes from on-going work in WP4.4.1. Further documentation will be available in [D4.3] after the implementation of ecoTourPlanning. The transfer database includes transfer-objects (import- and export-objects). These transfer-objects are being used and interpreted by the involved partners, e.g. the back office planning system exports for instance Tour data into the database and, later on during the mission execution, takes position data and messages of the vehicle telematic system into account. The physical process is based on a handshake procedure. Using flags (timestamp and action codes) the logical data exchange is managed. Export of planning data can be split into export of tour data, export of vehicle data and export of driver data. During the export of tour information, tour statistical data (total distance, number of transport orders; ...) as well as the resource allocation of tour and stop point activities including emissions for tour and single sequence tour stops is being delivered. The following diagram gives a system overview of the tables and interfaces as well as used keys.


As for an example the data set “Export of Tour data” is being presented in the following paragraph.

14-03-2011 44 Version 1.0


14-03-2011 45 Version 1.0

Table EXP_TOUR_HEADER:

field name typ description

TH_EXP_REFERENCE NUMERIC(9) Specific identification of export data set, corresponding to EXP_REFERENCE in EXP_HEADER

TH_PRECOMBINATION VARCHAR(255) Name of tour

TH_ORDERS NUMERIC(9) Number of transport orders in tour

TH_STOPS NUMERIC(9) Number of stop points in tour

TH_NOTES VARCHAR(255) Tour notes

TH_TOUR_OWNER VARCHAR(255) Planner who created the tour

TH_GROUPING1 VARCHAR(255) Tour group

TH_PROCESS_STATE NUMERIC(1) Process status of tour

TH_START_DATE NUMERIC(8) Tour start (date)

TH_START_TIME NUMERIC(4) Tour start (time)

TH_END_DATE NUMERIC(8) Tour end (date)

TH_END_TIME NUMERIC(4) Tour end (time)

TH_INTERVAL NUMERIC(9) Shifting interval of which the tour is allowed to be shifted without getting invalid

TH_DURATION NUMERIC(9) Tour duration

TH_DRIVINGTIME NUMERIC(9) Driving time of tour

TH_DRIVINGTIME_FACTOR NUMERIC(9) DRIVINGTIME_FACTOR (=factor which is used for multiplication of driving times of tour segments to enable in general vehicle or day time dependent time bonus or malus situations.

TH_HANDLINGTIME NUMERIC(9) Total handling time during stop stations

TH_IDLETIME NUMERIC(9) Total idle time

TH_WAITINGTIME NUMERIC(9) Total waiting time (due to arrival outside handling times)

TH_DISTANCE NUMERIC(9) Total tour distance

TH_EMPTY_DISTANCE NUMERIC(9) Total empty distance driven in tour

TH_RETURN_DISTANCE NUMERIC(9) Distance for returning to the depot at the end of the tour

TH_RETURN_DURATION NUMERIC(9) Duration for returning to the depot at the end of the tour

TH_DEPOT_LOADINGTIME NUMERIC(9) Time to load in the depot


14-03-2011 46 Version 1.0

TH_DEPOT_UNLOADINGTIME NUMERIC(9) Time to unload in the depot

TH_TURNINGTIME NUMERIC(9) Time to turn in the depot

TH_CODRIVER_NEEDED NUMERIC(1) Is a co-driver needed

TH_QUANTITY1 NUMERIC(9) Total mass of all transport orders in tour

TH_QUANTITY2 NUMERIC(9) Total volume of all transport orders in tour

TH_QUANTITY3 NUMERIC(9) Number of transport items to be transported in tour

TH_TOLLFEE NUMERIC(9) toll fee

TH_TOLLFEE_DISTANCE NUMERIC(9) Toll fee distance

TH_TOLLFEE_CURRENCY VARCHAR(3) Currency in which toll fee is calculated

TH_OWNCOST NUMERIC(9) Own cost

TH_OWNCOST_CURRENCY VARCHAR(3) Currency in which own cost is calculated

TH_RESOURCE_INFO VARCHAR(255) Vehicle ID of executing vehicle

TH_RESOURCE_LICENCEPLATE VARCHAR(255) Resource license plate

TH_DRIVER_INFO VARCHAR(255) Driver information

TH_HAULIER_INFO VARCHAR(255) Haulier information

TH_CUSTOM_STRING1 VARCHAR(255) Empty alphanumeric field




TH_CUSTOM_NUM1 NUMERIC(9) Empty numeric field




Table EXP_TOUR_TRANSPORTPOINT:


TP_EXP_REFERENCE NUMERIC(9) Identification of export tour data set, corresponds with EXP_REFERENCE in EXP_HEADER

TP_SEQU_NUMBER NUMERIC(9) Sequence number of loading/unloading during tour

TP_TS_SEQU_NUMBER NUMERIC(9) Link to corresponding stop number


14-03-2011 47 Version 1.0

TP_ACTIONPOINT_SEQU_NUMBER NUMERIC(9) Sequence number of stop point

TP_ACTION NUMERIC(2) Action at stop point

TP_ORDER_EXTID VARCHAR(255) External order ID

TP_ROUTE_SPLIT_NUMBER NUMERIC(5) ROUTE_SPLIT_NUMBER (in case of split), else 0

TP_LOAD_SPLIT_NUMBER NUMERIC(5) LOAD_SPLIT_NUMBER (in case of split), else 0

TP_ORDER_TYPE NUMERIC(2) order type

TP_ORDER_KIND VARCHAR(255) Kind of order

TP_QUANTITY1 NUMERIC(9) Weight

TP_QUANTITY2 NUMERIC(9) Volume

TP_QUANTITY3 NUMERIC(9) Number of items

TP_QUANTITY4 NUMERIC(9) Quantity (free to define)



TP_LENGTH NUMERIC(9) lenght

TP_WIDTH NUMERIC(9) width

TP_HEIGHT NUMERIC(9) height

TP_CUSTOM_STRING1 VARCHAR(255) Empty alphanumeric field




TP_CUSTOM_NUM1 NUMERIC(9) Empty numeric field



TP_TRANSPORT_CUSTOM_STRING1VARCHAR(255) Empty alphanumeric field




TP_TRANSPORT_CUSTOM_NUM1 NUMERIC(9) Empty numeric field




14-03-2011 48 Version 1.0

Table EXP_EMISSION will contain all the emission values for the whole Tour and for each tour stop. Table EXP_EMISSION:


EM_EXP_REFERENCE NUMERIC(9) Specific identification of export data set, corresponding to EXP_REFERENCE in EXP_HEADER

EM_EMISSIONTYPE NUMERIC(2) Emissionstyp

EM_STOPNUMBER NUMERIC(9) Stop number

EM_HC NUMERIC(5) emissions HC (*100

EM_CO NUMERIC(5) emissions CO (*100

EM_NOX NUMERIC(5) emissions NOx (*100

EM_MKR NUMERIC(5) emissions mKr (*100

EM_PARTIKEL NUMERIC(5) emissions Partikel (*100

EM_CO2 NUMERIC(5) emissions CO2 (*100

EM_CH4 NUMERIC(5) emissions CH4 (*100

EM_NMHC NUMERIC(5) emissions NMHC (*100

EM_PB NUMERIC(5) emissions Pb (*100

EM_SO2 NUMERIC(5) emissions SO2 (*100

EM_N2O NUMERIC(5) emissions N2O (*100

EM_NH3 NUMERIC(5) emissions NH3 (*100

EM_C6H6 NUMERIC(5) emissions C6H6 (*100



In the table EXP_TOUR_RESOURCE resource utilization (vehicle, trailer, driver,..) are listed. Table EXP_TOUR_RESOURCE:

field name typ description definition

SR_EXP_REFERENCE_FROM NUMERIC(9) Specific identification of export data set, corresponding to EXP_REFERENCE in EXP_HEADER


14-03-2011 49 Version 1.0

SR_TS_SEQU_NUMBER_FROM NUMERIC(9) Sequence number of first station (depot)

SR_EXP_REFERENCE_TO NUMERIC(9) Specific identification of export data set, corresponding to EXP_REFERENCE in EXP_HEADER

Identical to SR_EXP_REFERENCE_FROM

SR_TS_SEQU_NUMBER_TO NUMERIC(9) Sequence number of last station (depot)

SR_EXTID VARCHAR(255) External ID of resource

SR_RESOURCETYPE NUMERIC(2) Resource type 1=Vehicle 2=Driver

SR_LICENCEPLATE VARCHAR2(255) License plateSR_RESOURCETYPE=1 (Vehicle)

SR_VEHICLETYPE NUMERIC(2) Vehicle type SR_RESOURCETYPE=1 (Vehicle)

0=TRUCK 1=SEMI_TRAILER_TOWING 2=TRAILER 3=SEMI_TRAILER 4=DOUBLE_ROAD_TRAIN 5=ROAD_TRAIN 6=PASSENGER_CAR 7=CONTAINER 8=SWAP_TRAILER 9=BUS 10=OTHER

SR_PLANNEDDURATION

NUMBER(9) Planned mission duration (start-end interval of mission vehicle and driver)

SR_PRESTART_DISTANCE

NUMBER(9) Driving distance to reach the first tour stop location

SR_PRESTART_DURATION

NUMBER(9) Driving duration to reach the first tour stop location

SR_PRESTART_EXTID VARCHAR2(255) ext. Id of origin location before driving to the first stop location

SR_PRESTART_NAME1 VARCHAR2(255) Name and further information on origin location

SR_PRESTART_NAME2 VARCHAR2(255)

SR_PRESTART_COUNTRY

VARCHAR2(3)

SR_PRESTART_ZIPCODE

VARCHAR2(64)

SR_PRESTART_CITY

VARCHAR2(255)


14-03-2011 50 Version 1.0

SR_PRESTART_CITY_DISTRICT VARCHAR2(255)

SR_PRESTART_STREET VARCHAR2(255)

SR_PRESTART_HOUSENR

VARCHAR2(255)

[END_OF_DOCUMENT]

cooperative mobility systems and services for energy ......cooperative mobility systems and services...

Documents