cooperative mobility systems and services for energy ......cooperative mobility systems and services...
TRANSCRIPT
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architectureand System Specification
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
To be published, March 2012
[D4.5] D4.5: Integrated truck driver coaching system proto
To be published, March 2012
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
D4.2 - Functional Architectureand System Specification
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).
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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
4.2.1. Application Layer
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
D4.2 - Functional Architectureand System Specification
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
4.2.2. Technology Layer
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
D4.2 - Functional Architectureand System Specification
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
4.3.1. Application Layer
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.
D4.2 - Functional Architectureand System Specification
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)
D4.2 - Functional Architectureand System Specification
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)
4.3.2. Technology Layer
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.
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architecture and System Specification
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
PRODUCES SP Diagram Author Produces Object Delivered To SP2 Reference Diagram Contact
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
D4.2 - Functional Architecture and System Specification
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
PRODUCES SP Diagram Author Produces Object Delivered To SP2 Reference Diagram Contact
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
D4.2 - Functional Architectureand System Specification
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].
D4.2 - Functional Architecture and System Specification
Figure 14: Overview of internal SP4 interfaces
14-03-2011 32 Version 1.0
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architectureand System Specification
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.
D4.2 - Functional Architecture and System Specification
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
D4.2 - Functional Architectureand System Specification
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
D4.2 - Functional Architectureand System Specification
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_STRING2 VARCHAR(255) Empty alphanumeric field
TH_CUSTOM_STRING3 VARCHAR(255) Empty alphanumeric field
TH_CUSTOM_STRING4 VARCHAR(255) Empty alphanumeric field
TH_CUSTOM_NUM1 NUMERIC(9) Empty numeric field
TH_CUSTOM_NUM2 NUMERIC(9) Empty numeric field
TH_CUSTOM_NUM3 NUMERIC(9) Empty numeric field
TH_CUSTOM_NUM4 NUMERIC(9) Empty numeric field
Table EXP_TOUR_TRANSPORTPOINT:
field name typ description
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
D4.2 - Functional Architectureand System Specification
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_QUANTITY5 NUMERIC(9) Quantity (free to define)
TP_QUANTITY6 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_STRING2 VARCHAR(255) Empty alphanumeric field
TP_CUSTOM_STRING3 VARCHAR(255) Empty alphanumeric field
TP_CUSTOM_STRING4 VARCHAR(255) Empty alphanumeric field
TP_CUSTOM_NUM1 NUMERIC(9) Empty numeric field
TP_CUSTOM_NUM2 NUMERIC(9) Empty numeric field
TP_CUSTOM_NUM3 NUMERIC(9) Empty numeric field
TP_TRANSPORT_CUSTOM_STRING1VARCHAR(255) Empty alphanumeric field
TP_TRANSPORT_CUSTOM_STRING2VARCHAR(255) Empty alphanumeric field
TP_TRANSPORT_CUSTOM_STRING3VARCHAR(255) Empty alphanumeric field
TP_TRANSPORT_CUSTOM_STRING4VARCHAR(255) Empty alphanumeric field
TP_TRANSPORT_CUSTOM_NUM1 NUMERIC(9) Empty numeric field
TP_TRANSPORT_CUSTOM_NUM2 NUMERIC(9) Empty numeric field
TP_TRANSPORT_CUSTOM_NUM3 NUMERIC(9) Empty numeric field
D4.2 - Functional Architectureand System Specification
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:
field name typ description
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
EM_C7H8 NUMERIC(5) emissions C7H8 (*100
EM_C8H10 NUMERIC(5) emissions C8H10 (*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
D4.2 - Functional Architectureand System Specification
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)
D4.2 - Functional Architectureand System Specification
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]