EUROPEAN COMMISSION DG INFORMATION SOCIETY & MEDIA SEVENTH FRAMEWORK PROGRAMME THEME 3 ‘INFORMATION AND COMMUNICATION TECHNOLOGIES’ SMALL OR MEDIUM-SCALE FOCUSED RESEARCH PROJECT – CONTRACT N. FP7-216353
The SMARTFREIGHT framework architecture Deliverable no. Dissemination level Work Package Author(s) Responsible organisation Status (F: final, D: draft) Date File Name Project Start Date and Duration
F5.2 Public WP5 - Framework architecture for open solution for urban freight transport Marit Natvig (SINTEF) Tor Kjetil Moseng (SINTEF) SINTEF F 8 March 2011 D5.2-SMF-Final architecture.doc 01 January 2008, 30months
D5.2 The SMARTFREIGHT framework architecture
1
SMARTFREIGHT
TABLE OF CONTENTS Executive summary
7
Glossary of abbreviations used
9
1
Introduction 1.1 The SMARTFREIGHT idea 1.2 SMARTFREIGHT framework architecture introduction 1.2.1 The aims of SMARTFREIGHT framework architecture 1.2.2 A generic approach 1.2.3 The SMARTFREIGHT framework architecture content overview 1.3 Related work 1.3.1 ARKTRANS 1.3.2 CVIS 1.3.3 Common Framework 1.3.4 GOOD ROUTE 1.4 The content of this report
11 11 12 12 12 13 14 14 14 14 15 15
2
The Reference Model 2.1 Transport Demand 2.2 Transport Supply 2.2.1 Transport Service Management 2.2.2 Transport Operation Management 2.2.3 On-board Management 2.3 Transportation Area Management 2.3.1 Transportation Network Infrastructure Management 2.3.2 Transportation Network Utilisation 2.3.3 Emergency Management 2.4 Transportation Regulation 2.5 Transport Sector Support
16 17 17 17 17 17 18 18 18 18 18 19
3
Roles and objects 3.1 Roles and objects related to Transport Demand 3.2 Roles and objects related to Transport Supply 3.3 Roles and objects related to Transportation Area Management 3.4 Roles related to Transportation Regulation 3.5 Objects related to Transport Sector Support
20 22 22 27 32 32
4
Functional view - Transport Demand 4.1 Plan and Prepare Transport 4.2 Manage Transport
33 34 34
5
Functional view - Transport Supply 5.1 Transport Service Management 5.1.1 Provide Transport Service 5.1.1.1 Manage Strategically and Tactical Transport Service Planning 5.1.1.2 Manage Customer Relations 5.2 Transport Operation Management 5.2.1 Manage Transport Operation 5.2.1.1 Manage Transport Business 5.2.1.2 Manage Transport Operation Information 5.2.1.3 Plan and Prepare Transport Operation 5.2.1.4 Control Transport Operation 5.2.1.5 Monitor Transport Operation 5.2.2 Execute Transport Operation 5.2.2.1 Manage Transport Operation Information and Progress 5.2.2.2 Report on Transport Operation
35 35 36 36 36 37 37 38 39 39 41 42 43 44 45
D5.2 The SMARTFREIGHT framework architecture
2
SMARTFREIGHT
5.3
5.2.2.3 Manage Transportation Network Resource Booking 5.2.2.4 Support Transport Task Execution On-board Management 5.3.1 Operate Vehicle 5.3.1.1 Monitor Vehicle 5.3.1.2 Support and Control Vehicle Operation 5.3.1.3 Manage Applications 5.3.2 Manage Vehicle and Transport Operation Information 5.3.2.1 Process Access and Priority Offers 5.3.2.2 Manage Transport Operation Information 5.3.2.3 Manage Certificates 5.3.2.4 Manage Route Plan 5.3.2.5 Manage Fee Payment 5.3.3 Manage En-route Reporting 5.3.3.1 Report Vehicle Tracking Information 5.3.3.2 Report Vehicle Access Information 5.3.3.3 Report Vehicle Safety Related Information 5.3.3.4 Support Traffic Situation Reporting 5.3.3.5 Support Transport Problem Reporting
45 45 46 46 47 47 49 49 49 49 50 50 50 50 50 50 50 50 51
6
Functional view - Transportation Area Management 6.1 Transportation Network Utilisation 6.1.1 Plan Transportation Network Utilisation 6.1.2 Perform Operational Traffic Management 6.1.2.1 Perform Dynamic Traffic Management Planning 6.1.2.2 Monitor Traffic Situation 6.1.2.3 Perform Traffic Control 6.1.2.4 Manage Incident 6.1.2.5 Provide Traffic Situation Information 6.1.3 Manage Transportation Network Resources 6.1.3.1 Assign Transportation Network Resource 6.1.3.2 Monitor Transportation Network Resource Usage 6.2 Transportation Network Infrastructure Management 6.2.1 Plan Transportation Network 6.2.2 Manage Transportation Network Information 6.2.3 Support Transportation Network Continuous Operation 6.3 Emergency Management
51 51 52 53 54 55 56 58 58 59 59 59 60 60 61 61 61
7
Functional view – Transport Sector Support 7.1 Monitor and Report on Item 7.1.1 Monitor Item Condition 7.1.1.1 Monitor Temperature 7.1.1.2 Monitor Humidity 7.1.1.3 Monitor Shock 7.1.1.4 Monitor Security Issues 7.1.2 Track and Report Item Position 7.1.3 Track and Report Item Handling 7.1.4 Manage and Report Item Condition and Deviations 7.1.5 Manage and Report Item Information
62 62 63 63 63 63 63 63 63 63 63
8
Process view 8.1 Processes in the Transportation Network Utilisation domain 8.1.1 Perform Operational Traffic Management 8.1.1.1 Monitor Traffic Situation 8.1.1.2 Provide Traffic Situation Information 8.1.1.3 Perform Traffic Control 8.1.2 Mange Transportation Network Resources
64 66 66 67 68 69 71
D5.2 The SMARTFREIGHT framework architecture
3
SMARTFREIGHT
8.2 8.3
8.4
8.5 8.6 9
Processes in the Transport Service Management domain 8.2.1 Provide Transport Service Processes in the Transport Operation Management domain 8.3.1 Manage Transport Operation 8.3.1.1 Plan and Prepare Transport Operation 8.3.1.2 Monitor Transport Operation 8.3.1.3 Control Transport Operation 8.3.2 Execute Transport Operation Processes in the On-board Management domain 8.4.1 Manage Vehicle and Transport Operation Information 8.4.2 Operate Vehicle 8.4.2.1 Monitor Vehicle 8.4.2.2 Support and Control Vehicle Operation 8.4.3 Manage En-route Reporting Processes in the Transport Sector Support domain Information flows
Information view 9.1 Conceptual information models 9.1.1 Transportation Network Information 9.1.2 Resource Information 9.1.3 Traffic Management Information 9.1.4 TNS Information 9.1.5 Vehicle Information 9.1.6 TOP Information 9.1.7 TOS Information 9.1.8 Route Information 9.1.9 Item Information 9.1.10 Location Information 9.2 Service interfaces and APIs
72 72 72 73 74 75 76 77 78 78 79 80 81 82 83 83 90 90 91 92 93 95 98 99 100 101 102 103 104
10 Technical aspects 10.1 The CVIS service platform 10.2 Communication infrastructure 10.2.1 IPv6 10.2.2 CALM 10.2.2.1 CALM FAST 10.2.2.2 CALM MAIL 10.2.2.3 CALM M5 10.2.2.4 CALM 2G/3G 10.3 Application management 10.4 Applications and their communication 10.4.1 Distributed Directory Service (DDS) 10.4.2 Service advertisements 10.4.2.1 Service advertisements without properties 10.4.2.2 Service advertisements with properties 10.4.2.3 Publish and subscribe to service advertisements 10.4.3 Service calls 10.5 System architecture 10.5.1 Communication between system components 10.5.2 System components 10.5.3 Information exchange 10.6 Localisation 10.6.1 Positioning 10.6.2 Location referencing
106 106 107 107 108 108 108 108 108 109 110 110 110 110 110 111 111 112 112 113 115 125 125 125
11 Deployment
126
D5.2 The SMARTFREIGHT framework architecture
4
SMARTFREIGHT
11.1 Concepts supporting the realisation of different traffic management strategies 11.2 Realisation of SMARTFREIGHT functions
126 127
12 Terminology 12.1 Access and Priority Assignment (APA) policy 12.2 Access and Priority Offer (APO) 12.3 Checkpoint 12.4 Controlled Area 12.5 Entry Notification 12.6 Exit Notification 12.7 Handling Instruction 12.8 Incident 12.9 Incident and Accident Information 12.10 Load Item 12.11 Tracking Information 12.12 Traffic Flow Information 12.13 Traffic Information 12.14 Transportation Network 12.15 Transportation Network Condition 12.16 Transportation Network Information 12.17 Transportation Network Status (TNS) 12.18 Transport Item 12.19 Transport Execution Plan (TEP) 12.20 Transport Execution Status (TES) 12.21 Transport Operation 12.22 Transport Operation Plan (TOP) 12.23 Transport Operation Status (TOS) 12.24 Transportation Network Resource 12.25 Transport Task 12.26 Vehicle Characteristics
130 130 130 131 131 131 131 131 131 131 132 132 132 132 132 133 133 133 134 134 134 134 134 134 134 135 135
References
136
Annex A. User requirements A.1 The needs of city authorities A.2 The needs of freight distributors A.3 The needs of lorry drivers A.4 The needs of goods receivers
138 138 140 145 148
Annex B. Related activities B.1 AGORA C B.2 ARKTRANS B.3 Common Framework B.4 CVIS B.5 DATEX II B.6 EasyWay B.7 ETSI B.8 EURIDICE B.9 Freightwise B.10 GOOD ROUTE B.11 ROSATTE
149 149 149 150 150 151 151 151 152 152 153 154
Annex C. Locations referencing C.1 Location Referencing Mechanisms C.1.1 TMC C.1.2 TPEG-Loc C.1.3 Agora-C C.1.4 OpenLR
155 155 155 155 156 156
D5.2 The SMARTFREIGHT framework architecture
5
SMARTFREIGHT
C.2
AGORA-C in SMARTFREIGHT
157
Annex D. Security issues D.1 Certificates D.2 Access control
158 158 158
Annex E. Access control
160
Annex F. Vehicle-to-Infrastructure (V2I) Interaction F.1 Need for separate entry and exit notifications F.2 The realisation logic F.3 Dangerous goods information F.4 Realisation without RSEs
161 161 162 163 163
D5.2 The SMARTFREIGHT framework architecture
6
SMARTFREIGHT
The SMARTFREIGHT framework architecture
Executive summary Figure 5 illustrates the content of the SMARTFREIGHT framework architecture. It is has a topdown approach and is organised into three abstraction levels.
Overall conceptual aspects Logical aspects
Reference model
Functional viewpoint
Technical aspects
Roles Objects
Information viewpoint
Process viewpoint
Technical specifications
Figure 1: The content of the SMARTFREIGHT framework architecture
Transport Demand
Transport Supply Transport Service Management Transport Operation Management On-board Management
Transport Sector Support
Transportation Regulation
The top level addresses the overall conceptual aspects related to the transport sector. In the Reference Model the whole transport sector is divided into domains, each with specific responsibilities and focuses. Figure 2 illustrates the Reference Model and the scope of SMARTFREIGHT is marked with green (or grey if not printed in colours). The roles define the generic stakeholders related to the relevant domains of the Reference Mode, and the objects define generic entities (resources, equipment, etc.).
Not directly relevant to SMARTFREIGHT Relevant to SMARTFREIGHT
Transportation Area Management Transportation Network Infrastructure Management
Transportation Network Utilisation
Emergency Management
Figure 2: Reference Model and scope of SMARTFREIGHT The logical aspects address the SMARTFREIGHT solutions from a logical, technology independent point of view. The functional requirements and activities that take place in the relevant parts of the Reference Model are specified in the functional viewpoint. The process D5.2 The SMARTFREIGHT framework architecture
7
SMARTFREIGHT
viewpoint describes how these activities, being the responsibilities of different roles belonging to different part of the Reference Model, interact in processes. In the information viewpoint, the information that is exchanged is specified by means of detailed information models, and service interfaces with APIs (Application Program Interfaces) that support interactions between vehicles and traffic management/freight distribution management are specified. The technical aspects specify the realisation of the system components. Holding Area
Terminal Terminal areas Stop points
Stop points
Terminal Bus lane
Green area Loading bays
Checkpoint Controlled Area Transportation Network Resource
Area with DG restrictions
Tunnel
Figure 3 Transportation Network concepts The SMARTFREIGHT framework architecture defines a set of concepts that supports the realisation of the traffic management strategies in different cities: Controlled Area - i.e. area or section of the transportation network that is monitored or has access restrictions dependent on the individual vehicle properties and other conditions. Controlled areas may for example be tunnels where vehicles carrying dangerous goods are monitored or green areas of cities where access is given to only green vehicles. Transportation Network Resource - i.e. section of the network that can be assigned to individual vehicles, for example loading bays and parking lots that have to be pre-booked. Checkpoint – i.e. location where information is collected from or provided to vehicles. Access and Priority Assignment (APA) policy – i.e. a formal definition of the traffic management rules for a Controlled Area. There must be default APA policies for normal traffic conditions. In addition there may be dynamic APA policies in case of traffic situations that require specific measures. Access and Priority Offer (APO) – i.e. priority and access right assigned to an individual vehicle for a Controlled Area. APOs may be defined in two ways. Normally APOs depend on the vehicle properties and are dynamically derived from the APA policy as the vehicle drives through the transportation network. However, APOs may also be assigned to vehicles on request, for example in return of a fee.
D5.2 The SMARTFREIGHT framework architecture
8
SMARTFREIGHT
Glossary of abbreviations used ANPR
Automatic Number Plate Recognition
APA
Access and Priority Assignment
API
Application Programming Interface
APO
Access and Priority Offer
ATA
Actual Time of Arrival
ATC
Automated Traffic Control
ATD
Actual Time of Departure
CALM
Communication Access for Land Mobiles, ISO standard
CCTV
Closed-Circuit Television
CEN
The European Committee for Standardization
CVIS
Cooperative Vehicle-Infrastructure Systems, European project
DDS
Distributed Directory Service
DSRC
Dedicated Short-Range Communication
D2D
Door-to-Door
ETA
Estimated Time of Arrival
ETD
Estimated Time of departure
EU
European Union
FDMS
Freight Distribution Management System
FOAM
Framework for Open Application Management, CVIS framework
FP
Framework Programme
GNSS
Global Navigation Satellite System
GPS
Global Positioning System
GSM
Global System for Mobile Communications
HMC
Host Management Centre
HMCA
Host Management Centre Agent
ICT
Information and Communication Technology
I2V
Infrastructure-to-Vehicle
ID
Identity/Identifier
IP
Internet Protocol
ISO
International Standards Organization
ITS
Intelligent Transport Systems and services
LAN
Local Area Network
MAIL
CALM Media Adapted Interface Layer
M5
CALM M5. The ISO 21215 standard that incorporates WAVE (WAVE PHY/MAC is IEEE 802.11p standard)
NEMO
Network Mobility
OAGi
Open Applications Group Inc.
D5.2 The SMARTFREIGHT framework architecture
9
SMARTFREIGHT
OBE
On-Board Equipment
OGE
On-Goods Equipment
POMA
Position and Mapping (CVIS sub-project)
QoS
Quality of Service
RFID
Radio Frequency Identification
SOA
Service Oriented Architecture
TC
Technical Committee
TEP
Transport Execution Plan
TES
Transport Execution Status
TMC
Traffic Message Channel
TNS
Transportation Network Status
TOP
Transport Operation Plan
TPEG
Transport Protocol Experts Group
UML
Unified Modelling Language
URL
Uniform Resource Locator
UTMS
Urban Traffic Management System
VMS
Variable Message Signs
V2V
Vehicle-to-Vehicle
WS
Web-Service
XML
Extensible Markup Language
2G
Second Generation
3G
Third Generation
D5.2 The SMARTFREIGHT framework architecture
10
SMARTFREIGHT
1 Introduction The SMARTFREIGHT project, financed by the EU 7th Framework Programme for research and development, aims to make urban freight transport more efficient, environmentally friendly and safe by answering to challenges related to traffic management, freight distribution management, and a better coordination between the two. This report specifies the SMARTFREIGHT framework architecture. It provides a holistic and top down specification of the solutions defined by SMARTFREIGHT. The establishment has been an iterative process supported by the user requirements identified in SMARTFREIGHT deliverable D2.1 [1] and D2.2 [2] (see Annex A for more details) and input from the other SMARTFREIGHT activities. Results from related work are also used as input as described in section 1.3. 1.1 The SMARTFREIGHT idea Freight transport has a central role for the business and life of a city, having an impact on environment, traffic congestion and safety. Still, commercial traffic has never been given much attention in the transportation planning process. So far it has not been possible to take traffic management measures towards individual freight vehicles based on information about the current traffic situation; traffic management systems have not served those organising freight transports in the city; and it has been difficult to predict the access to limited resources like loading bays.
Figure 4: The SMARTFREIGHT idea SMARTFREIGHT aims to make urban freight transport more efficient, environmentally friendly and safe by developing and evaluating Information and Communication Technology (ICT) solutions for a better coordination between Urban Traffic Management Systems (UTMS) and Freight Distribution Management Systems (FDMS). Bi-directional wireless communication with On-Board Equipment (OBE) in vehicles opens for new possibilities and further cooperation between intelligent vehicles and traffic management. Based on information about the current traffic situation, the profile of vehicles and cargo, traffic management measures can be taken towards the individual freight vehicles. “Desired behaviour” like use of green vehicles will be rewarded. Green vehicles may for example be allowed to drive through the city centre, while others may have to take less preferable routes. The traffic management system will also serve those organising the freight distribution to support more efficient and reliable freight distribution. Reliable information about the traffic
D5.2 The SMARTFREIGHT framework architecture
11
SMARTFREIGHT
management policy and current or foreseen traffic situations can be provided as well as timeslots for access to resources like loading bays. 1.2 SMARTFREIGHT framework architecture introduction This section provides an introduction to the SMARTFREIGHT framework architecture description: What it aims to support; the motivation for the generic approach; and an overview of its content. 1.2.1 The aims of SMARTFREIGHT framework architecture The SMARTFREIGHT framework architecture provides a holistic and top down specification of the solutions defined by SMARTFREIGHT and aims to support The understanding of the SMARTFREIGHT solutions, i.e. the SMARTFREIGHT functionality, the information that is exchanged, between whom the information is exchanged and in which situations. The understanding of the context in which the SMARTFREIGHT solutions will operate. A holistic approach is taken to describe how the SMARTFREIGHT solutions depend upon and affect other solutions. The framework architecture does for example, at an overall level, illustrate how the SMARTFREIGHT solutions depend on a strategically planning of traffic management towards freight vehicles (e.g. establishment of access rules for different parts of the transportation network) even though such planning is not a part of SMARTFREIGHT. The deployment of SMARTFREIGHT solutions in different European cities, independent on their organisation and traffic pattern. The architecture supports o
The planning of the traffic management policy. Concepts that can be used in the planning are defined (e.g. Controlled Areas) as well as data structures for expression of traffic management policies.
o
The planning of how the solutions are to be organised. SMARTFREIGHT defines roles, i.e. responsibilities, to be assigned to real stakeholders.
The implementation of the SMARTFREIGHT solutions. Application Program Interfaces (APIs) for communication between stakeholders are defined, APIs for communication between on-board equipment (OBE) and road-side equipment (RSE) included. 1.2.2 A generic approach SMARTFREIGHT addresses urban freight transport. However, the generic mechanisms and concepts defined by SMARTFREIGHT may also (in the future) be of relevance towards nonfreight vehicles in non-urban areas. Vehicles of all types, for example public transport vehicles and service vehicles, may for example be comprised by individual traffic management measures. Thus, it is emphasised that the terminology and specifications are generic. Some examples are provided below. Whenever not required, we do not refer to urban transport or freight transport We use the term vehicle instead of freight vehicle. We use the terms traffic management or traffic control instead of urban traffic management and urban traffic control. Thus, we also avoid the terms like Urban Traffic Management System (UTMS) in the logical parts of the architecture description. We use the term transport operation management instead of urban freight distribution management. Thus, we also avoid the term like Freight Distribution Management System (FDMS) in the logical parts of the architecture description. We use generic roles representing generic responsibilities and focuses instead of references to specific stakeholders. In that way the architecture description is valid independent of:
D5.2 The SMARTFREIGHT framework architecture
12
SMARTFREIGHT
Local organisation and implementation, e.g. how the responsibility of the loading bays are organised. They may for example be managed by the public road administration, the city or a terminal operator. Geographic area addressed. The traffic management policy may for example concern the whole city, a limited area of the city, a tunnel or a terminal. We use generic objects instead of references to specific physical entities (see Chapter 3). The objects address the purpose of the physical entities, and not the actual occurrence or solution. Examples of generic objects: The Transportation Network Resource object. By means of this generic object, reservation or assignment of access to resources like loading bays, parking lots, waiting lots, etc., can be managed in a generic way. The On-Goods Equipment (OGE) object. It may be more or less advanced; from passive RFID tags to active tags with integrated sensors and support for different communication bearers. We have whenever feasible borrowed terms from the multimodal ITS framework ARKTRANS [3] [4] which uses the same terminology for all transport modes. ARKTRANS is also used in other transport projects, and by using ARKTRANS, the urban freight distribution solutions addressed by SMARTFREIGHT can more easily be in line with and integrated with the solutions from other freight related projects. This is important as urban distribution may be a part of co-modal transport. 1.2.3 The SMARTFREIGHT framework architecture content overview
Overall conceptual aspects Logical aspects Technical aspects
Reference model
Functional viewpoint
Roles Objects
Information viewpoint
Process viewpoint
Technical specifications
Figure 5: The SMARTFREIGHT framework architecture content The content of the SMARTFREIGHT framework architecture is, as illustrated in Figure 5, organised in layers addressing different abstraction levels. The overall concepts define the responsibilities and their scope: The Reference Model is the ARKTRANS Reference Model. It divides the transport sector into domains, each with specific responsibilities and focuses. The domains also define the structuring of the framework architecture description. The overall context of SMARTFREIGHT is defined by means of the Reference Model. The roles define different types of generic stakeholders (i.e. responsibilities) that are of relevance to SMARTFREIGHT. The objects define generic entities (resources, equipment, solutions and technologies) that are of relevant to SMARTFREIGHT.
D5.2 The SMARTFREIGHT framework architecture
13
SMARTFREIGHT
The logical aspects define the SMARTFREIGHT solutions from a logical point of view (i.e. independent of technologies): The functional viewpoint describes functional requirements related to the activities that take place in the different domains of the Reference Model by means of use cases. The process viewpoint describes how the activities in the domains of the Reference Model will interact to fulfil their responsibilities and objectives. The information viewpoint defines the content and structure of information elements, and the service interfaces with APIs that support exchange the information across the domains of the Reference Model The technical aspects specify the implementation of the relevant parts of the logical aspects by means of the CVIS platform. 1.3 Related work This section describes the main relations between the SMARTFREIGHT framework architecture and related work. Annex B provides information about more activities and further details, such as descriptions of what is “borrowed” from related activities, what has been developed further and also what input SMARTFREIGHT has provided to related activities. 1.3.1 ARKTRANS The SMARTFREIGHT framework architecture is a further development of the ARKTRANS framework for multimodal ITS. ARKTRANS was chosen as the starting point because the framework, in a better way than other transport related architectures, arranges for: An integration of the SMARTFREIGHT solutions in co-modal supply chains. ARKTRANS is used in projects dealing with such chains (e.g. D2D [5], Freightwise [6] and e-Freight [7]). By using ARKTRANS, the urban freight distribution addressed by SMARTFREIGHT can be an integrated part of the transport chain in line with the comodal requirements. Traffic management measures towards individual vehicles. Due to the multimodality, such traffic management is already considered in ARKTRANS as sea, air and rail transport addresses the individual transport means and not just the traffic flow (as traditionally done in road transport). A focus on open services and interoperability between stakeholders and systems, and not on the specification and design of the inner parts of the traffic management and freight distribution systems. 1.3.2 CVIS The technical aspects of the SMARTFREIGHT framework architecture (see Figure 5 and Chapter 10) builds upon results from the CVIS project [8] and OSGi [9]. The SMARTFREIGHT solutions can be considered as applications in the CVIS Application Layer. The basic and domain facilities provided by CVIS are used to achieve the required functionality. The CVIS architecture [10] does not put the CVIS applications into a broader context. By means of a top down approach, encompassing the total transport sector, the SMARTFREIGHT framework architecture description contributes to a holistic view upon the use of on-board and on-goods equipment. 1.3.3 Common Framework The SMARTFREIGHT framework architecture has been input to the European work on the “Common Framework for Information and Communication Systems in Transport and Logistics” (in short called Common Framework) and vice versa.
D5.2 The SMARTFREIGHT framework architecture
14
SMARTFREIGHT
SMARTFREIGHT is the main contributor to the Common Framework on issues covered by the Transport Operation Management, Transportation Area Management and On-board Management domains (see Figure 6). The two latter cover to a large extent the concept of cooperative systems. SMARTFREIGHT includes more details than Common Framework and has extended the specifications in the Common Framework. 1.3.4 GOOD ROUTE The GOOD ROUTE projects addresses transport of dangerous goods (DG) and related information flows. Time slots for DG passages through the infrastructure, DG route guidance, DG re-routing, enforcement related to DG, provision of status information to the transport chain, emergency handling, etc. are addressed. SMARTFREIGHT adds new aspects to traffic management related to DG by enabling traffic management towards individual vehicles that is depending on the profile of the vehicle, DG included. The traffic management policy is realised by means of an Access and Priority Assignment (APA) policy that is dynamically adapted to the traffic situation. SMARTFREIGHT has used the GOOD ROUTE solutions as an input on the requirements related to DG transport. The data types defined in the GOOD ROUTE XML Scheme is used as an input to the Information view. 1.4 The content of this report Several chapters define the content of the SMARTFREIGHT framework architecture, as illustrated in Figure 1: Chapter 2 specifies the Reference Model, which divides the transport sector into domains. The roles of the stakeholders and the objects involved are specified in Chapter 3. The functional views, which describe the functions required in the relevant domains of the Reference Model, are specified in Chapter 4, 5, 6 and 7. The process views, which describe process scenarios with information flows, are specified in Chapter 8. A complete list of required information flows is provided in 8.6. The information view in Chapter 9 includes conceptual information models that define the service interfaces with APIs that facilitates the information flows identified in Chapter 9. The APIs are listed in 9.2. The technical aspects regarding the implementation on top of the CVIS platform are specified in Chapter 10, including the realisation of the system components in 10.5. Chapter 11 describes how the SMARTFREIGHT framework architecture supports the deployment of the SMARTFREIGHT solutions. Chapter 12 provides an overview of terms used in the report. Several annexes provide additional information: Annex A provides an overview of the user requirements identified in the SMARTFREIGHT deliverables D2.1 and D2.2 and how the requirements are addressed by the SMARTFREIGHT framework architecture. Annex B provides an overview of what is “borrowed” from related activities, what has been developed further and what input SMARTFREIGHT has provided to other activities. Annex C explains the strategy used for location referencing. Annex D provides information on how security concerns can be addressed. Annex E describes access control strategies and the choices taken in SMARTFREIGHT. Annex F describes the strategy used for the establishment of awareness about the presence of vehicles in a section of the road network.
D5.2 The SMARTFREIGHT framework architecture
15
SMARTFREIGHT
2 The Reference Model The ARKTRANS Reference Model is used in several transport related projects 1 and has proven to be useful as an overall conceptual model of the transport sector in all transport modes (sea, road, air and rail). The model is also used as the top level for the SMARTFREIGHT architecture. 0F0F
Transport Demand
Transport Supply Transport Service Management Transport Operation Management On-board Management
Transport Sector Support
Transportation Regulation
The ARKTRANS Reference Model divides the transport domain into domains according to responsibilities and focus areas, and defines the overall relations between these domains, as illustrated in Figure 6. Knowing the related responsibilities and focus areas, it is easy to map activities, projects, systems and stakeholders into the model. Thus, the Reference Model provides an upper level conceptual view that is used to define the scope and context of activities or interests. Those parts of relevance to SMARTFREIGHT are indicated by green colours in the figure (or grey tones if not printed in colours). The white parts are not of directly relevance to SMARTFREIGHT, but may, as described below, influence on or be affected by the SMARTFREIGHT solutions.
Not directly relevant to SMARTFREIGHT Relevant to SMARTFREIGHT
Transportation Area Management Transportation Network Infrastructure Management
Transportation Network Utilisation
Emergency Management
Figure 6: ARKTRANS Reference Model and scope of SMARTFREIGHT The domains of the Reference Model exchange information and provide services to each other. Two domains may for example represent the two parties in a business-to-business relation. The consignor, in the Transport Demand domain, will for example order transport services from the transport service provider belonging to the Transport Supply domain. Functions provided by one domain may also be the basis for functions in other domains. Tracking information collected by the vehicles (the On-board Management domain) may for example support the management and tracking of fleet resources done by the fleet operator in the Transport Operation Management domain. Based on this tracking information, the fleet operator in the Transport Operation Management domain may also provide tracking or status information to the cargo owner in the Transport Demand domain. This chapter provides an overall description of all domains in the Reference Model. The domains and the relations that are of relevance to SMARTFREIGHT are described in more detail in the logical aspects of the architecture: the functional view (Chapter 4, 5, 6 and 7), the process view (Chapter 8), and the information view (Chapter 9). There is also a set of 1
E.g. D2D (5FP DG TREN), MarNIS (6FP DG TREN), Freightwise (6FP DG TREN), e-Freight (7FP DG TREN), L4Life (7FP DG TREN) and a number of national projects related to travel information services, traffic management, terminal management, etc.
D5.2 The SMARTFREIGHT framework architecture
16
SMARTFREIGHT
roles and objects associated to each domain, and those of relevance to SMARTFREIGHT are specified in Chapter 3. 2.1 Transport Demand The Transport Demand domain is the source of all transport. The focus is on those who need transport (consignor, consignee, cargo owner, etc.) and those who organise transport on behalf of others (forwarders, logistics providers, etc.). Transport is booked and followed up. The Transport Demand domain also addresses the items to be transported, named Transport Items. These are goods items or load units. SMARTFREIGHT does not address the Transport Demand domain. However, indirectly the SMARTFREIGHT solutions can be of relevance. The Transport Items may be monitored and tracked by means of On-Goods Equipment (OGE). 2.2 Transport Supply The Transport Supply domain addresses the provision of transport services, customer contact, transport operation management and transport operation execution included. 2.2.1 Transport Service Management The Transport Service Management domain addresses the provision of transport services to the Transport Demand domain. Customer relations are managed; long term planning of routes and timetables is carried out; and strategies are planned based on foreseen transport demand. SMARTFREIGHT does not address the Transport Service Management directly. However, indirectly SMARTFREIGHT will support the long term planning of freight distribution services, among others by means of mechanisms that improve the awareness about the foreseen traffic situation and associated traffic management policies. 2.2.2 Transport Operation Management The Transport Operation Management domain addresses transport operation planning, monitoring and control, and the execution of the transport tasks (loading, unloading, status reporting, etc.). By means of interactions with the On-board Management domain the vehicles can be tracked, and the driving operation can be supported. The Transport Operation Management domain is very relevant to SMARTFREIGHT. The transport operation planning can be improved by means of more accurate information from the Transportation Area Management domain (mainly the Transportation Network Utilisation part) about traffic management strategies and the current or expected traffic situation. The management of on-going transport operations are supported by means of interactions with the On-Board Equipment (OBE). 2.2.3 On-board Management The On-board Management domain addresses the operation of the vehicles. The operations should be carried out according to instructions received from the Transport Operation Management domain (destination, time schedule, etc.), but the driving operation is also heavily affected by the traffic situation. Thus, traffic management measures taken and traffic flow information provided by the Transportation Network Utilisation part of the Transportation Area Management domain influence on the execution. The On-board Management domain is strongly relevant to SMARTFREIGHT. The On-Board Equipment (OBE) will support the exchange of information with the Transportation Area Management domain. This includes the individual traffic management measures, and vehicles that fulfil certain requirements may gain privileges that help them to become more efficient and reliable.
D5.2 The SMARTFREIGHT framework architecture
17
SMARTFREIGHT
2.3 Transportation Area Management The Transportation Area Management domain addresses the physical Transportation Network infrastructure (roads, equipment for traffic control, terminal resources, etc.); the utilisation of this infrastructure by means of traffic flow management and management of individual vehicles in the infrastructure; and the handling of emergencies. Safety, efficiency and security for the individual users of the Transportation Network are emphasized as well as the protection of the environment and the public interests related to traffic and transport. The Transportation Area Management domain is further decomposed into the focus areas described below. 2.3.1 Transportation Network Infrastructure Management The Transportation Network Infrastructure Management domain addresses the physical Transportation Network infrastructure, including associated equipment used for traffic control and collection of traffic information. The decisions on the equipment usage, e.g. the text to be displayed by variable signs, are however taken by the Transportation Network Utilisation domain. The Transportation Network Infrastructure Management domain is of some relevance to SMARTFREIGHT. The Road-Side Equipment (RSE) is managed by this domain, and this is also the source of information about the physical infrastructure. 2.3.2 Transportation Network Utilisation The Transportation Network Utilisation domain aims at the most optimal utilisation of the Transportation Network infrastructure, among others to establish traffic management strategies for freight transport and the actual traffic management. Safety, security, efficiency and protection of the environment are emphasized. The Transportation Network Utilisation domain strongly relevant to SMARTFREIGHT: The Access and Priority Assignment (APA) policy is defined, including the Access and Priority Offers (APO) (e.g. access to green zones) to be given to vehicles depending on their vehicle type, loading factor, avoidance of rush hours, etc. The actual traffic management is carried out. The Access and Priority Assignment (APA) policy defines the measures to be taken towards individual freight vehicles. The assigned APOs decide how the individual freight vehicles can use of the Transportation Network. Information about the current and the expected traffic situation is provided to both the drivers (the On-board Management domain) and to those managing the transport operation (the Transport Operation Management domain). Transportation Network Resources such as loading bays may be assigned to individual vehicles. 2.3.3 Emergency Management The Emergency Management domain addresses preparedness and emergency response related to traffic and transport. These aspects are not directly addressed by SMARTFREIGHT. However, due to the SMARTFREIGHT solutions, information about the presence of dangerous cargo may for example be available and arrange for improved emergency preparedness and improved accidents and incidents handling. 2.4 Transportation Regulation The Transportation Regulation domain addresses the enforcement of laws and regulations related to traffic and transport. This domain is not addressed by SMARTFREIGHT. The SMARTFREIGHT solutions may however open for new opportunities with respect to detection of regulation violations and may through this also influence on regulation enforcement abilities.
D5.2 The SMARTFREIGHT framework architecture
18
SMARTFREIGHT
2.5 Transport Sector Support The Transport Sector Support domain provides services to the other domains. This may for example be information services (e.g. meteorological information and tourist information) and other supportive services like, for example fee collection services. In SMARTFREIGHT the Transport Sector Support domain provides generic services that can be used to monitor and track items, e.g. to monitor the temperature of goods items or load units or to track vehicles, goods items or load units. (The services are generic in the sense that they may also be used within other sectors than the transport sector.) The services will be implemented in the On-Goods Equipment (OGE).
D5.2 The SMARTFREIGHT framework architecture
19
SMARTFREIGHT
3 Roles and objects A stakeholder may be a person, a team, an organization or an institution. In the architecture description we define the stakeholders of relevance to SMARTFREIGHT by means of generic roles. One role represents a unique and consistent set of related responsibilities. By using roles, the architecture description can be generic and independent of organisational issues. The traffic management may for example be organised in different ways in different European cities. The public road administration or the city itself may have the responsibility, or there may be a combination where the public road administration and the city are responsible for different roads. The architecture description is abstracted from such organisational aspects by using the generic Traffic Manager role to represent this traffic management responsibility. The same role can also apply to the traffic management that may be needed in large terminals. A terminal operator may for example play the Traffic Manager role and manage entries, exits and access to terminal areas. Similarly, the Transportation Network Resource Manager role is responsible for the management of resources like loading and unloading areas. The role may for example be played by the public road administration, the city, a freight terminal, or a freight distribution centre that is managing the freight distribution resources for the whole city. Object are general terms representing physical entities (physical elements/units or technical solutions) of relevance to SMARTFREIGHT. An object represents abilities. The use of generic objects makes it easier to make references to these physical objects and abilities in a generic way, independent of technology and implementation. Roles and objects are used as generic names for stakeholders and entities. A role or an object relate to just one of the domains of the Reference Model. By means of the roles and objects we can refer to stakeholders, physical entities and technical solutions in a generic way that is independent of local organisations and implementations. Figure 7 shows how the overall roles and the objects relate to the different domains in the Reference Model and summarise the information exchange between the different domains. The Transport Supply and Transportation Network Area domains are further decomposed in the sections below. It is important to notice that an actor or stakeholder in the real world may play one or more roles. The public road administration or a city may for example have roles like the above mentioned Traffic Manager (responsible for the traffic management), Transport Network Resource Manager (responsible for assignment of resources like loading and unloading areas) and Transportation Infrastructure Manager (responsible for the physical infrastructure). In the same way, a physical entity or a technical solution may in the real world represent one or more objects. In SMARTFREIGHT, the On-board Equipment (OBE) will for example implement both the equipment that supports the Transport Operation Worker (the Worker‟s Equipment) and the equipment that supports the On-Board Manager (the Driver‟s Equipment). As illustrated in Figure 7 goods items are represented by different objects depending on the context. The Transport User will request transport of a Transport Item. A tag, represented by the On-Transport Item Equipment object, may be attached to the Transport Item, and the Transport User may communicate directly with the tag during the transport. This is not addressed by SMARTFREIGHT, but is a part of the holistic view upon freight transport. When the Transport Service Provider handles the goods, it may be sent at it is, or it may be put into load units (e.g. pallets or containers). In any case, the item that is transported (i.e. the goods itself or a load unit) is in SMARTFREIGHT represented by the Load Item object. The Load Item may also have a tag attached to it, the On-Load Item Equipment, which the Transport Service Provider may communicate with during the transport.
D5.2 The SMARTFREIGHT framework architecture
20
SMARTFREIGHT
act SMARTFREIGHT Top lev el use case
Depends on Realises Transport Item
On-Transport Item Equipment
On-Goods Equipment (OGE)
On Item Equipment
Depends on Transport User, e.g. a city centre retailer or other business
Transport Demand
Transport Sector Support On-Load Item Equipment
Load Item Item info, Item tracking, Item status
TEP, TES
Realises Transport Serv ice Prov ider, e.g. FDMS, Freight distributor
Vehicle
Transportation Area Manager
Worker's Equipment
Driv er's Equipment APA policy, TNS, APO, Route, Resource allocation, ...
On-Board Equipment (OBE)
Tracking, Entry, Exit, Vehicle info, ... Transportation Netw ork, e.g. road segment Realises
Transportation Area Management
Notification of illegal behaviour
Transportation Regulator
Realises
Transport Supply
Transportation Regulation
Transportation Netw ork Equipment
Transportation Netw ork Resource, e.g. loading bay
Road-Side Equipment (RSE)
TEP: Transport Execution Plan TES: Transport Execution Status TNS: Transportation Network Status APA: Access and Priority Assignment APO: Access and Priority Offer
Figure 7 The SMARTFREIGHT concept – domains, roles and objects In real life, the On-Transport Item Equipment and the On-Load Item Equipment objects may be the same or two different tags. In both cases the same functions may be required, e.g. monitoring of the condition of the Item and communication. Such tags are not just of interest to the transport sector. Shops and warehouses may also need the same functionality. Thus, the On-Transport Item Equipment and the On-Load Item Equipment are both specialisations of the generic functionality represented by a generic On-Item Equipment. A hierarchical structure of On-Item Equipments should be supported as there in the future may be several layers of load units within load units and goods within load units that may have to communicate with each other and their surroundings. In SMARTFREIGHT the On-Item Equipment is realised by what we call the On-Goods Equipment (OGE). The OGE supports goods to vehicle communication. The roles and objects used in SMARTFREIGHT are further described in the sections below.
D5.2 The SMARTFREIGHT framework architecture
21
SMARTFREIGHT
3.1
Roles and objects related to Transport Demand
Table 1 Roles related to Transport Demand Roles
Description
Transport User
The originator of a transport request. Responsible for Defining the transport demands, the description of the cargo included. Transport planning and re-planning (finding the best transport alternative, i.e. the best transport service) Transport service booking and follow up
Examples The consignee, the consignor or the cargo owner, typically a city centre retailer or other business A logistics provider or a forwarder when they are booking transport on behalf of their customer.
Table 2 Objects related to Transport Demand Object
Description
Transport Item
A good item or a collection of goods items that are to be transported. May be a load unit containing goods. Causes (“enables”) the transport demand.
Examples Environmental Affected Load (may be affected by its surroundings) Special Cargo (requires special treatment) like food, animals, human remains, valuables and dangerous cargo. Bulk, general cargo or packets Load unit - Pallet, Container
OnEquipment attached to a Transport Item. Specialisation Transport of the generic On-Item Equipment in 3.5 (inherits all the Item detailed roles). Equipment Enables support to the Transport User in identification, monitoring, tracking, etc. May also facilitate “intelligent goods” with agents representing the Transport User, i.e. ability to take decisions based on situational awareness.
On-Goods Equipment Tags on goods items
3.2 Roles and objects related to Transport Supply Figure 8 illustrates the decomposition of the Transport Supply domain and the associated Transport Service Provider role. The Transport Operation Manager role in the figure is even further decomposed in Table 3. As described in the introduction of the chapter, the On-Load Item Equipment is a specialisation of the On-item Equipment, and it is realised by means of the On-goods Equipment. As illustrated by Figure 8, both the Worker‟s Equipment, which support execution of transport tasks, and the Driver‟s Equipment, which support safe and efficient driving, are in SMARTFREIGHT realised by means of the On-Board Equipment (OBE). In other settings, the Worker‟s Equipment may for example be a nomadic device (e.g. PDA) dedicated to the reporting of status on transport tasks. However, in SMARTFREIGHT the OBE is used, and it also supports the vehicle to infrastructure and vehicle to goods communication.
D5.2 The SMARTFREIGHT framework architecture
22
SMARTFREIGHT
uc Transport Supply- ov erall
Transport Supply Transport Demand
TEP, TES
Transport Serv ice Management
Transport Serv ice Manager, e.g. freight distributor
«flow» Transport Operation Manager, e.g. FDMS, fleet operator, back officeItem info, Item tracking, Item status
Transport Operation Management
TOP, APO, Route, TNS, ...
TOS, Tracking, ...
APA policy, TNS, APO, Route, Resource Tracking, allocation, ... Entry, Exit, Vehicle info, ...
On-Load Item Equipment
On Item Equipment
Realises
Realises Worker's Equipment
On-Board Realises Equipment (OBE)
On-board Management
Transportation Netw ork Utilisation
Transport Sector Support
Driv er's Equipment
APA policy, APO, TNS, Notification, Route, ...
On-board Manager
Vehicle
On-Goods Equipment (OGE)
TEP: Transport Execution Plan TES: Transport Execution Status TOP: Transport Operation Plan TOS: Transport Operation Status TNS: Transportation Network Status APA: Access and Priority Assignment APO: Access and Priority Offer
Figure 8 Roles and objects related to the decomposed Transport Supply domain Table 3 Roles related to Transport Supply Roles
Description
Transport Service Provider
The provider of transport services. Responsible for the customer contact, the planning of transport services, and the planning, control and execution of transport operations.
Examples Forwarder or logistic provider See below
Decomposed into Transport Service Manager - see below Transport Operator – see below On-board Manager – see below
D5.2 The SMARTFREIGHT framework architecture
23
SMARTFREIGHT
Roles
Description
Transport Service Manager
Responsible for planning and handling of customer relations Planning of the services to be provided Formal agreements with customers, i.e. Transport Users The provision of transport services to a Transport User, e.g. the transport of cargo from one point to another, loading, unloading, reporting to authorities, etc.
Examples A forwarder or a logistics provider receiving and processing a transport service request. A transport operator/fleet operator receiving and processing a transport service request.
The provision of status information to the Transport User during the transport. Transport Operation Manager
Responsible for the planning and effectuation of the required transport related operation required for the provision of transport services. Decomposed into:
A fleet operator A freight distribution centre. See below
Transport Operator (see below) Transport Operation Worker (see below) Transport Operator
Responsible for the management and coordination of transport related operations. The transport related operations may be provided by vehicles or at pickup/delivery locations and terminals. (Transport operations may also be delivered by external transport service providers. These services are however booked by the Transport User role, but the Transport Operator must be aware of their status and consider the status in the total coordination). The Transport Operator is responsible for:
The transport back-office (of a transport operator /fleet operator) managing the use of resources (vehicles, drivers, etc.) and managing the execution of transport operations.
Transport operation planning (resource utilisation, time schedule, use of external services, etc.) Initiation, monitoring and follow up of the transport operations carried out by the Transport Operation Worker. Transport operations that can be carried out according to rules and regulations. Gathering information for administrative purposes. Transport Operation Worker
Responsible for the actual execution of the transport related operations according to instructions from the Transport Operator and according to laws and regulations, for example Reporting operations Cargo handling operations like loading, unloading, transhipment.
D5.2 The SMARTFREIGHT framework architecture
A driver or a terminal worker handling the cargo before departure or at destination. The driver or a terminal worker reporting about status of a transport task.
24
SMARTFREIGHT
Roles
Description
Examples
On-board Manager
Responsible for the operation of the vehicle. This includes
The driver of the vehicle.
Compliance with laws and regulations (traffic regulation measures included) Adaptation to the traffic situation in a way that ensures safety and contributes to efficiency. Taking the vehicle to the locations decided by the Transport Operation Management domain.
Table 4 Objects related to Transport Operation Management Objects
Description
Examples
Worker‟s Equipment used by the Transport Operation Worker. Equipment Enables support to the Transport Operation Worker in Execution of the transport operation and tasks Information exchange about the operation and tasks
PDA for communication with back office On-board equipment (OBE) for communication with back office
Status reporting. Load Item
The items being transported. May be goods or load units. One or more Transport Items may be put together into one load unit and become a Load Item.
General cargo
Causes (“enables”) transport operations.
Pallets
On-Load Equipment that can be attached to a Load Item or a Item transport means. Specialisation of the generic On-Item Equipment Equipment in 3.5 (inherits all the detailed roles). Enables Support to the Transport Service Provider: Identification, monitoring, tracking, etc. of Load Items
Containers
On-Goods Equipment (OGE) Equipment (tags) attached to goods or load units) Equipment (tags) attached to cargo compartment
“Intelligent goods” with agents representing the Transport Service Provider, i.e. ability to take decisions based on situational awareness. Load Item Equipment that communicates with On-Load Item Scanning Equipment. Equipment Enables registration and forwarding of information received from the On-Load Item Equipment
Scanning equipment at terminals or in vehicles
Terminal Terminal equipment that has to be booked for specific Equipment transport operations.
Loading and unloading equipment; cargo handling equipment; terminal vehicle; terminal load unit
Enables terminal operations.
Table 5 Objects related to On-board Management Superior objects Vehicle
Detailed objects Description Enables the transport of people or goods
D5.2 The SMARTFREIGHT framework architecture
Examples Freight distribution vehicle
25
SMARTFREIGHT
Superior objects
Detailed objects Description
Driver‟s Equipment
Equipment for Driver Support
Equipment used by the On-board Manager. Enables safe and efficient driving through the provision of support and control and interaction with the traffic management. Relevant functions may be Access to information services that are useful to the On-board Manager. Automated interactions with traffic management system
Examples On-board equipment (OBE) for communication with traffic management and information services May be integrated with for example Navigation Support Equipment. In that way information and routes guidance, etc. may be provided to the driver via the user interface of the navigation system
Alerts to the On-board Manager in case of emergencies Provision of guidelines or directions related to route, access, etc. Equipment for Vehicle Monitoring
Equipment enabling monitoring of sections of the vehicle. Provides information about the condition.
Tag with sensors monitoring cargo compartment, etc.
Tracking Equipment
Equipment enabling provision of position information.
GPS
Navigation Support Equipment
Equipment that helps (“enables”) the On-board Manager to find the route.
Misc. navigation systems (Garmin, Tom-Tom, etc.)
D5.2 The SMARTFREIGHT framework architecture
26
SMARTFREIGHT
3.3
Roles and objects related to Transportation Area Management
uc Transportation Area Management - ov erall
Transportation Area Management
Transportation Netw ork, e.g. road segment
Transportation Netw ork Resource, e.g. loading bay
Transportation Netw ork Infrastructure Management
Transportation Netw ork Infrastructure Manager, e.g. city or road administration
Transportation network info
Road-Side Equipment (RSE)
Realises
Transportation Netw ork Equipment
APA policy, TNS, APO, Route, Resource allocation, ... Transportation Netw ork Utilisation
Transportation Netw ork Utilisation Manager
Tracking, Entry, Exit, Vehicle info, ...
Transport Supply
Emergency notification
Emergency Manager
Emergency Management
TNS: Transportation Network Status APA: Access and Priority Assignment APO: Access and Priority Offer
Figure 9 Roles and objects related to the decomposed Transportation Area Management Figure 9 illustrates the decomposition of the Transportation Area Management domain and the associated Transportation Area Manager role. The Transportation Utilisation Manager role in the figure is even further decomposed in Table 6. As illustrated by Figure 9, this domain is related to the physical Transportation Network, as specified in Table 7, among others includes Transportation Network Resources such as loading bays and Transportations Network Equipment. The latter may support traffic monitoring and control and is in SMARTFREIGHT realised by means of Road-Side Equipment (RSE). The RSE supports the infrastructure side of the vehicle-infrastructure communication. Table 6 Roles related Transportation Area Management Roles
Description
Transportation Responsible for the transportation network and for the Area Manager arrangement of safe and efficient and environmental friendly traffic in the network. Decomposed into
Examples Public road administration Port authority City
Transportation Network Infrastructure Manager see below Transportation Network Utilisation Manager - see below
D5.2 The SMARTFREIGHT framework architecture
27
SMARTFREIGHT
Roles
Description
Transportation Responsible for the management of the physical Infrastructure Transportation Network infrastructure. This includes: Manager Operative planning, establishment, operation, maintenance, etc. of the physical Transportation Network infrastructure (related equipment including). Management of information about the physical Transportation Network infrastructure. Safety, efficiency and protection of the environment are emphasized. The role may be possessed by managers of both road networks (public and private) and terminal infrastructures.
Examples The public road administration managing the physical infrastructure consisting of the main roads and related equipment. The city managing the physical road network in the city centre. May also include the physical loading and unloading areas and related equipment. The terminal owner managing the physical infrastructure of the terminal.
Transportation Responsible for the planning and management of Network traffic in a way that ensures efficiency, safety and Utilisation protection of environment. Manager Decomposed into Traffic and Transportation Planner– see below Transportation Network Resource Manager – see below Traffic Manager – see below Traffic and Responsible for strategically and tactical planning of Transportation traffic and transportation issues in an area. This Planner planning includes The assessment of possible solutions and resulting impacts, e.g. by means of traffic modelling and impact evaluations. The coordination between traffic management issues and the needs of the Transport Service Providers and the Transport Users Decision of the overall APA policy, for example the use of green areas and the APOs in different situations (e.g. in which time periods; for which loading percentage, etc.)
The public road administration or the city planning how to manage the freight transport in the city – use of green areas, APA policy, guidelines for when the policy is to be changed, etc. The impacts (for example environmental impacts) must be considered.
Transportation Responsible for Network The assignment of Transportation Network Resource Resources to vehicles, e.g. loading bay, parking Manager lots and waiting lots.
A city, a road administration or a terminal operator managing the assignment of resources like loading and unloading areas.
Traffic Manager Responsible for the best possible traffic flow during normal and abnormal network and traffic situations. This includes
The city or public road administration managing the traffic on the roads – to achieve the optimal utilisation with respect to efficiency, safety, environment, etc.
Efficient traffic management and incident handling, e.g. by controlling the infrastructure and by guidance or orders given to the On-board
D5.2 The SMARTFREIGHT framework architecture
28
SMARTFREIGHT
Roles
Description
Examples
Managers. Registration and management of information about the traffic and Transport Network conditions. Provision of information about the traffic and Transport Network conditions to those needing it. Monitoring and controlling the access to specific areas or Transportation Network Resources, and detection of access violations.
Emergency Manager
Responsible for emergency preparedness and the management of emergency situations related to transport and traffic.
The Terminal owner managing the access to and movement of vehicles within the terminal. A city, a road administration or a terminal operator monitoring the access to areas (e.g. green areas) or resources like loading and unloading areas. Police, fire brigade, public road administration
Table 7 Objects related to Transportation Network Infrastructure Management Superior objects
Detailed objects
Description
Transportation Physical infrastructure. Network Enables the movement of vehicle, goods and people. See also illustration and description in 12.14.
Examples Road network and related equipment, Transfer Nodes (terminals), loading and unloading areas, etc.
Transportation Limited part of the Network Transportation Network. Section Enables identification of a part of the Transportation Network.
An area in a city, a terminal or an area at a terminal
Controlled Area
A Transportation Network Section that is regulated by an Access and Priority Assignment (APA) policy.
Green areas
Enables localization of
Areas where vehicles carrying dangerous goods have no access
A tunnel or a bridge A road, a section of a road or a lane.
Areas where certain vehicles have no access during rush hours
Access restrictions for vehicles with specific characteristics
A tunnel or a bridge
Priorities for vehicles with specific characteristics
A terminal with restrictions (e.g. due to security)
A bus lane
Supervision – to detect unauthorised entry Supervision – to keep track of vehicles with specific characteristics
D5.2 The SMARTFREIGHT framework architecture
29
SMARTFREIGHT
Superior objects
Detailed objects
Description
Checkpoint
A location in the Transportation Network.
A portal registering the vehicles passing by
Enables information passage to/from vehicles that facilitates
The information collected may for example be used to detect (unauthorised) entry to a Controlled Area or to keep track of specific vehicles in a Controlled Area.
Registration of presence of a vehicle
Examples
Registration of information about vehicles Registration of information about the traffic in general. Transportation See below Network Equipment Transportation See below Network Resource Transportation Part of the Transportation Network, with well Network defined identification and location that can only Resource be used by one vehicle at a time.
See below
Enables allocation management according to some strategy, for example first come first served or booking of timeslots. Loading bay
Area enabling vehicles to stop for loading or unloading
Areas for loading an unloading close to businesses in the city centre. Bus stops with dual function
Stop Point
Location at a Transfer Node enabling vehicle stops.
Gates, tracks or quays
Terminal Lot
An area of the Transfer Node enabling terminal operations.
Service area, transit area, manoeuvring area, ramp, transhipment area, etc.
Holding Lot
Area enabling vehicles to wait. May be used due to specific traffic situations or while waiting for other Transportation Network Resources.
Area where vehicles may stop and wait (e.g. for access to transport network resources)
Parking Lot
Area enabling parking of vehicles.
Parking lots in a city.
D5.2 The SMARTFREIGHT framework architecture
30
SMARTFREIGHT
Superior objects
Detailed objects
Description
Transportation An integrated part of the Transportation Network Network (located along, over, under, or at Equipment specific points in the Transportation Network).
Examples Road Side Equipment (RSE), e.g. the SMARTFREIGHT RSE implemented on a CVIS computer
Enables support to road users, monitor and/or control of behaviour or situations. The equipment may exchange information with systems or other equipment, and there may be several strategies for signalling, communication and information dissemination. The same physical equipment may serve as several object types
See below for more specific examples
Access Control Enables the monitoring and Equipment checking of the access to Controlled Areas and Transportation Network Resources
Detection equipment (cameras, tag readers, automatic number plate recognition, etc.)
Emergency Equipment
Equipment used in emergency situations.
Fire alarm within a tunnel, phones for emergency calls, etc.
Enables improves emergency response.
RES providing notifications to OBE
Equipment enabling dissemination of information to those using the Transportation Network, e.g. On-board Managers.
Fixed signs, variable message signs (VMS), information boards, communication equipment, etc.
Information Equipment
Traffic Control Equipment enabling control of Equipment traffic or vehicles (e.g. to detect illegal behaviour).
RSE detecting vehicles
RSE providing information to OBE Equipment for ATC (Automated Traffic Control), closed-circuit television (CCTV), etc. RSE providing APAs, notifications, etc. to OBE
Road-side Equipment for Communicatio n
Equipment localised along the road enabling information exchange with vehicles using the infrastructure
RSE communication with OBE and internet in general
Traffic Monitoring Equipment
Equipment enabling collection of data about traffic flow (amount of traffic, speed) and the behaviour of individual vehicles.
Sensors (traffic counters, detectors) Closed-circuit television (CCTV) Equipment for automatic number plate recognition (ANPR), etc. Traffic signal control systems may also provide this functionality (e.g. SCOOP). RSE detecting vehicles carrying DG
Traffic Regulation Equipment
Equipment enabling traffic regulation (to affect the traffic flow and behaviour in the traffic)
D5.2 The SMARTFREIGHT framework architecture
Traffic signals, fixed signals, variable message signs, etc. RSE enabling access control
31
SMARTFREIGHT
3.4
Roles related to Transportation Regulation
Table 8 Role related to Transportation Regulation Roles
Description
Examples
Transportation Responsible for being an executive authority and for Regulator regulation enforcement related to transport and traffic.
3.5
Customs Police
Objects related to Transport Sector Support
Table 9 Objects related to Transport Sector Support Superior objects
Detailed objects Description
On-Item Equipment
Identification Equipment
Examples
Equipment that can be attached to an Item.
Tags attached to vehicles, goods or load units
Enables item identification, monitoring, tracking, etc. May also facilitate “intelligent items”, i.e. ability to take decisions based on situational awareness.
Equipment in the cargo compartment
Equipment enabling identification of Item, equipment or transport means
Misc. tags, e.g.
Realised by means of the On-Goods Equipment
RFID tags Intelligent tags
Monitoring Equipment
Equipment enabling monitoring of Items or the surroundings of Items by means of misc. technologies. Provides information about the state.
Tag with sensors (video, temperature, humidity, etc.) monitoring goods items or load units Tag with sensors monitoring cargo compartment, terminal Ares, etc.
Item Scanning Equipment
Tracking Equipment
Equipment enabling tracking. Provides tracking information (e.g. tracking of Item).
GPS
Security Equipment
Equipment that supports (enables) prevention of thefts or other criminal acts as well as equipment that may support the police or the owner in case of thefts.
Tracking equipment
Positioning Equipment
Equipment enabling provision of position information.
GPS
Equipment that communicates with the On-Item Equipment.
Scanning equipment at terminals or in vehicles
Enables registration of information about an Item through communication with an On-Item Equipment (id, content, etc.)
D5.2 The SMARTFREIGHT framework architecture
32
SMARTFREIGHT
4 Functional view - Transport Demand The Transport Demand domain supports the Transport User, and addresses preparation, planning and management of a transport chain of variable complexity. A Transport User can be a consignor, consignee, cargo owner (typically a city centre retailer or other business), and forwarding agents/logistics providers that organise the transport on behalf of others. The Transport Demand domain also addresses the Transport Item (cargo or load unit). It may be monitored and tracked by means of an On-Transport Item Equipment, which may include the generic monitoring and tracking functions described in the Transport Sector Support domain (see 7.1) on its way through the transport chain, as illustrated by Figure 7 and Figure 10. act Transport Demand
Depends on Prepare and Plan Transport Transport Item
On-Transport Item Equipment «include»
Transport Demand
«include»
Manage Transport
Transport User, e.g. a city centre retailer or other business
Figure 10: Traffic Demand decomposition In SMARTFREIGHT the focus is not on the Transport User‟s monitoring and tracking of Transport Items. The monitoring and tracking is addressed from the Transport Service Provider‟s point of view. The same technology may however be used in both cases. Indirectly, the Transport User will also benefit from SMARTFREIGHT as the solutions will enable Reliability of the delivery. It is more likely that the expected goods can be delivered within the expected time window, and if the delivery vehicle is delayed, the freight distributor can inform the goods receivers and provides and provide a new expected time of arrival (ETA). The monitoring and information status exchange can also be improved. Parking lots and loading bay availability. Loading/unloading facilities can be pre-booked (by the Transport Operator) and available for the expected delivery timeslot. Acting responsibly. To maintain good customer relations, retailers can better ensure that their deliveries do not create a hazard to the general public, which may happen, for example, with illegal parking. Retailers need to minimise the impact of their deliveries on neighbouring businesses by ensuring that delivery vehicles arrive within designated times (e.g. where loading bay are pre-booked), and that delivery vehicles obey the vehicle access regulations that are imposed by the public authority. More cost effective transport due to more predictability and better planning of transport services that may also lead to more cost effective urban freight transport. The description below mainly focuses on the monitoring of the Transport Item and the reception of status information from the Transport supply domain.
D5.2 The SMARTFREIGHT framework architecture
33
SMARTFREIGHT
4.1 Plan and Prepare Transport The Transport User has a transport need. The planning, preparation and ordering of transport services are supported. The transport demand and preferences of the Transport User are defined, including handling instructions of the Transport Item. Thresholds with respect to temperature, humidity, shock, etc. may also be defined. SMARTFREIGHT has no direct relation to this issue. However, the On-Goods Equipment should be configured to monitor the state of the Transport Item according to requirements defined by the Transport User. 4.2 Manage Transport The transport execution is monitored and followed up by the Transport User based on status information received from the Transport Service Providers. The Transport User may for example be notified in case of Deviations related to the execution of the transport operation (e.g. delays) Deviations with respect to Transport Items (e.g. wrong temperature, damage) Successful delivery SMARTFREIGHT does not address the Transport User‟s monitoring of the Transport Item. However, the SMARTFREIGHT solutions will support such monitoring.
D5.2 The SMARTFREIGHT framework architecture
34
SMARTFREIGHT
5 Functional view - Transport Supply uc Transport Supply
Transport Serv ice Management
«include»
Transport Supply Transport Serv ice Prov ider, e.g. FDMS, Freight distributor
«include»
Transport Serv ice Manager, e.g. freight distributor
Transport Operation Manager, e.g. FDMS, fleet operator, back office Transport Operation Management Worker's Equipment Realises
«include»
On-Load Item Equipment
Realises On Item Equipment Realises
On-board Management Driv er's Equipment
On-Board Equipment (OBE)
On-board Manager
Figure 11: Transport Supply decomposition The Transport Supply domain encompasses functions related to three areas: Transport Service Management that provides freight distribution services to a Transport User (in the Transport Demand domain) by the Transport Service Manager role. Transport Operation Management where the transport operations are planned and managed by the Transport Operation Manager role. On-board Management where the vehicles are operated by the On-board Manager role. The green (or dark grey if not printed in colours) areas in Figure 11 are relevant to SMARTFREIGHT. They focus on how to manage and execute the transport operations and the operation of the vehicle. The SMARTFREIGHT solutions may increase the efficiency and the safety (due to better planning and information flows), and the availability and reliability of the systems (due to economy of scale). 5.1
Transport Service Management
uc Transport Serv ice Management
Transport Serv ice Manager, e.g. freight distributor
Transport Serv ice Management
«include»
Prov ide Transport Serv ice
«include»
«include»
Manage Strategic and Tactical Transport Serv ice Planning
Manage Customer Relations
Figure 12: Transport Service Management decomposition The provision of transport services can be decomposed into strategic and tactical (long term) planning and customer relations (Figure 12). None is directly addressed by
D5.2 The SMARTFREIGHT framework architecture
35
SMARTFREIGHT
SMARTFREIGHT, but SMARTFREIGHT may influence on both the strategies and the service content. 5.1.1 Provide Transport Service Decisions are taken about which services to provide and how to provide them, and the relations towards the customers are managed. 5.1.1.1 Manage Strategically and Tactical Transport Service Planning The Transport Service Manager makes long term strategic plans for the transport services to be offered. This may include the planning of the type of services to be provided, the routes and time scheduled to be followed, the type of vehicles to be used, etc. A wide spectre of tasks is relevant to improve the planning and the optimization, e.g.: Identification of customers‟ needs; prediction of the traffic situation and availability of network resources; the availability of Transportation Network resources like loading and unloading areas (managed by the Transportation Area Management domain); optimising the operations with respect to economy; yield management planning (to decide about prices, service packaging, sales strategies, etc.); resource scheduling and backup planning; and identification of the need for third party services. There may be a need for coordination between the transport service planning and the traffic and transportation planning. If so, the Traffic and Transportation Planner (in the Transportation Network Utilisation domain) should be informed about long term plans with respect to routes and time schedules. To achieve the most optimal solution, the routes and time schedules may have to be adjusted. SMARTFREIGHT does not address the long term planning directly. However, indirectly SMARTFREIGHT will support the long term planning of the freight distribution services (the second and third bullet above): The Transport Service Manager can receive and consider the access and priorities assignment policy (APA policy). The policy can be taken into account when time schedules, use of environmental friendly vehicles, use of back load and load factor are planned. The Transport Service Manager can expect a more predictable access to network resources such as loading and unloading areas through assignment of time slots. 5.1.1.2 Manage Customer Relations The Transport Service Manager handles the relations to the customers, services marketing, bookings, status reporting and deviation reporting included. SMARTFREIGHT does not address these customer relations directly, but the SMARTFREIGHT solutions may influence on the ability to provide new or improved transport services, e.g. more efficient tracking and monitoring of cargo, more environmental friendly services, etc.
D5.2 The SMARTFREIGHT framework architecture
36
SMARTFREIGHT
5.2
Transport Operation Management
uc Transport Operation Management
Manage Transport Operation Transport Operator, e.g. FDMS, fleet operator, back office
«include» Transport Operation Management Transport Operation Manager, e.g. FDMS, fleet operator, back office
«include» Execute Transport Operation Transport Operation Worker, e.g. driv er of car, terminal w orker
Transport Sector Support domain
Realises
Realises On-Goods Equipment (OGE)
On Item Equipment
On-Load Item Equipment
Worker's Equipment
On-Board Equipment (OBE)
Figure 13: Transport Operation Management decomposition The Transport Operation Management domain is decomposed into two areas: Manage Transport Operation where the planning and follow up of transport operations are done by the Transport Operator role. Execute Transport Operation where the actual execution of transport operations is done by the Transport Operation Worker role. 5.2.1 Manage Transport Operation Based on the strategic and tactical plans established by the Transport Service Manager, the Transport Operator manages the actual transport operations. One transport operation may handle several transport orders (ordered by different Transport Users). Thus, one transport operation carried out by one vehicle may carry goods related to different orders. Figure 14 shows the decomposition of the Transport Operation Management. The green (or dark grey if not printed in colours) areas are relevant to SMARTFREIGHT. SMARTFREIGHT will indirectly or directly enable improved efficiency and more reliable freight distribution operations (e.g. predictable deliveries, predictable quality, etc.). This can be achieved through: Access to reliable information from the traffic management systems (the Transportation Area Management domain), which can improve the planning. Reservations of Transportation Network Resources (e.g. loading bays). Better information exchange, coordination and control with the vehicles (the Transport Operation Worker role – see 5.2.2), which will enable o
Improved efficiency
o
More reliable deliveries – better ability to meet delivery windows
o
Improved safety (of drivers, vehicles, goods and third parties) through selection of appropriate routes, adaptation to traffic situations, and better monitoring and control.
o
Better collection of transport statistics regarding own services
D5.2 The SMARTFREIGHT framework architecture
37
SMARTFREIGHT
uc Manage Transport Operation
Manage Transport Business
Plan and Prepare Transport Operation
«include»
Adapt to Traffic Management Policy
«include» «include» «include» «include»
«include»
«include» Manage Performance
Transport Operator, e.g. FDMS, fleet operator, back office
Manage Transport Operation
«include»
«include»
Manage Transport Operation Information
Monitor Transport Operation
«include»
Prepare Use of Transportation Netw ork Resources and Serv ices
Control Transport Operation
«include»
«include»
«include»
Prov ide Transport Operation Information
Define Dev iation Handling
«include»
Request Traffic Management Measure
«include» «include»
Manage Schedule and Dev iation
Handle Transport Problems
«include»
Ev aluate Schedule and Dev iation
Prov ide Route Guidance
Track Vehicle
«include» «include»
Plan Transport Operation
«include»
Record Transport Operation Progress
Monitor Load Item
Track Load Item
Figure 14: Manage Transport Operation decomposition 5.2.1.1 Manage Transport Business By transport business management we mean all activities that affect the daily operation of the business, which comprise the following: Management of resources like crew and vehicles Management of information about the work assignment to resources Management of information about crew and vehicles, e.g. information about APOs that are acquired by request (e.g. in return of a fee) Management of statistics and information about o
Driving operations (use of brake, accelerator, gas, effects of driving style, fuel economy, etc.)
o
Working hours
o
Transport operation performance (e.g. time taken on certain aspects of the job – e.g. loading, unloading, driving, waiting, etc.)
o
Vehicle status (engine management, wear and tear, faults, emissions, fuel consumption, temperature control, weight sensors, etc.)
Distribution of software to on-board equipment, e.g. software that support the transport operation execution. SMARTFREIGHT does not address these issues directly, but the SMARTFREIGHT solutions may support information collection from vehicles that are required in the business management, e.g. performance statistics. Software can also be provided to the on-board equipment by means of the CVIS solutions used in SMARTFREIGHT..
D5.2 The SMARTFREIGHT framework architecture
38
SMARTFREIGHT
5.2.1.2 Manage Transport Operation Information Information about the Load Items is managed. This includes the mapping to Transport Items (one Load Item may contain several Transport Items), mapping to transport operations, type of cargo (e.g. dangerous cargo), handling requirements, etc. The condition of the Load Items, transport task status etc. is logged based on information acquired by the monitoring functions (see 5.2.1.5). SMARTFREIGHT does not address these issues directly, but the SMARTFREIGHT solutions facilitate such information management. 5.2.1.3 Plan and Prepare Transport Operation The requirements of the Transport Users, expressed in the Transport Execution Plan (TEP) received from the Transport Service Manager as well as other influencing factors have to be considered in the planning and preparation of specific transport operations. SMARTFREIGHT will support the operational planning by Provision of access to reliable information about the Transportation Network Status (TNS). Provision of information about the default as well as the dynamic APA policy. Enabling allocation of time slots for use of Transportation Network Resources like loading and unloading areas 5.2.1.3.1 Adapt to Traffic Management Policy The Transportation Area Management domain will manage the use of the Transportation Network according to APA policies. An APA policy define the conditions for getting access and priority offers (APOs) related to Controlled Areas. The APOs may depend on the type of vehicle (e.g. environmental friendly or not), type of cargo (e.g. dangerous cargo), load factor, planned destination, traffic situation, etc. The Transport Operator must be aware of the default APA policy, and the consequences of with respect to the efficiency of the transport related operations. SMARTFREIGHT addresses the provision of APA policy information, but not the actual transport operation planning based on this information. 5.2.1.3.2 Plan Transport Operation A Transport Operation Plan (TOP) is established for each transport operation based on the requirements from Transport Users (expressed by means of Transport Execution Plans, TEPs, and received from Transport Service Manager, see 5.1). The TOPs may also be adjusted for ongoing transport operations or due to foreseen performance problems detected in 5.2.1.3.4. Several issues are considered during the planning or re-planning: The Transport Items and how they are to be “transformed to” of included into Load Items, e.g. containers or pallets, and their handling instructions (e.g. temperature, pressure, security, etc.) The availability of required resources (e.g. drivers, vehicles, load units, etc.) Pick-up and delivery locations, the route to be followed and time schedules. In case of pre-defined routes, the route is based on the plans made in 5.1.1.1. The actual tasks to be executed (transport, loading, unloading, etc.) Required monitoring of the transport operations and Load Items and the reporting policy. The APA policy (default APA policy from 6.1.1 and current or foreseen APA policy from 6.1.2.1)
D5.2 The SMARTFREIGHT framework architecture
39
SMARTFREIGHT
The need for other access and priorities offers (APOs) than those automatically assigned according to the APA policy and whether other APOs can and should be requested (the actual requests for such APOs is however handled in 5.2.1.4.1) The ability of back-loading1F1F2, including the collection of waste and return goods from retail outlets. Back load will increase the percentage of filling and may cause privileges, i.e. better APOs. SMARTFREIGHT does not address the planning process, but support the three last bullet points through the provision of APA policies and the assignment of APOs 5.2.1.3.3 Define Deviation Handling The situations considered as deviations, e.g. too high temperature on cargo, and the actions taken in case of each deviation must be defined. (The deviation will be detected by means of the transport operation monitoring in 5.2.1.5). SMARTFREIGHT addresses the monitoring of the Transport Items‟ conditions, but does not directly support the collection of condition and deviation definitions from the Transport User. 5.2.1.3.4 Prepare Use of Transportation Network Resources and Services Access to Transportation Network Resources, e.g. time slots for use of loading bays, is booked from the Transportation Network Resource Manager in the Transportation Network Utilisation domain (see 6.1.3.1). Information about the availability of resources may also be acquired to support the planning. In case of deviations re-bookings or cancellations may be required (the local re-booking and cancellation policy must be taken into account – e.g. how long time in advance they have to be done, etc.). Information about the allocation is included into the TOP. 5.2.1.3.5 Manage Performance The ability to meet the TOP is considered, including: The access to Transportation Network Resources, i.e. loading bays, depends on the outcome in section 5.2.1.3.4. The Transportation Network Status (TNS) received from the Transportation Area Management domain (see 6.1.2.5, or be based on information from earlier transport operations (e.g. average travel times) and on-going transport operations (e.g. accidents, congestion, etc.) (see 5.2.1.4.3) The current status of on-going transport operations based on for example Transport Operation Status (TOS) reports (see 5.2.1.4.4) If the required performance cannot me met, the transport operation has to be re-planned (in 5.2.1.3.2). SMARTFREIGHT does not address the performance evaluation directly, but supports the required information exchange. 5.2.1.3.6 Provide Transport Operation Information When the transport operation is planned, the necessary Transportation Network Resources are booked and the ability to meet the required performance is ensured, resulting Transport Operation Plan (TOP) is provided to the Transport Operation Worker:
2
Back-loading refers to the use of vehicles to carry loads on the return legs of delivery journeys, with the aims of increasing vehicle utilisation and improving transport efficiency.
D5.2 The SMARTFREIGHT framework architecture
40
SMARTFREIGHT
5.2.1.4 Control Transport Operation The transport operations are controlled to facilitate detection of deviations or upcoming deviations and corrective measures. The aim is to fulfil time schedules as well as quality and safety requirements. Information about individual operations is received from the monitoring function (see 5.2.1.5). Transportation Network Status (TNS) information is considered, and the information exchange with vehicle is supported. SMARTFREIGHT will enable improved information exchange, including information exchange about the driving conditions with On-board Manager in the On-board Management domain. 5.2.1.4.1 Request Traffic Management Measure The APA policy decided by the Transportation Network Utilisation domain defines how APOs automatically will be assigned to vehicles. The Transport Operator must consider how to cope with delays and specific needs, and other APOs may be requested (e.g. in return for extra fees). 5.2.1.4.2 Provide Route Guidance The On-board Manager‟s navigation is supported. At the start of the transport operation the planned route and/or destinations along the route may be provided to the On-board Manager. However, in many cases it may be up to the On-board Manager to decide on the actual route to follow. The route may be updated due to changed schedules or new traffic situations. The On-board Manager may also request guidance to destination during the transport operation if he is unable to find the destination or uncertain of which route to take. Information on the Transportation Network Status (TNS) may also be communicated to the On-board Manager (see5.3.3.1). The actual route calculation is not a part of SMARTFREIGHT, but the required information exchange towards the vehicle is supported. 5.2.1.4.3 Handle Transport Problems The Transport Operator may receive information about problems related to the traffic, vehicle operation and navigation that may affect one or more transport operations. The actual effects on the transport operation is however detected by the monitoring functions (see 5.2.1.5). Actual and foreseen problems must if possible be handled. The problems may affect one specific transport operation (e.g. vehicle problems) or several transport operations (e.g. congestion). For example: Vehicle problems and driver illness will affect one specific transport operations. It can be handled by use of back-up resources. The Manage Schedule and Deviation function in 5.2.1.4.4 must be informed so that decisions about the need for example re-planning is considered. Difficulties in finding locations along the route, or uncertain of which route to take can be solved by means of route guidance (see 5.2.1.4.2) Involvement in accidents, heavy route congestion or other abnormal network conditions may affect several transport operations. The Manage Schedule and Deviation function in 5.2.1.4.4 must be informed so that decisions about for example re-planning can be taken. In addition route guidance (see 5.2.1.4.2) may be required. Security concerns may require specific measures, e.g. contact with authorities. SMARTFREIGHT does not directly address the management of the individual transport problems, but much of the required information exchange is supported.
D5.2 The SMARTFREIGHT framework architecture
41
SMARTFREIGHT
5.2.1.4.4 Manage Schedule and Deviation Deviations or foreseen deviations may be detected in several ways: The Schedule and Deviation Evaluation function (5.2.1.5.5) provides awareness about deviations detected by the transport operation monitoring. Deviations are predicted due to the transport problems identified in 5.2.1.4.3 The Transport Operator must decide how the deviations are to be handled, e.g.: Direct communication with vehicle/Transport Operation Worker and other information sources may be established whenever it is required to get more information about the situation. Dynamic adjustments of ongoing transport operations may be required. Re-planning may (see 5.2.1.3.1) is initiated, route guidance may be provided (see 5.2.1.4.2), APOs may be requested (see 5.2.1.4.1), etc. If the desired time of arrival or any other Transport User preferences cannot be met for any of the Load Items on-board, If deviations such as time schedule deviations, damages, condition infringements, etc. (depending on the deviation settings defined in 5.2.1.3.3) are detected, the Transport Service Manager is notified by means of a Transport Execution Status (TES) report in order to inform the respective Transport Users (see 5.1.1.2). Other measures, e.g. measures that are required due to deviation related to dangerous goods. The management of the dynamic operations is not directly addressed by SMARTFREIGHT, but the required information exchange is partly made available by SMARTFREIGHT. 5.2.1.5 Monitor Transport Operation The transport operations are tracked and the status of the vehicle and Load Items are monitored. Position and status information can be received at pre-defined intervals or locations or on request. The monitoring of Load Items may in the future be done through direct interactions with the OGE/Load Item, but in SMARTFREIGHT the status and position of a Load Item is monitored through interactions with the vehicle (the OGE). On detection of events or deviations, the Schedule and Deviation Management function (see 5.2.1.4.4 is triggered. The need for tracking and monitoring will vary and can be required when: Goods are highly expensive, dangerous or particularly prone to theft Delivery constraints are tight The On-board Manager and/or vehicle are urgently needed for another task There is a low level of trust with On-board Managers (e.g. sub-contracted agency Onboard Managers and On-board Managers paid an hourly rate). The Transport Operator needs to know all details to be able to o
Do resource planning. Use On-board Managers and vehicles that are available and conveniently located to undertake a new task or a task that needs to be rescheduled (e.g. back-loading collection task).
o
Inform clients of the whereabouts of their goods and the expected delivery time
o
Take remedial actions quickly in response to unexpected events such as a traffic accident.
D5.2 The SMARTFREIGHT framework architecture
42
SMARTFREIGHT
o
Keep a detailed record of vehicle movements as a proof in case of accidents, traffic violations, penalties imposed by the customer for late delivery, or for claiming compensation where the customer delays the On-board Manager.
SMARTFREIGHT will support the monitoring by providing access to tracking and status information from the OBE. 5.2.1.5.1 Track Vehicle The movement of vehicles may be tracked based on the tracking information received from the en-route reporting from the Driver‟s Equipment (see 5.3.3.1). Tracking at pre-defined intervals and on request tracking services may be provided. Stops and stop durations may also be registered. 5.2.1.5.2 Track Load Item Depending on the extend to which the cargo has to be tracked, Load Items (cargo) may be tracked based on Information derived from the vehicle tracking (see 5.2.1.5.1) A Transport Operation Status (TOS) from the transport operation reporting (see 5.2.2.2) The tracking may free the Transport Operation Worker from the need to keep a manual log of journey details. In SMARTFREIGHT just the vehicles are tracked. 5.2.1.5.3 Monitor Load Item Transport Operation Status (TOS) with Load Item condition information (e.g. temperature, humidity, etc.) and other information (e.g. damage reports) is received from the OBE (see 5.2.2.2). The information may be acquired through reception of condition information at predefined intervals or on request. 5.2.1.5.4 Record Transport Operation Progress The condition of the Load Items and the progress of the transport operation is received in the Transport Operation Status (TOS) from the OBE (see 5.2.2.2) and recorded. Loading, unloading, delivery, delivery problems (e.g. damage to goods), and associated administrative issues like invoicing and payment may be reported. Electronic signatures can be used to verify the information. The reason for unauthorised stops may also be registered. SMARTFREIGHT addresses just electronic reporting (not voice communication with the driver). The status recording is not directly addressed, but SMARTFREIGHT supports the exchange of status information. 5.2.1.5.5 Evaluate Schedule and Deviation The evaluation is not directly supported by SMARTFREIGHT; however the tracking (see 5.2.1.5.1 and 5.2.1.5.2), monitoring (see 5.2.1.5.3) and status recording (see 5.2.1.5.4) functions are used to detect deviations. Such actual transport execution information is then compared to the Transport Execution Plan. The deviation handling is defined in 5.2.1.3.3, and the Schedule and Deviation Management function (see 5.2.1.4.4) will handle the deviations. 5.2.2 Execute Transport Operation The actual execution of transport operations related to Load Items is supported, e.g. support of transport related tasks such as packing (put into a load unit), unpacking, loading, unloading, document handling, monitoring, reporting, pick-up, delivery, etc.
D5.2 The SMARTFREIGHT framework architecture
43
SMARTFREIGHT
The tasks are executed by the Transport Operation Worker role supported by the Worker‟s Equipment. It realised by means of the On-Board Equipment (OBE). The monitoring of the Load Items is done by means of the generic functions provided by the On-Item Equipment (see the Transport Sector Support domain). The On-Goods Equipment (OGE) will realise these functions. Information about the transport operation is received from the Transport Operator (see 5.2), and the status of the operations is also reported to the Transport Operator. Figure 15 shows the Execute Transport Operation decomposition. uc Execute Transport Operation
Execute Transport Operation
Manage Transport Operation Information and Progress
«include»
Transport Sector Support domain
On-Load Item Equipment «include»
«include»
Manage Transportation Netw ork Resource Booking
«include»
Report on Transport Operation
Support Transport Task Execution On Item Equipment Realises
Realises
Realises
On-Board Equipment (OBE)
Worker's Equipment
Transport Operation Worker, e.g. driv er of car, terminal w orker
On-Goods Equipment (OGE)
Figure 15: Transport Operation Execution decomposition SMARTFREIGHT will enable better information exchange and coordination between the OBE/driver (who has the Transport Operation Worker role) and the back-office (which has the Transport Operator role). 5.2.2.1 Manage Transport Operation Information and Progress Information about the transport operation and how it has to be carried out is received and updated by interactions with the Transport Operator and the Load Item. The Transport Operator will provide the TOP (Transport Operation Plan) and the plan is also maintained in case of changes. The Load Item may provide information about itself, tracking information and status information. The transport execution is managed. As far as possible this should be done automatically. The Transport Operation Worker should as far as possible not have to register events and statuses manually. Position of Load Items may be received from the generic tracking service (see 7.1.2) which may run on On-load Item Equipment. If the Load Item is not individually tracked, the position of vehicle may be used (received from 7.1.2) Load Item status on o
Load Item conditions and deviations. Such status information may be received from the generic condition monitoring services (see 7.1.1) which may run on On-load Item Equipment. Deviations such as delivery problems and damage may however also be registered manually.
o
The progress of the transport operation tasks (loading, unloading, etc.). Such status information may be automatically registered by generic status reporting service (see 7.1.3) which may run on Load Item Scanning Equipment, or the
D5.2 The SMARTFREIGHT framework architecture
44
SMARTFREIGHT
Transport Operation Worker may register the status on the Worker‟s Equipment (see 5.2.2.4). This also includes proof of delivery (with electronic signatures). 5.2.2.2 Report on Transport Operation The Transport Operation Status (TOS) is established based on the information managed in 5.2.2.1 and electronically reported to the Transport Operator (see 5.2.1.5) by means of the Worker‟s Equipment. If information about transport problems is received from the On-board Manager (see 5.3.3.5) this information is also reported to the Transport Operator. Unplanned stops may also be reported. 5.2.2.3 Manage Transportation Network Resource Booking The booking of Transportation Network Resources (e.g. timeslots for access to loading and unloading areas) may be managed by the Transport Operator (who may have pre-booked time slots – see 5.2.1.3.4 and entered the booking information into the TOP). However, the Transport Operation Worker may also book or change booking through interactions with the Transportation Network Resource Manager (see 6.1.3.1). Information about bookings is managed as a part of the transport operation information (5.2.2.1). Information about the availability of resources may also be acquired (see 6.1.3.1) to support the planning. Whenever there are deviations from the planned time schedule, re-bookings or cancellations must be provided (the local policy will decide about the re-booking and cancellation policy – e.g. how long time in advance they have to be done). 5.2.2.4 Support Transport Task Execution The Worker‟s Equipment may support the execution of the Transport Operation Worker in many ways, e.g.: Information can be provided about the condition of Load Items (based on input from the monitoring in 7.1), and in case of deviations the Transport Operation Worker can be asked to take measures (e.g. adjust the temperature). The handling of the Load Items (e.g. loading, unloading, packing, etc.) can be supported with information about how they are to be handled. The progress of the transport operation tasks (loading, unloading, etc.) may be registered automatically (by means of communication with a generic status reporting service - see 7.1.3) or the Transport Operation Worker may register the status (e.g. Proof of delivery with electronic signature) on the Worker‟s Equipment. The transport task execution support is outside the scope of SMARTFREIGHT, but may be supported by the information established by the SMARTFREIGHT solutions.
D5.2 The SMARTFREIGHT framework architecture
45
SMARTFREIGHT
5.3 On-board Management The On-board Management domain supports the On-board Manager by means of the Driver‟s Equipment, which is realised by the On-Board Equipment (OBE). The transport operation information (received from the Transport Operation Worker role in the Transport Operation Management domain) holds information that is needed when the driving operations are planned and carried out. The decomposition of the On-board Management domain is shown in Figure 16. The green (or dark grey if not printed in colours) are relevant to SMARTFREIGHT. Focus is on how to support the On-board Manager by means of On-Board Equipment enabling information exchange and cooperation with the traffic management system (the Transportation Network Utilisation domain). This may increase the efficiency and the safety (due to better planning and information flows), and the availability and reliability of the systems (due to economy of scale). uc On-board Management
Register Vehicle Tracking Information «include» Monitor Vehicle
«include»
«include» Operate Vehicle
On-board Manager
Support and Control Vehicle Operation «include»
«include»
«include»
«include»
Manage Transport Operation Information
«include»
Manage Vehicle and Transport Operation Information
«include»
Driv er's Equipment
«include»
Support Nav igation
«include» Use Information Serv ices
Manage Applications
Realises
On-board Management
Monitor Vehicle Status
Manage Route
«include»
On-Board Equipment (OBE)
«include»
Prov ide Automated Driv ing Support
Process Access and Priority Offers
«include» «include»
«include» Manage Fee Payment
Manage Route Plan
«include»
Manage En-route Reporting
Report Vehicle Tracking Information
Vehicle «include»
«include» Support Transport Problem Reporting
«include»
«include»
Support Traffic Situation Reporting
Manage Certificates
«include»
Report Vehicle Access Information
Report Vehicle Safety Related Information
Figure 16: On-board Management decomposition 5.3.1 Operate Vehicle SMARTFREIGHT will through interactions between the vehicle and the Transportation Area Management domain support driving and navigation that are in accordance with individual traffic management measures. This will give the On-board Manager Improved awareness about the current and foreseen traffic situation
D5.2 The SMARTFREIGHT framework architecture
46
SMARTFREIGHT
More predictable access to Transportation Network Resources. Advantageously assess and priority offers if the transport operation is adapted to the APA policy The driving and navigation operation is supported by the On-Board Equipment. The operation will, among others, be influenced by: The transport operation to be executed and the status of the cargo and the operation Transportation Network Status (TNS) The dynamic APA policy 5.3.1.1 Monitor Vehicle Information about the vehicle status and the movement of the vehicle (tracking of position, speed, and direction information) is registered. 5.3.1.1.1 Monitor Vehicle Status The status of the vehicle (speed, temperature, the status of different control systems, engine parameters, emissions, noise, etc) is monitored. Relevant vehicle status information may be sent to the Transport Operator. The actual monitoring is not addressed by SMARTFREIGHT, but the On-Board Equipment may register vehicle parameters. 5.3.1.1.2 Register Vehicle Tracking Information The position, speed, and direction of the vehicle are continuously registered. Stops and the duration of stops may also be tracked. The function may be supported by the generic tracking service in 7.1.2. The On-Board Equipment developed in SMARTFREIGHT will register the position of the vehicle. 5.3.1.2 Support and Control Vehicle Operation The vehicle is operated through a continuous process consisting of observations and evaluations (to establish situational awareness), decisions and actions. Regulations must be complied with as well as individual directions provided by the traffic management system (the Transportation Network Utilisation domain), e.g. access restrictions to parts of the transportation network (see 6.1.2.3.5.3). SMARTFREIGHT does not address the generic driving process, just the information exchange with the traffic management system. 5.3.1.2.1 Manage Route The route is planned based on The transport operation information received from the Transport Operation Worker in the Transport Operation Management domain and the route plan that might be derived from the transport operation information (see 5.3.2.2and 5.3.2.4). Generic information about the Transportation Network Status (TNS) (e.g. incidents, accidents, traffic flow information, etc.) as received in 5.3.1.2.4. APOs that may be computed by the vehicle itself (as a response to received APA policies) or assigned to the vehicle on request. The APOs may define: o
Access permissions that may include time slots for access (see 5.3.2.3). Vehicles may for example be asked to wait until the traffic situation has improved. Access certificates with access permissions may also be issued on request.
D5.2 The SMARTFREIGHT framework architecture
47
SMARTFREIGHT
o
Access restrictions for specific Controlled Areas. Access restrictions may be fed into navigation systems (so that the restrictions can be considered in the route planning).
o
Priorities
The On-board Manager may need support to the route planning in a number of different circumstances, including whenever: The On-board Manager is unfamiliar with the available Transportation Network or the location of the destination address. The vehicle is particularly wide, tall or heavy and the On-board Manager needs to know about any width, height and weight restrictions (e.g. low or weak bridges). The delivery round contains many drop-off points and the optimum route around them may not be obvious. The transport operation requires the On-board Manager to take a specified route or to visit delivery points in a certain order; this could be for a number of different reasons including the delivery requirements, vehicle restrictions or due to the goal of minimising fuel consumption. SMARTFREIGHT does not address the route planning directly. Much of the required information exchange is however supported by the On-Board Equipment. 5.3.1.2.2 Support Navigation The navigation support can be provided by either separate equipment or separate systems, or by an integration of several tools. Different types of information may be combined and presented, e.g. maps with static information (speed limits, road geometry, road suitability measures, etc.) and real-time information about the network and traffic status (journey time, delay data, temporarily speed limit, lane closures, accident warnings, road works, tolling information, etc.). Such integration may simplify the navigation and support the decisions, however, information overload should be avoided. Just the information that is likely to be of interest should be provided. The On-board Manager may be guided through the planned route, and information about the expected time of arrival or delays may be provided. SMARTFREIGHT does not address the navigation support directly. The APOs should however be fed into the navigations too so that they can be considered when the routes are planned. Notifications may also be received from the Traffic Manager, e.g. about illegal entrance, postponed access (e.g. to tunnels due to other vehicles in the tunnel), granted access (e.g. when tunnel can be accessed), emergencies, etc. 5.3.1.2.3 Provide Automated Driving Support Automated driving support may assist the On-board Manager is dangerous situations. The degree of automation and intervention may vary. SMARTFREIGHT does not address the On-board Manager support directly. However, the on-board equipment and the communication facilities (vehicle-to-vehicle and vehicle-toinfrastructure) will facilitate co-operative functions that improve the safety (alerts, automated braking, etc.). 5.3.1.2.4 Use Information Services The On-board Manager may request information manually, and on-board systems, e.g. navigation support systems, may request such information automatically. Information is collected, stored, and if required presented in a way that is appropriate to the On-board Manager. HMI considerations have to be taken to ensure safety.
D5.2 The SMARTFREIGHT framework architecture
48
SMARTFREIGHT
Relevant information may be received from the Transportation Network Utilisation domain (see 6.1.2.5) or the Transport Operation Management domain if the information is routed via the Transport Operator (see 5.2.1.4.2). This information includes: Information on the current or predicted Transportation Network Status (TNS) such as traffic information (e.g. traffic density, travel times, warnings, etc - see 6.1.2.5.3), transportation network conditions (e.g. slippery road, closed roads, etc - see 6.1.2.5.5) and incident or accident information (see 6.1.2.5.1) Transportation Network information, information about holding areas included (6.1.2.5.4) Route information (see 6.1.2.5.1) SMARTFREIGHT addresses parts of the information exchange, and the use of the information services may be implemented by means of the On-Board Equipment. 5.3.1.3 Manage Applications The applications of the On-board Manager are managed, i.e. they are downloaded and updated. SMARTFREIGHT does not address this issue. The CVIS platform, on which SAMRTFREIGHT is based, does however provide mechanisms that support application uploading and downloading. 5.3.2 Manage Vehicle and Transport Operation Information Information about the vehicle and different aspects of the vehicle operation (e.g. vehicle properties, cargo on board, speed, engine parameters, position, assigned certificates, etc.) is recorded and provided to those entitled to get access to such information. 5.3.2.1 Process Access and Priority Offers The dynamic APA policy is received (see 6.1.2.1). If the vehicle has not been assigned individual access certificates and priorities (received from the Transport Operator in 5.2.1.4.1 or requested by the On-board Manager in 5.3.2.3), APOs (access rights and priorities) are computed based on: The vehicle properties (type, engine, size, etc.) The type of cargo on-board (e.g. dangerous cargo and amount) (established in 5.3.2.2) Load factor (established in 5.3.2.2) The dynamic APA policy The APOs must be computed when the vehicle approaches a Controlled Area, when vehicle is loaded or unloaded, and when an updated APA policy is received before the Controlled Area is entered (e.g. while waiting at a holding area). 5.3.2.2 Manage Transport Operation Information Vehicle and transport operation information is registered and managed. Relevant information is: The identity of the vehicle and vehicle properties (type of vehicle, type of engine, size of vehicle, weight of empty vehicle, etc.) Overall information about the Load Items (type of cargo on board and description of hazardous materials, vehicle fill, vehicle weight when laden) The next destinations and related time slots and bookings of resources, e.g. loading bays The On-Board Equipment developed in SMARTFREIGHT will support the registration of the vehicle and transport operation information.
D5.2 The SMARTFREIGHT framework architecture
49
SMARTFREIGHT
5.3.2.3 Manage Certificates The APOs that are computed based on the received APA policy (see 5.3.2.1) and the APOs that are assigned to the vehicle on request are managed. The latter may be requested by the vehicle itself or provided by the Transport Operator. In SMARTFREIGHT the On-board Equipment will management of these APOs. 5.3.2.4 Manage Route Plan Information about the planned destination(s) and related time slots, Transportation Network Resource bookings (e.g. loading bays) and estimated times of arrival (ETA) is managed. SMARTFREIGHT does not address this function, but it ay be implemented on the On-Board Equipment. 5.3.2.5 Manage Fee Payment Before, during or after the transport, the required fee payments are performed, and information about the payment is registered. The payment may be manual, by credit card, electronic. SMARTFREIGHT does not address fee collection. The On-Board Equipment may however support the payment as well as payment information management. The fee may also be dependent on the APOs assigned to the vehicle 5.3.3 Manage En-route Reporting The vehicle will report or publish information during the transport. 5.3.3.1 Report Vehicle Tracking Information The tracking information registered in 5.3.1.1.2 is made available to those entitled to such information together with related information from 5.3.2.2 (e.g. speed.) Stops and duration of stops may be tracked. 5.3.3.2 Report Vehicle Access Information Entry and exit information is reported whenever required (see discussion in Annex F as the vehicle drives through the Transportation Network to document the entries and exits to and from the Controlled Areas. Vehicle information may also be provided to support the generation of statistics. 5.3.3.3 Report Vehicle Safety Related Information The safety status of the vehicle, e.g. information about dangerous goods (if any), the condition of such goods and the safety status of the vehicle (parameters that may indicate the vehicle may become problems of any kind – e.g. fuel status, engine problems, etc.) are reported to the Transportation Network Utilisation domain. This may for example be of interest before the entrance of tunnels or other critical Controlled Areas. SMARTFREIGHT will not address the reporting, but the On-Board Equipment may be used for this purpose, and such information may influence on the individual traffic management measures. 5.3.3.4 Support Traffic Situation Reporting Information about the Transportation Network Status (TNS) (e.g. meteorological conditions, incidents and accidents, abnormal network conditions, congestion, etc.) can be reported to the Traffic Manager so that traffic management measures can be taken. SMARTFREIGHT does not address the reporting, but the information exchange (TNS) is specified.
D5.2 The SMARTFREIGHT framework architecture
50
SMARTFREIGHT
5.3.3.5 Support Transport Problem Reporting The On-board Manager may report problems that may affect the transport operation to the Transport Operation Worker (5.2.2.2) Vehicle problems and driver illness that may affect one specific transport operations. Difficulties in finding locations along the route, or uncertain of which route to take can be solved by means of require route guidance Security concerns may require specific measures, e.g. contact with authorities. Expected time of arrival to planned destinations in case of foreseen delays SMARTFREIGHT will not address the reporting, but the On-Board Equipment may be used for this purpose, and such information may influence on the planning in the Transport Operation Management domain.
6 Functional view - Transportation Area Management The Transportation Area Management domain mainly focuses on the Transportation Network (the infrastructure enabling the transport) and is further decomposed into: Transportation Network Infrastructure Management where the physical transportation Network with related equipment is managed by the Transportation Network Infrastructure Manager. Transportation Network Utilisation where the management of the traffic in the Transportation Network is done by the Transportation Network Utilisation Manager. Emergency Management where emergency preparedness and emergency management are handled by the Emergency Manager. uc Transportation Area Management
Realises
Transportation Netw ork Equipment Transportation Netw ork Infrastructure Management «include»
Transportation Area Manager
Transportation Area Management
«include»
Road-Side Equipment (RSE)
Transportation Netw ork Infrastructure Manager, e.g. city or road administration
Transportation Netw ork Utilisation Transportation Netw ork Utilisation Manager
«include» Emergency Management
Emergency Manager
Figure 17: Transportation Area Management decomposition 6.1 Transportation Network Utilisation The Transportation Network Utilisation domain aims to utilise the infrastructure in the best possible way according to an overall strategy.
D5.2 The SMARTFREIGHT framework architecture
51
SMARTFREIGHT
uc Transportation Netw ork Utilisation
Plan Transportation Netw ork Utilisation
«include» Transportation Netw ork Utilisation
«include»
Perform Operational Traffic Management
Transportation Netw ork Utilisation Manager
Traffic and Transportation Planner, e.g. city or road administration
Traffic Manager, e.g. UTMS, city or road administration
«include» Manage Transportation Netw ork Resources
Transportation Netw ork Resource Manager, e.g. city or terminal
Figure 18: Transportation Network Utilisation decomposition Figure 18 shows the Transportation Network Utilisation decomposition, and the green (or dark grey if not printed in colours) are addressed by SMARTFREIGHT. However, all three issues are of relevance to SMARTFREIGHT: The Transportation Network Utilisation planning must determine the overall strategy for regulation of freight transport in the city, the use of Controlled Areas and traffic management measures included. The planning is not directly addressed by SMARTFREIGHT, but an implementation of the SMARTFREIGHT solutions will provide new possibilities that will influence on the planning. The operational traffic management is based on awareness about current and upcoming traffic situations. This includes evaluations of the how the traffic situation will develop and decisions upon and effectuations of traffic management measures to influence on the situation in a positive way. The measures will in the context of SMARTFREIGHT also be taken towards individual freight vehicles. The aims are to minimize congestion and pollution, to utilize the Transportation Network as efficient as possible, to support safe distribution of dangerous cargo, and to increase the efficiency in freight distribution for vehicles complying with regulations and guidelines. The access to Transportation Network Resources such as loading bays must be managed. 6.1.1 Plan Transportation Network Utilisation This function is about the strategic planning of the traffic management policy for different day and time periods (e.g. rush hours). Normal variations in the traffic situation must be considered and handled. Thus, the policy is defined based on Statistics about traffic and transport demands (e.g. number of vehicles) Information about the pre-defined routes of the Transport Service Providers. The needs of the city and the society (safety, efficiency, environmental protection, etc.) The needs of different actors (public transport, freight transport, retailer, etc.) Cooperation with surrounding traffic management areas or regions
D5.2 The SMARTFREIGHT framework architecture
52
SMARTFREIGHT
The resulting policy may for example define measures that encourage the Transport Service Providers to enter the city at other times to improve the efficiency and reduce the negative effects of the transport. Within the context of SMARTFREIGHT, the following should be defined The required monitoring, e.g. monitoring of vehicles carrying dangerous cargo in certain Controlled Areas such as tunnels The Controlled Areas (tunnels, green areas, road segments, etc.) The APA policies associated to the Controlled Areas on different day and for different time periods, including o
The default conditions for monitoring, e.g. that vehicles carrying dangerous goods should be monitored
o
The default conditions (e.g. vehicle characteristics) for assignments of access and priorities.
Rules for access to Transportation Network Resources, e.g. booking and cancellation strategies. Guidelines for how different traffic situations should influence on the dynamic APA policies. The default APA policies should be provided to the Transport Service Providers to support their planning process. SMARTFREIGHT does not address the planning, but SMARTFREIGHT provides concepts and mechanisms that should be used in the planning process, e.g. the concepts of Controlled Areas and APA policies. The planning should also consider how the SMARTFREIGHT solutions should be used to implement the APA policies, e.g. the use and localisation of Road-Side Equipment (RSE). 6.1.2 Perform Operational Traffic Management The traffic is during normal traffic situations managed according to the APA policies established in 6.1.1. However, dynamic APA policies may also be established to handle abnormal traffic situations. Figure 19 shows the decomposition of the operational traffic management activity, which is highly relevant to SMARTFREIGHT. The SMARTFREIGHT solutions will support Improved access to information about freight transport (statistics) Improved ability to monitor specific vehicles, e.g. vehicles carrying dangerous cargo Ability to give privileges to individual vehicles with a desired behaviour (green vehicles, vehicles avoiding of rush hours, etc.) Improved ability to detect illegal behaviour Ability to take traffic management measures that are adapted to the traffic situation.
D5.2 The SMARTFREIGHT framework architecture
53
SMARTFREIGHT
uc Perform Operational Traffic Management
Perform DynamicTransport Management Planning
Monitor Traffic Situatuation «include»
«include»
«include»
«include»
Monitor Hazardous Goods
«include»
«include»
Monitor Transportation Netw ork
Monitor Env ironmental Condition
Assess Traffic Situation
Monitor Traffic Flow
Control Traffic Flow «include» «include» Perform Operational Traffic Management
«include»
Traffic Manager, e.g. UTMS, city or road administration
Perform Traffic Control
Operate Transport Netw ork Equipment
«include»
«include»
«include»
Manage Safety Measures
Manage Incident «include» «include»
Manage Access and Priority Assignments
Prov ide Incident and Accedent Information
«include»
«include» Prov ide Traffic Information Situation
«include»
«include»
«include»
Prov ide Route and Nav igation Information
Prov ide Traffic Flow Information
«include»
Prov ide Transportation Netw ork Information
Control Indiv idual Vehicle
«include»
Manage Presence in Controlled Area
«include» Prov ide Transportation Netw ork Condition Information
Track Vehicle
Figure 19: Perform Operational Traffic Management decomposition 6.1.2.1 Perform Dynamic Traffic Management Planning During normal traffic situations, the default APA policies defined in 6.1.1 are used. Short term and dynamic APA policies may however be defined to handle current and foreseen traffic situation that deviate from the normal. The APA policy guidelines defined in 6.1.1 may provide guidelines for how to define the dynamic APA policies, and they are also based upon Prognosis for traffic situation (traffic density, congestion, etc.) and environmental conditions (weather, pollution, etc.) Information about upcoming events Information from the monitoring functions (see 6.1.2.2), e.g. information about traffic exceptions, Transportation Network conditions, accidents and incidents. A balancing of different needs, e.g. public transport vs. freight distribution. Information about the dynamic APA policy is provided to vehicles and Transport Operators. The actual dynamic planning of APA policies is not addressed by SMARTFREIGHT, but the use and distribution of such policies are however essential to SMARTFREIGHT. The
D5.2 The SMARTFREIGHT framework architecture
54
SMARTFREIGHT
distribution of the APA policies to vehicles is decentralised, i.e. performed by means of RoadSide Equipment (RSE) (see Annex E). 6.1.2.2 Monitor Traffic Situation The traffic situation is monitored continuously to detect incidents and situations that may influence on safety and traffic flow. The monitoring provides: An accurate and detailed overview of the current Transportation Network Status (TNS). This includes awareness about abnormal and unplanned conditions that may influence on the traffic flow and safety such as o
Traffic issues such as congestion, accidents and incidents
o
Environmental conditions such as meteorological conditions, pollution, dust, smoke, noise, spill of harmful materials, etc.
o
Specific Transportation Network conditions such as the condition of the road, maintenance, obstructions, reduced capacity, etc.
Empirical traffic data that support traffic planning and development schemes and impacts on traffic (needed in 6.1.1.) Awareness about the presence of vehicles carrying dangerous cargo The information established during the monitoring must be collected and stored in such a way that it can support other functions such as traffic control, incident and emergency management, preparation of prognosis, and traffic planning and optimising. 6.1.2.2.1 Monitor Environmental Conditions Meteorological conditions, pollution (dust, spill of harmful materials, etc.), noise, etc. are monitored to detect situations that must be addressed by the traffic management. The monitoring of the environmental conditions is not a part of SMARTFREIGHT, but the conditions may influence on the dynamic APA policies. 6.1.2.2.2 Monitor Hazardous Goods The presence of vehicles carrying hazardous materials in Controlled Areas may be detected (see 6.1.2.3.5.2). This contributes to awareness about the presence of hazardous materials in for example tunnels and other parts of the Transportation Network where such cargo may cause a safety risk in case of incidents or emergencies. Such awareness may be useful related to traffic control (see 6.1.2.3) and for purposes not addressed by SMARTFREIGHT, e.g. emergency management. 6.1.2.2.3 Monitor Traffic Flow Information about traffic flow and vehicles is continuously received from several sources. Specific attention is given to vehicles assumed to represent a risk with respect to human lives or health; environmental issues; or traffic problems. This may for example be public transport vehicles (transporting many persons) and vehicles with special properties (e.g. emergency vehicles, slow vehicles, vehicles that are long or broad, etc.). The monitoring of the traffic flow may lead to detections of incidents and potential dangerous situations. The monitoring of the traffic flow in general is not a part of SMARTFREIGHT, but the traffic situation will influence on the dynamic APA policies. 6.1.2.2.4 Monitor Transportation Network Transportation Network information (speed limits, maintenance, reduced capacity, restrictions, etc.) is received from 6.2.2. In addition abnormal and unplanned Transportation
D5.2 The SMARTFREIGHT framework architecture
55
SMARTFREIGHT
Network conditions (e.g. maintenance, reduced capacity, restrictions, etc.) that may influence on the traffic flow and on the safety are received from the continuous Transportation Network operation (see 6.2.3). The monitoring of the Transportation Network is not a part of SMARTFREIGHT, but the conditions may influence on the dynamic APA policies. 6.1.2.3 Perform Traffic Control The traffic is controlled to achieve optimal efficiency and safety and to minimize the negative effects on the environment (pollution, noise, etc.). Traffic management measures are mainly taken based on an assessment of the awareness about the current and foreseen situation. Traditionally, the road traffic management measures are directed towards the traffic flow, e.g. through the provision of speed limits on variable message signs, generic route guidance, signalling, etc. This traffic flow management is not addressed by SMARTFREIGHT. The traffic management measures towards individual freight vehicles (see 6.1.2.3.5) are however emphasised, and these must co-exist with the traditional type of traffic control. 6.1.2.3.1 Assess Traffic Situation The traffic situation is assessed based on predictions or analysis of available information on: The traffic situation awareness established by the monitoring functions in 6.1.2.2. This also includes the detection of incidents and situations that may become dangerous. Expected traffic changes, and predicted development based on prognosis and empirical information Many data analysis methods may be used, and the assessment may trigger alerts. Travel times and delays can be calculated. The assessment of the traffic situation is not directly addressed by SMARTFREIGHT, but the assessment will influence on the dynamic APA policies. 6.1.2.3.2 Control Traffic Flow Based on the situation awareness established in 6.1.2.3.1, decisions about generic traffic management measures are taken. The aim is to affect the safety, the traffic flow, traffic density and environmental issues in a positive way. Different traffic management measures may be taken, for example the use of Transportation Network Equipment (see 6.1.2.3.3) to provide information or to control the behaviour of the On-board Managers, or to provide information or guidelines via other channels (e.g. media). The Traffic Manager needs to have an understanding of how On-board Managers might respond to the measures and information. Rerouting behaviour in response to traffic management measures is a highly complex field of study and far from being fully understood due to the difficulty in obtaining meaningful data for describing it. A Traffic Manager also has to consider the impact of systems providing navigation support (e.g. satellite navigation systems) might have on route choices, and, thereby, the traffic situation since these systems may be develop to provide effective dynamic rerouting information, e.g. in response to an accident. If a large proportion of the driving population are following the same routing advice provided by the satellite navigation system, then this could have a significant effect on the traffic network. The navigation support systems are not within the control of the Traffic Manager, but the individual traffic management measures described in 6.1.2.3.5 might open for new possibilities. Also, demands from transport users or authorities must be handled. This can be for example priority to or access of emergency cars. SMARTFREIGHT do not address this generic traffic flow management, but the measures taken towards individual freight vehicles (see 6.1.2.3.5). Information overload can also be
D5.2 The SMARTFREIGHT framework architecture
56
SMARTFREIGHT
avoided by means of road-side equipment (RSE). Local information can be provided to just the vehicles in the vicinity. 6.1.2.3.3 Operate Transportation Network Equipment The continuous operation of the Transportation Network Equipment (power supply, maintenance of hardware, etc.) is the responsibility of the Transportation Network Infrastructure Management domain (see 6.2.3). The use of the equipment in traffic management is however a part of this function in the Transportation Network Utilisation domain. In the SMARTFREIGHT context this functions is about the operation of the road-side equipment (RSE). The applications that are to run on the RSE and information that is to be provided to the vehicles (e.g. TNS, APA policy, transportation network information) are downloaded to the RSE to enable Monitoring of individual vehicles, e.g. their presence in Controlled Areas Data collection for statistics Provision of information about the dynamic APA policies that enables the vehicles to compute their Access and Priority Offers (APOs) Provision of information about the Transportation Network Status (TNS) Provision of other information, e.g. transportation network information such as updated maps, recommend speed or speed limits (this is not covered by SMARTFREIGHT) 6.1.2.3.4 Manage Safety Measures The detection of incidents or accidents may trigger actions that prevent or minimise the negative effects (e.g. closure of tunnels or bridges). SMARTFREIGHT does not address this issue directly, but the infrastructure–to-vehicle communication enabled by the RSE and the OBE opens for new possibilities for safety related actions towards all or specific vehicles. 6.1.2.3.5 Control Individual Vehicle In addition to the generic management of the traffic flow, vehicles are monitored and controlled in an individual manner. This is one of the core issues in the SMARTFREIGHT project. 6.1.2.3.5.1 Track Vehicle Vehicles may be tracked (see 5.3.3.1). 6.1.2.3.5.2 Manage Presence in Controlled Area Information about entries to and exits from Controlled Areas (e.g. tunnels, bus lanes or green areas) are registered to keep track of the individual vehicles in these parts of the Transportation Network. This also enables the tracking of entries to and exits from Transportation Network Resources (e.g. loading and unloading areas) and provision of such information to the Transportation Network Resource Manager (see 6.1.3). The APOs and resource bookings of the vehicles can be collected and checked as well as the safety statuses (e.g. the presence of dangerous goods) and vehicle information for statistics. The required processing of the information from the vehicles is in SMARTFREIGHT distributed to the Road Side Equipment (RSE) (see Annex E and Annex F). The entry, exit and safety status registration may be useful for purposes not addressed by SMARTFREIGHT for example emergency management (e.g. awareness about dangerous
D5.2 The SMARTFREIGHT framework architecture
57
SMARTFREIGHT
cargo inside tunnels) and transportation regulation (police may be notified in case of illegal entrance). 6.1.2.3.5.3 Manage Access and Priority Assignments The vehicles will get the dynamic APA policies (as described in 6.1.2.1), and the APOs, will be computed by the on-board equipment. The APOs define priorities, access permissions and access restrictions to Controlled Areas. This function enables exceptions from this onboard computation of the APOs. The Traffic Manager may, if politically accepted, assign APOs to vehicles on request, for example in return of a fee. The request may for example be caused by a need for goods delivery inside a Controlled Area where the vehicle does not have access according to the default APA policy. Both vehicles and Transport Operators may request APOs. These APOs will overrule the APOs that are automatically computed by the vehicles (based on the APA policy). 6.1.2.4 Manage Incident Incidents may be detected due to monitoring (see 6.1.2.2). Some incidents arise due to emergency situations. However, most incidents are normal variations that require no, or just minor, adjustments. Information about an incident is established, verified and stored. The handling may for example be done by the traffic control (see 6.1.2.3), Transportation Network maintenance (see 6.2.3), or emergency management. SMARTFREIGHT does not address incident management directly, but the On-Board Equipment opens for new possibilities, e.g. better awareness about the presence of hazardous material inside tunnels. 6.1.2.5 Provide Traffic Situation Information Verified information about the traffic situation and Transportation Network is crucial for, among others, the On-board Managers (the On-board Management domain), the backoffices managing the transport operations (the Transport Operator role in the Transport Operation Management domain). The information may be prognosis for the future as well as information based on real time observations or measurements. Thus, the information must contain meta information that reflects how the information is established (observation, measurement, calculated forecast, etc.). SMARTFREIGHT addresses to some extent the dissemination of relevant information to Transport Operators and On-board Managers. 6.1.2.5.1 Provide Incident and Accident Information Information about incidents and accidents and specific problems such as roadwork, is provided. See 12.12. 6.1.2.5.2 Provide Route and Navigation Information The On-board Managers may need route guidance to find and follow the optimal route with respect to traffic flow and safety or specific routes for freight vehicles. Based on available information and needs, route information is provided, information about expected travel times and delays included. 6.1.2.5.3 Provide Traffic Flow Information Traffic flow information (estimated travel times and delays included) is provided. See 12.12. 6.1.2.5.4 Provide Transportation Network Information
D5.2 The SMARTFREIGHT framework architecture
58
SMARTFREIGHT
Transportation Network information is provided, e.g. regulation information (speed limits, etc.), holding area information and information about planned roadwork. SMARTFREIGHT does not address how such information is to be provided. It should be integrated with the navigation systems. Holding area information should be included to support the freight vehicles. 6.1.2.5.5 Provide Transportation Network Condition Information Transportation Network condition is provided. See 12.15. 6.1.3 Manage Transportation Network Resources The use of the Transportation Network Resources is managed. uc Transportation Netw ork Resource Management
Assign Transportation Netw ork Resource
Transportation Netw ork Resource Manager, e.g. city or terminal
Manage Transportation Netw ork Resources
«include»
«include»
Monitor Transportation Netw ork Resource Usage
Figure 20 Transportation Network Resource Management decomposition SMARTFREIGHT will enable Assignment of timeslots for access to Transportation Network Resources like loading and unloading areas to facilitate deliveries More optimal utilisation of the Transportation Network Resources. Monitoring of the use of Transportation Network Resources and detection of illegal use that may support enforcement. The enforcement is however not addressed by SMARTFREIGHT. 6.1.3.1 Assign Transportation Network Resource The rules for use of Transportation Network Resources are established (e.g. first come – first served, booking of time slots, price level, fine for early arrival/late departure, etc.) as a part of the strategic planning (see 6.1.1), and if required, the resource allocation is managed according to this strategy (e.g. assignment of timeslots for use). In communication with the Transport Operator (see 5.2.1.3.4) or the Transport Operation Worker (see 5.2.2.3), Transportation Network Resources like loading bays are booked or rebooked (i.e. changed), or the bookings may be cancelled. Information about the availability of the resources may also be provided (e.g. available time slots) 6.1.3.2 Monitor Transportation Network Resource Usage The use of Transportation Network Resources is monitored based on the entry and exit information (received from 6.1.2.3.5.2). The use will be checked, and illegal use will be detected and handled according to local procedures.
D5.2 The SMARTFREIGHT framework architecture
59
SMARTFREIGHT
6.2 Transportation Network Infrastructure Management The Transportation Network Infrastructure Management domain provides functions required by those managing the physical Transportation Network infrastructure. Information about the Transportation Network infrastructure (transportation network information), Transportation Network Resources included, is managed and can be provided to those entitled to such information (see Figure 21). uc Transportation Netw ork Infrastructure Management
Plan Transportation Netw ork
«include»
Transportation Infrastructure Manager, e.g. city or road administration
Transportation Netw ork Infrastructure Management
«include»
Manage Transportation Netw ork Information
«include» Support Transportation Netw ork Continous Operation Transportation Netw ork Equipment
Figure 21: Transportation Network Infrastructure Management decomposition The area is relevant to SMARTFREIGHT due to: The planning of the physical Transportation Network infrastructure must consider the need for freight distribution. The relevant Transportation Network information must be provided to those planning and providing freight distribution services. The road-side equipment (RSE) that enables vehicle-to-infrastructure communication must be planned, installed and operated. 6.2.1 Plan Transportation Network The capacity and development of the Transportation Network and the Transportation Network Equipment must be planned. The process must also consider the need for freight distribution. Consider to reallocate road space, for example by „no-car lanes‟ to benefit all road users Provide the required number of loading bays to minimize the parking restrictions and problems for delivery vehicles Provide additional overnight parking facilities. Review loading and traffic restrictions Proposals for new premises must specify planned infrastructure for freight deliveries Existing premises without their own delivery areas should report their additional needs to the city for their consideration
D5.2 The SMARTFREIGHT framework architecture
60
SMARTFREIGHT
The placement of the RSE must be coordinated with the APA policy and the associated Controlled Areas (as planned in 6.1.1) SMARTFREIGHT does not address the Transportation Network planning directly, but the planning process should take the bullet points listed above into consideration. The RSE that enables vehicle-to-infrastructure communication must be planned. 6.2.2 Manage Transportation Network Information Information about the Transportation Network, the Transportation Network Resources included, is established, verified, updated and made available to the Traffic Manager (who may provide it to others). The establishment and provision of Transportation Network information is not an issue in SMARTFREIGHT, but the Transportation Infrastructure Manager should publicise information relevant to those planning and providing freight distribution services so that this information can be available to the Transport Supply domain. 6.2.3 Support Transportation Network Continuous Operation The Transportation Network is maintained and operated, and information about the dynamic Transportation Network Status (TNS) is provided to the Traffic Manager (who may provide it to others). This continuous operation of the Transportation Network Equipment, the RSE included, is also handled. The traffic management measures provided by the RSE is however controlled and initiated by the traffic management part of the Transportation Network Utilisation domain (see 6.1.2.3.3). SMARTFREIGT does not address the continuous operation of the Transportation Network Equipment in general. Road-side equipment (RSE) is however crucial to the SMARFREIGHT solution. It must be configured to operate according to decisions taken by the Traffic Manager. Application and information (e.g. the current APA policy) must for example be downloaded to the RSE. 6.3 Emergency Management Emergency preparedness and the handling of emergency situations are managed. SMARTFREIGHT does not address the emergency issues, but the SMARTFREIGHT solutions may establish information and awareness that can support the emergency handling.
D5.2 The SMARTFREIGHT framework architecture
61
SMARTFREIGHT
7 Functional view – Transport Sector Support The Transport Sector Support domain provides generic services required by several part of the transport sector. In SMARTFREIGHT the focus is on generic functions and services for item monitoring and tracking. These items may be Transport Items, Load Items, vehicles, etc. In SMARTFREIGHT, however, the focus is on the Load Items and vehicles. The Load Items are monitored by the On-Goods Equipment (OGE), and the vehicles are tracked by the Onboard Equipment (OBE). Several roles and domains in the Reference Model may need such services, e.g. The Transport User in the Transport Demand domain may want to monitor/track Transport Items The Transport Service Provider (which is decomposed into the Transport Service Manager, the Transport Operator and the Transport Operation Worker roles) in the Transport Supply domain may want to monitor/track vehicles, Load Items, loading areas in vehicles, etc. The relevant operations taken in the Transport Sector Support domain are shown in Figure 22. uc Transport Sector Support
Transport Sector Support
Monitor Item Condition
On-Goods Equipment (OGE)
Monitor Temperature
«include» «include» Track and Report Item Position
Realises
Monitor and Report on Item On Item Equipment
«include»
«include»
Monitor Humidity
«include» «include» «include» Track and Report Item Handling
Monitor Shock
«include»
«include»
Manage and Report Item Condition and Dev iations
Monitor Security Issues
Manage and Report Item Information On-Load Item Equipment
On-Transport Item Equipment
Figure 22: Transport Sector Support decomposition 7.1 Monitor and Report on Item Provides monitoring and reporting services related to an Item, e.g. a goods item, a load unit or a loading area. The Item Status is reported.
D5.2 The SMARTFREIGHT framework architecture
62
SMARTFREIGHT
7.1.1 Monitor Item Condition The state of the Item is monitored and registered. 7.1.1.1 Monitor Temperature The temperature of the Item is monitored and registered. 7.1.1.2 Monitor Humidity The humidity of the Item is monitored and registered. 7.1.1.3 Monitor Shock Shocks inflicted to the Item are monitored and registered. 7.1.1.4 Monitor Security Issues Possible security violations are detected and reported. This is not addressed by SMARTFREIGHT, but the On-Board Equipment and On-Goods Equipment may also be used for security monitoring. 7.1.2 Track and Report Item Position The position of an item is tracked and reported. Tracking at pre-defined intervals and on request may be provided. Tracking at checkpoints may be supported by Item Scanning Equipment. 7.1.3 Track and Report Item Handling The handling actions (loading, unloading, delivery, etc.) are tracked and reported as Item status. This may be done automatically by means of Item Scanning Equipment. 7.1.4 Manage and Report Item Condition and Deviations The monitoring done in 7.1.1 provides information about the condition of the item. Deviations with respect to threshold values are detected, and deviations and conditions are reported as an Item status. 7.1.5 Manage and Report Item Information Information about the item (content, weight, volume, etc.) is reported according to predefined schemes.
D5.2 The SMARTFREIGHT framework architecture
63
SMARTFREIGHT
8 Process view In this chapter the use cases from the functional views are taken as activities, and they are put together to processes where information is exchanged. The processes are described at a high level to enable generalization and independency from real-life procedures, which may be executed in several ways. The main intention has been to identify, verify and describe the required information flows. The processes are illustrated in UML activity diagrams in swim lanes. Each swim lane represents a role. The activities are represented by the rounded rectangles, and they are described by the corresponding use cases in Chapter 4, 5, 6 and 7 (the activities and the use cases are named equally). The activities of direct relevance to SMARTFREIGHT are green (or grey if not printed in colours). The arrows between the activities within one swim lane represent the control flows between the tasks and show the sequence in which the activities are executed. The dotted arrows between the activities in different swim lanes are information flows. SMARTFREIGHT addresses the bold information flows. They are summarized in section 8.6. It is important to notice that o
There is no depiction of the information flows within one single swim lane (between the activities belonging to one role). Just the information flows to and from other roles (i.e. other swim lanes) are depicted;
o
It is assumed that all information received by one activity is available to the other activities of the role, i.e. all activities within the same swim lane. This includes information established at process initiation as well as updates to this information and new information established throughout the process.
Additional notations are used to express the details regarding the process execution and control flow, e.g. conditional executions and time dependencies. o
Processes are split into parallel branches by means of the fork symbol (line with one control flow in and more than one out);
o
Parallel executions are synchronized by means of the join symbol (line with more than one control flow in and equal or less control flows out);
o
Decisions are depicted by the diamond symbol.
The processes are described on a high level to enable generalization and independency from local procedures. The overall process diagram is depicted in Figure 23, and the activities marked with ∞ are further decomposed into sub-processes.
D5.2 The SMARTFREIGHT framework architecture
64
SMARTFREIGHT
act Ov erallProcess Transportation Network On-board Management Transportation Network Utilisation Infrastructure Management Traffic and Transportation Planner Transportation Netw ork Resource Manager Transportation Netw ork Infrastructure Manager
Traffic Manager
Transport Operation Management Transport Operation Worker (and Woker's Equipment)
Transport Serv ice Manager Transport User
Transport Operator Prov ide Transport Serv ice
APA policy
Plan Transportation Infrastructure Utilisation
Manage Transport Operation
APA policy
Transportation network info Manage Transportation Netw ork Information
APA policy
Perform Operational Traffic Management
Support Transportation Netw ork Continuos Operation
Entry notification, Exit notification
Resource allocation Resource allocation
Manage Vehicle and Transport Operation Information
Transport operation info, Item info Tracking, Transport problem
Notification (of illegal behaviour) APA policy, APO TNS Applications, APA policy, TNS, Transportation network info Applications
Tracking, Safety status Entry notification, Exit notification, Vehicle info
Execute Transport Item info, Item Operation tracking, Item Item info Monitor and status Report on Item
Manage En-Route Reporting
TOP TOS, Transport problem
APO
Tracking, TNS
Route, Transportation network info, TNS Route, Transportation network info, TNS, Notification
Operate Vehicle Vehicle status Route, Transportation network info, TNS
Figure 23: Overall process view
D5.2 The SMARTFREIGHT framework architecture65
Plan and Prepare Transport
TEP
Manage Transport TES
APO
Manage Transportation Netw ork Resources
TEP
TES
APA policy
Transportation network info
Transport Demand
On-board Manager (and Driv er's Equipment) On-Item Equipment
Plan Transportation Netw ork
Transport Service Management
SMARTFREIGHT
8.1 Processes in the Transportation Network Utilisation domain The Traffic Manger and Transportation Network Resource Manager swim-lanes in Figure 23 are further described. 8.1.1 Perform Operational Traffic Management act Perform Operational Traffic Management
Managed according to traffic management policy from the Traffic and Transportation Planner and current and foresenn traffic situation
Perform Operational Traffic Management Traffic Manager Transportation Netw ork Infrastructure Manager
Transport Operator ActivityInitial
Traffic and Transportation Planner
Plan Transportation Infrastructure Utilisation
On-board Manager (and Driv er's Equipment)
Route, TNS, Transportation network info
Prov ide Traffic Situation Information
APA policy «flow»
Operate Vehicle
«flow» Route, TNS, Transportation network info «flow»
Manage Transportation Netw ork Information
Perform Dynamic Traffic Management Planning
Transportation network info Monitor Traffic Situation
«flow»
APA policy «flow»
Manage Transport Operation
TNS Support Transportation Netw ork Continuos Operation
Notification «flow»
APA policy «flow» Manage Incident
Applications, APA policy, TNS, Transportation network info
Manage Vehicle and Transport Operation Information
APO «flow»
Perform Traffic Control APO «flow» Tracking, Safety status «flow»
Transportation Netw ork Resource Manager
Entry notification, Exit notification, Vehicle info Manage Transportation Netw ork Resources
Entry notification, Exit notification
Manage En-Route Reporting
«flow»
Notification of illegal behaviour «flow» Notification of illegal behaviour «flow»
Transportation Regulation
ActivityFinal
Figure 24: Perform Operational Traffic Management Figure 24 provides an overall view upon the traffic management process as seen from the Traffic Manager‟s point of view: The traffic is managed based on, among others, o
Information about the Transportation Network and the Transportation Network Status (TNS) from the Transportation Infrastructure Manager
o
The default APA policy defined by the Traffic and Transportation Planner
D5.2 The SMARTFREIGHT framework architecture
66
SMARTFREIGHT
The Transport Operator and the On-board Manager is provided with information that supports the planning and execution of transport operations such as o
APO policies
o
Route information
o
Transportation network information and Transportation Network Status (TNS).
The Transport Operator and the On-board Manager may request Access and Priority Offers (APOs). The Transportation Infrastructure Manager is provided with information that is to be provisioned to the RSE (the Transportation Infrastructure Manager is responsible for the continues operation of the RSE) such as o
Applications that are to be provisioned
o
Information that is to be used by these applications, such as APA policies, Transportation Network information and the Transportation Network Status (TNS)
The On-board Manager (i.e. the vehicle) will provide information as the vehicle is moving around. Depending on the requirements to that particular vehicle, information is provided: o
Entry and Exit notification on entrance to and exit from Controlled Areas
o
Safety status (e.g. dangerous goods status) decisive for access to such areas.
o
Vehicle information that can be used in statistics and Tracking information.
The Transportation Network Resource Manager may get Entry and Exit notification on entrance to and exit from Transportation Network Resources and may respond with a notification in case of illegal use of resources. In case of illegal behaviour or if other messages have to be provided to the On-board Manager (e.g. access postponed to tunnels, access granted, etc.), the On-board Manager is notified. Notifications on illegal behaviour may also be sent to Transportation Regulation. 8.1.1.1 Monitor Traffic Situation act Monitor Traffic Situation Monitor Traffic Situation Transportation Netw ork Infrastructure Manager
Traffic Manager
ActivityInitial Manage Transportation Netw ork Information
Transportation network info «flow»
Monitor Transportation Netw ork
TNS «flow» Support Transportation Netw ork Continuos Operation
TNS
Monitor Env ironmental Condition
Monitor Traffic Flow
Monitor Hazardous Goods
«flow»
Figure 25: Monitor Transportation Network Status
D5.2 The SMARTFREIGHT framework architecture
67
SMARTFREIGHT
The traffic situation is monitored based on Transportation Network Information and Transportation Network Status (TNS) from the Transportation Infrastructure Manager and monitoring of the traffic flow, as in traditional traffic management systems. The Monitor Hazardous Goods activity will use make use of the information about the individual vehicle and their presence in Controlled Areas that is established by the Perform Traffic Control activity – see 8.1.1.3. 8.1.1.2 Provide Traffic Situation Information act Prov ide Traffic Situation Information Provide Traffic Situation Information Traffic Manager
Transport Operator On-board Manager (and Driv er's Equipment)
Prov ide Incident and Accident Information
Manage Transport Operation
TNS «flow»
Prov ide Traffic Flow Information
«flow» «flow» TNS
Prov ide Transportation Netw ork Information
Prov ide Transportation Netw ork Condition Information
Transportation network info
TNS
«flow»
«flow»
«flow»
«flow» «flow»
Route Prov ide Route and Nav igation Information
«flow»
Operate Vehicle
«flow»
Figure 26: Provide Traffic Situation Information The Transport Operator and the On-board Manager get access to information services providing up to date information about: Transportation network information Transportation Network Status (TNS). Route information
D5.2 The SMARTFREIGHT framework architecture
68
SMARTFREIGHT
8.1.1.3 Perform Traffic Control act Perform Traffic Control Perform Traffic Control Transportation Netw ork Infrastructure Manager
Traffic Manager
On-board Manager (and Driv er's Equipment)
Traffic situation information available
Situation awareness is established at the start of this process (by the Monitor Traffic fuction), and the awareness is continiously updated during the process.
Support Transportation Netw ork Continuos Operation
Assess Traffic Situation
Applications, Transportation network info «flow» «flow»
Transportation Netw ork Resource Manager
Transport Operator
Manage Vehicle and Transport Operation Information
Act depending on the situation
Operate Transportation Netw ork Equipment
APO «flow» Control Indiv idual Vehicle
APA policy, TNS
Control Traffic Flow
Manage Safety Measures
Manage Transport Operation
APO «flow» Entry notification, Exit notification, Vehicle info «flow»
Manage En-Route Reporting
Tracking, Safety status «flow»
Transportation Regulation
Notification (of illegal behaviour) «flow»
Entry notification, Notification Exit notification «flow» Notification «flow» (of illegal behaviour) «flow»
ActivityFinal
Operate Vehicle
Manage Transportation Netw ork Resources
Figure 27: Perform Traffic Control Traffic flow and safety measures are managed, and the individual vehicles are controlled. The Transport Operator and the On-board Manager may on request get APOs. The On-board Manager (i.e. vehicle) will provide information according to requirements: o
Entry and Exit notification on entrance to and exit from Controlled Areas and Safety status (e.g. information about dangerous goods).
o
Vehicle information that can be used in statistics and Tracking information.
The Transportation Network Resource Manager may get Entry and Exit notification on entrance to and exit from Transportation Network Resources and may respond with a notification in case of illegal use of resources. Notifications are provided to the On-board Manager on illegal behaviour, access postponed to tunnels, access granted, etc. Notifications may also be sent to Transportation Regulation. The Transportation Infrastructure Manager is provided with input to the Transportation Network Equipment, i.e. the RSE, such as applications that are to be provisioned and information that is to be used by these applications (APA policies, Transportation Network information and TNS, etc.) 8.1.1.3.1 Control Individual Vehicle
D5.2 The SMARTFREIGHT framework architecture
69
SMARTFREIGHT
act Control Indiv idual Vehicle Control Individual Vehicle On-board Manager (and Driv er's Equipment)
Traffic Manager
Transportation Netw ork Resource Manager
Manage Vehicle and Transport Operation Information
APO
Manage Access and Priority Assignments
«flow»
Manage En-Route Reporting
Transport Operator
The traffic situation is known when this prosess starts (situation awareness is established by the Monitor Traffic and Infrastructure Condition process).
Entry notification, Exit notification «flow» Safety status
Manage Transport Operation
APO «flow»
Entry notification, If Transportation Manage Exit notification Network Section Presence in is a Resource Controlled Area «flow»
«flow» Vehicle info
Manage Transportation Netw ork Notification Resources of illegal behaviour
«flow» Track Vehicle
«flow»
Tracking «flow»
Notification «flow»
ActivityFinal
Operate Vehicle
Notification (of illegal behaviour) «flow»
Transportation Regulation
Figure 28: Control Individual Vehicle The individual vehicles are controlled. The Transport Operator and the On-board Manager may on request get APOs. The On-board Manager (i.e. vehicle) will provide information according to requirements: o
Entry and Exit notification on entrance to and exit from Controlled Areas and Safety status (e.g. information about dangerous goods).
o
Vehicle information that can be used in statistics and Tracking information.
The Transportation Network Resource Manager may get Entry and Exit notification on entrance to and exit from Transportation Network Resources and may respond with notifications in case of illegal use of resources. Notifications are provided to the On-board Manager on illegal behaviour, access postponed to tunnels, access granted, etc. Notifications may also be sent to Transportation Regulation.
D5.2 The SMARTFREIGHT framework architecture
70
SMARTFREIGHT
8.1.2 Mange Transportation Network Resources act Manage Transport Netw ork Resources Manage Transportation Network Resources Transportation Netw ork Resource Manager Traffic Manager
ActivityInitial Assign Transportation Netw ork Resource
Transport Operation Worker (and Woker's Equipment) Transport Operation Manager
Resource allocation «flow»
Plan and Prepare Transport Operation
Resource allocation «flow» Entry notification, Exit notification Perform Traffic Control
«flow» «flow» Notification (of illegal behaviour)
Execute Transport Operation
Monitor Transportation Netw ork Resource Usage
ActivityFinal
Figure 29: Manage Transportation Network Resource The Transportation Network Resources are booked by the Transport Operator and/or the Transport Operation Worker. When the vehicle enters or exits the resource, entry and exit notifications are received from the Traffic Manager, and illegal use of resources can be detected.
D5.2 The SMARTFREIGHT framework architecture
71
SMARTFREIGHT
8.2 Processes in the Transport Service Management domain The Transport Service Manager swim-lane in Figure 23 is further described. 8.2.1 Provide Transport Service act Prov ide Transport Serv ice Provide Transport Service Transport Operation Manager Traffic and Transportation Planner
Transport Serv ice Manager
Transport User Plan and Prepare Transport
Manage Transport Operation
ActivityInitial
TEP Manage Transport
«flow»
TEP
Manage Customer Relations
«flow» TES «flow»
TES «flow»
Adapts to strategy
Manage Strategical and Tactical Transport Serv ice Planning
APA policy «flow»
Plan Transportation Infrastructure Utilisation
Figure 30: Provide Transport Service 8.3 Processes in the Transport Operation Management domain The Transport Operator and Transport Operation Worker swim-lanes in Figure 23 are further described.
D5.2 The SMARTFREIGHT framework architecture
72
SMARTFREIGHT
8.3.1 Manage Transport Operation act Manage Transport Operation
Traffic Manager
Manage Transport Operation
Transport Serv ice Manager
Transportation Netw ork Resource Manager
Transport Operation Manager
Plan Transportation Infrastructure Utilisation
APA policy «flow»
Route, TNS «flow» Transportation network info
TOP
Plan and Prepare Transport Operation Manage Transport Operation Information
«flow» Resource allocation
Monitor Transport Operation
TOS
«flow» Driv er (and Driv er's Equipment) Tracking «flow»
«flow» TNS Prov ide Transport Serv ice
Execute Transport Operation
«flow»
«flow» APA policy
Manage Transportation Netw ork Resources
Transport Operation Worker (and Woker's Equipment)
ActivityInitial
Including the re-planning of ongoing operations, e.g. due to deviations or the possible back-load. The plans will be used by the control and monitoring functions.
Perform Operational Traffic Management
Traffic and Transportation Planner
Manage En-Route Reporting
«flow» «flow»
TNS
TEP «flow»
Control Transport Operation
Transport problem «flow»
Route, TNS
TES «flow»
«flow» Transportation network info
APO
Manage Transport Business
«flow»
«flow» Vehicle status «flow» APO «flow»
Yes Replanning required?
Operate Vehicle
No
Transport operation info, Item info «flow»
Manage Vehicle and Transport Operation Information
ActivityFinal
Figure 31: Manage Transport Operation The transport Operation is managed by the Transport Operator: The Transport Operation Plan (TOP) is prepared (or re-planned) and provided to the Transport Operation Worker based on o
TEPs from the Transport Service Manager. They defines the transport demands
o
Transportation Network information, TNS and routes and received from the Traffic Manager
o
Default APA policies received form the Traffic and Transportation Planner or dynamic APA policies received from the Traffic Manager
o
The bookings of Transportation Network Resources
o
TNS reported by the vehicles
The ongoing transport operation is monitored based on tracking information from the On-board Manager (i.e. vehicle) and Transport Operation Status (TOS) from the Transport Operation Worker. Transport operations are controlled based on updated information about o
APOs received on request from the Traffic Manager
o
TNS reported by the vehicles
D5.2 The SMARTFREIGHT framework architecture
73
SMARTFREIGHT
o
Transport problems related to the transport operations
Relevant route information, Transportation Network information, TNS and APOs are provided to the On-board Manager to support the vehicle operation. 8.3.1.1 Plan and Prepare Transport Operation act Plan and Prepare Transport Operation Plan and Prepare Transport Operation Traffic and Transportation Planner
Transport Operation Manager Transport Serv ice Manager Transport Operation Worker (and Woker's Equipment)
Traffic Manager
Driv er (and Driv er's Equipment)
ActivityInitial
Plan Transportation Infrastructure Utilisation
Adapt to Traffic Management Policy
APA policy «flow» Perform Operational Traffic Management
The available resources that can be used in the operation (vehicle, drivers, etc.) are known.
Route Plan Transport Operation
«flow»
Prov ide Transport Serv ice
TEP «flow»
Transportation network info «flow» APA policy
Transportation Netw ork Resource Manager
«flow»
Define Dev iation Handling
TNS
Assign Transportation Netw ork Resource
Resource allocation
Prepare Use of Transport Netw ork Resources and Serv ices
«flow»
Manage Performance
TNS
«flow»
«flow»
Manage En-Route Reporting
Performance OK? Yes Prov ide No Transport Operation Information
TOP
Execute Transport Operation
«flow»
ActivityFinal
Figure 32: Plan and Prepare Transport Operation The Transport Operation Plan (TOP) is prepared (or re-planned) and provided to the Transport Operation Worker based on TEPs from the Transport Service Manager. They defines the transport demands Transportation Network information, TNS and routes and received from the Traffic Manager Default APA policies received form the Traffic and Transportation Planner or dynamic APA policies received from the Traffic Manager The bookings of Transportation Network Resources TNS reported by the vehicles
D5.2 The SMARTFREIGHT framework architecture
74
SMARTFREIGHT
8.3.1.2 Monitor Transport Operation act Monitor Transport Operation Monitor Transport Operation Transport Operation Manager
Transport Operation Worker (and Woker's Equipment) Driv er (and Driv er's Equipment)
ActivityInitial
Manage En-Route Reporting
Tracking
Track Vehicle
«flow» Track Load Item
Monitor Load Item
TOS Record Transport Operation Progress
«flow»
TOS «flow»
TOS «flow»
Report on Transport Operation
Ev aluate Schedule and Dev iation
FlowFinal
Figure 33: Monitor Transport Operation Transport operations are monitored based on tracking information and information about the Transport Operation Status (TOS).
D5.2 The SMARTFREIGHT framework architecture
75
SMARTFREIGHT
8.3.1.3 Control Transport Operation act Control Transport Operation Control Transport Operation Driv er (and Driv er's Equipment)
Transport Operation Manager
Traffic Manager
Manage Vehicle and Transport Operation Information
If this is OK according to policy
Control Indiv idual Vehicle
ActivityInitial APOs OK?
APO «flow»
No Request Traffic Management Measure
APO «flow»
Transport Operation Worker (and Woker's Equipment) Yes
Provide route guidance? Not required
Execute Transport Operation Yes
Route, TNS Operate Vehicle
«flow» Transportation network info
Prov ide Route Guidance Transport problem
«flow»
«flow» Transport Serv ice Manager
Manage En-Route Reporting
Handle Transport Problems
TNS «flow»
Manage Schedule and Dev iation
TES «flow»
Prov ide Transport Serv ice
No Operation finished?
Depending on thye current plan, the detected transport problems and deviations detected by the monitoring function.
Yes ActivityFinal
Figure 34: Control Transport Operation Transport operations are controlled based on updated information about APOs received on request from the Traffic Manager TNS reported by the vehicles Transport problems related to the transport operations Relevant route information, Transportation Network information, TNS and APOs are provided to the On-board Manager to support the vehicle operation.
D5.2 The SMARTFREIGHT framework architecture
76
SMARTFREIGHT
8.3.2 Execute Transport Operation act Execute Transport Operation Execute Transport Operation Transportation Netw ork Resource Manager
Transport Operation Worker (and Woker's Equipment)
Driv er (and Driv er's Equipment)
On-Item Equipment Transport Operation Manager
ActivityInitial
Manage and Report Item Information Item info «flow»
Manage Transportation Netw ork Resources Resource allocation «flow»
Item tracking «flow»
Manage Transport Operation Information and Progress
Manage Transport Netw ork Resource Bookings
Manage Transport Operation
TOP «flow»
Item status Manage Vehicle and Transport Operation Information
Track and Report Item Position
Transport operation info, Item Info «flow»
«flow»
Track and Report Item Handling
Item status Monitor and Report on Item
Tracking «flow»
Support Transport Task Execution
Report on Transport Operation
TOS, Transport problem
Transport problem Manage En-Route Reporting
«flow»
ActivityFinal
Figure 35: Execute Transport Operation The transport operation is executed by the Transport Operation Worker. The progress is managed based on The TOP received from the Transport Operator Item information, Item tracking and Item status received from the Load Item (represented by the On-Item Equipment). Tracking information from the vehicle Transport operation information and Load Item information are provided to the On-board Manager to support the driving operation, and if required, Transportation Network Resources are booked. During the operation execution Transport problems may be detected by the On-board Manager. These and Transport Operation Status (TOS) are reported to the Transport Operator It is important to bear in mind that the process and activities may be more or less automated. The progress monitoring and status reporting may for example be carried out automatically.
D5.2 The SMARTFREIGHT framework architecture
77
SMARTFREIGHT
8.4 Processes in the On-board Management domain The On-board Manager (and Driver‟s Equipment) swim-lane in Figure 23 is further described. 8.4.1 Manage Vehicle and Transport Operation Information act Manage Vehicle and Transport Operation Information Manage Vehicle and Transport Operation Information Driv er (and Driv er's Equipment) Traffic Manager
Process Access and Priority Offers Perform Operational Traffic Management
On-Item Equipment Transport Operation Worker (and Woker's Equipment)
Start of leg
Manage Transport Operation Information
Execute Transport Operation Transport operation info, Item info «flow»
APA policy «flow»
Item Info «flow»
APO
Manage Certificates
Manage and Report Item Information
Transport Operation Manager
«flow» APO Manage Route Plan
«flow»
Control Transport Operation
Manage Fee Payment
Figure 36: Manage Vehicle Information Information about the vehicle and transport operation is established based on the transport operation information and Item information (about the Load Items) from the Transport Operation Worker. Item information may also be provided directly from the Load Items. The dynamic APA policies are received from the Traffic Manager. They are processed, and the APOs of the vehicle are established. APOS may also be requested from the Traffic Manager, or they may be provided by the Transport Operator.
D5.2 The SMARTFREIGHT framework architecture
78
SMARTFREIGHT
8.4.2 Operate Vehicle act Operate Vehicle Operate Vehicle
Driv er (and Driv er's Equipment)
Transportation Infrastructure Manager Traffic Manager
The vehicle's APOs, transport operation information (e.g. route plan), Transportation Network Status (TNS), etc. are available to the Operate Vehicle process.
Perform Operational Traffic Management
Transport Operation Manager
ActivityInitial
Support and Control Vehicle Operation
Route, TNS «flow»
Route, TNS
Manage Transport Operation
«flow»
Transportation network info «flow»
Transportation network info «trace»
Notification «flow» Support Transportation Netw ork Continuos Operation
Applications
Manage Applications
Monitor Vehicle
«flow» Vehicle status «flow»
ActivityFinal
Figure 37: Operate Vehicle Information about the transport operation (destinations, time schedule, etc.) and APOs are assumed to be available for this process. The vehicle is operated according Updated routes information, Transportation Network information and TNS from the Traffic Manager or the Transport Operator and Notifications received from the Traffic Manager. The status of the vehicle may be provided to the Transport Operator. Applications may be provisioned on the Driver's Equipment.
D5.2 The SMARTFREIGHT framework architecture
79
SMARTFREIGHT
8.4.2.1 Monitor Vehicle act Monitor Vehicle Monitor Vehicle
Driv er (and Driv er's Equipment) Transport Operation Manager
ActivityInitial
Monitor Vehicle Status
Vehicle status «flow»
Manage Transport Operation
Register Vehicle Tracking Information
(from Transport Service Management)
ActivityFinal
Figure 38: Monitor Vehicle The vehicle monitoring process may provide vehicle status information to the Transport Operator.
D5.2 The SMARTFREIGHT framework architecture
80
SMARTFREIGHT
8.4.2.2 Support and Control Vehicle Operation act Support and Control Vehicle Operation Support and Control Vehicle Operation
Traffic Manager
Driv er (and Driv er's Equipment) The vehicle's APOs, transport operation information (e.g. route plan), Transportation Network Status (TNS), etc. are available to the Operate Vehicle process.
Perform Operational Traffic Management
Notification
Prov ide Automated Driv ing Support
Support Nav igation
«flow»
Transport Operation Manager
ActivityInitial
Manage Route
Input from misc. sources
Route, TNS «flow» Transportation network info
Use Information Serv ices
«flow»
Route, TNS «flow» Transportation network info
Manage Transport Operation
«flow»
ActivityFinal
Figure 39: Support and Control Vehicle Operation The vehicle operation is controlled and supported through: Transportation Network information, route information and TNS received from the Traffic Manager or the Transport Operator. Notification (e.g. information about illegal behaviour or instructions) received from the Traffic Manager.
D5.2 The SMARTFREIGHT framework architecture
81
SMARTFREIGHT
8.4.3 Manage En-route Reporting act Manage En-route Reporting Transport Operation Worker (and Woker's Equipment) Manage En-route Reporting Driv er (and Driv er's Equipment)
Traffic Manager
Perform Operational Traffic Management
ActivityInitial
Transport Operation Manager
A substitute to Load Item tracking (when the Load Item is onboard) Tracking
Execute Transport Operation
«flow» Tracking
Tracking
Report Vehicle «flow» Tracking Information
Monitor Transport Operation
«flow» Report Vehicle Access Information
Entry notification, Exit notification, «flow» Vehicle info
Report Vehicle Safety Related Information
Safety status «flow» Support Traffic Situation Reporting
Manage Transport Operation TNS «flow»
Support Transport Problem Reporting
Transport problem «flow»
Figure 40: Manage En-route Reporting The vehicle may report: Tracking information to both the Traffic Manager, Transport Operator and the Transport Operation Worker Entry and exit notifications on entries to and exits from Controlled Areas Vehicle information (i.e. input to statistics) Safety status information (e.g. fuel status, engine problems, etc.) to the Traffic Manager. TNS information to the Transport Operator Information about Transport problems to the Transport Operator
D5.2 The SMARTFREIGHT framework architecture
82
SMARTFREIGHT
8.5
Processes in the Transport Sector Support domain
act Monitor and Report on Item Monitor and Report on Item Driv er (and Driv er's Equipment)
On-Item Equipment
ActivityInitial
The On-item Equipment may also report to the Transport User. This is however not included in this diagram as it is outside the scope of SMARTFREIGHT.
Monitor Item Condition
Manage and Report Item Condition and Dev iations
Manage Vehicle and Transport Operation Information
Transport Operation Worker (and Woker's Equipment)
Track and Report Item Position Track and Report Item Handling
Item tracking «flow» Item status «flow» Item status
Item info «flow»
«flow» Item info
Manage and Report Item Information
«flow»
Execute Transport Operation
ActivityFinal
Figure 41: Monitor and Report on Item The On-Item Equipment provides generic functions that may be used for many purposes; among others the monitoring required by the On-board Manager and the Transport Operation Worker. Item information (e.g. information about Load Items), Item status information (e.g. information about temperature and deviations) and Item tracking information (i.e. location) may be provided. 8.6 Information flows The table below provide an overview over the information flows in the activity diagrams in the sections above. All information flows are listed, but those that are not directly relevant to the SMARTFREIGHT solutions are in grey rows. The columns provide the following information: Name of information flow, as used in the activity diagrams Source and destination domains and activities. The domain names (i.e. the domain in the Reference Model) are printed in bold. An information flow may be realised by means of many interactions in either directions, e.g. service advertisements followed by a request and a response interaction. The sources and the destinations in this table are however those that
D5.2 The SMARTFREIGHT framework architecture
83
SMARTFREIGHT
provides and receives the core information content, e.g. the source and destination of the response interaction. Comments Table 10 Information flows with source, destination and linkage to information view INFOFLOWS
SOURCE DOMAIN/ ACTIVITY
DESTINATION DOMAIN/ACTIVITY
Adapts to strategy
Transport Service Management. Transportation Network Utilisation Provide Transport Service.
Comments Not further described. Just a dependency.
APA policy Transportation Network Utilisation. Perform Operational Traffic Management. Perform Dynamic Traffic Management Planning.
On-board Management. Manage Vehicle and Transport Operation Information. Process Access and Priority Offers
APA policy Transportation Network Utilisation. Perform Operational Traffic Management. Perform Dynamic Traffic Management Planning.
Transport Operation Management. Consider current and Manage Transport Operation. Plan foreseen dynamic APA and Prepare Transport Operation. policies during planning Plan Transport Operation.
APA policy Transportation Network Utilisation. Plan Transportation Network Utilisation.
Transport Operation Management. Consider default APA policy Manage Transport Operation. Plan during planning and Prepare Transport Operation. Adapt to Traffic Management Policy
APA policy to the driver
Transportation Network APA policy Transportation Network Utilisation. Perform Operational Infrastructure Management. Traffic Management. Perform Support Transportation Network Traffic Control. Operate Continuous Operation. Transportation Network Equipment
Download new APA policy to RSE for distributed interaction with vehicles.
APA policy Transportation Network Utilisation. Plan Transportation Network Utilisation.
Transport Service Management. Provide Transport Service. Manage Strategical and Tactical Transport Service Planning
Outside the scope of SMARTFREIGHT.
APA policy Transportation Network Utilisation. Plan Transportation Network Utilisation.
Transportation Network Utilisation. Internal information Perform Operational Traffic exchange within the traffic Management. Perform Dynamic management organisation. Traffic Management Planning
APO
Transport Operation On-board Management. Manage Management. Manage Transport Vehicle and Transport Operation Operation. Control Transport Information. Manage Certificates Operation. Request Traffic Management Measure
Transport Operator provides APO to the driver
APO
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Access and Priority Assignments
Provision of APO after request from the driver
On-board Management. Manage Vehicle and Transport Operation Information. Manage Certificates
D5.2 The SMARTFREIGHT framework architecture
84
SMARTFREIGHT
APO
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Access and Priority Assignments
Applications
Transportation Network Transportation Network Utilisation. Perform Operational Infrastructure Management. Traffic Management. Perform Support Transportation Network Traffic Control. Operate Continuous Operation. Transportation Network Equipment
Outside the scope of SMARTFREIGHT (covered by CVIS).
Transportation Network Infrastructure Management. Support Transportation Network Continuous Operation.
Outside the scope of SMARTFREIGHT (covered by CVIS).
Applications
Transport Operation Management. Provision of APO after Manage Transport Operation. Control request from the Transport Transport Operation. Request Traffic Operator Management Measure
On-board Management. Operate Vehicle. Manage Applications
Applications are uploaded from Host Management Centre to RSE.
Advertisement from RSE, which provides an URL for download. Download to OBE from Host Management Centre.
On-board Management. Manage Entry notification En-Route Reporting. Report Vehicle Access Information Exit notification
Transportation Network Utilisation. Vehicle reports entry to / Perform Operational Traffic exit from Controlled Area Management. Perform Traffic Control. Control Individual Vehicle. Manage Presence in Controlled Area.
Transportation Network Entry notification Utilisation. Perform Operational Traffic Management. Perform Exit Traffic Control. Control Individual notification Vehicle. Manage Presence in Controlled Area
Transportation Network Utilisation. Internal information Manage Transportation Network exchange within the traffic Resources. Monitor Transportation management organisation. Network Resource Usage
Item Info
Transport Sector Support. Monitor and Report Item. Monitor and Report on Item. Manage and Report Item Information.
On-board Management. Manage Vehicle and Transport Operation Information. Manage Transport Operation Information
Item info
Transport Sector Support. Monitor and Report Item. Monitor and Report on Item. Manage and Report Item Information.
Transport Operation Management. Load Item reports Execute Transport Operation. information about itself to Manage Transport Operation the transport worker. Information and Progress
Item info
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress
On-board Management. Manage Vehicle and Transport Operation Information. Manage Transport Operation Information.
Not relevant – internal data exchange within OBE
Item status Transport Sector Support. Monitor and Report Item. Manage and Report Item Condition and Deviations.
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress
Load Item reports about item condition and deviations to the transport worker.
Item status Transport Sector Support. Monitor and Report Item. Track and Report Item Handling.
Transport Operation Management. Load Item reports handling Execute Transport Operation. information to the transport Manage Transport Operation worker. Information and Progress
D5.2 The SMARTFREIGHT framework architecture
Load Item reports information about itself to the vehicle.
85
SMARTFREIGHT
Item tracking
Transport Sector Support. Monitor and Report Item. Track and Report Item Position.
Notification Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Presence in Controlled Area
Transport Operation Management. Load Item reports tracking Execute Transport Operation. information to the transport Manage Transport Operation worker. Information and Progress. On-board Management. Operate Traffic management Vehicle. Support and Control Vehicle notifications are provided to Operation. Support Navigation the driver.
Transportation Network Utilisation. Internal information Notification Transportation Network Utilisation. Manage (of illegal Perform Operational Traffic exchange within the traffic behaviour) Transportation Network Management. Perform Traffic Control. management organisation. Resources. Monitor Transportation Control Individual Vehicle. Manage Network Resource Usage Presence in Controlled Area Notification Transportation Network Utilisation. Perform Operational (of illegal behaviour) Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Presence in Controlled Area.
Transportation Regulation
Outside the scope of SMARTFREIGHT
Driver (with the transport operation worker role) books transportation network resources
Resource allocation
Transportation Network Utilisation. Manage Transportation Network Resources. Assign Transportation Network Resource.
Transport Operation Management. Execute Transport Operation. Manage Transport Network Resource Bookings.
Resource allocation
Transportation Network Utilisation. Manage Transportation Network Resources. Assign Transportation Network Resource.
Transport Operation Management. Transport operator books Manage Transport Operation. Plan transportation network and Prepare Transport Operation. resources Prepare Use of Transport Network Resources and Services
Route
Transport Operation On-board Management. Operate Transport operator provides Management. Manage Transport Vehicle. Support and Control Vehicle route information to the Operation. Control Transport Operation. Use Information Services driver Operation. Provide Route Guidance
Route
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Route and Navigation Information
On-board Management. Operate Traffic manager provides Vehicle. Support and Control Vehicle route information to the Operation. Use Information Services driver
Route
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Route and Navigation Information
Transport Operation Management. Transport operator provides Manage Transport Operation. Plan route information to the and Prepare Transport Operation. transport operator Plan Transport Operation
Safety status
On-board Management. Manage Transportation Network Utilisation. Vehicle provides safety En-Route Reporting. Report Perform Operational Traffic status information to the Vehicle Safety Related Information Management. Perform Traffic Control. traffic manager Control Individual Vehicle. Manage Presence in Controlled Area
D5.2 The SMARTFREIGHT framework architecture
86
SMARTFREIGHT
TEP
Transport Demand. Plan and Prepare Transport.
Transport Service Management. Provide Transport Service. Manage Customer Relations.
TEP
Transport Service Management. Transport Operation Management. Outside the scope of Provide Transport Service. Manage Transport Operation. Plan SMARTFRIGHT (covered Manage Customer Relations. and Prepare Transport Operation. by Freightwise). Plan Transport Operation
TES
Transport Operation Transport Service Management. Management. Manage Transport Provide Transport Service. Manage Operation. Control Transport Customer Relations. Operation. Manage Schedule and Deviation
Outside the scope of SMARTFRIGHT (covered by Freightwise).
TES
Transport Service Management. Transport Demand. Manage Provide Transport Service. Transport Manage Customer Relations.
Outside the scope of SMARTFRIGHT (covered by Freightwise).
TNS
Transportation Network Transportation Network Utilisation. Perform Operational Infrastructure Management. Traffic Management. Perform Support Transportation Network Traffic Control. Operate Continuous Operation. Transportation Network Equipment
Traffic Manager provides Transportation Network Status information to the Transportation Network Infrastructure Manager, e.g. information that the RSE shall provide to the vehicles.
TNS
On-board Management. Manage Transport Operation Management. En-Route Reporting. Support Manage Transport Operation. Plan Traffic Situation Reporting. and Prepare Transport Operation. Manage Performance
Driver provides Transportation Network Status information to the Transport Operator
TNS
Transport Operation On-board Management. Operate Transport Operator provides Management. Manage Transport Vehicle. Support and Control Vehicle route guidance to the driver Operation. Control Transport Operation. Use Information Services Operation. Provide Route Guidance
TNS
Transportation Network Infrastructure Management. Support Transportation Network Continuous Operation
Transportation Network Utilisation. Perform Operational Traffic Management. Monitor Traffic Situation. Monitor Transportation Network
Outside the scope of SMARTFREIGHT - info flow within traffic management organisation.
TNS
Transportation Network Infrastructure Management. Support Transportation Network Continuous Operation
Transportation Network Utilisation. Perform Operational Traffic Management. Monitor Traffic Situation Monitor Environmental Condition
Outside the scope of SMARTFREIGHT - info flow within traffic management organisation.
TNS
Transportation Network On-board Management. Operate Traffic Manager provides Utilisation. Perform Operational Vehicle. Support and Control Vehicle incident and accident Traffic Management. Provide Operation. Use Information Services Information to the driver Traffic Situation Information. Provide Incident and Accident Information
TNS
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Traffic Flow Information
Outside the scope of SMARTFRIGHT (covered by Freightwise).
On-board Management. Operate Traffic Manager provides Vehicle. Support and Control Vehicle traffic flow information to the Operation. Use Information Services driver
D5.2 The SMARTFREIGHT framework architecture
87
SMARTFREIGHT
TNS
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Transportation Network Condition Information
On-board Management. Operate Traffic Manager provides Vehicle. Support and Control Vehicle transportation network Operation. Use Information Services condition information to the driver
TNS
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Traffic Flow Information
Transport Operation Management. Traffic Manager provides Manage Transport Operation. Plan traffic flow information to the and Prepare Transport Operation. transport operator Manage Performance
TNS
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Incident and Accident Information
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Plan Transport Operation
Traffic Manager provides incident and accident Information to the transport operator
TNS
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Transportation Network Condition Information
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Plan Transport Operation
Traffic Manager provides transportation network condition information to the transport operator
TOP
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Provide Transport Operation Information.
Transport Operation Management. Transport Operator provides Execute Transport Operation. the transport operation plan Manage Transport Operation to the driver. Information and Progress
TOS
Transport Operation Management. Execute Transport Operation. Report on Transport Operation.
Transport Operation Management. Driver provides status Manage Transport Operation. Monitor information to the transport Transport Operation. Record operator. Transport Operation Progress.
Tracking
On-board Management. Manage Transport Operation Management. Vehicle provides tracking En-Route Reporting. Report Manage Transport Operation. Monitor information to the transport Vehicle Tracking Information. Transport Operation operator.
Tracking
On-board Management. Manage Transport Operation Management. Not relevant – internal data En-Route Reporting. Report Execute Transport Operation. exchange within OBE Vehicle Tracking Information. Manage Transport Operation Information and Progress
Tracking
On-board Management. Manage Transportation Network Utilisation. Vehicle provides tracking En-Route Reporting. Report Perform Operational Traffic information to the traffic Vehicle Tracking Information. Management. Perform Traffic Control. manager. Control Individual Vehicle. Track Vehicle
Transport operation info
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress
Transport problem
On-board Management. Manage Transport Operation Management. Not relevant – internal data En-Route Reporting. Support Execute Transport Operation. Report exchange within OBE Transport Problem Reporting on Transport Operation.
On-board Management. Manage Vehicle and Transport Operation Information. Manage Transport Operation Information.
D5.2 The SMARTFREIGHT framework architecture
Not relevant – internal data exchange within OBE
88
SMARTFREIGHT
Transport problem
Transport Operation Management. Execute Transport Operation. Report on Transport Operation.
Transport Operation Management. Driver reports about Manage Transport Operation. Control transport problems to the Transport Operation. Handle transport operator. Transport Problems
Transportation network information
Transportation Network Transportation Network Utilisation. Perform Operational Infrastructure Management. Traffic Management. Perform Support Transportation Network Traffic Control. Operate Continuous Operation. Transportation Network Equipment
Outside the scope of SMARTFREIGHT
Transport Operation On-board Management. Operate Transportation Management. Manage Transport Vehicle. Support and Control Vehicle network info Operation. Control Transport Operation. Use Information Services Operation. Provide Route Guidance
Acquisition of information about the transportation network (e.g. electronic charts) is outside the scope of SMARTFREIGHT
Transportation Network Transportation Infrastructure Management. network info Manage Transportation Network Information.
Transportation Network Utilisation. Perform Operational Traffic Management. Monitor Traffic Situation. Monitor Transportation Network..
Outside the scope of SMARTFREIGHT – info flow within traffic management organisation.
TranTransportation Network sportation Infrastructure Management. network info Manage Transportation Network Information.
Transportation Network Utilisation. Outside the scope of Plan Transportation Network SMARTFREIGHT - info flow Utilisation. within traffic management organisation.
Transportation Network On-board Management. Operate Transportation Utilisation. Perform Operational Vehicle. Support and Control Vehicle network info Traffic Management. Provide Operation. Use Information Services Traffic Situation Information. Provide Transportation Network Information
Acquisition of information about the transportation network (e.g. electronic charts) is outside the scope of SMARTFREIGHT
Transportation Network Transportation Utilisation. Perform Operational network info Traffic Management. Provide Traffic Situation Information. Provide Transportation Network Information
Acquisition of information about the transportation network (e.g. electronic charts) is outside the scope of SMARTFREIGHT
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Plan Transport Operation
Vehicle info On-board Management. Manage Transportation Network Utilisation. Vehicle provides information En-Route Reporting. Report Perform Operational Traffic about itself to the traffic Vehicle Access Information Management. Perform Traffic Control. manager. Control Individual Vehicle. Manage Presence in Controlled Area. Vehicle status
On-board Management. Operate Transport Operation Management. Outside the scope of Vehicle. Monitor Vehicle. Monitor Manage Transport Operation. SMARTFREIGHT Vehicle Status Manage Transport Business
D5.2 The SMARTFREIGHT framework architecture
89
SMARTFREIGHT
9 Information view The information view specifies the information content of the information flows identified in the process view in Chapter 8 (see Table 9). This is done by means of conceptual information models modelled as UML class diagrams. They define Information elements, modelled as classes with attributes. These classes define the building blocks for the information content in the information flows in the process view. Service interfaces modelled as UML interfaces with operations. These operations are the SMARTFREIGHT APIs and describe the information content in the interactions by means if the classes mentioned above. 9.1 Conceptual information models Figure 42 provides an overview of the conceptual information models. The classes and interfaces are listed. The interfaces are at the end of the lists and their names are prefixed with “I”. They are described in section 9.2.
Figure 42: Overview of information models defined in SMARTFREIGHT
D5.2 The SMARTFREIGHT framework architecture
90
SMARTFREIGHT
The information models are defined by means of UML class diagrams. The scope of the each information models is defined by a boundary in the diagrams. The classes and their outgoing associations define information structures. A class may also have associations to classes in other models. Such external classes are placed outside the boundary, and their names are prefixed with the associated model names. The information structure will also include sub-structures defined by the associations going out form the external classes. These are however not depicted in the diagrams. To simplify the reading, the service interfaces are green (or dark grey if not printed in colours). So are also the top information elements (i.e. classes) in the information structures that are parameters (input and return parameters) in the APIs (i.e. the operations in the interfaces). 9.1.1 Transportation Network Information class Transportation Netw ork Information
Location Information:: Polygon Transportation Network Information The Controlled Area may have to be specified in more detail. Areas may be included or excluded (the include attribute is ftrue or alse). Eg. a controlled area may be the inner part of a city, but the tunnel below the city centre may not be a part of the section.
0..*
TransportationNetw orkSection +
0..*
ScetionName: string
Location Information:: AgoraCReference
0..1 Resource Information:: TransportationNetw orkResource ControlledArea + +
AreaElement +
ControlledAreaID: string 0..1 Description: string 1
Included: boolean
1..*
Traffic Management Information:: AreaPolicyElement
1..* Location Information:: CheckpointLocation
Checkpoint 0..* + A sub-set of the total Transportation Network. The area is defined and the ID is assigned when the APA policy is defined.
ChrckpointID: string
0..* Traffic Management Information::APORequest
1 0..*
Figure 43: Transportation Network Information The Transportation Network Information model provides information elements that are crucial for the traffic management concepts and mechanisms provided by SMARTFREIGHT. A Transportation Network Section is any part of the Transportation Network. It can be defined by means of a polygon or an AGORA reference (see Annex C). A Controlled Area is Transportation Network Section that is controlled according to an APA policy. (The control may be related to access restricted, monitoring or reporting requirements). o
A Controlled Area may also contain other Controlled Areas.
o
Area Elements (which also are Transportation Network Sections) may be included into or excluded from the Controlled Area. The inner centre of a city may for example be a Controlled Area, but the tunnel under the city centre (which may be a main road) may be excluded from the area. This facilitates different APA policies for tunnel and the narrow streets in the city centre.
D5.2 The SMARTFREIGHT framework architecture
91
SMARTFREIGHT
o
A Controlled Area may have Check Points
9.1.2 Resource Information class Resource Information Resource Information «interface» IResource + + + + + +
Vehicle Information:: VehicleCharecteristics
getResourceBooking(ResourceRequest) : ResourceBooking[] pushResourceBooking(ResourceBooking) : void pushResourceDeviation(ResourceDeviation) : void updateResourceBooking(ResourceBookingUpdate) : ResourceBooking cancelResourceBooking(string) : void getResourceStatus(ResourceRequest) : ResourceAvailability[]
ResourceRequest
0..* The booking priority may depend on the vehicle properties.
TOP Infromation:: PickUpLocation
+ 0..1 + + + + 0..* +
Vehicle Information:: VehicleInfo
Vehicle Information:: VehicleEntry
VehicleID: VehicleIdentification BookingTime: dateTime 1..*
ResourceBooking
0..1 TOP Infromation:: Deliv eryLocation
+ +
BookingId: string VehicleID: VehicleIdentification BookingSuccessful: boolean BookingTime: dateTime [0..1] FromTime: dateTime [0..1] ToTime: dateTime [0..1]
+
BookingId: string
0..1 0..1 Due to
Associated holding area
0..* + Assosiated holding area + + Traffic Management Information:: 0..* + Notification +
0..1
TypeOfResource: ResourceType Location: VisitLocation EarliestTime: dateTime LatestTime: dateTime Duration: int
LoadingBay ParkingLot WaitingLot StopPoint TerminalLot HoldingLot SheredResource
TransportationNetw orkResource TypeOfResource: ResourceType ResourceID: string Length: long Width: long Location : AgoraCReference
Transportation Netw ork Information:: TransportationNetw orkSection 0..1
«enumeration» ResourceDev iationType Occupid Closed
ResourceDev iation
0..1 Transportation Netw ork Information::ControlledArea
+ + + + +
«enumeration» ResourceType
IssueInformation Traffic Management Information::AccessRight
ResourceDemand
ResourceBookingUpdate
ResourceAv ailability Depending on whether the resource is monitored (controlled) or not.
+ +
FromTime: dateTime [0..1] ToTime: dateTime [0..1]
+ + + +
BookingID: string Timestamp: dateTime Devaition: ResourceDeviationType Duration: duration
Figure 44: Resource Information Information needed in the information flows concerning the Transportation Network Resources is modelled. A Transportation Network Resource is of a certain type, it has an ID and a size. It also has a location that is provided as an AGORA C reference to support localisation in a navigation system (the location can be provided relative to a fixed point in the vicinity, e.g. the entrance of the parking area). In addition, the Transportation Network Resource is associated to either a Transportation Network Section (e.g. a part of a city or a road) or a Controlled Area. The latter is the case if the access to the resource is monitored. A Resource Request will include o
A Resource Demand defining the type of resource needed, the location to be visited (the resource should be in the vicinity of this location) and the relevant time slot.
o
Vehicle Characteristics – to indicate size requirements, etc.
D5.2 The SMARTFREIGHT framework architecture
92
SMARTFREIGHT
A Resource Availability provides information about an available resource A Resource Booking will, if successful, provides information about the booked resource and the timeslot for which the resource is booked. A Resource Booking Update will be equal to a Resource Request (the update inherits the request), except for the Id of the booking that has to be updated. A Resource Deviation provides information about deviations related to a booked resource. 9.1.3 Traffic Management Information class Traffic Management Information Traffic Management Information «interface» ITrafficManagement + + + + + +
getAPApolicy(string) : AccesAndPriorityAssignmentPolicy pushAPApolicy(AccesAndPriorityAssignmentPolicy) : void uploadAPApolicy() : AccesAndPriorityAssignmentPolicy pushNotification(Notification) : void getAPO(APORequest) : AccessAndPriorityOffer[] pushAPO(AccessAndPriorityOffer) : void
AccesAndPriorityAssignmentPolicy An area (e.g. city, terminal or part of a city) may have an Access and Priority Assignment (APA) policy, and the policy may contain subpolicies for sub-areas.
APORequest + + + + +
0..* AreaPolicyElement
Distributed computation of Access and Priority Offers (APOs): When a vehicle receives the APA policy, it may compute is own APOs by comparing the APA with the properties of the vehicle.
+ + + + + + + + + +
1
TypeOfTransport: TransportType CargoTypeClass: GoodsType [0..*] FuelClass: FuelType EnginClass: EnginType [0..*] MinLoadFactor: LoadFactorType MaxWeight: int MaxAxels: int MaxLength: decimal MaxHeight: decimal ResourceBooked: boolean
AccessAndPriorityOffer + +
Priority +
VehicleID: VehicleIdentification ControlledAreaID: string
0..1
Vehicle Information:: VehicleEntry
PriorityLevel: int 0..1
0..1 0..1
0..*
+ +
FromTime: time ToTime: time
In the policy the AccessAllowed flag is always true. The vehicle must consider its properties and generates its own instances of access rights. The AccessAlloed flag may then be false. The checkpoints are for example used to direct the traffic via specific entrances.
AccessAllowed: boolean EntryCheckpoint: Checkpoint [0..*] ExitCheckpoint: Checkpoint [0..*] DynamicAccessAssignment: boolean Information: string [0..1]
Due to 0..1
Resource Information:: ResourceBooking
Associated holding area 0..1
0..*
0..* VehicleReportRequirement
AccessCondition +
InformatioMessage: string
+ + + +
EntryNotification: ReportingRequirement [0..1] ExitNotification: ReportingRequirement [0..1] SafetyStatusReport: ReportingRequirement [0..1] Tracking: ReportingRequirement [0..1]
Resource Information:: TransportationNetw orkResource
0..* «enumeration» NotificationType
Some products (e.g. driving simulators) have ways to specify restrictions. Look at these. DATEX can also be used.
Just present in processed access rights Not in the generic APA policy.
0..1
AccessRight
Timeslot + + + + +
Transportation Netw ork Information::ControlledArea
Derived from APA policy or provided on requested.
0..1
IssuerOrganisationNumber: string IssuerOrganisationName: string FromDateTime: dateTime ToDateTime: dateTime Weekday: int [1..7]
TransportationNetworkSection
1
IssueInformation + + + + +
Vehicle Information:: 1 VehicleCharecteristics
FromDateTime: dateTime ToDateTime: dateTime Weekday: int [1..7] PriorityRequest: int [0..1] AccessRequest: boolean [0..1]
IllegalEntrance Emergency AssessGranted AccessPostponed
Assosiated holding area Notification + + +
Notification: NotificationType ValiedFor: string Description: string
route to be followed
0..1
Route Information:: Route
Figure 45: Traffic Management Information
D5.2 The SMARTFREIGHT framework architecture
93
SMARTFREIGHT
Traffic management measures towards individual vehicles are facilitated by Access and Priority Assignment (APA) policies and Access and Priority Offers (APOs). A Transport Operation Worker (e.g. a driver) or a Transport Operator may request APOs by means of an APO Request. An APO is associated with a particular vehicle and a Controlled area, and the APO can be derives from the Area Policy Element, or it can be provided on request: An APA Policy consists of Area Policy Elements. Each Area Policy Element defines the policy associated to a Controlled Area for vehicles with certain characteristics. The policy has to be compared with these characteristics when the APO is derived: Type of Transport has to be compared with the content of the Transport Operation Plan (TOP – see 9.1.6) Fuel Class, Engine Class Max Weight, Max Axels and Max Length have to be compared with information provided in the Vehicle Characteristics, and Min Load Factor Class has to be compared with information provided in the Cargo Summary (see 9.1.5) Cargo Type Class has to be compared with information about the Items on-board (see 9.1.9) If Resource Booked is true, the vehicle must have booked Transportation Network Resources within the Controlled Area or a Controlled Area inside this area. Both the APO and the Area Policy Element define Priorities and the Access Right associated to a Controlled Area. Both Priorities and an Access Rights inherit Issue Information, which identifies the issuer and is valid for a time period. Within this period access rights or priorities may be assigned for specific week days and specific time slots, e.g. outside rush hours. APA policies will define which vehicles that have access to Controlled Areas (defined by means of their properties in the Area Policy Element class). Thus, the Access Allowed attribute is always true in Access Rights belonging to APA policies. APOs are derived from the APA policies and assigned to individual vehicles. A vehicle may get or be denied access to Controlled Areas. Thus, in APOs, the Access Allowed attribute in the Access Rights may be either true or false. In Access Rights in APOs, information about Resource Bookings must be provided if resource bookings are a prerequisite for access in the associated APA policy (the Resource Booked attribute in the Area Policy Element is true). The vehicle may have to enter or exit the area via certain entry and exit points, and the access may be dynamically assigned when the vehicle is approaching the area depending on for example the number of vehicles in the area, the number of vehicles with dangerous goods, etc. Information about Access Conditions may be provided Vehicle Reporting Requirements (see 9.1.9) for the Controlled Area may be provided, i.e. whether and, if relevant, when and how Entry Notifications, Exit Notification, Safety Status and Tracking information should be reported. Access Rights may have associated Transportation Network Resources. This is to inform about holding areas that may be used if the vehicle has to wait for access. Notification may be of different types. They may provide, postpone or deny access (e.g. as a respond to an entry notification in case access is dynamically assigned), or they may include route specifications (if the notifications has to include route guidance) and references to resources (e.g. to holding areas to be used).
D5.2 The SMARTFREIGHT framework architecture
94
SMARTFREIGHT
9.1.4 TNS Information
Figure 46: Transportation Network Status (TNS) Information The TNS can be requested by means of a QueryLocation that might be a specific location that for example can be identified in the navigation system (location type AgoraCReference), a visit location (e.g. address) or a distance specified by means of a from and a to location.
D5.2 The SMARTFREIGHT framework architecture
95
SMARTFREIGHT
The actual Transportation Network Status is inspired by the Freightwise TNS model, which again is inspired by DATEX II (see A.4 for descriptions of modifications done by SMARTFREIGHT). Several types of information can be provided by the TNS: The location for which the status is always provided. The AGORA C location reference provides flexibility. It may for example be a location point or a specific distance along a specific road. Information about the source of the information is also provided. If statistical data, the dates for the statistics may be provided Weather information can be provided. Details are further defined in Figure 47 Traffic flow information can be provided, including information about travel times and delays. Information about the conditions along the road can be provided. Incident and accident information can be provided. An incident may be an activity, an obstruction that affects the traffic, and the cause of the incident may also be provided. composite structure WeatherValue
WeatherValue::RoadSurfaceConditionMeasurements
WeatherValue::PollutionMeasurement + +
+ + +
PollutantConcentration: float PollutantType: PollutantTypeEnum
DepthOfSnow: float [0..1] RoadSurfaceTemperature: float [0..1] WaterFilmThickness: float [0..1]
0..1 0..1
WeatherValue::Visibility +
WeatherValue::Ice
Imported from the Freightwise project
VisibilityValue: float 0..1
+
IceThickness: float
WeatherValue::PrecipitationDetail + + +
DepositionDepth: float [0..1] PrecipitationIntensity: float [0..1] PrecipitationType: PrecipitationTypeEnum [0..1]
0..1 WeatherValue::Tide
WeatherValue 0..1
+ 0..1 + -
WeatherValue::Temperature + + + + +
AirTemperature: float [0..1] DewPointTemperature: float [0..1] MaximumTemperature: float [0..1] MinimumTemperature: float [0..1] WaterTemperature: float [0..1]
0..1
+
MaximumWindSpeed: float [0..1] WindDirectionCompass: DirectionCompassEnum [0..1] WindSpeed: float [0..1]
WaveHeight: float
0..1
WeatherValue::Wind + + +
WeatherValue::Wav es
0..1
0..1
HighTide: float WaterLevel: float LowTide: float
WeatherValue::SeaCurrent + +
CurrentSpeed: float CurrentDirection: DirectionCompassEnum
Figure 47 Weather Value details Several data types are imported from the Freightwise project, as illustrated in Figure 48.
D5.2 The SMARTFREIGHT framework architecture
96
SMARTFREIGHT
class TNSdatatypes «enumeration» PoorEnv ironmentTypeEnum
«enumeration» VehicleObstructionTypeEnum
«enumeration» DisturbanceActiv ityTypeEnum
Attributes + abnormalTemperature: string + badWeather: string + blizzard: string + blowingDust: string + blowingSnow: string + crosswinds: string + damagingHail: string + denseFog: string + eclipse: string + extremeCold: string + extremeHeat: string + fog: string + freezingFog: string + frost: string + gales: string + gustyWinds: string + hail: string + heavyFrost: string + heavyRain: string + heavySnowfall: string + hurricaneForceWinds: string + lowSunGlare: string + moderateFog: string + ozonePollution: string + patchyFog: string + precipitationInTheArea: string + rain: string + rainChangingToSnow: string + sandStorms: string + severeExhaustPollution: string + severeSmog: string + showers: string + sleet: string + smogAlert: string + smokeHazard: string + snowChangingToRain: string + snowfall: string + sprayHazard: string + stormForceWinds: string + strongGustsOfWind: string + strongWinds: string + swarmsOfInsects: string + temperatureFalling: string + thunderstorms: string + tornadoes: string + veryStrongGustsOfWind: string + visibilityReduced: string + whiteOut: string + winterStorm: string
Attributes + abandonedVehicle: string + abnormalLoad: string + brokenDownBus: string + brokenDownHeavyLorry: string + brokenDownVehicle: string + convoy: string + damagedVehicle: string + dangerousSlowMovingVehicle: string + emergencyVehicle: string + highSpeedEmergencyVehicle: string + longLoad: string + militaryConvoy: string + overheightVehicle: string + prohibitedVehicleOnTheRoadway: string + saltingOrGrittingVehicleInUse: string + slowMovingMaintenanceVehicle: string + slowVehicle: string + snowplough: string + trackLayingVehicle: string + unlitVehicleOnTheRoad: string + vehicleOnFire: string + vehicleCarryingHazardousMaterials: string + vehicleOnWrongCarriageway: string + vehiclesSlowingToLookAtAccidents: string + vehicleStuck: string + vehicleStuckUnderBridge: string + vehicleWithOverheightLoad: string + vehicleWithOverwideLoad: string + other: string
Attributes + airRaid: string + altercationOfVehicleOccupants: string + assault: string + assetDestruction: string + attack: string + bombAlert: string + civilEmergency: string + crowd: string + demonstration: string + evacuation: string + explosion: string + explosionHazard: string + filterBlockade: string + goSlowOperation: string + gunfireOnRoadway: string + illVehicleOccupants: string + march: string + procession: string + publicDisturbance: string + sabotage: string + securityAlert: string + securityIncident: string + sightseersObstructingAccess: string + strike: string + terroristIncident: string + theft: string + other: string
«enumeration» ObstructionTypeEnum
Attributes + airCrash: string + childrenOnRoadway: string + clearanceWork: string + craneOperating: string + cyclistsOnRoadway: string + damagedCrashBarrier: string + fallingIce: string + fallingLightIceOrSnow: string + highSpeedChase: string + houseFire: string + incident: string + industrialAccident: string + movingHazardsOnTheRoad: string + objectOnTheRoad: string + objectsFallingFromMovingVehicle: string + obstructionOnTheRoad: string «enumeration» + peopleOnRoadway: string EquipmentDamageTypeEnum + railCrash: string + recklessDriver: string Attributes + rescueAndRecoveryWork: string + burstPipe: string + severeFrostDamagedRoadway: string + burstWaterMain: string + shedLoad: string + fallenPowerCables: string + snowAndIceDebris: string + gasLeak: string + spillageOccurringFromMovingVehicle: string + roadInfrastructureDamage: string + spillageOnTheRoad: string + sewerCollapse: string + unprotectedAccidentArea: string + other: string + other: string
Attributes + accident: string + congestion: string + equipmentFailure: string + infrastructureFailure: string + obstruction: string + poorWeather: string + problemsAtBorderPost: string + problemsAtCustomPost: string + problemsOnLocalRoads: string + roadsideEvent: string + securityIncident: string + terrorism: string + vandalism: string
Attributes + impossible: string + hazardous: string + normal: string + passableWithCare: string + unknown: string + veryHazardous: string + winterConditions: string + other: string
«enumeration» Env ironmentalObstructionTypeEnum Attributes + avalanches: string + earthquakeDamage: string + fallenTrees: string + flashFloods: string + flooding: string + grassFire: string + landslips: string + mudSlide: string + rockfalls: string + seriousFire: string + sewerOverflow: string + stormDamage: string + subsidence: string + other: string «enumeration» AuthorityOperationTypeEnum Attributes + policeCheckPoint: string + policeInvestigation: string + survey: string + vehicleInspectionCheckPoint: string + other: string «enumeration» SourceTypeEnum
«enumeration» CauseTypeEnum
«enumeration» Driv ingConditionTypeEnum
Imported from the Freightwise project
Attributes + automobileClubPatrol: string + cameraObservation: string + freightVehicleOperator: string + inductionLoopMonitoringStation: string + infraredMonitoringStation: string + microwaveMonitoringStation: string + mobileTelephoneCaller: string + nonPoliceEmergencyServicePatrol: string + otherInformation: string + otherOfficialVehicle: string + policePatrol: string + privateBreakdownService: string + publicAndPrivateUtilities: string + registeredMotoristObserver: string + roadAuthorities: string + roadOperatorPatrol: string + roadsideTelephoneCaller: string + spotterAircraft: string + trafficMonitoringStation: string + transitOperator: string + vehicleProbeMeasurement: string + videoProcessingMonitoringStation: string
«enumeration» TrafficStatusEnum Attributes + impossible: string + congested: string + heavy: string + freeFlow: string + unknown: string
Figure 48 Data types related to Transportation Network Status
D5.2 The SMARTFREIGHT framework architecture
97
SMARTFREIGHT
9.1.5 Vehicle Information class Vehicle Information Vehicle Information
+ + + + + + + + + + + + +
getVehicleTracking(VehicleIdentification) : VehicleTracking pushVehicleTracking(VehicleTracking) : void getVehicleInfo(VehicleIdentification) : VehicleInfo pushVehicleInfo(VehicleInfo) : void getVehicleEntryNotification(string) : VehicleEntry pushVehicleEntryNotification(VehicleEntry) : void getVehicleExitNotification(string) : VehicleExit pushVehicleExitNotification(VehicleExit) : void getSafetyStatus() : VehicleSafetyStatus[] pushSafetyStatus(VehicleSafetyStatus) : void pushVehicleStatus(VehicleStatus) : void getVehicleStatus() : VehicleStatus pushTransportProblem(TransportProblem) : void LoadFactorType
+ +
FillingPercentage: int [0..1] CargoWeight: int [0..1]
+ + + + + +
Width: decimal Hight: decimal GrossWeight: int Length: decimal NoOfAxels: int YearOfManufacture : string
TractorUnitInformation
0..1
Euro0 Euro1 Euro2 Euro3 Euro4 Euro5 Euro6
Electrisity Diesel Petrol Natural gas Hydrogen Other
VehicleIdentification + + +
VehicleCharecteristics + + + + + + + + + +
«enumera... EnginType
«enumeratio... FuelType
«interface» IVehicle
Nationality: string RegistrationID: string IPaddress: string
Traffic Management Information:: APORequest
1
VehicleID: VehicleIdentification Fuel: FuelType [1..*] EnginStandard: EnginType Hight: decimal GrossWeight: int NoOfAxels: int Width: decimal Length: decimal YearOfManufacture : string MaxLoadVolume: double
TrailerInformation + + + 0..* + + + + +
TrailerID: string Hight: decimal Width: decimal GrossWeight: int Length: decimal NoOfAxels: int YearOfManufacture : string MaxLoadVolume: double
Resource Information:: ResourceRequest
0..* VehicleOw ner
CargoSummary + + + + + +
LoadFactor: LoadFactorType LoadFactorValue: int Weight: double DangerousGoods: DGdescription [0..*] Volume: double Value: int
+ + +
OrganisationNumber: string Name: string ContactInfo: ContactInformation Location Information:: VisitLocation
VehicleDestination VehicleInfo 1
1..*
+
SeqNo: int 0..*
0..* GoodsTypeInformation + + +
0..1 VehicleEntry
TypeOfCargo: GoodsType Amount: int Unit: string
+ + +
VehicleID: VehicleIdentification Timestamp: dateTime ControlledAreaID: string
VehicleSafetyStatus + + + + +
Those that are relevant to this entry. IssueInformation
VehicleExit
VehicleID: VehicleIdentification DangerousGoods: DGdescription [0..*] FuelLevelOK: boolean EnginStatusOK: boolean BrakesOK: boolean
+ + +
0..1 Traffic Management Information:: AccessRight
VehicleID: VehicleIdentification Timestamp: dateTime ControlledAreaID: string
VehicleTracking Not addressed by SMARTFREIGHT. To be further elaborated.
VehicleStatus + +
VehicleID: VehicleIdentification Milage: int
Resource Information:: ResourceBooking
TransportProblem + + + + + +
VehicleID: VehicleIdentification DriverIllness: boolean VehicleOperationProblem: boolean LoactionNotFound: boolean AccidentInvolvement: boolean SecurityConcerns: bollean
+ + + +
Timestamp: int VehicleID: VehicleIdentification Location: Point Speed: int [0..1]
IssueInformation Traffic Management 0..1 Information::Priority
0..1 VehicleStop +
StopDuration: duration
Figure 49: Vehicle Information The Vehicle Identification consists of the nationality of the vehicle, the registration Id of the vehicle and the IP address of the vehicle. It enables communication directly with the vehicle.
D5.2 The SMARTFREIGHT framework architecture
98
SMARTFREIGHT
The Vehicle Info provides an overview of information about the vehicle and its cargo. Such information may be required by authorities (input to statistics, regulation enforcement, etc.): A Cargo Summary that provides an overview of the cargo carried by the vehicle, dangerous cargo included. The Vehicle Characteristics, including Tractor Unit Information, Trailer Information and Vehicle Owner information. The planned Destinations of the vehicle The Resource Bookings of the vehicle Entrance to and exit from Controlled Areas may have to be reported (such requirements are defined in the APA policy). The content of the Entrance Notification will depend on the Controlled Area: On entry to Transport Network Resources, Resource Booking may have to be referred. On entry to areas with access right assignments, Access Rights may have to be referred. On entry to areas with priority assignments, Priorities may have to be referred. Transport Problems should be reported to the Transport Operator in case of problems, and Vehicle Safety Status, Vehicle Status and Vehicle Tracking may also be reported (depending on the report requirements in the APA policy and in the TOP). The Vehicle Tracking may report Vehicle Stops. 9.1.6 TOP Information class TOP Information Transport Operation Plan «interface» ITOP + +
getTOP(string) : TransportOperationPlan pushTOP(TransportOperationPlan) : void
May be pre-planned and provided by Transport Operation Manager; defined by driver or on-board navigation system; defined by traffic management; or actual.
TransportOperationPlan + + + + +
TOPID: string VehicleID: VehicleIdentification TypeOfTransport: TransportType TrackingRequirement: ReportingRequirement [0..1] TOSRequirement: ReportingRequirement [0..1] 0..1
0..*
RoutePlan +
The TOP may be updated during the transport operation.
LoadItem
Item
RouteToBeFollowed: RouteID [0..1]
Item Information: :ItemInfo 0..*
0..1
Handling + + + + + +
PlannedTime: dataTime EstimatedTime: dataTime [0..1] ActualTime: dataTime [0..1] Action : HandlingType Location: VisitLocation HandlingInstruction: string
1..*
«enumeratio... HandlingType
PickUpLocation +
Location: VisitLocation 0..1 Deliv eryLocation +
0..1
Location: VisitLocation
Load Unload Store PickUp Deliver
«enumeration» TransportType FreightDeliveryTransport WasteTransport NotOnDutyTransport OnDutyTransport ConsolidatedTransport ReturnLoad
0..1
JourneySegment Route Information:: RoadJourneySegment
Resource Information:: ResourceBooking
Figure 50: Transport Operation Plan (TOP) Information
D5.2 The SMARTFREIGHT framework architecture
99
SMARTFREIGHT
The Transport Operation Plan (TOP) provides information about how the transport operation to be carried out: The Transport Operation Plan has a TOP ID and it is related to a Vehicle. It also concerns a specific type of transport which indicates the transport intention. Reporting requirements are also association to the transport operation and will determine vehicle tracking (to be provided to the Transport Operator) and the TOS reporting (see 9.1.7). A Route Plan may be assigned before the initiation of the transport operation, or the route decided upon by the driver. The Load Items and the tasks associated with the Load Items are defined ( if not empty vehicle) o
Item Information is inherited, DG Description (if dangerous goods) and Item Instructions included (see 9.1.9).
o
The Pick Up and Delivery Locations are defined as well as the associated Resource Bookings.
o
The Handling that is required is defined.
9.1.7 TOS Information class TOS Information
Transport Operation Status (TOS)
«interface» ITOS + +
getTOS(string) : TransportOperationStatus pushTOS(TransportOperationStatus) : void
«enumeration» OperationStatusType NotStarted InProgress Completed Canceled NoStatus UnplannedStop
TransportOperationStatus + + + + +
TimeStamp: dateTime TOPID: string OperationStatus: OperationStatusType StatusTime: dateTime Description: string
Item
Item 0..* Information:: ItemStatus
Figure 51: Transport Operation Status (TOS) Information The Transport Operation Status (TOS) is associated with a Transport Operation (TOP ID), and the operation status is reported. In addition, the status of the Load Items may also be reported as Item Statuses (see 9.1.9).
D5.2 The SMARTFREIGHT framework architecture
100
SMARTFREIGHT
9.1.8 Route Information class Route Information Route Information
«interface» IRoute + +
Inspired by the ARKTRANS framework
getRoute(RouteLocations) : Route pushRoute(Route) : void
RoadJourneySegment
Route +
+ 0..* + +
RouteID: string [0..1]
Use AGORA C extended profile to specify the road network and location. Consult this work.
TOP Infromation:: RoutePlan
Length: int TimeEstimate: duration 1..* Description: string [0..1]
JourneySegment + +
Seqno: int AngoraCSegment: AgoraCReference
Defines locations that have to be visited on a route.
ViaLocation
RouteLocations + +
ToLocation: VisitLocation FromLocation: VisitLocation
+ 0..* +
Seqno: int ViaLocation: VisitLocation
Figure 52: Route Information A Route is specified by means of Road Journey Segments. For each segment there is a time estimate. The route is described by means of an AGORA C Reference. A Route can be requested by means of Route Locations specifying the start and the end locations of the route. In addition Via Locations can be provided.
D5.2 The SMARTFREIGHT framework architecture
101
SMARTFREIGHT
9.1.9 Item Information class Item Information Item Information «interface» IItem + + + + + +
+ + + + + +
ReportRequirement: ReportReqType [1..*] Interval: int [0..1] CheckPoint: AgoraCReference [0..*] CheckPointRadius: decimal [0..1] GeoFence: Polygon [0..1] ReportingAddress: anyURI
TypeOfDG: ADRtype Amount: decimal Unit: string 0..*
ADRtype
+ + + + + +
ItemId: string
TypeOfItem: GoodsType [1..*] Amount: int Unit: string StatusReport: ReportingRequirement [0..1] Tracking: ReportingRequirement [0..1] InfoReport: ReportingRequirement [0..1] 0..*
ItemStatus
TOS Infromation:: TransportOperationStatus 0..*
+ + + + + +
ItemInstruction
Status: ItemStatusType StatusTime: dateTime ItemConditionDeviation: boolean ItemTimeDeviation: boolean Description: string [0..1] Location: Point [0..1]
+ + + + +
0..*
ConditionType: ItemConditionType Value: decimal [0..1] MeasurementUnit: MeasureType [0..1] Description: string [0..1]
TypeOfInstruction: ItemConditionType MinValue: decimal [0..1] MaxValue: decimal [0..1] MeasurementUnit: MeasureType [0..1] Description: string [0..1]
0..1
ItemCondition + + + +
«enumer... GoodsType
ItemInfo
Item +
NoReport OnHandling Intervalls OnCheckpoints OnDeviation OnRequest OnGeoFence
ReportingRequirement
DGdescription + + +
«enumeration» ReportReqType
The Item may be a Transport Item or a Load Item.
getItemTracking(Item) : ItemTracking pushItemTracking(ItemTracking) : void getItemStatus(Item) : ItemStatus pushItemStatus(ItemStatus) : void pushItemInfo(ItemInfo) : void getItemInfo(Item) : ItemInfo
ItemTiming +
NewETA: dateTime
ItemTracking + + + +
TimeStamp: dateTime ItemID: string StatusTime: dateTime Location: Point
DG Empty xxx yyy
«enumeration» ItemConditionType Temperature Humidity Clean Damage SecurityWarning
«enumeration» ItemStatusType Loaded Unloaded Arrived Departed No_status Under_progress Draft
Figure 53: Item Information The Item is a generic item that in SMARTFREIGHT mainly will be a Load Item. Such a Load Item may be an empty load unit or it may have content. However, the Reporting Requirements may be associated with anything. In SMARTFREIGHT they also are used to indicate reporting requirements to vehicles as specified in the APA Policy (see 9.1.3) and in the TP (see 9.1.6). The Item Information provides aggregated information about the content of the Item, such as type of goods and amount of goods. If the Item contains dangerous goods, DG Description provides details about the goods. Reporting requirements are also provided, i.e. requirements with respect to the reporting of Item Status, Item Tracking and Item Info. Item Instructions are also provided, i.e. instructions with respect to the conditions in which the Item should be kept. The Reporting Requirements specifies the trigger of the reporting (see the Report Req Type). This may for example be At specific intervals. If so, the intervals are provided. On checkpoints. If so, the checkpoints are provided. AGORA C references may be used as well as a radius to arrange for some flexibility. When a geo-fence is crossed. If so, the geo-fence is provided. On deviations from the Item Instruction. When the Item is handled.
D5.2 The SMARTFREIGHT framework architecture
102
SMARTFREIGHT
The Item Status provides information about and/or a new estimated ETA (Estimated Time of Arrival), and the Item Tracking provides information about the position of the Item as a specific timestamp. 9.1.10 Location Information class Location Information Location VisitLocation
FromToLocation Point + +
+ +
Latitude: long Longitude: long
+ + + +
FromLocation: VisitLocation ToLocation: VisitLocation
LocationName: string [0..1] StreetAddress: ContactInformation [0..1] GeoReference: AgoraCReference [0..1] AdditionalDescription: string [0..1]
ContactInformation AgoraCReference +
AngoraCRef: string 0..*
Polygon +
Vertices: Point [3..*] {ordered}
+ + + +
Person:: string Address: string Telephone: string Fax: string
Vehicle Information: :VehicleDestination
CheckpointLocation + + + +
Latitude: double Longitude: double Distance: double Direction: double
Transportation Netw ork Information::Checkpoint
0..*
Transportation Netw ork Information:: TransportationNetw orkSection
Figure 54: Location Information Locations can be provided in many ways, depending on what is feasible in the particular situations. See also Annex C for more details: Points are used when a position is to be reported, e.g. related to tracking. Visit Locations are used to support the localisation of an address or a named location. The address or the location name can be provided as well as an AGORA C Reference and a description (e.g. more details). May for example be used to define delivery locations. From To Locations are used to provide two Visit Locations. May for example be used to request Transport Network Status information for routes between two locations. AGORA C References are used to support: the localisation in a navigation system; locations related to geographical objects, e.g. locations along a road or near a junction; or the location of a booked Transport Network Resource (the location can be provided as an offset from the entrance of the parking area). Polygons are used to define an area, e.g. the extension of a Transportation Network Section. Contact Information is about how to get in touch with someone. Check Point Locations provides a point along the road and a line across the road from this point. A vehicle will be on the check point when the line is crossed. May for example define entry and exit points to and from Controlled Areas.
D5.2 The SMARTFREIGHT framework architecture
103
SMARTFREIGHT
9.2 Service interfaces and APIs SMARTFREIGHT has several service interfaces with APIs, as illustrated in the conceptual information models in 9.1. Table 10 provides an overview. The APIs enables the interactions identified in the process view (see Table 9 on page 84). Table 11 Service interfaces and APIs Service Interfaces
APIs
Input
Output
Description
IResource
getResourceBooking
ResourceRequest
ResourceBooking
Book a resource
See 9.1.2
pushResourceBooking
ResourceBooking
Provision of resource booking
pushResourceDeviation
ResouceDeviation
Provide deviation info on booked resource
updateResourceBooking
ResourceBookingUpdate
cancelResourceBooking
BookingID
getResourceStatus
ResourceRequest
ResourceAvailability
Get info on resource availability
ControlledAreaID
AccessAndPriorityAssignmentPolicy
Get APA policy
ITrafficgetAPApolicy Management pushAPApolicy See 9.1.3 uploadAPApolicy
ResourceBooking
Change a booking Cancel a booking
AccessAndPriorityAssignmentPolicy
Provide APA policy
AccessAndPriorityAssignmentPolicy
Update the APA policy on a RSE
pushNotification
Notification
Notify the On-board Manager
getAPO
APORequest
pushAPO
AccessAndPriorityOffer
ITNS
getTNS
QueryLocation
See 9.1.4
pushTNS
TransportationNetworkStatus
Provide TNS
uploadTNS
TransportationNetworkStatus
Update TNS on a RSE
IVehicle
getVehicleTracking
VehicleIdentification
See 9.1.5
pushVehicleTracking
VehicleTracking
getVehicleInfo pushVehicleInfo
AccessAndPriorityOffer
Provide an APO TransportationNetworkStatus
VehicleTracking
Request TNS
Request tracking info Provide tracking info
VehicleInfo
Request vehicle info - e.g. for statistics.
VehicleInfo
D5.2 The SMARTFREIGHT framework architecture
Request an APO
Provide vehicle info
104
SMARTFREIGHT
Service Interfaces
APIs
Input
getVehicleEntryNotification ControlledAreaID
Output
Description
VehicleEntry
Request entry notification
pushVehicleEntryNotificatio VehicleEntry n getVehicleExitNotification
ControlledAreaID
Provide entry notification VehicleExit
Request exit notification
pushVehicleExitNotification VehicleExit getSafetyStatus
Provide exit notification VehicleSafetyStatus
Request vehicle safety status
pushSafetyStatus
VehicleSafetyStatus
Provide vehicle safety status
pushVehicleStatus
VehicleStatus
Provide vehicle status
getVehicleStatus
VehicleStatus
Request vehicle status
pushTransportProblem
TransportProblem
ITOP See 9.1.6
getTOP
VehicleId
pushTOP
TransportOperationPlan
ITOS See 9.1.7)
getTOS
TOPID
pushTOS
TransportOperationStatus
IRoute See 9.1.8
getRoute
RouteLocations
pushRoute
Route
IItem
getItemTracking
Item
See 9.1.9
pushItemTracking
ItemTracking
getItemStatus
Item
pushItemStatus
ItemStatus
Provide item status
pushItemInfo
ItemInfo
Provide item info
getItemInfo
Item
D5.2 The SMARTFREIGHT framework architecture
Provide transport problem information TransportOperationPlan
Request TOP Provide TOP
TransportOperationStatus
Request TOS Provide TOS
Route
Request route guidance Provide route guidance
ItemTracking
Request item tracking Provide item tracking
ItemStatus
Request item status
ItemInfo
Request item info
105
SMARTFREIGHT
10 Technical aspects This chapter looks into the more technical details of the SMARTFREIGHT architecture; especially the link between the specifications in earlier chapters of this deliverable and the technical considerations and implementations in WP3 and WP4. In SMARTFREIGHT, the technical emphases have been put on application development for the UTMS (Urban Traffic Management System) and FDMS (Freight Distribution Management System), along with the communication between vehicle and infrastructure (i.e. RSE and the UTMS and FDMS). The earlier chapters in this deliverable have specified the functionalities, processes and APIs needed to move information from one role to another (e.g. from Onboard Manager to Traffic Manager, and from Transport Operator to the Transport Operation Worker). The functionalities will be implemented as services and applications deployed in OBEs, RSEs, and back offices. SMARTFREIGHT uses technology partly developed in the CVIS project. The CVIS service platform is based on the OSGi technology platform, which involves sophisticated application handling at the end-user systems. These systems are a part of the CVIS system architecture that ensures a common communication pattern for the system components. The actual transmission of information is handled by the ISO CALM family of standards [12] that provides different communication bearers depending on the services‟ and applications‟ requirements. SMARTFREIGHT is one of the first external users of the CVIS service platform, and represents therefore an important arena for testing of the CVIS technology. Section 10.1 provides more details on the CVIS service platform, while Section 10.2 looks at the communication infrastructure by briefly mention some important communication technologies in the context of SMARTFREIGHT. Section 10.3 considers the management of the applications, while how the applications communicate is described in more detail in Section 10.4. The system architecture for the SMARTFREIGHT solutions are described in Section 10.5. The internal realisation of the system components is however not specified as the focus is on the interactions between the components. Last, Section 10.6.2 looks at how to describe locations and vehicles‟ position. 10.1 The CVIS service platform Inside all CVIS hosts there is a CVIS service platform [9] which constitutes the environment for application support (e.g. life cycle management, directory services, communication, etc.). The service platform lies on top of the communication infrastructure, and provides services and run-time support for the applications. Figure 55 shows the layered architecture in CVIS. The applications use services offered by the basic and domain facilities (i.e. services), along with the OSGi-based execution infrastructure. The facilities and the OSGi execution environment constitute the CVIS service platform. For an application, the available services are offered through: Execution environment: a Java Virtual Machine on top of Linux OS with defined Java APIs [13] OSGi services and framework: e.g. class loading, life cycle management, connector service, etc. [8] FOAM architectural elements: services enabled by the CVIS project for application support [14] The standard OSGi services along with the services (i.e. facilities) from the CVIS sub-project FOAM (Framework for Open Application Management) will enable an easier application development in CVIS. All services are provided through defined APIs. This enables application development of interoperable and communicating modules. The APIs are provided in the same way as the Java APIs provided by Sun/Oracle; they are specified in the
D5.2 The SMARTFREIGHT framework architecture
106
SMARTFREIGHT
Java-doc format since Java is the native language, and the APIs become available to a class after importing the correct Java package (or bundle in OSGi terms). Figure 55 differentiate between basic and domain facilities. The domain facilities are services more specific for vehicular applications, while basic facilities are generic services suitable for applications in any area.
Figure 55: The CVIS layered architecture [Illustration from CVIS] Applications developed in SMARTFREIGHT will in the CVIS layered architecture appear together with the other applications. These applications will thus use the services offered through the CVIS service platform. But in order to fulfil the SMARTFREIGHT functions they will interact with each other through defined SMARTFREIGHT interfaces (APIs). These APIs are well defined to be used outside of the project as well. 10.2 Communication infrastructure The communication infrastructure consists of both the computer hardware with operative system (OS) as well as the lower layer communication protocols. For details on the hardware and OS required, it is referred to WP4 and the deliverables D4.1 and D4.2. This section will give a brief introduction to the most important communication protocols used in SMARTFREIGHT that influence the SMARTFREIGHT applications the most. More details on the access protocols can be found in D4.4. 10.2.1 IPv6 Version 6 of the Internet Protocol (IPv6) [15] is the successor of the IPv4 used in Internet today. IPv6 provides several improvements compared to the old IPv4. One important improvement especially relevant for SMARTFREIGHT is the increased number of available IP-addresses, which means that all devices (including OBE and OGE) can be globally reachable2F . But also aspects like better bandwidth efficiency due to different forms of multicast, improved information security for all packets, higher QoS granularity, and better mobility support make IPv6 attractive in a SMARTFREIGHT context. The improved mobility support includes Mobile IPv6, which provides better route optimization and handover, and Network Mobility (NEMO) [16] for router mobility3F . However, a change from IPv4 to IPv6 will affect many million network devices, and it will therefore be an extended period where IPv4 and IPv6 will coexist.
D5.2 The SMARTFREIGHT framework architecture
107
SMARTFREIGHT
IPv6 makes all vehicles and their goods reachable through RSE or cellular systems for the UTMS and FDMS in SMARTFREIGHT. This enables more individual information and control. One major drawback is the large overhead incurred for IPv6 – especially in highly mobile contexts where only a small amount of data is to be sent and multi-hop is not required (e.g. service advertisements from RSEs to vehicles). Then CALM FAST is an alternative (see Section 10.2.2.1). 10.2.2 CALM The CALM concept is a family of international standards for wired and wireless communication using different access technologies, and is developed under the ISO umbrella in TC204 WG16. These ISO standards specify a common architecture, network protocols and communication interface definitions [12]. Two important features of CALM are heterogeneous handover support, i.e. handover between different access technologies, and the communication abstraction meaning that the applications do not have to care about the network and access protocols being used. In urban scenarios as SMARTFREIGHT there could be a range of available access technologies like e.g. CALM M5 (Section 10.2.2.3) and 2G/3G (Section 10.2.2.4). Using CALM means that the applications do not have to worry about the communication; they will receive the best available connection at any given time. CALM is available for the SMARTFREIGHT applications through the CALM connection manager interfaces. 10.2.2.1 CALM FAST CALM FAST [17] is a network protocol to use in scenarios where the more heavyweight IPv6 is not optimal. CALM FAST is suitable for short messages requiring low delay – typically vehicle to infrastructure (V2I) and vehicle to vehicle (V2V) messages. Routing is not supported, which limits its use to single hop scenarios as in V2I and V2V. CALM FAST is only specified over CALM M5, but can also be used over Dedicated Short-Range Communication (DSRC) with the use of CALM MAIL (see Section 10.2.2.2) in between. All communication between the OBE and RSE in SMARTFREIGHT will use the CALM FAST protocol. Also, CALM FAST will be used between the OGE and OBE. For the multi-hop situations in SMARTFREIGHT, IPv6 is used (e.g. OBE to UTMS and FDMS). 10.2.2.2 CALM MAIL CALM MAIL (Media Adapted Interface Layer) [18] is an adaptation layer for the access technology Dedicated Short-Range Communication (DSRC), standardized by CEN [19]. It allows CALM FAST or IPv6 to use DSRC as its information bearer. DSRC is much used in tolling applications, and will in SMARTFREIGHT be used between the OGE and OBE. CALM MAIL will therefore be implemented in the OGE-OBE communication. 10.2.2.3 CALM M5 CALM M5 [20] is a medium-range access protocol operating in the 5 GHz band. It is much used in both V2I and V2V communication as it offers both broadcast and unicast. Critical road safety applications have a dedicated frequency band where low overhead and delay are important. Other applications use another band where e.g. IPv6 can be used for increased Internet functionality. All OBE to/from RSE communication in SMARTFREIGHT will use CALM M5. Service advertisements from the RSE is sent by CALM FAST / CALM M5, while information from the OBE to/from the UTMS and FDMS use IPv6 / CALM M5 when an RSE is used as an intermediate router. 10.2.2.4 CALM 2G/3G Cellular networks are important for their coverage. The 3GPP standards GSM/GPRS, often referred as 2G, and UMTS, often referred as 3G, are the main technologies for the long
D5.2 The SMARTFREIGHT framework architecture
108
SMARTFREIGHT
range communication [21]. These networks require an infrastructure, which now covers most of the European continent (at least the 2G infrastructure). The CALM family of standards includes protocols for using both 2G and 3G as the information bearer [20, 21]. SMARTFREIGHT applications will use the 2G/3G access for communication with the UTMS and FDMS in cooperation with RSEs for continuous connectivity. This use is not visible to the applications since their operation is not time critical. 10.3 Application management An application is a software implementation with one or more functionalities that can be run in a runtime environment. An application can offer services to other applications, and use services offered by others. A service is, in OSGi terms, a self contained software component consisting of one or more interfaces, which represent the functionality of the service, and a class implementing the interface(s). Applications run in CVIS hosts that can be located in e.g. vehicles, roadside equipments (RSEs) and other devices. The applications are on top of the CVIS service platform, as can be seen from Figure 55. CVIS makes a clear distinction between deployment and provisioning. An application is first deployed from, possibly third parties, service and software providers to a Host Management Centre (HMC), where the applications will reside in a software repository. Then the applications are provisioned from the HMC to different hosts. Figure 56 shows how the software is first deployed in the HMC from possibly two different stakeholders. Then the software is provisioned to a CVIS host (here: a nomadic user, RSE, and OBE). After the software is provisioned, the information flows are directly with the different service centres like FDMS. To handle application updates, etc the hosts have a Host Management Centre Agent (HMCA) implemented that communicates with the HMC. The HMCA service is located within the basic facilities in the CVIS service platform, shown in Figure 55. The deployment and provisioning services are available through Web Service (WS) APIs.
Figure 56: Application management [Illustration from CVIS] In SMARTFREIGHT, the most relevant scenarios related to the management of applications is when the vehicles‟ OBE downloads an application, and when the UTMS uploads an application to RSEs. Application downloads to OBEs will either be required or requested. Either way, the OBE will use an IPv6 address to locate the application. An application download can e.g. be required when a vehicle enters a city area where special restrictions apply that need an own application for their interpretation. Application uploads to RSEs are controlled by the HMC. The HMC will thus use the RSEs‟ IPv6 addresses for communicating to RSE hosts. One example of use is when a D5.2 The SMARTFREIGHT framework architecture
109
SMARTFREIGHT
city wants to control its border by limiting the access to it. There are different options, but one could be to allow the RSE to do a local decision on admission of vehicles or not – something that would require an upload to the RSE. Note that there are defined Web Services for application provisioning in the CVIS service platform. 10.4 Applications and their communication The CVIS service platform supports the applications‟ communication through connection services with defined interfaces. Long range communication technology will make a mobile device able to have a continuous connection with other applications, while short and medium range communication technologies limits the range in which other applications may exist. These latter technologies offer more locally provided information (e.g. safety information important and relevant for only a specific crossing), as well as higher bandwidths and lower latencies. To know when other applications are in communication range, applications use the Distributed Directory Service (DDS) for application discovery, which is located in the FOAM architecture [14], and a broadcast message termed service advertisements to notify about their presence. After the discovery phase, the applications have different service call alternatives to use. Section 10.4.3 elaborates more on this. 10.4.1 Distributed Directory Service (DDS) To be able to find other applications and let other applications find it, each application must register with its local DDS (each CVIS Host has a local DDS client in the FOAM service platform). Identification, application type, URL for communication, and optional properties are registered. A replying URL will be necessary when broadcasting service advertisements. The properties can be the context of the application and the mobile device itself, and could thus be used in the search for applications. One example of relevant context is the vehicle cargo. This could be used in SMARTFREIGHT to inform only vehicles with dangerous goods of the local precautions that must be taken in a specific area. 10.4.2 Service advertisements For contacting other applications a service advertisement is used. The service advertisement may include data for others to receive in addition to an URL for any replies when broadcasting is used. The service advertisement may include properties for searching for only a subset of possible applications meeting the search criterions, e.g. informing only vehicles with dangerous goods. Note that a search will have a limited validity due to possible dynamic properties (e.g. goods may be unloaded). 10.4.2.1 Service advertisements without properties Without specifying any properties, the service advertisement targets all vehicles within range, i.e. all vehicles with the proper application to receive the information. If no suitable application is present, the OBE can be instructed to download such an application. In SMARTFREIGHT the RSE will send advertisements without properties to all vehicles in relevant scenarios like: Provision of APA policy Others – depending on city policy 10.4.2.2 Service advertisements with properties In SMARTFREIGHT the most relevant properties to include would be in relation to the access restrictions that some areas may have – e.g. the goods type and engine type. Dangerous goods are restricted in many urban areas, including the tunnel scenario demonstrated in SMARTFREIGHT, while the type of engine is important in low-emission areas (i.e. green zones). The goods type enumerations, which include dangerous goods, are D5.2 The SMARTFREIGHT framework architecture
110
SMARTFREIGHT
defined in the GoodsType class in the Item Information model, while the engine type enumerations are defined in the EngineType class in the Vehicle Information model. Scenarios where targeted vehicles must provide information include: Provision of Entry and Exit notifications Provision of Vehicle information Provision of Safety status 10.4.2.3 Publish and subscribe to service advertisements The search and find application process is, however, not suitable for all situations in the vehicular environment. When a DDS receives a search message, the DDS must process the enquiry and contact its registered application, which then will setup a communication channel back to the requesting application. This dwell time will in many cases be too long compared to the time two applications are in range (e.g. when a vehicle passes a RSE in relatively high speed). For this reason a publish and subscribe relation is used. When the application registers to its local DDS, it can set the parameter isPublish, which indicates that the DDS will continuous broadcast service advertisements from the application. Any application that wants to get immediate information about such applications‟ presence can subscribe to these advertisements through its own local DDS. Consequently, the subscribing application‟s DDS will listen to any publishing applications nearby, and establish a communication channel immediately if someone appears. This may be relevant for. Downloading of APA policies Provision of Entry and Exit notifications Provision of Vehicle information Provision of Safety status Reception of Notifications 10.4.3 Service calls Service calls, or remote procedure calls, are a request for a service from an application. Services are available through defined interfaces (i.e. Application Programming Interface (API)). These APIs will define which information is required and its structure. In SMARTFREIGHT, the applications will reside in different environments like the OGE, OBE, RSE, and back offices. The CVIS service platform offers connection services to the applications which allow both Web Services and ordinary HTTP operations. For the actual transmission of the information, the appropriate communication bearer to use will depend on the information sent (i.e. time criticality, size, QoS, etc.). By using the CALM connection manager, the best available communication will be chosen. Below, different scenarios are discussed. Service calls to and from the OBE The OBE applications will use the APIs defined in SMARTFREIGHT to communicate with other entities. Upper layer application data will be packed into lower layers, and depending on the intended receiver, availability, and QoS aspects, be sent over an appropriate bearer. For single hop communication, like service advertisements, with the RSE, the CALM FAST over M5 is most suitable. CALM FAST / M5 provides low latency for a small amount of data. The bandwidth is shared among many vehicles, thus requiring short messages. For other communication, like to and from the UTMS and FDMS, IPv6 over M5 or 2G/3G provides a multi-hop solution with handovers.
D5.2 The SMARTFREIGHT framework architecture
111
SMARTFREIGHT
One scenario could be that a vehicle drives towards a city and picks up a service advertisement from a RSE using CALM FAST / M5 specifying that the vehicle must download a required application through a specified URL. When this application (after install, etc.) sends information to the Traffic Manager, it uses IPv6 / M5 or IPv6 / 3G depending on availability. Any information in the opposite direction will use the vehicle‟s IPv6 address received from its point of attachment (i.e. either RSE or 3G). Service calls to and from the OGE As for the applications in the OBE, the OGE applications will have the SMARTFREIGHT API available as well as the CVIS service platform with connection services. The difference from the OBE applications is that the OGE applications will use CALM MAIL / DSRC as a communication bearer. For global reachability, IPv6 could be used. The OBE would then work as an intermediate router for information to and from the OGE. However, due to limitations on the SMARTFREIGHT DSRC implementation, IPv6 incurs too much overhead. Consequently, CALM FAST will be used to allow the OGE to send periodic service advertisements to the OBE with goods information. The OBE will thus be continuous updated on its associated goods. Service calls between back offices and RSEs All communication that happens between different back office systems will not require CVIS support. It also means that the communication can use normal IPv4 addresses and routing over Ethernet. Web Services and HTTP GET/PUSH over a fixed line are the most common communication solutions to use. When communicating with the RSEs, IPv6 must be used. The bearer will in most cases be fibre, while also directional wireless connections are used. 10.5 System architecture Vehicle On-goods Equipment (OGE) On-board Equipment (OBE)
Freight Distribution Management System (FDMS)
Roadside Equipment (RSE)
Urban Traffic Management System (UTMS)
Control Centre (CC) incl. HMC
Figure 57: The system components The system architecture in SMARTFREIGHT defines the system components and their relations, as depicted in Figure 57. The solution is based on the CVIS system architecture, and focus is on the interactions between the systems components by means of the services provided by the CVIS platform. 10.5.1 Communication between system components The following communication is done for each system component: On-Goods Equipment (OGE): The OGE interacts with the OBE on goods related information. The OGE is quite simple in SMARTFREIGHT, informing the OBE (which may further notify other actors) about sensor data like temperature and shock.
D5.2 The SMARTFREIGHT framework architecture
112
SMARTFREIGHT
On-Board Equipment (OBE): The OBE act as a router for the OGE, collecting, requesting, and forwarding information on its behalf. Application management is handled by the HMC at the CC The OBE further interacts with the central systems (UTMS and FDMS) in different ways: o
Via RSE (if RSE is available). Information to the UTMS can be routed via the RSE or the RSE may act on behalf of the UTMS.
o
Via the mobile cellular network (i.e. 3G/UMTS).
Roadside Equipment (RSE): The RSE serves as an intermediate router for both the vehicle, UTMS, and CC. In addition there are may be traffic management applications running on the RSE that communicates with the vehicle and the UTMS. Freight Distribution Management System (FDMS): The FDMS will control and monitor the transport operation, while it will receive information from the UTMS. After FDMS specific applications have been deployed to the vehicles by the HMC, the application interaction is directly between the vehicle and FDMS. Urban Traffic Management System (UTMS): The UTMS exchanges information with the vehicle, RSE, and FDMS. It will also interact with the CC for application provisioning to the application repository. Control Centre (CC), including HMC: The CC will receive software from the FDMS and UTMS (provisioning), while it will deploy the software in the vehicle and RSE. The management of applications is handled by the HMC. 10.5.2 System components The OGE, OBE, RSE and CC system components consist of a subsystem of a gateway, host and router as specified in CVIS. The gateway is the interface to legend systems and manufacturer specifics like vehicle sensors. The host is the computer where the software is deployed, while the router is the access to system components providing the required SMARTFREIGHT functionality or the Internet. The SMARTFREIGHT functionality is specified by the logical parts of the framework architecture, and this functionality is implemented by the system components as specified in Table 11. Table 12 Relations between system components and conceptual and logical aspects System Realises the conceptual and logical parts of the framework architecture comRoles Objects Use cases Service Interfaces ponents (see 9.2) OGE
Transport On-Load Item Operation Worker Equipment/ On-Item Equipment
Transport Sector Support. Monitor and Report On Item (see 7.1)
IItem
OBE
Transport Worker‟s Operation Worker Equipment
Execute Transport Operation (see 5.2.2)
IResource IItem IVehicle ITOP ITOS
Driver‟s Equipment
On-board Management (see 5.3)
ITrafficManagement IVehicle ITNS IRoute IItem
On-Board Manager
D5.2 The SMARTFREIGHT framework architecture
113
SMARTFREIGHT
RSE
Transportation Network Infrastructure Manager Traffic Manager (Distributed solution: Applications that represent the Traffic Manager are running on the RSE)
Transportation Support Transportation Network Network Continuous Operation (see Equipment 6.2.3) Perform Dynamic Traffic Management Planning (see 6.1.2.1)
ITrafficManagement
Manage Presence in Controlled ITrafficManagement Area (see 6.1.2.3.5.2) IVehicle ITNS Provide Traffic Situation IRoute Information (see 6.1.2.5)
FDMS
Transport Operation Manager
Manage Transport Operation (see 5.2.1)
IResource ITrafficManagement ITNS IVehicle ITOP ITOS IRoute
UTMS
Traffic Manager
Perform Operational Traffic Management (see 6.1.2)
ITrafficManagement ITNS IVehicle IRoute
Transportation Network Resource Manager
Manage Transportation Network IResource Resources (see 6.1.3)
CC
Transportation Network Infrastructure Manager
Transportation Support Transportation Network Application management Network Continuous Operation (see as described in 10.3 Equipment 6.2.3)
From service interfaces in Table 11 it can be derived that the system components have to realise the APIs corresponding to the service interfaces (see 9.2). They will enable the required information exchange.
D5.2 The SMARTFREIGHT framework architecture
114
SMARTFREIGHT
10.5.3 Information exchange The table below is an extension of Table 9 on page 84 (the entries that are not directly related to SMARTFREIGHT are removed): From Table 9: Name of information flow (as used in the activity diagrams in Chapter 8) System component followed by source and destination domains and activities (from Table 9). The SMARTFREIGHT service interfaces and APIs to be used to realise the information flows (see 9.2 for details). How the information flow is triggered. Both decentralised solutions with RSEs as well as centralised solutions without RSEs are described. CVIS facilities to be used to realise the information flow. The bold keywords refer to the descriptions in section 10.4. Table 13 Information flows with source, destination and linkage to information view InfoFlows
System component Source Domain/ Activity
APA policy UTMS (represented by RSE) Transportation Network Utilisation. Perform Operational Traffic Management. Perform Dynamic Traffic Management Planning. APA policy UMTS Transportation Network Utilisation. Perform Operational Traffic Management. Perform Dynamic Traffic Management Planning.
System component Service Interface Destination Domain/Activity API OBE
ITrafficManagement:
On-board Management. Manage Vehicle and Transport Operation Information. Process Access and Priority Offers
getAPApolicy (sent by OBE to RSE)
FDMS
ITrafficManagement:
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Plan Transport Operation.
getAPApolicy (initiated by Transport Operator)
D5.2 The SMARTFREIGHT framework architecture
115
Triggered by
CVIS facilities to be used
Advertisement from RSE on area boarder or On-board Geofencing appl.
RSE Service Advertisement OBE will respond with a Service Call via onboard internet access
Need for information NA (internet) on dynamic policy
SMARTFREIGHT
APA policy UMTS Transportation Network Utilisation. Plan Transportation Network Utilisation.
APA policy UMTS
APO
APO
FDMS
ITrafficManagement:
Transport Operation getAPApolicy (initiated by Management. Manage Transport Operator) Transport Operation. Plan and Prepare Transport Operation. Adapt to Traffic Management Policy CC
ITrafficManagement:
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Operate Transportation Network Equipment
Transportation Network uploadAPApolicy (initiated Infrastructure Management. by Traffic Manager) Support Transportation Network Continuous Operation.
FDMS
OBE
ITrafficManagement:
Transport Operation Management. Manage Transport Operation. Control Transport Operation. Request Traffic Management Measure
On-board Management. Manage Vehicle and Transport Operation Information. Manage Certificates
pushAPO (initiated by Transport Operator)
UMTS
OBE
ITrafficManagement:
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Access and Priority Assignments
On-board Management. Manage Vehicle and Transport Operation Information. Manage Certificates
getAPO (initiated by OBE)
D5.2 The SMARTFREIGHT framework architecture
116
Need for information NA (internet) on default policy
Policy updates
Service Call from Traffic Manager.
Need for information OBE Service Call via onprovision board internet access
Need for APO
OBE Service Call via onboard internet access
SMARTFREIGHT
APO
UMTS
FDMS
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Access and Priority Assignments
Transport Operation getAPO (initiated by Management. Manage Transport Operator) Transport Operation. Control Transport Operation. Request Traffic Management Measure
OBE Entry notification On-board Management. Exit Manage En-Route Reporting. notification Report Vehicle Access Information
Item Info
Item info
ITrafficManagement:
UMTS (represented by RSE) IVehicle:
Need for APO
NA (internet)
RSE service advertisement
RSE Service Advertisement
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Presence in Controlled Area.
pushVehcleEntryNotification (sent by OBE) or pushVehcleExitNotification (sent by OBE)
OBE will do Service Call via on-board internet Entry/exit notification access requested in APA Policy.
OGE
OBE
IItem:
OBE need for info
Transport Sector Support. Monitor and Report Item. Monitor and Report on Item. Manage and Report Item Information.
On-board Management. Manage Vehicle and Transport Operation Information. Manage Transport Operation Information
getItemInfo (initiated by OBE)
Item‟s info report requirements
OGE
OBE
IItem:
Need for item info
Transport Sector Support. Monitor and Report Item. Monitor and Report on Item. Manage and Report Item Information.
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress
getItemInfo (initiated by OBE)
Item‟s info report requirements
D5.2 The SMARTFREIGHT framework architecture
pushItemInfo (initiated by OGE)
pushItemInfo (initiated by OGE)
117
OBE Service Call via onboard internet access OGE Service Call via on-board internet access
Service Call from Transport Operation Worker, via on-board internet access OGE Service Call via on-board internet access
SMARTFREIGHT
Item status OGE
OBE
IItem:
Need for status info
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress
getItemStatus (initiated by OBE)
Item‟s status report requirements
OBE
IItem:
Need for status info
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress
getItemStatus (initiated by OBE)
Item‟s status report requirements
OGE
OBE
IItem:
Transport Sector Support. Monitor and Report Item. Track and Report Item Position.
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress.
getItemTracking (initiated by OBE) Item‟s tracking requirements pushItemTracking (initiated by OGE)
OBE
ITrafficManagement:
On-board Management. Operate Vehicle. Support and Control Vehicle Operation. Support Navigation
pushNotification (initiated by RSE if decentralised monitoring, else initiated by the Traffic Manager)
Transport Sector Support. Monitor and Report Item. Manage and Report Item Condition and Deviations. Item status OGE Transport Sector Support. Monitor and Report Item. Track and Report Item Handling.
Item tracking
Notification UMTS (represented by RSE) Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Presence in Controlled Area
pushItemStatus (initiated by OGE)
OGE Service Call via on-board internet access
pushItemStatus (initiated by OGE) Need for tracking info
RSE towards individual vehicle: On need for dynamic access control On illegal access
118
Service Call from Transport Operation Worker, via on-board internet access OGE Service Call via on-board internet access
RSE on need for information broadcasts.
D5.2 The SMARTFREIGHT framework architecture
Service Call from Transport Operation Worker, via on-board internet access
Service Call from Transport Operation Worker, via on-board internet access OGE Service Call via on-board internet access The RSE will send the notification to the individual OBE in a Service Call via internet to the IP address received in the Entry Notification. Broadcasts: RSE Service Advertisement with or without properties. Notification can be included or the OBE will respond with a Service Call via on-board internet access
SMARTFREIGHT
Resource allocation
UMTS
OBE
IResource:
Transportation Network Utilisation. Manage Transportation Network Resources. Assign Transportation Network Resource.
Transport Operation Management. Execute Transport Operation. Manage Transport Network Resource Bookings.
getResourceStatus getResourceBooking
Resource demand or changes in demand handled by the driver
Service Call via onboard internet access
Resource demand or changes in demand handled by the operator
NA (internet)
Driver needs route guidance from the operator
Service Call via onboard internet access
Driver needs route guidance from the traffic manager
Service Call via onboard internet access
updateResourceBooking cancelResourceBooking (all initiated by Transport Operation Worker from OBE)
Resource allocation
Route
Route
UMTS
FDMS
IResource:
Transportation Network Utilisation. Manage Transportation Network Resources. Assign Transportation Network Resource.
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Prepare Use of Transport Network Resources and Services
getResourceStatus
FDMS
OBE
IRoute:
Transport Operation Management. Manage Transport Operation. Control Transport Operation. Provide Route Guidance
On-board Management. Operate Vehicle. Support and Control Vehicle Operation. Use Information Services
getRoute (initiated by OBE)
UMTS
OBE
IRoute:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Route and Navigation Information
On-board Management. Operate Vehicle. Support and Control Vehicle Operation. Use Information Services
getRoute (initiated by OBE)
D5.2 The SMARTFREIGHT framework architecture
getResource updateResourceBooking cancelResourceBooking (all initiated by Transport Operator)
119
SMARTFREIGHT
Route
Safety status
TNS
TNS
UMTS
FDMS
IRoute:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Route and Navigation Information
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Plan Transport Operation
getRoute (initiated by Transport Operator)
OBE
UMTS (represented by RSE) IVehicle:
On-board Management. Manage En-Route Reporting. Report Vehicle Safety Related Information
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Presence in Controlled Area
pushSafetyStatus (sent by OBE – triggered by RSE or geo-fencing))
UMTS
CC
ITrafficManagement:
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Operate Transportation Network Equipment
Transportation Network uploadTNS (initiated by Infrastructure Management. Traffic Manager) Support Transportation Network Continuous Operation.
OBE
FDMS
ITNS:
On-board Management. Manage En-Route Reporting. Support Traffic Situation Reporting.
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Manage Performance
pushTNS
D5.2 The SMARTFREIGHT framework architecture
120
Operator needs route guidance from the traffic manager
NA (internet)
RSE service announcement
RSE Service Advertisement with or without properties.
Vehicle reporting requirements in APA The OBE will respond with a Service Call via Policy. on-board internet access.
TNS updates
Service Call from Traffic Manager.
Driver will provide TNS information to the operator
Service Call via onboard internet access.
SMARTFREIGHT
TNS
TNS
TNS
TNS
FDMS
OBE
ITNS:
Transport Operation Management. Manage Transport Operation. Control Transport Operation. Provide Route Guidance
On-board Management. Operate Vehicle. Support and Control Vehicle Operation. Use Information Services
getTNS (initiated by OBE)
UMTS
OBE
ITNS:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Incident and Accident Information
On-board Management. Operate Vehicle. Support and Control Vehicle Operation. Use Information Services
getTNS (initiated by OBE)
UMTS
OBE
ITNS:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Traffic Flow Information
On-board Management. Operate Vehicle. Support and Control Vehicle Operation. Use Information Services
getTNS (initiated by OBE)
UMTS
OBE
ITNS:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Transportation Network Condition Information
On-board Management. Operate Vehicle. Support and Control Vehicle Operation. Use Information Services
getTNS (initiated by OBE)
D5.2 The SMARTFREIGHT framework architecture
pushTNS (initiated by RSE)
pushTNS (initiated by RSE)
pushTNS (initiated by RSE)
121
Driver needs TNS information from the operator
Service Call via onboard internet access.
Driver needs info (incidents and accidents) from the traffic manager or RSE publishes such info.
OBE initiates Service Call via on-board internet access
Driver needs info (traffic flow) from the traffic manager or RSE publishes such info.
OBE initiates Service Call via on-board internet access
Driver needs info (network conditions) from the traffic manager or RSE publishes such info.
OBE initiates Service Call via on-board internet access
RSE Service Advertisement with or without properties. The OBE will respond with a Service Call via on-board internet access.
RSE Service Advertisement with or without properties. The OBE will respond with a Service Call via on-board internet access.
RSE Service Advertisement with or without properties. The OBE will respond with a Service Call via on-board internet access.
SMARTFREIGHT
TNS
TNS
TNS
TOP
TOS
UMTS
FDMS
ITNS:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Traffic Flow Information
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Manage Performance
getTNS (initiated by Transport Operator)
UMTS
FDMS
ITNS:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Incident and Accident Information
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Plan Transport Operation
getTNS (initiated by Transport Operator)
UMTS
FDMS
ITNS:
Transportation Network Utilisation. Perform Operational Traffic Management. Provide Traffic Situation Information. Provide Transportation Network Condition Information
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Plan Transport Operation
getTNS (initiated by Transport Operator)
FDMS
OBE
ITOP:
Transport Operation Management. Manage Transport Operation. Plan and Prepare Transport Operation. Provide Transport Operation Information.
Transport Operation Management. Execute Transport Operation. Manage Transport Operation Information and Progress
getTOP (initiated by OBE)
OBE
FDMS
ITOS:
Transport Operation Management. Execute Transport Operation. Report on Transport Operation.
Transport Operation getTOS (initiated by Management. Manage Transport Operator) Transport Operation. Monitor pushTOS (initiated by OBE) Transport Operation. Record Transport Operation Progress.
D5.2 The SMARTFREIGHT framework architecture
pushTOP (initiated by Transport Operator)
122
Operator needs traffic flow information from the operator
NA (internet)
Operator needs NA (internet) incident and accident information from the traffic manager
Operator needs network condition information from the operator
NA (internet)
Need for TOP information
Service Call from Transport Operation Worker, via on-board internet access.
New or updated TOP
Internet from Transport Operator. Service Call via onTOS reporting requirement in TOP. board internet access.
SMARTFREIGHT
OBE
FDMS
On-board Management. Manage En-Route Reporting. Report Vehicle Tracking Information.
Transport Operation Management. Manage Transport Operation. Monitor Transport Operation
OBE
UMTS (represented by RSE) IVehicle:
On-board Management. Manage En-Route Reporting. Report Vehicle Tracking Information.
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Track Vehicle
pushVehicleTracking (sent by OBE – triggered by RSE or geo-fencing or time interval)
Transport problem
OBE
FDMS
IVehicle:
Transport Operation Management. Execute Transport Operation. Report on Transport Operation.
Transport Operation Management. Manage Transport Operation. Control Transport Operation. Handle Transport Problems
pushTransportProblem (initiated by OBE)
Vehicle info
OBE
UMTS (represented by RSE) IVehicle:
On-board Management. Manage En-Route Reporting. Report Vehicle Access Information
Transportation Network Utilisation. Perform Operational Traffic Management. Perform Traffic Control. Control Individual Vehicle. Manage Presence in Controlled Area.
Tracking
Tracking
D5.2 The SMARTFREIGHT framework architecture
IVehicle:
Service Call from Vehicle tracking requirements in Transport Operator, via getVehicleTracking (initiated Route Plan (in TOP) on-board internet access. by Traffic Operation Service Call via onManager) board internet access. pushVehicleTracking (sent by OBE)
pushVehicleData (initiated by OBE)
RSE service announcement or
RSE Service Advertisement with or without properties.
Service Call via onVehicle reporting board internet access. requirements in APA Policy. Transport problem occurred
Service Call from Transport Operation Worker, via on-board internet access.
RSE service announcement
RSE Service Advertisement with or without properties.
or
Service Call via onVehicle reporting board internet access. requirements in APA Policy.
123
SMARTFREIGHT As mentioned above, the service interfaces and API identified in 9.2 defines the information exchange possibilities between the system components, and they are implemented by the system components as described in Table 11. Figure 58 shows an access control example by means of a sequence diagram showing the interactions between the OBE and the RSE. The left column is the OBE acting on behalf of the On-board Manager. The right column is the RSE, which runs applications that are representing the Traffic Manager. sd EntryExitControl «interface»
«interface»
PhysicalArchitecture::OBE::Driver's Equipment::DEInterface
PhysicalArchitecture::RSE::RSEInterface
getAPApolicy(ControlledAreaID)
getAPApolicy(ControlledAreaID) :AccesAndPriorityAssignmentPolicy Process policy and wait for checkpoint()
alt No reason for access restrictions Checkpoint identified() pushVehicleEntryNotification(VehicleEntry)
pushNotification(access granted)
Consider access request()
Drive through Controlled Area to checkpoint() pushVehicleExitNotification(VehicleExit)
alt Access cannot be granted imediatly. Vehicle has to w ailt.
Checkpoint identified() pushVehicleEntryNotification(VehicleEntry) Consider access request() pushNotification(acces posponded) Find available timeslot() Wait for access() pushNotification(access granted) Drive through Controlled Area to checkpoint() pushVehicleExitNotification(VehicleExit)
Figure 58 Sequence diagram for access management example In this case the need for entry and exit notifications is published via the APA policy. At certain checkpoints (presuming close to the boarders of a Controlled Area), the vehicle has to send entry and exit notifications. The APA policy will in this case also specify that access will be dynamically assigned. The example shows 2 alternatives. In the first case, access to the Controlled Area is granted at once. In the second case, access is postponed, and the vehicle has to wait for a notification that tells that access is granted.
D5.2 The SMARTFREIGHT framework architecture
124
SMARTFREIGHT
10.6 Localisation Localisation has two sides; the exact position of an object (e.g. a vehicle and its goods), and the description of a location (i.e. point, linear line and area in the transportation network). Both are highlighted below. 10.6.1 Positioning To be able to position vehicles and their goods, the Global Positioning System (GPS) is used [24]. GPS is a Global Navigation Satellite System (GNSS) that gives the longitude and latitude coordinates of a GPS receiver. The GPS signal is further enhanced with EGNOS [25], which is meant to supplement GPS by reporting on the reliability and accuracy of the signals. In addition to the GNSS coordinates, each vehicle will have an accelerometer, a gyrometer, and an odometer to make the positioning even more reliable and accurate. These additional components are especially valuable in areas where the GPS signals are weak. The SMARTFREIGHT applications will retrieve the position from positioning services in the CVIS service platform. These services are offered by the Position and Mapping (POMA) subproject of CVIS [9]. 10.6.2 Location referencing To describe and represent an area or point unambiguously on a map demands a location referencing method. Such methods differ in the way they work; table look-up of predefined codes like in TMC [26] and TPEG-Loc [27] is one alternative, while dynamic on-demand calculations like in AGORA-C [28] and OpenLR [29] is another alternative. These four methods are described in more detail in Annex C. SMARTFREIGHT will, as CVIS, use the AGORA-C reference method. AGORA-C is a well proven and accurate method that suits the needs of SMARTFREIGHT. AGORA-C references and map matching services are available from the POMA services in the CVIS service platform for all SMARTFREIGHT applications to use.
D5.2 The SMARTFREIGHT framework architecture
125
SMARTFREIGHT
11 Deployment This chapter describes how the SMARTFREIGHT framework architecture can support the realisation of the SMARTFREIGHT functions and services in different cities with different needs. The concepts defined by the framework architecture are crucial for the deployment. 11.1 Concepts supporting the realisation of different traffic management strategies All cities are different, and the traffic management strategies towards freight distributions also differ. Some cities have broad streets and prefer deliveries by few larger vehicles, whilst others have narrow streets and require deliveries by smaller vehicles. Different areas and road segments may need access restrictions or monitoring due to safety, environmental or efficiency reasons, and the access assignment strategies to resources like loading bays and holding areas should also be flexible. Hence, the cities should be allowed to define conditions for access and monitoring depending on local needs. The SMARTFREIGHT framework architecture defines generic mechanisms that support the realisation of the traffic management strategies in different cities. It is up to the cities to define their strategy by means of concepts such as: Controlled Areas - i.e. areas or sections of the network that are monitored or have access restrictions dependent on the individual vehicle properties and other conditions. Controlled areas may for example be tunnels where vehicles carrying dangerous goods are monitored or green areas of cities where access is given to only green vehicles. As a part of the strategic traffic management planning, the cities have to define the APA Policies (see below) associated to their Controlled Areas. Transportation Network Resources - i.e. sections of the network that can be assigned to individual vehicles, for example loading bays and parking lots that have to be pre-booked. Transportation Network Resources must be defined as described in Figure 44. Transportation Network Resources may also be Controlled Areas to arrange for monitoring and access control. Checkpoints – i.e. locations where information is collected from or provided to vehicles. Access and Priority Assignment (APA) policy – i.e. a formal definition of the traffic management rules for a Controlled Area. There must be default APA policies for normal traffic conditions. In addition there may be dynamic APA policies in case of traffic situations that require specific measures. An APA policy may define the required vehicle properties for priority or access to the controlled area, the properties of the vehicles to be monitored in the controlled area, vehicle reporting requirements, etc. An APA policy is defined as described in Figure 45, and it is related to a Controlled Area as defined in Figure 43. Access and Priority Offer (APO) – i.e. priorities and access rights assigned to an individual vehicle for a Controlled Area. APOs may be defined in two ways. Normally the APO depends on the vehicle properties and is dynamically derived from the APA policy as the vehicle drives through the transportation network (see Annex E). However, APOs may also be assigned to vehicles on request (if that is possible according to the policy), for example in return of a fee. In short, the deployment of the SMARTFREIGHT solutions must include several steps: As a part of the strategic planning. The city must: Define its Controlled Areas Define the default APA policies associated to the Controlled Areas, i.e. the conditions for assess and monitoring. There may be a need for different APA policies for different time periods, e.g. special APA policies for rush hours.
D5.2 The SMARTFREIGHT framework architecture
126
SMARTFREIGHT
Consider how abnormal traffic situations should be handled and define templates for dynamic APA policies for foreseen situations. The strategy for assignment of APOs on request should be considered. APOs may for example be assigned to vehicles in return of a fee. Define Transportation Network Resources and the access conditions. They may also be defined as Controlled Areas to arrange for monitoring and control. Consider how situations awareness established by the monitoring of Controlled Areas should be used in regulation enforcement and emergency management. Decide how the required information exchange with the vehicles should be realised. Road Side Equipment (RSE) may have to be installed at certain locations, or the vehicles may have to report to central servers via internet connections. The decisions must be reflected in the VehicleReportingRequirements in the APA policies and in assigned APOs (see Figure 45). Different reporting requirement strategies are described in 9.1.9. Establishment of technical infrastructure. If relevant, Road Side Equipment and central systems must be installed and the required applications must be developed (or purchased) and installed. The SMARTFREIGHT APIs (see Table 10 and the definitions of the APIs in section 9.1) should simplify the development. The Host Management Centre and the management and distribution of applications to RSEs and OBEs must be planned and established (see 10.3). The operation of the SMARTFREIGHT solutions. The operation should include a continuous monitoring of and adoption to the traffic and environmental situation. Dynamic APA policies should be issues whenever required. The Host Management Centre should administrate the installations and updates of applications 11.2 Realisation of SMARTFREIGHT functions SMARTFREIGHT has identified a list of relevant functions, see Table 13, and a selection of these functions are demonstrated, simulated and evaluated at the demonstrations sites. Table 13 refers to the relevant service interfaces (see Table 10) to be used in realisations. Table 14. Functions to be supported and how they can be realised Functions
Realisation
Service interface
A1
The area to be controlled must be defined as a Controlled Area.
ITrafficManag ement
Traffic control depending on service level
The APA policy for this Controlled Area must be defined. Different “service levels” are represented as different sets of vehicle properties. The priorities and access rights associated with the different sets of properties are defined. The APA policy with access rights and priorities are provided to the vehicles so that they can compute their APOs (see Annex E).
A2
Conditional route assignment, including green areas
The calculation of conditional routes is distributed to the vehicles. Access rights are provided to the vehicles as a part of the APA policy (see A1), and the vehicles can compute their APOs and plan their routs
D5.2 The SMARTFREIGHT framework architecture
ITrafficManag ement IRoute
127
SMARTFREIGHT
accordingly. Thus, green areas can be avoided by those vehicles that do not have access. APO can also be assigned to vehicles independent of the APA policy (on demand). A vehicle may also request routing support or routes may be provided to vehicles. A3
Tracking of dangerous The area in which the tracking shall take place must goods be defined as a Controlled Area.
ITrafficManag ement
The APA policy for the area must define the properties of the vehicles that are to be tracked and the tracking IVehicle must be facilitated by the VehicleReportRequirements in the APA policy (see 9.1.3). Thus, the APO computed by the vehicle will define the VehicleReportRequirements for that vehicle. (APOs with may also be provided to vehicles independent of the APA policy.) Depending on the VehicleReportRequirements, different measures are possible: Tracking information to traffic management: The VehicleReportRequirements may require that tracking information is reported at certain intervals or at certain locations. Awareness about vehicles in Controlled Areas, e.g. tunnels: The VehicleReportRequirements may require that entry and exit information is reported on entry to/exit from a controlled area (e.g. a tunnel). A4
Incident management support
Entry and exit detection that support awareness about ITrafficManag vehicles in controlled areas (se A3) and tracking of ement selected vehicles (see A3) may support incident IVehicle management. Since awareness about the presence of vehicles may support the decisions to be taken in case of incidents. Dynamic access assignment to controlled areas is also supported. Vehicles may receive notifications telling them that access to a Controlled Area not has been granted. This may also support the incident management. Vehicles may also be asked to report safety related information. Awareness about the safety status of vehicles may also support incident handling.
A5
Data collection for Vehicles can be asked to report vehicle information for IVehicle statistics and planning statistics.
A6
Enforcement support
Entry and exit location and tracking support the detection of unauthorised entries to controlled areas. This information can be used in enforcement.
ITrafficManag ement
A7
Provision of traffic data to freight distribution management systems
Such data can be provided in a standard way.
ITNS
B1
New data exchange with the traffic
Many types of relevant information may be requested from the traffic management system such as: traffic
D5.2 The SMARTFREIGHT framework architecture
128
SMARTFREIGHT
management system
data, traffic condition information, route information.
B2
Return load coordination
The APA policy may promote return load by assigning ITrafficManag access rights and priorities to vehicles carrying return ement load. IResource Resource bookings, APOs and TOPs support ITOP dynamic planning and dynamic return load coordination.
B3
Shared use of vehicle coordination
Standardised interfaces towards the vehicle support shared use.
ITOP
Planned use of loading/unloading area
Access to default APA policy supports the planning of deliveries.
ITrafficManag ement
The routes can be planned depending on the APA policy, and resources such as loading bays can be booked to fit with the plan. Resources can also be rebooked and cancelled in case of changed plans.
IResource
B4
B5
B6
Load unit tracking and Load Items can be tracked and monitored by the monitoring OBE, and the status can be provided to back offices, etc. Waiting area
ITOS
IItem ITOS
The APA policy may refer to holding areas that can be ITrafficManag used when vehicles have to wait for their time slots. ement Depending on the policy, holding areas may be booked.
IResource
C1
Routing support
Vehicles may request route calculation support
IRoute
C2
Service level
The properties of the vehicles will decide its access rights and priorities.
ITrafficManag ement
C3
Transport operation planning support
Transport Operation Plans, APA polices and resource bookings support the planning
ITOP IResource ITrafficManag ement
C4
Timeslot allocation for loading/ unloading
Resources such as loading bays can be booked, rebooked and cancelled.
IResource
C5
Load/unload tracking + status information
Status can be reported
ITOS
C6
Efficient communication with distribution centre
Transport Operation Plans and status information can be exchanged.
ITOP
D5.2 The SMARTFREIGHT framework architecture
ITOS
129
SMARTFREIGHT
12 Terminology This chapter defines some terms that are important to the overall understanding of SMARTFREIGHT framework architecture. However, the list is not complete as the report itself defines terminology with respect to roles, decomposition of the transport sector, functions, interactions, information elements, etc. 12.1 Access and Priority Assignment (APA) policy A Controlled Area will have an Access and Priority Assignment (APA) policy that defines: The Access and Priorities Offers (APOs) to be assigned to vehicles depending on their Vehicle Characteristics. Reporting requirements related to access rights. Two types of APA policies may be available: A default APA policy, which is defined based on the normal traffic situation for the relevant time period (e.g. during rush hours, outside rush hours and on specific days). The default policy may be used for long term planning of transport operations. Dynamic APA policies, which are defined depending on the current traffic situation. The dynamic policies should be considered during the short term planning of transport operation and during the execution of the operations. During normal traffic situations, the dynamic APA policy will be equal to the default APA policy. The dynamic APA policy is provided to the vehicles, and the vehicle‟s current APOs can be derived from the policy. See content definition in information model in 9.1.1 and 9.1.3. 12.2 Access and Priority Offer (APO) The APO informs the On-board Manager, and if relevant also the navigation system, about the access and priorities permissions of the vehicle in certain Controlled Area. It defines among others: The related APA policy version on which it is based The vehicle to which it is valid The period for which it is issued (specified by a from and a to date and time) The time for which the APO is valid, i.e. which weekday and time slots (specified by to from and to hours). The Controlled Area(s) that are covered by the APO Access rights in these Controlled Areas (tunnels, green areas of the city, bus lanes, etc.) Access rejections in these Controlled Areas Priorities in these Controlled Areas See content definition in information model in 9.1.3. An APO defines the access rights and priorities assigned to a vehicle in a certain Controlled Area. An APO can be assigned to a vehicle in two ways The APO can be derived from an APA policy. The APO can be assigned based on request for a specific APO.
D5.2 The SMARTFREIGHT framework architecture
130
SMARTFREIGHT
12.3 Checkpoint A location in the Transportation Network. See 12.14. for description 12.4 Controlled Area A Controlled Area is a Transportation Network Section that has assigned an Access and Priority Assignment (APA) policy which defines how access rights and priorities should be assigned to the vehicles in this area and/or which vehicles that should be monitored in the area. On entry to and exit from Controlled Areas there will be interactions between the On-board Manager and Traffic Manager. The latter may be represented by the RSE. These interactions may contain different combinations of information flows, such as: Entry notification (from OBE to RSE) Exit notification (from OBE to RSE) Vehicle info (from OBE to RSE) Safety Status (from OBE to RSE) Tracking (from OBE to RSE) APA Policy (from RSE to OBE) Notification (from RSE to OBE) 12.5 Entry Notification Sent to Traffic Manager (may be represented by the RSE) on entry to Controlled Area (if required). See content definition in information model in section 9.1.5. 12.6 Exit Notification Sent to Traffic Manager (may be represented by the RSE) on exit from Controlled Area (if required). See content definition in information model in section 9.1.5. 12.7 Handling Instruction Specifies how a Transport Item shall be handled (temperature, etc.) during a specific Transport Operations (loading, unloading, other terminal operations, transport on a vehicle, etc.). 12.8 Incident An abnormal and unplanned situation that may affect safety or the traffic flow in a negative way, e.g.: Situations that may lead to emergency situations (e.g. accident, regulation violation, error, robbery) Specific Transportation Network Conditions that may need attention Specific environmental conditions (e.g. pollution or weather conditions) 12.9 Incident and Accident Information Information about Incidents and accidents is provided. The information is reported in the Transportation Network Status (TNS), which is based on DATEX II. See information model in section 9.1.4.
D5.2 The SMARTFREIGHT framework architecture
131
SMARTFREIGHT
12.10 Load Item The cargo unit to be transported, as seen from the Transport Operator‟s and Transport Operation Worker‟s point of view. May be a load unit, or general cargo. Several Transport Items may be combined into one Load Item. 12.11 Tracking Information The tracking information is provided to the Traffic Manager (may be represented by the RSE) or Transport Operator. It may be provided periodically, at specific locations, on specific events or on request. See content definition in information model in section 9.1.5. 12.12 Traffic Flow Information May include: Traffic flow, such as traffic density, speed, journey times and delay. Abnormal traffic conditions such as congestion followed by information about length of queue, the likely duration, the estimated delay, the reasons for the abnormal condition Warnings like about car travelling on wrong side of road, accident ahead, etc. The information is reported in the Transportation Network Status (TNS), which is based on DATEX II. See information model in section 9.1.4. 12.13 Traffic Information Includes Incident and Accident Information and Traffic Flow Information. The information is reported in the Transportation Network Status (TNS), which is based on DATEX II. See information model in section 9.1.4. 12.14 Transportation Network Physical infrastructure for transport. It that enables movement (e.g. roads, equipment along the roads and transfer nodes, i.e. terminals) and handling of cargo (e.g. Transportation Network Resources like loading bays). Holding Area
Terminal Terminal areas Stop points
Stop points
Terminal Bus lane
Green area Loading bays
Checkpoint Controlled Area Transportation Network Resource
Area with DG restrictions
Tunnel
Figure 59 Transportation Network As illustrated in Figure 59, a Transportation Network may contain Controlled Areas (for example green areas, areas with dangerous goods restrictions, holding areas or terminal areas) and Transportation Network Resources (for example terminal areas, stop pints at
D5.2 The SMARTFREIGHT framework architecture
132
SMARTFREIGHT
holding areas or terminal areas and loading bays), and there may be Checkpoints along the infrastructure. See 3.3 for further description. 12.15 Transportation Network Condition Dynamic information about abnormal and unplanned conditions in the Transportation Network due to situations that cannot be controlled (weather, incidents, accidents, etc.). For example surface conditions such as slippery roads; obstructions; restricted view; or reduced capacity. The abnormal and unplanned conditions may lead to regulatory decisions (e.g. reduced speed limit). Such regulations are however a part of the Transportation Network Information. The Transportation Network Condition information is reported in the Transportation Network Status (TNS), which is based on DATEX II. See information model in section 9.1.4. 12.16 Transportation Network Information Information about the physical Transportation Network, information about the regulations valid in the Transportation Network included (e.g. speed limit and restrictions with respect to height, width, weight, etc.) The information content is outside the scope of SMARTFREIGHT, but may for example include: Transportation Network Section ID Type information (e.g. road, lane, junction, holding lot, loading bays, terminal lot, etc.) The Transportation Network geometry, size and location information Regulations, normal as well as specific regulations due to Transportation Network conditions and events e.g. closed roads, platooning, reduced speed, etc. For example restrictions (with respect to weight, width, height, etc.), access restrictions (green zones, etc.), speed limits Condition information – conditions caused by planned/foreseen activities/events, e.g. situations that may influence on quality or capacity (e.g. roadwork) Suitability information (for different vehicle types) Transportation Network Resource information for example: Availability information (number of free spaces, etc.), assignment policy (booking required, first come first served, etc.), price information, associated services (restaurant, gas station, toilets, etc.) The provision of Transportation Network information is not an issue in SMARTFREIGHT, but the Transportation Infrastructure Manager should publicise information relevant to those planning and providing freight distribution services. 12.17 Transportation Network Status (TNS) The Transportation Network Status (TNS) is based on DATEX II. It provides information to On-board Managers, Transport Service Providers and others reflecting a total assessment of the traffic situation that may affect safety and efficiency. If possible, several types of information such as Traffic Information (including Traffic Flow Information and Incident and Accident Information), Transportation Network Information and Transportation Network Condition should to be included. See information model in section 9.1.4.
D5.2 The SMARTFREIGHT framework architecture
133
SMARTFREIGHT
12.18 Transport Item The goods unit to be transported, as seen from the Transport User‟s point of view. May be a load unit, a trade unit or general cargo. Will by the Transport Service Provided be “transformed” into a Load Item. Several Transport Items may be combined into one Load Item. 12.19 Transport Execution Plan (TEP) The definition of the transport service that is requested by the Transport User. Is used as a transport service booking. 12.20 Transport Execution Status (TES) The status of a transport booking. Is related to a Transport Execution Plan (TEP). 12.21 Transport Operation An operation that contribute to the fulfilment of transport services, and is usually related to movement and handling of Load Items. A transport operation is executed according to a Transport Operation Plan (TOP). Status is reported by means of a Transport Operation Status (TOS). May include one or more Transport Tasks. 12.22 Transport Operation Plan (TOP) Specifies how a Transport Operation is to be executed. A TOP may include: The route for the specific transport operation, i.e. the route to be followed between the pick-up and delivery locations The work description o
The Load Items involved and, if relevant, dangerous goods descriptions
o
Pick-up and delivery locations, and if relevant, associated Transportation Network Resource Bookings (e.g. bookings of loading bays)
o
The Transport Tasks that are to be executed and associated time schedules
o
The Handling Instructions (e.g. requirements for special treatment, etc).
Reporting requirements See content definition in information model in 9.1.6. 12.23 Transport Operation Status (TOS) Provides status information related to a Transport Operation such as: Progress information Tracking information (for vehicle and/or Load Item) Condition information for Load Items See content definition in information model in 9.1.7). 12.24 Transportation Network Resource An identified resource in the Transportation Network that can only be used by one vehicle at a time. May be a Controlled Area (entry and exit may be monitored). The access is managed according to some strategy, for example First come first served Booking of timeslots (see related information in section 9.1.2)
D5.2 The SMARTFREIGHT framework architecture
134
SMARTFREIGHT
12.25 Transport Task A task related to a Transport Operation. Is described in a Transport Operation Plan. May encompass one or more Load Items, and there may be Handling Instructions related to a Transport Task. Examples of Transport Tasks: Pick-up of one or more Load Items Delivery of one or more Load Items Stripping of a Load Item(e.g. container) Stuffing of a Load Item (e.g. of container) Document handling Loading Unloading 12.26 Vehicle Characteristics The vehicle characteristics define the properties of the vehicle as described in 9.1.5., among others: The size of the vehicle; type of transport; fuel class and engine class; and cargo type (dangerous cargo included).
D5.2 The SMARTFREIGHT framework architecture
135
SMARTFREIGHT
References [1]
McLeod F. et.al., D2.1 User Needs Review, FP7-216353, TRG.
[2]
McLeod F. et.al., D2.2 "Stakeholder Consultations and System Performance Scenarios", FP7-216353, TRG.
[3]
ITS Norway. ARKTRANS Web-site. [cited 2009 25 April]; Web-page for access to information about ARKTRANS]. Available from: www.arktrans.no.
[4]
Natvig M. et al., ARKTRANS - The multimodal ITS framework architecture, Version 6. 2009, SINTEF A12001, ISBN 978-82-14-04444-7, 320 pages.
[5]
D2D project. Project http://www.d2d.no/.
[6]
Freightwise project. Project Web-site. [cited 2009 25 april]; Available from: http://freightwise.info/cms/.
[7]
The e-Freight project. The e-Freght Web-site. [cited 2010 14 December]; Available from: http://www.efreightproject.eu/.
[8]
The CVIS project. The CVIS Web-site. [cited 2009 25 April]; Available from: http://www.cvisproject.org/.
[9]
OSGi Alliance. OSGi http://www.osgi.org/.
[10]
Solberg A. et.al., CVIS D3.3 Architecture and System Specifications. 2007, DG INFOSO project FP6-2004-IST-4-027293-IP.
[11]
Hendriks T. et al., AGORA-C specification - Specification of the AGORA-C on-the-fly location referencing method. 2005.
[12]
Communication Access for Land Mobiles (CALM). ISO TC204 Working Group 16. [cited 2010 10th August]; Available from: http://www.isotc204wg16.org
[13]
Java technology. Oracle Corporation. Available from: http://java.com
[14]
Baggen M. et al. CVIS D.FOAM.3.1 Architecture and System Specifications, The CVIS-project (FP6). 2007
[15]
Deering S. and Hinden R., RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Request for Comment (RFC), The Internet Society. 1998.
[16]
Devarapalli V. et al. RFC 3963: Network Mobility (NEMO) Basic Support Protocol. Request for Comment (RFC), The Internet Society. 2005.
[17]
ISO/DIS 29281 Intelligent transport systems - Communications access for land mobiles (CALM) - Non-IP networking. ISO TC 204. 2007.
[18]
ISO 24103:2009 Intelligent transport systems - Communications access for land mobiles (CALM) - Media adapted interface layer (MAIL).ISO TC 204. 2009.
[19]
EN 12795:2003 Road transport and traffic telematics - Dedicated Short Range Communication (DSRC) - DSRC data link layer: medium access and logical link control. CEN/TC 278. 2003.
[20]
ISO/FDIS 21215:2010 Intelligent transport systems - Communications access for land mobiles (CALM) - M5. ISO TC 204. 2010.
[21]
The 3rd Generation Partnership http://www.3gpp.org/partners
Web-site.
Web-site.
[cited
2009
[cited
D5.2 The SMARTFREIGHT framework architecture
2009
Project
25
25
April];
April];
(3GPP).
Available
Available
Available
from:
from:
from:
136
SMARTFREIGHT
[22]
ISO 21212:2008 Intelligent transport systems - Communications access for land mobiles (CALM) - 2G Cellular systems. ISO TC 204. 2008.
[23]
ISO 21213:2008 Intelligent transport systems - Communications access for land mobiles (CALM) - 3G Cellular systems. ISO TC 204. 2008.
[24]
The Global Positioning System (GPS). Available from: http://www.gps.gov/
[25]
The European Geostationary Navigation Overlay Service (EGNOS). Available from: http://www.esa.int/esaNA/egnos.html
[26]
ISO, TC 204, ISO 14819-1:2003, Traffic and Traveller Information (TTI) – TTI messages via traffic message coding -- Part 1: Coding protocol for Radio Data System – Traffic Message Channel (RDS-TMC) using ALERT-C. 2003.
[27]
ISO, TC 204, ISO/TS 18234-series:2006 Traffic and Travel Information (TTI) – TTI via Transport Protocol Expert Group (TPEG) data-streams – Part 1 to 10. 2006.
[28]
ISO, TC 204, ISO 17572-3:2008 Intelligent transport systems (ITS) - Location referencing for geographic databases - Part 3: Dynamic location references (dynamic profile). 2008.
[29]
TomTom International B.V., “OpenLR White Paper”, version 1.2, 2010. Available from: http://www.openlr.org/data/docs/OpenLR-Whitepaper_v1.2.pdf
[30]
Dai X., Lv W., Zhu T. (2008). Improved Dynamic Location Reference Method AgoraC Based On Rule Optimization. International Conference on Computer Science and Software Engineering.
[31]
GST Safety Channel, Safety Channel: Prioritized safety-related traffic information, White Paper, October 2006.
[32]
ISO, TC 204, ISO 14819-1:2003, Traffic and Traveller Information (TTI) – TTI messages via traffic message coding -- Part 1: Coding protocol for Radio Data System – Traffic Message Channel (RDS-TMC) using ALERT-C
[33]
ISO, TC 204, ISO 17572-3:2008 Intelligent transport systems (ITS) - Location referencing for geographic databases - Part 3: Dynamic location references (dynamic profile)
[34]
ISO, TC 204, ISO/TS 18234-series:2006 Traffic and Travel Information (TTI) – TTI via Transport Protocol Expert Group (TPEG) data-streams – Part 1 to 10.
[35]
ISO, TC 204, ISO/TS 24530-2:2006 Traffic and Travel Information (TTI) – TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) – Part 2: tpeg-locML
[36]
The Mobile.Info-project. Available: http://www.mobile-info.org
[37]
OpenLR, TomTom International B.V. Available: http://www.openlr.org/index.html
[38]
Wevers K. and Hendriks T., AGORA-C map-based location referencing, Transportation Research Record, vol. 1972, pp 115-122, 2006.
[39]
Wikström L. et al. ROSATTE D3.1 Specification of data exchange methods, The ROSATTE project (FP7), 2009
D5.2 The SMARTFREIGHT framework architecture
137
SMARTFREIGHT
Annex A.
User requirements
SMARTFREIGHT deliverables D2.1 “User Needs Review” [1] and D2.2 – "Stakeholder Consultations and System Performance Scenarios" [2] provide a comprehensive discussion of the urban freight distribution problem area, related solutions and user needs. This section summarise the user requirements identified in D2.1 and D.2 and how they are addressed by the SMARTFREIGHT framework architecture. Some of the requirements are directly addressed, whilst others are just indirectly related. The latter requirements may for example be prerequisites for an implementation of the solutions, or the requirements can more easily be fulfilled due to the SMARTFREIGHT solutions. The tables below describe how the requirements are addressed by the SMARTFREIGHT framework architecture, and there are references to the relevant use cases (in Chapter 4, 5, 6 and 7) and information flows (see section 8.6).
A.1 The needs of city authorities The needs of the city authorities are derived from section 2.1 in D2.1 and discussion summary in D2.2. A. Requirement
How addressed in SMARTFREIGHT
See functions and information flows
A.1
Define and implement policy for priority scheme and vehicle access to city Data acquisition for statistics concerning urban freight Collaboration with freight companies to improve the operational efficiency of freight vehicles
The policy elaboration is not directly addressed. Focus is on the distribution of it to potential users. A default policy will define the Access and Priority Assignments (APAs) in normal situations. If the traffic conditions are un-normal, the APA policy may be dynamically updated.
6.1.1 (default policy) 6.1.2.1 (dynamic policy)
The tracking of vehicles and the registration of their presence will generate data for statistics. So may also the monitoring of dangerous goods (DG).
6.1.2.3.5.1 (tracking) 6.1.2.3.5.2 (presence) 6.1.2.2.2 (DG)
The provision of APA policy information and reliable information on the traffic and transportation network status (especially information about incidents and expected delays) support the planning of freight operations. The information can be delivered in real-time when needed.
6.1.1+ 6.1.2.1 (policy) 6.1.2.5 (info)
Collaboration with police (enforcement of regulations - parking, etc.)
The actual enforcement is not addressed, but can be supported: On detection of access violations or illegal use of resources (e.g. loading bays) police can be notified.
Coordinated urban freight policy
The APA actual coordination is not addressed, but the ability to represent the APA policy in a standard format may support such coordination.
6.1.1+ 6.1.2.1 (policy)
Access to real-time and detailed
The monitoring functions acquire data on environmental conditions, network conditions, traffic flow, accidents and incidents, dangerous
6.1.2.2
A.2
A.3
A.4
A.5
A.6
Info flow: APA policy
Info flow: Vehicle info
See requirement A.2 (statistics) Info flow: TNS
Better statistics also arrange for traffic management measures that can benefit freight distribution. 6.1.2.3.5.2 (access violation) 6.1.3.2 (illegal use of resource) Info flow: Notification
D5.2 The SMARTFREIGHT framework architecture
Info flow: APA policy
Info flow: TNS
138
SMARTFREIGHT
A.7
A.8
A.9
overview of current traffic situation Short-term and longterms forecasts of traffic conditions Journey time and delay estimates
Utilise available road capacity and reduce delays and congestion
goods.
The elaboration of forecasts is not addressed, but the monitoring provides data that can be used in the assessment of the current and foreseen traffic situation.
See requirement A.6 (monitoring) 6.1.2.3.1 (assessment)
The elaboration of estimates is not addressed, but the registration of vehicles at checkpoints may support journey time and delay calculations (probe vehicles). Information about travel times and delays is provided to others as a part of the route guidance and transportation network status.
6.1.2.3.5.1 (track) 6.1.2.3.1 (calculation) 6.1.2.5.3 (provision) 6.1.2.5.2 (route )
Better statistics, traffic condition estimates, dynamic APA policy (access restrictions, etc.), and individual vehicle control arrange for better utilisation of the capacity and reduced delays and congestion
See requirement A.2 (statistics) See requirement A.8 (estimates) 6.1.2.1 (policy) 6.1.2.3.5 (control)
(processing – no info flow)
Info flows: TNS, Route
(processing – no info flow) A.10 Prioritise freight vehicles
The Access and Priority Offers (APOs) to vehicles are decided by the policy. The actual prioritising is done as a part of the individual traffic management.
6.1.1+ 6.1.2.1 (policy) 6.1.2.3.5.3 (prioritising)
A.11 Provision of timetables for planned roadwork A.12 Provision of route guidance A.13 Support prebooking of parking areas and loading bays A.14 Vehicle detection
Provided as a part of the transportation network status
6.1.2.5.4
Information about specific routes for freight vehicles is provided.
6.1.2.5.2
Resources, e.g. parking lots or loading bays, can be booked and re-booked in case of changes.
6.1.3.1
Exit and entry detection at checkpoints are detected by means of tracking information and this information is used to register presence of vehicles.
6.1.2.3.5.1 (track) 6.1.2.3.5.2 (register)
Vehicles that act according to the recommendations in the policy will get privileges, e.g. vehicles that are energy effective and clean. Illegal behaviour can be automatically detected.
6.1.1+ 6.1.2.1 (policy) 6.1.2.3.5.2 (access violation) 6.1.3.2 (illegal use of resource)
A.15 Encourage better driver behaviour, including behaviour that improve the environment A.16 Late arrival to booked loading bays may be cause penalties
Info flows: APA policy, APO
Info flow: TNS
Info flow: Route
Info flow: Resource allocation
Info flow: Entry notification, Exit notification
Info flows: APA policy Not directly addressed, but unauthorised use (use outside the booked time slot included) will be registered. It is up to the city how this information is used, e.g. to issue fines
D5.2 The SMARTFREIGHT framework architecture
6.1.3.2 Info flows: Entry notification, Exit notification
139
SMARTFREIGHT
A.17 Facilitate standardised information exchange between the systems of different stakeholders A.18 Wireless communicatio n with vehicles
The open services defined in the information viewpoint facilitate interoperability.
Use of the CVIS technology facilitates communication.
Realisation by means of CVIS technology – see Chapter 10
A.19 Data needed if lorry breakdown causing network delays: Information about vehicle A.20 Data needed: Location of lorries to be controlled A.21 Vehicle data needed: Destinations (e.g. loading bays) Weight (unladen/laden) No of axles Engine type Fuel type Load factor A.22 Data needed: Loading bay data (e.g. time slots available, existing bookings). may be needed A.23 Data needed: Freight access regulations.
The vehicle can report about their safety status, including potential problems and actual problems.
6.1.2.3.5.2
The APA policy may sate that vehicles with specific properties have to report their location.
6.1.2.3.5.1
Vehicles may be tracked or they may on request provide such information when their presence is registered.
6.1.2.3.5.1 (tracking) 6.1.2.3.5.2 (presence)
If managed by the UTMS itself: Booking mechanisms facilitates the management of loading bays and related information.
6.1.3.2
This facilitate information provision, policy provision, etc.
Information viewpoint 6.1.1+ 6.1.2.1 (policy) 6.1.2.5 (info provision) Info flows: See 9.2 and 8.6.
Info flows: Safety status Vehicle info
Info flow: Tracking
Info flow: Vehicle info
Info flow: Resource allocation
If others are managing the loading bays, information on availability can be received. The APA policy provides the access regulations
6.1.2.1 Info flow: APA policy
A.2 The needs of freight distributors The needs of the freight distributors are derived from section 2.2 in D2.1 and discussion summary in D2.2. B. Requirement
How addressed in SMARTFREIGHT
See functions and information flows
B.1
Supported by dynamic planning (see B.22); adjustments of plans and behaviour according to the local APA policy; and booking of resources
5.2.1.3.1 (planning) 5.2.1.3.1 (default policy) 5.2.1.3.1 (current policy) 5.2.2.3 (booking)
In time deliveries
Info flow: APA policy,
D5.2 The SMARTFREIGHT framework architecture
140
SMARTFREIGHT
Resource allocation, APO, TNS, etc. B.2
Safety of drivers, vehicles and third parties
The APA policy can be used to increase safety. The policy may for example restrict transport of dangerous goods (DG) to certain areas/routes, and DG transport may be monitored in a better way.
5.2.1.3.1 (default policy) 5.2.1.3.1 (current policy) 5.2.1.3.3 (DG deviation and handling definition) 5.2.1.5.3 (DG monitoring) Info flow: APA policy.
B.3
B.4
B.5
B.6
B.7
Drivers must get information about any changes to tasks For dangerous goods (DG): Information about goods type, and transport requirements must be available For DG: Information about the condition of the goods must be available
Transport operation plans, updated plans included, are provided to the driver.
5.2.1.3.1
Information about DG is provided to the OBE (so that it can be reported from the vehicle).
5.2.1.3.6 (Fleet manager)
On-board the information is managed.
Info flow: TOP
The condition that qualify as deviations and required handling of such deviations can be defined.
5.2.1.3.3 (deviation and handling definition) 5.2.1.5.3 (monitoring) 5.2.1.4.3 (handling)
For DG: Information about preferred road network must be available
Information about the APA policy (with restrictions fro DG, etc.) is received from the traffic management authorities and can be used in the route planning. The default policy may be used for long-term planning. The current policy for short-term decisions and plans.
5.2.1.3.1 (default policy) 5.2.1.3.1 (current policy)
Vehicle monitoring
The vehicles are tracked.
5.2.1.5.1 (vehicle tracking)
DG can be monitored during the transport, and deviations can be detected and handled.
Info flow: TOP
Info flow: TOS
Info flow: Route
Info flow: Tracking B.8
Goods monitoring
The goods is tracked, and the condition of the goods is monitored.
5.2.1.5.2 (goods tracking) 5.2.1.5.3 (goods condition) Info flow: TOS
B.9
Safety of goods
B.10 Drivers must be able to report transport problems (accidents, vehicle problems, illness, security concerns, need for assistance, etc.) B.11 Drivers should inform about
The monitoring of the condition of the goods arrange for early measures in case of deviations
5.2.1.5.3
Information about transport problems related to a vehicle, accidents involving a vehicle and assistance needs are received from the driver.
5.2.1.4.3 (reception)
Information about deviations with respect to the transport tasks are received from the drivers.
5.2.1.4.4 (reception)
D5.2 The SMARTFREIGHT framework architecture
Info flow: TOS
Info flow: TOS
141
SMARTFREIGHT
B.12
B.13
B.14
B.15
B.16
B.17
delivery problems and ETA Drivers should inform about congestions or abnormal traffic situations Drivers must be able to get route guidance Continuous monitoring of the transport operation should be possible Check the progress of a transport operation whenever required. Compare planned progress with actual progress A frequent comparison of vehicle‟s position with planned route and schedule
B.18 Keep record of vehicle movements to document details in case of accidents, offence accusations, late delivery accusations, etc. B.19 Take remedial actions quickly in response to unexpected events
New may be ETA is provided.
Info flow: TOS
Information that may affect one or more transport operations is received from the drivers. This information is considered in the planning of new and on-going operations.
5.2.1.3.1
Route guidance may be provided to the drivers.
5.2.1.4.2
Info flow: TNS
Info flow: Route Several issues related to transport operations can be monitored (tracking of vehicle, tracking of goods, condition of goods, progress), and the status is evaluated to detect deviations of any kind.
The progress can be continuously monitored or checked whenever required
The information about the actual transport is compared with the plan.
5.2.1.5.1 (vehicle tracking) 5.2.1.5.2 (goods tracking) 5.2.1.5.3 (condition) 5.2.1.5.4 (status recording) 5.2.1.5.5 (evaluation) Info flows: Tracking, TOS 5.2.1.5.1 (vehicle tracking) 5.2.1.5.5 (detect deviation) Info flow: Tracking
The vehicles are tracked.
5.2.1.5.1 Info flow: Tracking
The transport operations are monitored and deviations are detected. Remedial actions may be taken. It is also possible to pre-define how deviations should be handled. Plans can be updated
5.2.1.5.3 (monitoring) 5.2.1.4.4 (handling) 5.2.1.3.3 (deviation handling definition) 5.2.1.3.1 (plan) Info flows: TOS, TOP
B.20 A list of vehicle stops and time stopped
Stops may be tracked.
B.21 Ability to plan efficient routes and schedules
The actual route planning is not handled, but the schedule planning is supported by awareness about the current APA policy and the ability to book resources (e.g. loading bays)
5.2.1.3.1 (planning) 5.2.1.3.1 (policy) 5.2.1.3.4 (resources)
The actual route planning is not handled, but dynamic route and schedule planning is supported by awareness about the current APA
5.2.1.3.1 (planning) 5.2.1.4.3 (input on traffic situation)
B.22 Dynamic adjustments to planned routes
5.2.1.5.1 Info flow: Tracking, TOS
D5.2 The SMARTFREIGHT framework architecture
Info flow: APA policy, TOP
142
SMARTFREIGHT
and schedules, rescheduling of tasks, etc.
policy and traffic situation (input from Network Management domain and ongoing operations); the access to Transportation Network Resources (e.g. loading bays); transport operations status and deviations.
5.2.1.4.4 (deviations)
B.23 Divert lorries to make collections
The dynamic adjustment of plans (see B.22) will also handle changes in the transport operation plans.
5.2.1.3.1 (planning)
B.24 Advice driver to change delivery plans B.25 Direct communication with sources of information
New plans will be sent to the driver.
5.2.1.3.6
The dynamic planning function will use information from the Transportation Network Utilisation domain, i.e. information about current APA policy, traffic conditions, etc.
5.2.1.3.1 (planning)
B.26 Automatic warnings in case of deviations B.27 Record status of delivery tasks and proof of delivery B.28 Support back loading
The Transport Operator may be alerted in case of deviations
5.2.1.4.4
The status is logged.
5.2.1.2
The ability of back-loading is handled by the support to dynamic planning.
5.2.1.3.1 (planning)
B.29 Support waste and return goods collection
The ability of collection of waste and return goods is handled by the support to dynamic planning.
5.2.1.3.1 (planning)
B.30 It must be possible to request loading bays of appropriate size near the required location at required time B.31 Use of open standards, e.g. for provision of fleet management information to invehicle application B.32 ICT solutions must fit with the needs of small operators
Loading bays can be booked by the fleet manager, and information provided to the driver.
5.2.1.3.4 (fleet manager) 5.2.1.3.6 (provide info)
B.33 Maximise fleet efficiency
Not addressed by SMARTFREIGHT. The dynamic planning does however consider the optimal performance and utilisation of resources.
5.2.1.3.1
B.34 Unauthorised access to information (position, cargo, destination …) should not be
Not addressed by SMARTFREIGHT. The solutions are however based on information exchange between the vehicle/operator and the city authorities. No information is made public. By means of information security measures confidentiality and integrity can be ensured.
See Annex D
Info flow: TOP
Info flow: TOP
Info flow: TOP
Info flow: TNS
Info flow: TOS
Info flow: TOS
In case of changed plans, the booking can be changed or cancelled.
The services interfaces that are specified by SMARTFREIGHT will be public available and can be used as input to standardisation
Info flow: TOP
Info flow: TOP
Info flow: Resource allocation, TOP See 9.2
The OBE is today based on prototypes from the CVIS project. In the future such CALM based equipment probably will be standard equipment in vehicles. The SMARTFREIGHT applications should be able to run on such equipment can be used by small operators.
D5.2 The SMARTFREIGHT framework architecture
143
SMARTFREIGHT
possible. B.35 Efficient payment and payment processes
Not addressed by SMARTFREIGHT. The ability to request APOs that differ from the default policy arrange for efficient fee collections in return of advantageous APOs (if the policy is to collect fees for such APOs).
5.2.1.4.1 APO requests
Info flow: APO
The On-board Equipment may also include payment functionality (but this in not addressed) B.36 Inform clients about the whereabouts of goods and expected delivery time. B.37 Inform customer in case deviations (e.g. new ETA)
Not addressed by SMARTFREIGHT. However, the monitoring and management of the transport operations arrange for such functionality in the customer relation function. These issues are addressed by the Freightwise project, and SMARTFREIGHT is coordinated with Freightwise to arrange for a total solution that supports the submission of such information to the customers.
5.1.1.2
B.38 Explanations of unscheduled or unauthorised stops.
Not addressed by SMARTFREIGHT. However, the tracking of vehicles may also detect stops, and the driver may report about and explain unauthorised stops. Such information can also be recorded.
5.2.1.5.1 (tracking) 5.2.2.2 (reporting) 5.2.1.5.4 (recording)
B.39 Support electronic signature
Not addressed by SMARTFREIGHT, but will probably follow the financial transaction.
See Annex D.
Info flow: TES
Info flow: Tracking, TOS
May also be a part of a Transport Operation Status reporting “proof of delivery”. B.40 Monitor driver and vehicle performance
Not addressed by SMARTFREIGHT, but such information may be reported from the vehicles and registered. Statistics may be generated.
B.41 Interface towards intermodal freight transport
Not directly addressed by SMARTFREIGHT, but deliveries/collections at ports can be handled like other transport tasks. The largest challenges are related to harmonisation and standardisation of the information exchange. SMARTFREIGHT will handle this through coordination with the Freightwise and e-Freight projects.
B.42 Geofencing functions to indicate when customer should be notified, when fleet manager should be notified, etc. B.43 Efficient methods for waste and return goods B.44 Telematic systems that are cost effective, flexible, interoperable, sustainable, ensure security, etc.
Not addressed by SMARTFREIGHT, but the reporting requirements provided to the driver may use geofencing. The transport operation monitoring should adapt to these requirements.
5.2.1.1 Info flow: Vehicle status
5.2.1.3.6 (reporting requirements) 5.2.1.5 (monitoring)
The service interfaces may be triggered by geofencing or by the RSE - see 9.2. Not addressed by SMARTFREIGHT, but partly covered as described in B.28 and B.29
5.2.1.3.1 (planning) Info flow: TOP
Not addressed by SMARTFREIGHT. Ensured through the use of CALM and the CVIS platform.
D5.2 The SMARTFREIGHT framework architecture
144
SMARTFREIGHT
B.45 User friendly systems and good support
Not addressed by SMARTFREIGHT. The SMARTFREIGHT prototypes do not aim at the optimal user interfaces, but proof of concept.
B.46 Information tailored to the individual driver and to the route being travelled to avoid overloading the driver with irrelevant information.
The FDMS can receive traffic and rout information from the UTMS and provide route guidance to the individual driver.
5.2.1.4.2Info flow: Route, TNS
A.3 The needs of lorry drivers The needs of the drivers are derived from the needs of the city authorities, the freight distributors and section 2.3 in D2.1 and discussion summary in D2.2. The driver may have 2 roles: The Transport Operation Worker is responsible for the execution of the transport operation tasks (see functions in section 5.2.2). The On-board Manager is responsible for the operation of the vehicle in the traffic (see Chapter 5.3). C. Requirement
How addressed in SMARTFREIGHT
See functions and information flows
C.1
Supported by dynamic updates of transport operation plans and dynamic adaptation to the APOs that can be derived from the current APA policy, Ability to request APOs and route planning that is according to APOs
5.2.2.1 (plan updates) 5.3.2.1 (policy) 5.3.2.3 (APOs) 5.3.2.4 (route planning)
In time deliveries
Info flows: APA policy, APO, TNS, etc. C.2
C.3
C.4
C.5
The driver should know about availability of loading bay time slots
Information about the availability of loading bays may be requested.
It must be possible to request loading bays of appropriate size near the required location at required time Drivers should inform about delivery problems and ETA Free the driver from the need to keep manual logs
Information about loading bays bookings can be received from the fleet manager or they can be booked by the driver.
If resources (e.g. loading bays) are booked, the driver knows they are available.
5.2.2.3 (info request) 5.2.2.1 (info about bookings related to transport operation) Info flow: Resource allocation
In case of changed plans, the booking can be changed or cancelled.
5.2.2.1 (receive info) 5.2.2.3 (booking) Info flow: Resource allocation
New ETA or information about delivery problems can be provided.
5.2.2.2 (report)
The information that is to be reported is to a large extent automatically established, and the reporting is as far as possible automatically
5.2.2.1 (establishment) 5.2.2.2 (reporting)
Info flow: TOS, Transport problem
Info flow: TOS C.6
Drivers must be able to report
Transport problems are reported.
D5.2 The SMARTFREIGHT framework architecture
5.3.3.5 Info flow: Transport
145
SMARTFREIGHT
C.7
C.8
transport problems (involvement in accidents, vehicle problems, need for assistance, illness, etc.) Drivers should inform about congestions or abnormal traffic situations Safety of drivers, vehicles and third parties
problem
The transportation network status may be reported.
5.3.3.4
Adaptation to the APA policy (which defines the APOs) increase the safety (e.g. routes depending on type of vehicle and goods).
5.3.2.1 (policy) 5.3.2.3 (APOs) 5.3.2.4 (route planning) 5.3.3.1 (tracking) 5.3.3.2 (entry/exit) 5.3.3.3 (safety related) 5.3.3.4 (traffic situation) 5.3.1.2.2 (driver)
The en-route reporting (tracking, entry and exit, safety related info) will also increase safety (e.g. through improved awareness about DG). Traffic situation can also be reported. The driver may also be monitored.
Info flow: TNS
Info flows: APA policy, TNS, Entry notification, Exit notification, etc. C.9
Vehicle tracking (may provide input on travel times and delays)
The vehicles are tracked. This includes the entry and exit to/from Controlled Areas.
5.3.3.1 (tracking) 5.3.3.2 (entry/exit)
C.10 The vehicles should provide input to statistics C.11 For dangerous goods (DG), information about goods type and transport requirements must be available
Information is provided on entry to specific areas
5.3.3.2Info flow: Vehicle info
On-board the information is managed.
5.2.2.1 (on-board info) 5.3.3.1 (tracking) 5.3.3.2 (entry/exit)
C.12 For DG information about the condition of the goods must be available C.13 For DG information about preferred road network must be available C.14 Drivers must get dynamic route guidance in response to realtime traffic
Information about DG may be reported.
Info flows: Tracking, Entry notification, Exit notification
Information about DG is provided when vehicles are tracked and when the entry and exit to/from Controlled Areas are reported
Info flows: Tracking, Entry notification, Exit notification 5.3.3.3 (DG info) 7.1.4 (condition) Info flows: Safety status, TOS Derived from the access and priorities offered by the APA policy.
5.3.2.1 (policy)
Route information can be received and used in the route planning.
5.3.1.2.4 (Information collection) 5.3.1.2.1 (Route planning)
Traffic information will inform about the reason for re-routing.
D5.2 The SMARTFREIGHT framework architecture
Info flow: APA policy
146
SMARTFREIGHT
C.15
C.16 C.17
C.18
C.19
C.20
C.21
C.22
conditions and info about the reasons for rerouting Drivers must get transportation network information Drivers must get traffic information Drivers must get warnings about problems and safety risks The drivers must get information about planned events. Drivers must get information events have cleared Drivers should get traffic information in an appropriate format, simple to use and at a low cost. The data must be available via a variety of media There should be pan-European solutions (crossborder support). Drivers should get traffic information FDMS to allow filtering and decisions on which messages drivers should receive;
Info flow: Route, TNS
Required information can be received and used to support in the driving operation. Will include transportation network status, including traffic information (congestion, accident/incidents, road works, delays, travel times, etc.), warnings, etc.
5.3.1.2.4
Partly addressed by SMARTFREIGHT.
5.3.1.2.4
SMARTFREIGHT addresses the delivery of traffic information via the OBE and has defined a format that is inspired by DATEX II.
Info flow: TNS
Info flow: TNS
The SMARTFREIGHT solution can be combined with other media.SMARTFREIGHT does not address the organisation of pan-European solutions, but the same information exchange format (TNS) should be used everywhere.
Traffic information may be received from the UTMS or the FDMS.
5.3.1.2.4
C.23 The drivers should be allowed to use bus lanes
The APA policy is received, and APOs that may allow the use of bus lanes may be derived from the policy. Such APOs may also be received on request.
5.3.2.1 5.3.2.3 (on request)
C.24 Keep record of vehicle movements to document details in case of accidents, offence accusations, etc. C.25 A list of vehicle stops and time stopped C.26 Ability to plan efficient routes
The vehicle is tracked and entries and exits to/from Controlled Areas can be registered.
5.3.3.1 (tracking) 5.3.3.2 (entry/exit)
Info flow: TNS
Info flows: APA policy, APO
Info flow: Tracking
Stops may be tracked.
5.3.3.1 (tracking) Info flow: Tracking
The actual route planning is not addressed, but can be supported by the dynamic APA policy,
D5.2 The SMARTFREIGHT framework architecture
5.3.2.1(policy) 5.3.2.3 (APO request)
147
SMARTFREIGHT
and schedules
the ability to request APOs and route planning that is according to the APOs.
5.3.2.4 (route planning) Info flows: APA policy, APO
C.27 Divert lorries and dynamic adjustments to planned routes and schedules C.28 Direct communication with sources of information C.29 Parking regulations must be enforced to prevent illegal use of loading bays C.30 The drivers should get map updates
New plans may be received.
C.31 The driver should get info about parking zones
Not addressed by SMARTFREIGHT
C.32 Automatic warnings in case of deviations
Not addressed by SMARTFREIGHT
5.2.2.1 (transport operation plan) 5.3.2.2(driving info) Info flows: TOP
Misc. information services may be used
5.3.1.2.4 Info flows: See 9.2
Not addressed by SMARTFREIGHT
5.3.3.2
However, entries to and exits from areas are reported. This may support enforcement.
Info flows: Entry notification, Exit notification
Not addressed by SMARTFREIGHT However, the driver may for example use information services (see 5.3.1.2.4) to download maps, or the use of such information services may be automated.
Can be a part of the transportation network information.
Info flow: Resource allocation
5.3.1.2.3
The driver may for example be alerted
A.4 The needs of goods receivers The needs of the goods receivers are derived from section 2.4 in D2.1. D. Requirement
How addressed in SMARTFREIGHT
D.1
APA policy that support efficiency for those who behave according to the city policy and the ability to book loading bays.
Reliability of the delivery
Info flow: APA policy, APO, TNS, etc. D.2
Information about deviations
The driver must report about delivery or transport problems or problem so that the transport user can be informed Info flow: TOS, Transport problem
D.3
D.4
Parking and loading bay availability Freight distributors should act responsible
Pre-booking of loading bays Info flow: Resource allocation Illegal parking is avoided by booking of loading bays and detection of illegal use. In time arrivals will limit the number of lorries by means of loading bay bookings. Info flow: Resource allocation, Entry notification, Exit notification
D5.2 The SMARTFREIGHT framework architecture
148
SMARTFREIGHT
Annex B.
Related activities
This annex describes initiatives and results that are related to SMARTFREIGHT. When relevant it is also described what is “borrowed” from others, the additions and modifications done in SMARTFREIGHT, and also input that SMARTFREIGHT has provided to other projects and initiatives.
B.1 AGORA C AGORA C [11] is a method for on-fly location referencing, and is for a large part based on results from the EU funded AGORA project. AGORA C stands for AGORA Compact. AGORA C is further described in Annex C. Use of AGORA C SMARTFREIGHT has selected to use AGORA C for location referencing. AGORA C provides a method for use of minimal information to unambiguously locate something on a map. Two location referencing purposes are addressed: Applicable to problem or status locations. No pre-coding or locations tables (like in RDSTMC) are required. Applicable to use in routing to destinations. AGORA C relies on specific attributes that are available in current digital map databases for navigation systems and other ADAS applications. Value added by SMARTFREIGHT: The SMARTFREIGH architecture has used the AGORA C method for location referencing whenever feasible, as described in Annex C. The Trondheim pilot did however not implement this solution. SMARTFEEIGHT has found that area referencing is required. This is however not covered by the CVIS platform. Recently, many projects prefer Open LR to ANGORA C due to no the ANGORA license fee. Open LR does however not include area referencing. SMARTFREIGHT provides knowledge that can be included in Open LR.
B.2 ARKTRANS Use of ARKTRANS ARKTRANS was used as a starting point for the work on the SMARTFREIGHT framework architecture. ARKTRANS has provided input to: The identification and specification of the SMARTFREIGHT functions. The ARKTRANS functions were used as a starting point, but the function descriptions are refined and made more detailed to address the objectives of SMARTFREIGHT. The names and overall aim of many of the functions do however intentionally correspond to the ARKTRANS functions. In that way the SMARTFREIGHT solutions are more likely to fit into the total picture of the transport sector, as represented by ARKTRANS, and the solutions can more easily can be related to solutions established by other projects using ARKTRANS The terminology used in SMARTFEIGHT. As mentioned in the introduction (see 1.2.2), the terminology of ARKTRANS is used whenever feasible. This arrange for generic specifications and coordination towards the Freightwise and e-Freight projects.
D5.2 The SMARTFREIGHT framework architecture
149
SMARTFREIGHT
The identification and specifications of the information flows. Some of the information flows in ARKTRANS were used as a starting point for the identification of the flows in SMARTFREIGHT. The RoadJourneySegment of the journey information provided by the getTravelPlan operation in ARKTRANS is adopted by SMARTFREIGHT as a mechanism for provision of routes to the drivers. Most of the ARKTRANS information flows are however not specified by means of detailed information models. The process specification. The ARKTRANS process descriptions are used as a starting point, but they are refined to illustrate details about the issues addressed by SMARTFREIGHT Value added by SMARTFREIGHT: SMARTFREIGHT has developed further: Knowledge about how the APA policy can be represented. Generic issues and concepts on transportation network resources. Verification of the usability and relevance of the functional decomposition and the information flows Generic functionality for monitoring and communications with Items (Transport Items as well as Load Items)
B.3 Common Framework The SMARTFREIGHT framework architecture has been input to the European work on the “Common Framework for Information and Communication Systems in Transport and Logistics” (in short called Common Framework) and vice versa. Thus, the SMARTFREIGHT framework architecture is harmonized with the needs identified in other European projects providing input to the Common Framework (among others the e-Freight project). Value added by SMARTFREIGHT: SMARTFREIGHT is the main contributor to the Common Framework on issues covered by the Transport Operation Management, Transportation Area Management and On-board Management domains. The two latter together cover the concept of cooperative systems. SMARTFREIGHT includes more details than Common Framework and has extended the specifications in the Common Framework.
B.4 CVIS Use of CVIS results SMARTFREIGHT utilize the following facilities in CVIS: Location services Communication services according to CALM Application uploading/downloading services Advertisements services Application development framework Value added by SMARTFREIGHT: SMARTFEEIGHT has found that area referencing in accordance with ANGORA C is required. This is however not covered by the current version of the CVIS platform. SMARTFREIGHT also has a new approach to access control, as described in Annex E.
D5.2 The SMARTFREIGHT framework architecture
150
SMARTFREIGHT
B.5 DATEX II Use of DATEX II The DATEX II standard specifies how traffic related information can be exchanged between road administrations. DATEX is used as the basis for several of the information flows in SMARTFREIGHT: The TNS (Transportation Network Status) is expressed by means of data elements from the DATEX standard. Value added by SMARTFREIGHT: Location referencing according to ANGORA C is combined with DATEX II solutions. This enables a more accurate definition of locations. DATEX information elements is used in information flows to vehicles and from vehicle to the Transport Operator (may also be reported to others in the same way, e.g. the Traffic Manager and other vehicles). In that way traffic flow information can be provided by vehicles, e.g. when they are used as probe vehicles and when they report about the conditions, e.g. to facilitate automated reporting of road condition (slippery road, etc).
B.6 EasyWay Value added by SMARTFREIGHT SMARTFREIGHT has provided input to the work on cooperative system applications in EasyWay.
B.7 ETSI Use of ETSI specifications ETSI has specified aV2X application layer model and defined a set of basic applications (Reference: ETSI TR 102 638 v1.1.1: Intelligent Transport Systems (ITS): Vehicular Communications; Basic Set of Applications; Definitions). SMARTFREIGHT fits into the application layer defined by ETSI. Value added by SMARTFREIGHT SMARTFREIGHT service interfaces (see 9.2) can provide input to the implementation of the applications and use cases described in the ETSI TR 102 638 report (Table 6.1 and Annex C), as summarized in Table 15. Table 15 Mapping SMARTFREIGHT service interfaces towards ETSI applications and use cases Application
ETSI use cases
SMARTFREIGHT Service interface
Driving assistance
C.1.3.1 Wrong way driving
ITNS
C.1.3.3 Traffic condition warning
ITNS
C.1.3.4 Signal violation warning
Notification (not directly addressed, but can be included)
C.1.3.5 Roadwork warning
ITNS
C.1.3.6 Decentralized floating car data
ITNS
Road Hazard warming
Notification (not directly addressed, but can be included) Cooperative
C.2.3 Traffic information and recommended itinerary
D5.2 The SMARTFREIGHT framework architecture
ITNS IRoute
151
SMARTFREIGHT
navigation
C.2.4 Enhanced route guidance and navigation
IRoute
C.2.6 Co-operative flexible lane change
ITrafficManagement (APA policy, APO)
C.2.7 Limited access warning, detour notification
ITrafficManagement (APA policy, APO)
Location based services
C3.2 Automatic access control/parking access
ITrafficManagement (Entry notification, Exit notification)
Communitie s services
C.3.16 Fleet management
IRoute
IResource ITOP ITOS C.3.18 Loading zone management
IResource
SMARTFREIGHT also addresses use cases that so far are not identified by ETSI, e.g. use cases related to the APA policy and individual APOs. The access control solution defined by SMARTFREIGHT also provides a new alternative.
B.8 EURIDICE The EURIDICE project is dealing with intelligent cargo. By means of tags attached to the goods items or load units and intelligent agents running on these tags, the goods can take decisions and take part in the information exchange during the transport. Value added by SMARTFREIGHT: The SMARTFREIGHT solutions do not address intelligent goods, but it is emphasized that the SMARTFREIGHT framework architecture must not be in conflict with such solutions. Thus, the SMARTFREIGHT framework architecture is adapted to the intelligent goods scenario: The roles arrange for flexibility in how solutions are organised. Functionality that supports the Transport User (responsible for the booking and follow up of the transport) can be distributed to agents running on the tags. In the same way, the tags may also implement the functionality required by the Transport Service Provider or others. Hence there may be several intelligent agents on a tag that are monitoring the transport, taking decisions and communication with the surroundings on behalf of different stakeholders. The On-Goods-Equipment is specified in such a way that it may support generic functions that may be requested by many different stakeholders, those outside the transport sector included, as well as functions requested by stakeholders with specific transport related roles. The On-Goods-Equipment and the related objects and specifications in the architecture can be extended to include intelligent agents. The intelligent agent may for example represent the generic roles and functionality required by these roles.
B.9 Freightwise Use of Freightwise results SMARTFREIGHT and Freightwise address different aspects of the transport service provision. Freightwise addresses the interaction with the Transport User (transport booking and status reporting). SMARTFREIGHT addresses the planning and execution of the transport operations. Thus, the projects do not overlap, but their results should fit together. SMARTFREIGHT must build on the booking information established by Freightwise, and SMARTFREIGHT should provide status information from the transport operations (Transport Operation Status – TOS) that in the Freightwise solutions can be used as input to the status D5.2 The SMARTFREIGHT framework architecture
152
SMARTFREIGHT
reporting to the transport user (Transport Execution Status – TES). Freightwise has also specified the information that the transport service provider need about the transportation network (Transportation Network Status – TNS). The following Freightwise results are used as a starting point for the work in SMARTFREIGHT: TNS (Transportation Network Status) is used as a starting point for information about the status of the transportation network. TES (Transport Execution Status) is used as a starting point for the TOS (Transport Operation Status). The TOS does however require some extra statuses to support the follow up of the transport operation. Value added by SMARTFREIGHT SMARTFREIGHT has extended the scope from transport booking and status reporting to include also the execution of the transport operation. SMARTFREIGHT has suggested changes in the messages defined by Freightwise as well as new use of the messages: Indicators are added to the TNS to indicate whether the information provided is a forecast (prediction of traffic conditions, weather conditions, etc.) or actual observations. The TNS is used to exchange information about driving conditions from the driver to the Transport Operator. The TNS (Transportation Network Status) is checked towards the needs of the fleet managers and drivers doing urban freight distribution. This verification of usability is valuable. The TNS is updated to provide information about travel times and delays (needed by the fleet managers and drivers) (added to the TrafficInformation class). The location referencing in TNS is modified. An AGORA-C compatible approach is used. The TES (Transport Execution Status) does just address the goods items (Transport Items) provided by the transport user. These may be packed in a different way (Load Items) during the transport. SMARTFREIGHT has introduced a generic Item that can represent the condition and status of both Transport Items and Load Items (such information may be stored on the On-item Equipment object). The same data elements can be used to represent the conditions and statuses of all Items, Transport Items and the Load Items included. Thus, SMARTFREIGHT has contributed to a harmonisation of data elements so that they cover the needs of both SMARTFREIGHT and Freightwise.
B.10 GOOD ROUTE Use of Good Route results The GOOD ROUTE project addressed transport of dangerous goods (DG) and related information flows. Time slots for DG passages through the infrastructure, DG route guidance, DG re-routing, enforcement related to DG, provision of status information to the transport chain, emergency handling, etc. are focused. SMARTFREIGHT has used the GOOD ROUTE solutions as an input on the requirements related to DG transport. Several of the data types defined in the GOOD ROUTE XML Scheme is used as an input to the Information view in SMARTFREIGHT. Value added by SMARTFREIGHT: The GOOD ROUTE project had terminated when SMARTFREIGHT started. Thus, SMARTFREIGHT has not provided input to GOOD ROUTE. SMARTFREIGHT do however adds new aspects to traffic management related to DG by enabling traffic management D5.2 The SMARTFREIGHT framework architecture
153
SMARTFREIGHT
towards individual vehicles that is depending on the profile of the vehicle, DG included. The APA policy is dynamically adapted to the traffic situation.
B.11 ROSATTE SMARTFREIGHT has not re-used results from the ROSATTE project directly, but has exchanged knowledge about the AGORA C location method with the ROSATTE project.
D5.2 The SMARTFREIGHT framework architecture
154
SMARTFREIGHT
Annex C.
Locations referencing
The applications and services enabled by SMARTFREIGHT will in many cases need some kind of location referencing beyond human readable addresses. Both the Traffic Manager and the Transport Operator will communicate with the driver (i.e. the On-board Manager and the Transport Operation Worker roles) by transmitting information containing references to locations that will appear on the OBE – e.g. Controlled Areas, routing guidance, pick-up and delivery locations, etc. There are several existing location referencing mechanisms, which mainly differ in functionality, accuracy, complexity and deployment. This annex provides a brief introduction to the location referencing mechanisms.
C.1 Location Referencing Mechanisms There exists different mechanisms for describing a location. Such mechanisms differ in terms of functionality, accuracy, complexity and deployment. Here, four mechanisms are presented: the location tables in Traffic Message Channel (TMC) [32], the Transports Protocol Experts Group‟s Location Referencing (TPEG-Loc) [34], Agora-C [33], and OpenLR [29]. C.1.1 TMC TMC is a standard for providing textual traffic information to travellers, either as explicit messages to the traveller or as implicit messages sent directly to the navigation system in order to dynamically guide the traveller. TMC is typically communicated to travellers through the Radio Data System (RDS-TMC) over the FM channel. The development of RDS-TMC was maintained by the previous TMC Forum, which now together with the TPEG Forum, and the German Mobile.Info project constitute the Traveller Information Services Association (TISA) that maintains the current development and deployment of RDS-TMC. TMC is a static location reference method meaning that each location is defined by predefined location codes contained in different tables. This means that a specific location must either exist within the table, or be described by an offset distance and direction from the closest location that exists within the table. However, the number of possible location codes in a table is limited leading to a lower possibility of getting accurate location descriptions. To correctly interpret a location code necessitates that the receiver of the code must have the same table and table version as the sender. TMC will in many cases give an exact representation of a specific location, but may in other cases give inaccurate representations in different navigation systems – and in worst case no match due to different table versions. C.1.2 TPEG-Loc TPEG-Loc is a location referencing method, which is a part of the TPEG message structure. Like TMC, TPEG is now maintained and further developed by TISA. TPEG defines a message structure for exchange of Traffic and Travel Information (TTI), which consists of a message header, message application content, and a location reference. TPEG comes in two different formats: binary [34] and XML (tpeg-locML)[35]. At first it was reckoned as a technology for the delivery segment, i.e. for wireless delivery to e.g. vehicles, due to its compact light-weight binary version. However, as the human readable tpeg-locML version of TPEG was defined, TPEG now also serves the content segment of the TTI delivery chain. TPEG-Loc provides dynamic location references through both a human and machine readable format (i.e. the XML and binary versions). Predefined location types describe the locations at different levels, from the large area reference to the node description of e.g. an airport. TPEG-Loc contains WGS84 coordinates in addition to the location types. Compared D5.2 The SMARTFREIGHT framework architecture
155
SMARTFREIGHT
to the location tables in TMC, TPEG-Loc is independent of location tables and thus the problems related to unsynchronized location tables. However, the mechanism is not fully suited to describe relative complex sections and routes in urban areas, which is needed in SMARTFREIGHT. C.1.3 Agora-C AGORA-C is a dynamic location referencing method, which has evolved from the EC funded AGORA project. The aim of this project was to develop a single method for dynamic location referencing independent of predefined location tables, map versions, and navigation system manufacturer. The work on AGORA-C has resulted in the ISO standard 17572-3 [33]. To define a location, AGORA-C includes different location points that are linked together to either decide a point location, a linear location (i.e. a section of the transportation network), or an area location. The location points are described by their WGS84 coordinates along with physical properties such as type (e.g. road, intersection, etc.), road class, driving direction, and complexity (related to intersections). No predefined location tables are used. By following well-defined encoding rules, the location in question will be a reference that can be decoded by another part that may not have the exact same map version as the encoder does. All the encoder and decoder requires is that the map database is based on the Geographic Data File (GDF) format. In tests, AGORA-C has shown a hit rate of > 98 % (i.e. percentage correctly matched and correctly identified as not present in the receiver‟s map database) [39]. In the Extended Profile, AGORA-C is also capable of providing routing assistance to a destination. By following the encoder rules in the ISO specification, the location can either be exchanged by a binary format or an XML format. The binary format gives an effective data exchange over low capacity communication links and is thus suitable for delivery to mobile navigation units. In a paper by Dai et al. [30] the encoding rules and format are further improved for even better efficiency. However, parts of the ISO standard is protected by Intellectual Property Rights (IPR). To avoid complex IPR situations involving several different stakeholders, the IPR are managed through Via licensing. C.1.4 OpenLR OpenLR is, as AGORA-C, a dynamic location referencing method that is independent of predefined location tables to reference a location. It is an open standard that is developed and maintained by TomTom International B.V. However, everyone is invited and encouraged to be involved in the further development. OpenLR is more or less a reaction to the licenses attached to the use of AGORA-C; OpenLR is protected under an extended version of the GPL version 2. OpenLR works by forming different location reference (LR) points to a line. Currently, OpenLR does only support line segments, and not points nor areas. However, according to the developers, OpenLR is easy extendable for such purposes as well. Each LR point is defined by WGS84 coordinates, and attributes like functional road class (e.g. main road, first class road, etc.) and form of way (e.g. motorway, roundabout, etc.). Such attributes are general requirements to the maps used in the exchange of locations. If the maps follow the requirements, OpenLR will be independent of map version and vendor. To make OpenLR human readable, it is described in the XML format along with a binary version for more efficient transmission over resource restricted mediums. A location is encoded based on defined rules. This is true also for decoding of locations. On the OpenLR web-site there is a reference implementation in Java available for download [37]. Test data is also available for testing implementations.
D5.2 The SMARTFREIGHT framework architecture
156
SMARTFREIGHT
C.2 AGORA-C in SMARTFREIGHT The future location referencing methods use dynamic on-the-fly encoding and decoding of location references independent of map differences and predefined location codes with lookup tables. AGORA-C is at the moment, probably the best alternative among this category of methods. There are large companies behind the deployment of AGORA-C, it is described in an ISO standard, and it is expected that the uptake in navigation systems for dynamic route guidance will increase with the release of the standard and the availability of licenses. By including AGORA-C in SMARTFREIGHT we get an accurate representation of locations. ISO 17572-3 provides for a logical encoding structure in terms of an UML model, which is translated into the two content equivalent physical formats binary and XML. The binary format is only readable for machines, but is effective for wireless transmissions (i.e. between vehicles and infrastructure). The XML format represents the opposite – readable for humans, but more heavy-weight for low capacity channels. In SMARTFREIGHT, the location references will be used between several different actors. The Transport Operation Worker will receive location references from its Transport Operator related to the transport operation, and from the Traffic Manager related to Controlled Areas and Transportation Network Status (TNS) with dynamic information on incidents and road conditions. There is also information with location references going between the Traffic Manager and the Transport Operator related to the city‟s APA policies, Transportation Network Resource bookings and TNS. AGORA-C will thus have different usage scenarios that require different aspects of the format exchanged. One possible solution in SMARTFREIGHT is to provide some location information in plain text, i.e. important information like street name and number, intended for the Transport Operation Worker among others, together with an AGORA-C location reference that can directly be located on the map in the On-Board Equipment. Location referencing is defined as a domain facility in the CVIS service platform, i.e. a service that is available for applications through a set of APIs. However, not all implementations may have all facilities available. The AGORA-C reference is therefore either encoded as a string on the sending side (base64 encoding/decoding) using the facility, or requested through a Web Service. The same approach is recommended for SMARTFREIGHT.
D5.2 The SMARTFREIGHT framework architecture
157
SMARTFREIGHT
Annex D.
Security issues
D.1 Certificates A certificate will include An ID A public key An electronic signature There may be a hierarchy of authorities that must have certificates International authority: For authentication of the hierarchy of certificates issued by other authorities Regional authority (if relevant), e.g. Europe: For authentication of the hierarchy of certificates issued by other authorities Local authority, e.g. national, city or terminal: May communicate with the vehicles via Road Side Equipment (RSE). Certificates may be provided together with services advertisements Road Side Equipment (RSE), representing local authorities, must also have certificates: They must identify themselves by means of certificates Vehicle must also have certificates to verify Static data about the characteristics of the vehicle, an electronic license
D.2 Access control The SMARTFREIGHT solutions are based on a distributed computation of the APOs. It must be ensured that the APOs of a vehicle are correct. It must be impossible to construct APOs that provide illegal access and priorities. The vehicles may also have to report on entry to for example tunnels, and the secure reporting must be ensured. There are security challenges related to: 1. Authentication – correct identification is ensured by means of electronic signatures. It can be verified that o Service advertisements are from an authorized actor o
The APA policy is provided by an authorized authority and communicated by authorised RSE
o
The vehicle identity is correct
2. Integrity – correct (not manipulated) information content is ensured by means of electronic signatures of information content to verify that for example o The address for applications downloading, which is provided in a service advertisement, is trustworthy o
The APA policy has not been changed by unauthorized actors
o
That the vehicle characteristics are correct
o
The APO is valid for this vehicle
o
The APO of the vehicle has not been changed (it is retrieved from the APA policy)
o
The computation of the APOs is correct.
D5.2 The SMARTFREIGHT framework architecture
158
SMARTFREIGHT
3. Confidentiality - is ensured by encryption information to avoid unauthorized access to information, e.g. information about the cargo. 4. Non-repudiation – is ensured by confirmations. It must be impossible for vehicles to claim that information (e.g. the APA policy) has not been received if it has been received. o Vehicles may confirm reception of information by sending a signed information confirmation. The confirmation may be sent to another address than the RSE and may be consulted in case of regulation violations. o
Several responses may be required, e.g. one for confirmation of information receipt and one for actions taken (e.g. application downloading)
D5.2 The SMARTFREIGHT framework architecture
159
SMARTFREIGHT
Annex E.
Access control
Vehicle Characteristics
APA Policy
In SMARTFREIGHT, vehicles are allowed to enter Controlled Areas, i.e. specific areas of the city or different sections of the transportation network infrastructures (e.g. specific lanes, terminal areas, etc.), depending on the individual characteristics of the vehicle. Such individual access and priority Offers (APOs) are derived from the Access and Priority Assignment (APA) policy, which defines the conditions for access by means of vehicle characteristics.
Computations
APO
Figure 60 Main principles for computation of Access and Priority Offer (APO)
There are alternative approaches to the actual computation of the APOs: 1. Centralized access control Information about the characteristics of each vehicle has to be communicated to a central processing entity. 2. Access control distributed to RSE (Road Side Equipment) This is the solution implemented by CVIS. The vehicle provides information to the RSE, and the RSE will compute and provide the relevant APOs. 3. Access control distributed to OBE (On-Board Equipment). The vehicle will receive the relevant APA policies and compute its own APOs. In SMARTFREIGHT alternative 3 is chosen, and the reasons for this are summarized in Table 16.
Characteristics
Table 16 Access control alternatives Centralized
Distributed to RSE
Distributed to OBE
Control of the city Large processing overhead Communication overhead (V2I and backbone) Less in-vehicle processing
Control of separate areas within the city Processing overhead dep. on degree of distribution Communication overhead (V2I) Less in-vehicle processing
Control of the vehicle Possible processing/ communication overhead (on-board) - if many restricted areas
Can be combined with collection of data for statistics Less efficient routes without complete info about transport operation
Scalability depends on degree of distribution Less efficient routes without complete info about transport operation
D5.2 The SMARTFREIGHT framework architecture
Scalable solution (processing and communication) More privacy Less data for statistics (can be collected in other ways) Policy can more easily be used in the planning
160
SMARTFREIGHT
Annex F.
Vehicle-to-Infrastructure (V2I) Interaction
On entrance to and exit from Controlled Areas interactions with the road-side equipment (RSE) may be relevant to enable access control (for restricted areas) and/or vehicle monitoring (e.g. monitoring of vehicles carrying DG in Controlled Areas): Entry Notification, Exit Notification, Tracking and Safety Status Reporting Entry notification
A
Transportation Network Section
Exit notification
B
Tracking Safety Status
Tracking
Figure 61 Relevant interactions with RSE
F.1 Need for separate entry and exit notifications The Traffic Managers may need to be aware of the presence of vehicles (e.g. vehicles carrying dangerous goods) in separate road sections (i.e. Controlled Areas). There are 2 alternative ways of doing this: The tracking information can be used to generate the required awareness about the presence of the vehicle. The vehicle can send entry and exit notifications on arrival to and exit from the road sections. The alternatives are discussed in the table below. Table 17 Interaction alternatives Alternatives
Status at location A (entry)
Status at location B (exit)
Consequence for the Traffic Manager
Tracking
Tracking received
Tracking received
All information about the vehicle‟s presence is correct
Tracking received
Tracking lost
Incorrect awareness. Thinks that the vehicle is inside the section (has not left the section).
Tracking lost
Tracking received
Incorrect awareness. Thinks that the vehicle is inside the section (the exit is recognised as an entry).
Tracking lost
Tracking lost
No awareness about the presence of vehicle in the section.
Notification received
Notification received
All information about the vehicle‟s presence
Notification received
Notification lost
Incorrect awareness. Thinks that the vehicle is inside the section (has not left the section).
Notification lost
Notification received
Incorrect awareness. No awareness about the presence of vehicle in the section, but the exit is detected, and the awareness after the exit is correct.
Notification lost
Notification lost
No awareness about the presence of vehicle in the section.
Entry and Exit notifications
D5.2 The SMARTFREIGHT framework architecture
161
SMARTFREIGHT
The use of entry and exit notifications provides a better awareness in case a notification is lost. Hence, the entry and exit notification solution is used.
F.2 The realisation logic Road side equipment (RSE) may be used to detect entries and exits from Controlled Areas, as illustrated in Figure 62. The vehicle will have to drive through area A, B, C and D to get to its destination in area E. RSEs are located at position 1, 2, 3, 4 and 5. Some of them detect exits and entries from more than one area. The RSE at location 2 will for example detect entries and exits to and from area B and C.
A B
Start
×
1
C
2
E 3
D
4
5
×
Destination
Figure 62 Controlled Areas and checkpoints with RSEs The RSE will announce requests for entry and exit notifications to the relevant areas, but the vehicle must keep track of whether an entry or an exit notification is to be sent. This is done by means of two stacks: An entry stack defining the Controlled Areas that are to be visited during the trip (the next section is always on the top, the destination section is at the bottom) An exit stack defining the current sections that the vehicle is inside (the innermost section is always on the top of the stack). Table 18 The entry and exit stacks at different locations Location
Entry Stack
Entry notification for
Exit Stack
Outside A
A-B-C-D-E
1
B-C-D-E
A
A
2
D-E
B and C
C-B-A
3
E
D
D-B-A
C
4
E
B-A
D
E
B and A
5
E
Exit notification for
The entry stack is established based on the planned route and the APA policy (which defines the areas where need entry and exit notifications are needed). Thus, at the start the entry stack will contain all the areas to be visited as illustrated in Table 17. When a entry notification that is associated with the top of the entry stack is triggered (e.g. by a request from the RSE), the relevant entry notification is sent, and the associated area is moved from the entry stack to the exit stack. When an exit notification that is associated with the top of the exit stack is triggered, the relevant exit notification is sent, and the associated area is removed from the stack. D5.2 The SMARTFREIGHT framework architecture
162
SMARTFREIGHT
F.3 Dangerous goods information The dangerous goods information is reported at any time a SRE requests a Safety Status report.
F.4 Realisation without RSEs The APA policy will define requirements with respect to Entry notifications, Exit notifications and Safety status reports for Controlled Areas. These Areas can be registered in the navigation system of the vehicle, and Entry notifications, Exit notifications and Safety status reports can be sent whenever required by means of geo-fencing mechanisms.
D5.2 The SMARTFREIGHT framework architecture
163
