The myriad information flows in freight and fleet management
Impact of new technologies
Designing a reference system architecture
- The need for open, standardised interfaces
- What is a system architecture?
- Benefits of common architectures
- Link to KAREN
- Focus on on-board systems
- User needs results
- Functional architecture results
- Information and management architecture results
- Physical and communication architecture results
Standardisation recommendations
Recommendations to transport companies
Recommendations for solution providers and truck manufacturers

Results and achievements

The myriad information flows in freight and fleet management 

Road freight transport has been tremendously successful in establishing itself as the most reliable and cost-effective means of goods transport. The industry is organised in different sectors to accommodate the various types of goods and services that are delivered. All these sectors have one common characteristic: the many different actors involved and the need for these actors to be informed about the progress of orders in real-time. In addition, the industry also heavily interacts with many external parties such as authorities, road operators and service providers.

Impact of new technologies

Thanks to new information and communication technologies today's driver can, in principle, stay away from his base for several weeks. With a mobile office, offer calculation, order booking and confirmation, optimisation of itineraries, document management, load plan control, invoicing and many other exciting applications can now be handled on the spot, directly by the driver. New vehicle-related technologies also allow unseen support in the form of enhanced driver safety and comfort. Moreover, transport companies can use the influx of data to control all relevant aspects of freight, fleet and driver/vehicle management at company level, ranging from cargo tracking and minimising maintenance costs to identifying needs for driver training. All this allows unprecedented gains in efficiency, comfort and safety.

Designing a reference system architecture

The need for open, standardised interfaces

The take-up of integrated ITS applications for freight and fleet management by the transport sector in Europe is still rather slow and their use is mainly confined to Europe's larger and more advanced transport companies. To make the benefits of these ITS applications accessible to all transport companies, including small and medium-sized enterprises, costs need to be reduced and problems related to compatibility and ergonomics overcome. The mass-market penetration of new information and communication technologies such as mobile Internet will certainly help reduce hardware and communication costs. However, to bring costs further down and to unleash the full potential of technology, systems need to be more modular and to rely more on open, standardised interfaces.

What is a system architecture?

An architecture is a structured way of describing a system with a view to ensure interoperability between its components. Whilst allowing for many different specific designs or implementations, it groups a number of common views that allow identifying and describing the necessary commonalities for interoperability across these implementations. The development of a system architecture starts with the identification of key user needs that must be addressed by the system and that will be rigorously traced across the different views.

Benefits of common architectures

There are many advantages of building common architectures:

• To build a common view and understanding of systems

• To follow a modular approach in system design

• To ensure compatibility between implementations across different manufacturers

• To create an open market for services and equipment

• To exploit economies of scale in the production and delivery of these services and equipment.

This is particularly relevant in the complex environment of the transport industry where many industry-related and external parties are involved.

Link to KAREN

COMETA has worked in close co-operation with the KAREN project that has developed an overall framework architecture for ITS in Europe. By using the same methodology as KAREN and by ensuring that the different architectural views are fully consistent, the COMETA results can be seen as complimentary to the outcome of KAREN. Whilst KAREN has focused on the system components within freight and fleet management that are typically deployed outside the vehicle, COMETA has focused on the components that are typically carried out on-board.

Focus on on-board systems

COMETA has developed a common architecture for on-board systems in road freight transport. Starting from an extensive survey of transport companies, system manufacturers and policy makers, COMETA has developed three key architectural views:

• A functional and control architecture

• An information and management architecture and

• A physical and communication architecture.

These architectures have then been used as a basis for identifying standardisation requirements as well as for compiling a set of recommendations on how the COMETA architectures can best be exploited. The recommendations were targeted at the three main stakeholders in the market take-up of on-board systems for freight and fleet management: transport companies, solution providers and vehicle manufacturers.

User needs results

Transport companies, drivers and commercial partners representing different transport sectors as well as authorities were surveyed to identify their needs. 119 key needs were retained.

Functional architecture results

Based on the user needs analysis, three important areas of functionality that need to be supported on-board were defined and decomposed into detailed modular processes:

• Manage business transactions: transport orders are acquired by preparing transport offers in response to transport opportunities or by indicating the availability of excess capacity; clients are provided with status information as agreed in the transport order or in response to a specific request; and all administrative aspects of the order including invoices and payment are handled.

• Prepare vehicle, driver, equipment and cargo: resources are prepared by checking their availability and status; examples of resources are the vehicle, the driver, the required equipment, the cargo and any intermodal transport involved in the order.

• Perform and control vehicle, driver, cargo and equipment operations:

  • Support to check whether loaded or unloaded cargo corresponds to the transport order; support to comply with regulations; the provision of driver assistance functions; access to comfort services and support for payment operations.

  • The monitoring and control of any relevant vehicle, driver, cargo and equipment parameters including storage of relevant parameter values for future use.

These processes as well as the relevant information and control flows between them were properly described and documented in the form of diagrams for easy reference.

Information and management architecture results

To keep diagrams as simple as possible, only one datastore was used in the diagrams of the functional architecture (the "Vehicle, Driver, Cargo and Equipment" datastore). In the information architecture, the entities of which this common database consists were described. An entity- relationship diagram was used to visualise the entities and the nature of the relationships between entities. These entities are building blocks for establishing an on-board database.

Physical and communication architecture results

The physical and communication architecture distinguishes between the following subsystems:

• The driver task management subsystem: this supports the execution, monitoring, reporting of tasks required from a driver by his fleet manager or directly by another partner.

• The vehicle monitoring and control subsystem: this provides internal support to the driver, automatically or on request, in order to prepare, execute, monitor and report any operation; this subsystem also groups different modules supporting driver control, vehicle operations and control as well as cargo control.

• Five other associated subsystems including traffic information and route guidance, advanced driver assistance, payment, the digital tachograph and autonomous equipment.

In the medium-to long-term, COMETA expects these systems to be fully integrated.

Standardisation recommendations

The design of a reference system architecture, in combination with KAREN results, allows restarting the activities of CEN TC 278 WG 2 and of CEFACT, the body for EDIFACT standardisation. Although COMETA did not result in formal new proposals, it has supported and enhanced on-going investigations addressing external and internal communications. As an example, the proposed mobile EDI messages proposed by the French company association EDITRANSPORT have been evaluated examined. A number of proposals for extensions have been made including driver availability, social regulations, technical data capture and intermodal applications. The same is true for the proposed "Fleet Application Protocol" (FAP) that will be submitted to CEN TC 278 WG 2 as a result of FLEETMAP Project, in which extensions such as new services for tour management have been introduced as a result of COMETA. At a more general level, there is a need to more actively involve the transport sector in the development of in-vehicle data buses and related standards based on COMETA results.

Recommendations to transport companies

For a successful implementation of a new on-board system, a project team should be set-up and detailed plans should be made for each implementation phase. Particular attention should be given to cost-benefit and HMI aspects. Also of importance are the two scenario's developed by COMETA: for an independent driver the truck is a mobile office and a lot of functionality that is carried out at the home base in the case of fleet drivers is moved on-board.

Recommendations for solution providers and truck manufacturers

The detailed user needs identified by COMETA allow solution providers and truck manufacturers to be close to the market with their products. In this context, solution providers and truck manufacturers should also examine the two scenarios developed by COMETA: the independent driver scenario and the fleet driver scenario. The functions identified by COMETA, the interaction between functions and the allocation of functions to physical entities as well as the database design proposed by COMETA allow service providers and truck manufacturers to position their current products in a wider context and to investigate the scope for new products and market opportunities.