TR 4005, COMETA Project is supported by the European Commission DG INFSO
in the scope of the Fourth Framework Program, Transport Application Programme.
April 1998 - June 2000

Executive summary
Users requirements and technical solutions (WP2 and WP3)
Predesign of an on-board systems architecture (WP4)
Validation of implementation (WP5)
COMETA Final architectures(WP6)
Exploitation and dissemination of results(WP7)
Handbooks

Executive summary

Introduction

This document describes the guidelines and recommendations for some key potential users of the COMETA system architecture, namely for freight and fleet management. Its subject is the optimisation of the use of on-board systems and their integration in the operator"s information system and daily activity.

These guidelines are produced for decision-makers who decide upon the acquisition and implementation of new technologies and require their evolution, and for fleet managers. It is also intended for potential users of data produced, transmitted and processed by the tools that are implemented. This document seeks to present a set of reflections and “references” which will help potential users, in the broadest sense, to correlate their needs with possible ways by which they may be met.

Thus, this document is intended to serve as an “Introduction to the world of on-board systems”, dedicated to the popularisation of this concept for a manager who has had neither the time nor the occasion to become familiarised with the different aspects of the concept and their global integration.

What is COMETA?

About the COMETA project

In the coming years, as a result of on-board systems, new information technologies will have a direct impact on the task profiles of drivers and dispatchers. The risk associated with the introduction of new systems stems mainly from problems of interoperability and the ergonomy of on-board systems on trucks, and the multiplication of costs. The COMETA project has been initiated to reply to these concerns by defining and designing modular associations of various functions performed on-board, so as to allow for their interface within a global transport telematics system. This has resulted in on-board information systems architecture.

COMETA on-board architecture

Architecture is a structured way of describing a system with a view to ensuring interoperability between its components. 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.

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
• A physical and communication architecture

These architectures have been used as a basis for identifying standardisation requirements as well as compiling a set of recommendations on how the COMETA architecture can be best exploited. These three architectures are described in more detail in appendix1 (see Handbook for fleet managers).

The main objectives

The objective is to achieve an open system architecture for on-board freight, fleet and cargo management systems with standardised interfaces for Europe-wide applications. Having explored and identified the possibility of integrating all on-board elements related to the driver/operator"s function through an open data interchange system, COMETA subsequently took into account other relevant projects like KAREN (overall system architecture), FLEETMAP (standardising the communication between homebase and vehicle) and national projects concerning mobile EDI.

Methodology of the Project

The COMETA project has lasted two years (1998-2000). The methodology is shown in figure below (with active links to the relevant parts).

As figure shows, the consortium has carried out the following activities:

• Precise identification of the needs of users through audits and questionnaires;

• Review of existing tools and solutions and their potential for integration;

• Design of COMETA draft architecture and description of the main trends in HMI, software, costs and architecture;

• Construction of national pilots to validate the COMETA draft architecture;

• Production of final COMETA architecture and the provision of guidelines and recommendations to transport companies, truck manufacturers and solution providers, along with the drawing-up of proposals for standardisation;

• Exploitation and dissemination of the key results of the project, these being the COMETA final architecture, an extensive list of user needs and an overview of the state of the art.

Roadmap to COMETA results

The COMETA project has produced a series of results. These results are available through a number of "products", varying from a global brochure to very detailed deliverables. A roadmap to the COMETA results is shown next figure below (with active links to the relevant parts).

Users requirements and technical solutions (WP2 and WP3)

• Work package 2 : Users requirements
• Work package 3 : brief review of existing tools/solution and evaluation of their integration potential. Identification of expectable evolution in the coming years.
• Matching users requirement (WP 2) with technical solutions (WP 3)

Predesign of an on-board systems architecture (WP4)

The completion of Work Packages 2 and 3 gave rise to results which provided vital information concerning "User requirements"; tools and technical solutions currently available on the market or which may become available in the short term.

These "User requirements" were matched with technical solutions in the Framework Report and this made it possible to define the framework in which an on-board system architecture could be "pre-designed". This pre-design is the subject matter of the D4, further to the work on WP4.

Documents D2 and D3 benefited from links and synergy with the KAREN and INTACT programmes as well as from reports compiled for the Framework UGFFM (User Freight and Fleet Management) support action.

The Guidelines and Templates of CONVERGE and the methodology of KAREN were also used to support the work on WP4.
This document (D4) visualises what the intelligent truck of the future could look like, not only from the viewpoint of the technical contribution to the vehicle but also from the viewpoint of how this will affect drivers and the goods.

Close attention was devoted to the precision of communications between the vehicle, its driver and his environment, but also to the man-machine interface as the guarantee of the sustainability of the solutions contemplated.
This document provides elements resulting from the consolidation of "Users needs", specifies the state of the art in the standardisation and harmonisation of on-board equipment in the various previous projects, and at the level of the European and world standardisation bodies.

Particular attention has been paid to the links between the two KAREN and COMETA projects to ensure the greatest possible coherence between the architectures that have resulted from these two projects and the resulting applications.
After a description of the theory of transport operations, which lies at the very heart of the problem, the D4 document presents the "COMETA High Level Architecture" containing in particular the "context diagram". The chapters devoted to the information architecture, the functional and control architecture, and to the physical and communication architecture, analyse in detail the high level functions, the low level functions, the data flows and the data stores. These documents have all resulted from meticulous analysis work which made up the most important part of Deliverable 4.

In provision of the implementation of these architectures, analyses were performed on the trends in HMI, in application software. Cost scenarios were drafted, together with a prospective vision of the evolution of the COMETA architecture.

To specify the data which are important for the understanding of the various chapters of the document, appendices were written and form an integral part of this Deliverable4. They have been divided into two parts : the first covers the "Consolidated User Needs" and the "Consolidation of the Handbook"; the second covers the external links, in particular with KAREN, INTACT, CEN, the standardisation structures, and the taking into account of the Digital tachograph.

This document has been constructed around a particularly detailed analysis of all the components that go to make up an operational and physical architecture of an on-board system in goods transport vehicles.

Despite its level of precision, this document remains a pre-design study of that architecture. The next stage of the COMETA project, and in particular the Validation phase, will be of vital importance to transform this pre-design into a full-bodied design resulting in a benchmark architecture.

This is the challenge for the WP5 which will involve pilots in a validation stage for implementation.

Validation of implementation (WP5)

The draft version of the COMETA system architecture was validated with transport companies, system/truck manufacturers and system/service providers from France, Germany, Holland, Italy and Sweden, associated to the project as sponsoring partners. Hereby the validation focussed on different aspects: technically, on verification and evaluation of the draft by means of existing (or planned) systems and expert interviews; economically, on evaluation of measurable/non-measurable benefits and costs. The results (of each country) are consolidated in this report, which additionally includes a description of the mobile computing environment and of some of the technologies available.

A system architecture is a model, an accurate reflection of a theory or hypothesis, describing the essential constitution and behaviour of a set of systems. These systems are (implicitly or explicitly) grouped to a set, either because they possess strong functional affinities, or because there are important synergetic effects between them.

To validate a system architecture means to prove or even to determine the importance, reliability and the value of each of its descriptive components and therefore of the theory (or hypothesis) hereby formulated.
In a bottom-up modality the COMETA system architecture draft was verified technically, using existing (pilot) systems as a comparison criteria. The results will be a direct input to the system architecture modification.
The user acceptance was assessed in interviews with system/truck manufacturers and system/service providers as potential primary users, and with transport companies as potential secondary users of the final system architecture. A (simplified) deployment risk analysis was carried out using the knowledge of experts of these two groups of interviewees.

In order to convey to interested readers which costs have to be borne when such a system is introduced, a cost analysis was carried out. A benefit analysis summarises the benefits which can be expected from the usage of a system with the functionality of the COMETA system architecture.

In addition this report allows an overview on the trends in mobile computing and on some of the technologies used in this context and which therefore need to be taken into consideration by COMETA.

The final COMETA will be more than an hypothesis; it will be a theory. The work devoted to WP5 will help to reach this objective and certainly even more than that: It will contribute in shaping the final COMETA into a generic design.

COMETA Final architectures (WP6)

The objectives of the WP6 are to reconsider the predesign of an on board systems architecture(s) after the validations( WP5), to identify all needed adaptations, improvements and strengthening of weak points, and to identify all kind of necessary parallel actions (and their targets) and recommendations to be made, in order to speed up the concretisation of this on board system architectures, modular, interoperable, cost effective.

The WP 6 deliverables are the most important deliverables for COMETA in terms of content (the emphasis of WP 7 is on presentation, and WP 7 deliverables are almost entirely based on the results of WP 6) as they contain the final COMETA architectures as well as COMETA’s recommendations toward standardisation bodies, fleet managers and solution providers/truck manufacturers.

Overview of the available documents :

• Final architectures (D6.1). This document contains the design of an on board system(s) Architecture for commercial vehicles, reminding the context for future on board systems for freight and fleet management, developing functional, information, physical and communication levels of this Architecture as well as a risks analysis and implementation hypothesis.

As such, this deliverable contains all the necessary material to serve as the basis for the three other deliverables that are the additional outcome of WP 6:

• Standardisation recommendations (D6.2). Harmonisation and Standardisation proposals regarding on board systems: At Architecture level, mobile electronic data interchange, interfaces for on board data processing and vehicle data links.
• Recommendations to fleet managers (D6.3). This document represent a first high level step, it aims to provide a reference for innovative fleet managers, or their Electronic Data Processing responsibles, when reconsidering (reeingeneering aspects) their information aspects including drivers/vehicles as components.
• Recommendations to truck manufacturers and solution providers (D6.4). An overview about the COMETA user needs, about the tools available to implement the interfaces defined by the COMETA system architecture and about the currently expanding technological areas is given. In a second part of the document a substantial number of guidelines and recommendations for truck manufacturers and solution providers are given.

Exploitation and dissemination of results(WP7).

Through this final phase of COMETA should be achieve its concrete objective and, hopefully, fulfilled its justifications, seen as benefits for different actors:

• To favour a market widening for the industrial manufacturing of "plug in devices" for the design and manufacturing of "intelligent vehicles", for trivial off the shelf accessibility to solutions, which formerly were seen as too sophisticated.
• To favour cost reduction of on board data capture, data processing, data exchange, and increase of their user friendliness.
• To help fleet operators to identify and express their needs and be prepared to satisfy them, in terms of functionalities and integrated approach of their performances.
• To favour balanced benefits between private management usage, collective management and administrative regulations enforcement usage, allowed by the sharing of common devices in an appropriately structured technical architecture (tachograph, automatic identification, positioning, technical safety monitoring, etc…
• To speed up or start any standardisation requirement identified within the project.

Handbooks