Functional specification for an integrated freight and fleet management system

(1)

Functional specification for an integrated

freight and fleet management system

Part A

Status: RP

Telematics applications of common interest

Project: INTACT

Contract: TR4018

Workpackage leader: Institutet för transportforskning

Project Co-ordinator: Netherlands Economic Institute

Nature: report

Contractual date of delivery: June 1998 Date: September 1998

Project funded by the European Commission under the Telematics Applications Programme of the 4th Framework Programme

(2)

Building on the experience gained from the DRIVE-I and DRIVE-II (ATT) projects, the main objective of the INTACT project is to develop a generic data model to facilitate the realisation of integrated management systems in freight transport and to validate this model through demonstrations at various transport companies in Europe.

An important step towards such a generic data model is the functional specification. To meet the overall objective of the INTACT project the functional specification has been made from two perspectives: • for the case specific integration of telematic applications at the test site companies (Track A); • for the generic integration of telematic applications (Track B).

The methodology used has been adapted to the current objectives. The main objective of the specific track is to provide a functional specification that is detailed enough to make it possible to start the design phase (workpackage 7) of the demonstrator applications. Therefore the specific analysis has been focused in depth rather than in width. For the generic track the situation is more or less the opposite. The INTACT framework has been used directly as a platform.

The total architecture model is made up of two fundamental components that together make a powerful tool for system description:

• functional diagrams; • data dictionary.

For the generic analysis, the INTACT framework, which was an important part of the user requirements analysis in workpackage 3, serves as a platform for further analysis in this workpackage. The generic analysis consists of three consecutive parts:

• revision of the INTACT framework;

• break-down analysis of the functions within the framework; • building a data dictionary with descriptions of the components.

Keyword list

User requirements, Telematics, Freight transport, Systems integration, Functional Specification, Functional Modelling

Workpackage(s) contributing to the deliverable

Workpackages 3 and 4

Acknowledgement:

This deliverable has been completed with the help of all INTACT partners.

Deliverable 5.1 consists of two parts:

• Part A: main report with annexes detailing the generic functional specification; • Part B: annexes detailing the specific functional specifications for each test site. This is part A.

(3)

Project Partners

Partners in the INTACT project Country

Research organisations

Netherlands Economic Institute The Netherlands

Netherlands Organisation for Applied Scientific Research TNO The Netherlands TFK - Institutet för transportforskning Sweden Transeuropean Consulting Unit of Thessaloniki Greece

University of Westminster UK

IT providers

Interchain BV The Netherlands

Infodis BV The Netherlands

PTV Planungbüro Transport und Verkehr GmbH Germany QUADRIGA - Telemática e Comunicaçoes, Lda Portugal

Transport companies

C. van Heezik BV The Netherlands

Inter City Trucks (Holdings) Ltd UK

Jan de Rijk Transport BV The Netherlands

(4)

The work presented in the report1 has been carried out within the functional specification workpackage of the INTACT project. The objective of the workpackage is to define the functional specification of an integrated management system for road freight transport on two levels:

• specific for each demonstrator company;

• generic for the road freight transport sector as a whole.

These two levels follows the two main "tracks" of the INTACT project. Even though these two streams work out in parallel, they give different perspectives on the problems. The workpackage is an important basis for the further workpackages in the project, where demonstration applications will be designed and a generic information model will be built.

In the INTACT project the analysis methodology that has been used is mainly consistent with CONVERGE directives. According to CONVERGE the functional architecture describes the conceptual structure of the logical behaviour of the system.

The methodology used has been adapted to the current objectives. The main objective of the specific track is to provide a functional specification that is detailed enough to make it possible to start the design phase of the demonstrator applications. Therefore the specific analysis has been focusing on the depth rather than the width. For the generic track the situation is more or less the opposite. The INTACT framework has been used directly as a platform.

The total architecture model is made up of two fundamental components that together make a powerful tool for system description:

• functional diagrams; • data dictionary.

For the generic analysis, the INTACT framework that was an important part of the user requirements analysis in workpackage 3, serves as a platform for further analysis in this workpackage. The generic analysis consist of three consecutive parts:

• revision of the INTACT framework;

• break-down analysis of the functions within the framework; • building a data dictionary with descriptions of the components.

A goal of the development of the INTACT framework is to obtain a useful tool for the further analysis within the INTACT project. One important task for the revision is to identify the relevant parts of the model, and leave out parts that are of less interest. It is of great advantage to keep the model as simple as possible. On the other hand, the framework must be exhaustive enough to describe the daily operations of the transport business. The level of detail has been adapted to the needs of the current analysis. Only details that have been deemed relevant to the further analysis have been included in the model. Consequently e.g. payments have not been considered, since the parties, functions and information flows as well as the problems related to this, are not unique for the road freight transport business.

The original INTACT framework was based on an early draft proposal of the CEN TC278 committee. This draft has been changed by the CEN committee and a newer proposal exists. Therefore a comparison has been made of the INTACT framework and the new CEN proposal. The differences have been analysed and considered.

1

Deliverable 5.1 has been split into parts A and B. Part A contains the main report and the annexes presenting the generic functional specification. Part B contains the annexes presenting the specific functional specifications for each test site.

(5)

In the generic track a break down analysis has been made of the revised INTACT framework. All functions have been split into several sub-functions. The information flows between these sub-functions (i.e. inside the original functions) have been identified and mapped. The result of this has been a data dictionary, which is a very important input to the INTACT workpackage 6, where a conceptual information model is to be built.

The specific track of the INTACT project relies on the pilot projects at the four road freight transport companies within the INTACT consortium. All the companies can be considered as medium and large sized operators and regard telematics applications as a means of achieving improved business efficiency and providing them with a competitive edge in those markets in which they operate. The topics for the pilot projects have been chosen to fulfil the user requirements of the demonstration companies.

The objectives of the specific functional analysis were the following:

• to create a functional specification that will serve as an input to the design workpackage (WP7); • to perform an analysis that makes it possible to compare the test sites;

• to perform an analysis that is comparable with the generic one in order to verify the generic framework.

An analysis of the similarities between the various test sites was made. The exchange of experience between the test sites is of major importance for obtaining successful implementations. The comparisons were made through the following perspectives:

• central administration systems in general; • on-board computers and administrative system; • operational planning systems and on-board computers; • administrative systems and operational planning systems.

In order to validate the INTACT framework it has been related to the experience from: • the test site projects;

(6)

5.4.2 Similarities related to central administration systems in general 26 5.4.3 Similarities related to on board computers and administration systems 27 5.4.4 Similarities related to operational planning systems and on board computers 28 5.4.5 Similarities related to administrative systems and operational planning system 28

(7)

6 Comparisons of the generic and the specific framework 29

6.1 Relations to the INTACT framework 29

6.1.1 Parties 29

6.1.2 Functions 30

6.1.3 Information flows 31

6.2 The test sites and the user requirements 32

6.3 Conclusions and discussion 33

7 Conclusions 34

References 36

Abbreviations 37

Annex A1: Terminology

Annex A2: INTACT framework Annex A3: Comparison tables

(8)

1 Introduction

In this chapter an overview is given of the INTACT project and the User Requirements Workpackage, which this report is mainly concerned with. Finally the structure of the report is presented.

1.1 Overall description of the INTACT project

Building on the experience gained from the DRIVE-I and DRIVE-II (ATT) projects, the main objective of the INTACT project is:

To develop a generic data model to facilitate the realisation of integrated management systems in freight transport and to validate this model through demonstrations at various transport companies in Europe.

In order to achieve the main objective, 4 specific objectives have been defined which will be realised over the next 2 years:

1. To formulate a conceptual information model to serve as a generic platform for the integration of various telematics applications used by transport companies;

2. To develop working interfaces for telematics systems in the office of transport companies as well as systems with shippers, multimodal operators and suppliers;

3. To validate these interfaces through verification and demonstration in real life conditions at 4 representative transport companies in Europe;

4. To disseminate the results to suppliers and users of freight telematics systems in order to accelerate the adoption/use of integrated telematics systems in transport.

Through this process it will be demonstrated that the model will function as a generic tool for the easy and cost effective interconnection of various telematics applications. The generic tool, which is based on the specifications of the model, will thus fulfil the need of many transport companies: to move from stand alone telematics applications to an Integrated Management System. The project has been divided into 10 clearly defined workpackages, which are shown in Figure 1.1.

Figure 1.1 Overall INTACT project structure

u s e r r e q u i r e m e n t s ( c a s e s p e c i f i c ) f u n c t i o n a l s p e c i f i c a t i o n f o r p i l o t s p i l o t d e m o n s t r a t i o n u s e r r e q u i r e m e n t s ( g e n e r i c ) f u n c t i o n a l s p e c i f i c a t i o n d e v e l o p m e n t o f c o n c e p t u a l i n f o r m a t i o n m o d e l b u i l d i n g i n t e r f a c e s c o m p a t i b i l i t y o f m a i n I T s y s t e m s v e r f i c a t i o n E x p l o i t a t i o n p l a n e v a l u a t i o n m e t h o d 4 s p e c i f i c p i l o t d e m o n s t r a t i o n s c o n c e p t u a l i n f o r m a t i o n m o d e l P r o j e c t m a n a g e m e n t W P 3 W P 5 W P 5 W P 4 W P 3 W P 6 W P 7 W P 8 W P 9 W P 1 0 W P 1 a n d e v a l u a t i o n o f p i l o t s E x t e r n a l c o m m u n i c a t i o n W P 2

(9)

As figure 1.1 shows, the project consists of 2 parallel ‘tracks’, which will be discussed in this paragraph. These tracks are:

• Track A: 4 case specific pilot demonstrations

The first step in defining the functional specifications for the interfaces is a user requirements analysis, which will be carried out at the four test sites. Having defined the functional specification the next step will be to build the interfaces for the test site transport companies. This will be completed in close co-operation with the partners responsible for building the generic data model. The impacts will be evaluated from a technical, operational, organisational, commercial, financial and social perspective.

• Track B: development of a generic data model

Running consecutively to the case specific user requirements analysis, a similar exercise will be carried out for the generic case. The results of both analysis contribute to the definition of the generic functional specifications. After the functionality of the required system has been specified, a unified data model of the system will be built. The model will consist of data flows, their functions, and their dynamic interactions. Descriptions will be given of the business functions of the flows, attributes of the data, and functions performed by each data object in the system. These data objects will then be unified into a data dictionary.

In order to validate the generic data model, the model will be compared with the actual interfaces that will be developed at the test sites. Based on the comparison between the generic data model and the actual interfaces, the model will be modified where necessary. The evaluation results will be the focus of the information disseminated by the project to a wider audience, i.e. other transport companies and telematics providers.

1.2 The Functional Specification Workpackage

The objective of the workpackage is to define the functional specification of an integrated management system for road freight transport on two levels:

- specific for each demonstrator companies;

- generic for the road freight transport sector as a whole.

These two levels follow the two main "tracks" of the INTACT project. Even though these two streams work out in parallel, they give different perspectives on the subject.

Having identified the needs from the users' perspective in workpackage 3, and the main freight telematic systems in workpackage 4, the next step towards a generic information model is to complete a functional specification. The generic track has a broad perspective and aims to provide an interpretation that applies to most road freight transport companies in general. The result of the functional specification will be the main input to the design of the information model in the INTACT workpackage 6. The functional specification is based on the INTACT generic framework that was defined in the earlier workpackages 3 and 4.

For the specific track of the functional specification, the focus has been slightly different. The objective of the functional specification is to provide a thorough specification, which makes it possible to directly start the design phase in workpackage 7. Therefore the functional analysis at the test sites has been focused on the specific cases. A more pragmatic approach has been used, and the analyses have focused on the requirements for the design.

It is important to compare the results from various sources in order to find out similarities and exchange experience. The search for similarities is of course important between the different test sites, in order to be able to find generic solutions that may be used in several test sites. But also a comparison with the

(10)

framework. Solving real life problems is a way to validate the ideas behind the framework.

The relations of the functional specification workpackage to other workpackages within the INTACT project, are shown in figure 1.2.

Figure 1.2: Relations to other workpackages.

WP3

User requirement

WP4

Compatibility

WP5

Functional

specification

WP6

Conceptual

infomodel

WP7

Building

demonstrator

1.3 Structure of the Report

The structure of this report follows the sequence of the work tasks that have taken place in the INTACT functional specification workpackage.

Chapter 2 describes the approach and methodology that has been used for the work. An overall description of the work is provided.

Chapter 3 presents the INTACT framework and revision of it. This revision is an important part of the work on the generic track of the project.

Chapter 4 discusses the generic break-down of the INTACT framework. This break-down, which results in a data dictionary, is the main part of the generic track. A data dictionary report is found in the annexes.

The specific track of the workpackage is presented in chapter 5, where the four road freight transport companies participating in the demonstrations are presented, as well as the pilot projects at each test site. A comparison of the test sites has been made and similarities and discrepancies have been found. The full reports from the demonstrator sites are to be found in the annexes.

In chapter 6, a comparison of the both tracks (generic and specific) is found.

Conclusions are drawn in chapter 7.

A functional specification report is by nature very technical and complex. The main result of the studies is a set of diagrams including parties, functions, information flows and sometimes databases. In addition tables that describe all the components are to be found. The more technical text of this report can be found in the annexes. Annexes 4, 5, 6 and 7 are presented in a separate volume: Deliverable 5.1 part B. Part B presents the pilot specific functional sepcifications.

(11)

2 Approach and methodology

In the following sections of this chapter, the overall structure of the work and methodology used to develop the functional specification is discussed and details about the approach to the specific test site and generic cases are given. A further discussion concerning this topic may be found in annex A2.

2.1 Overall structure of the work

The work has been divided such that two tracks, one examining specific test site companies (Track A) and the other addressing a generic model (Track B), have been completed separately, but the work carried out in parallel.

For the generic analysis, the INTACT framework (which was an important output from the user requirements analysis in Workpackage 32) serves as a platform for the analysis carried out in this workpackage. The framework is described in section 3.

The generic analysis consists of three consecutive parts: - revision of the INTACT framework;

- break-down analysis of the functions within the framework;

- building a data dictionary with descriptions of the components of the framework (parties, functions and information flows).

The specific track, has been concerned with developing functional specifications that are sufficiently detailed and which can be taken forward into WP07, the workpackage in which the interfaces are designed and built. Therefore the specific analysis has focused on the detail rather than broad ideas. Instead of drawing on details of the INTACT framework and using this as a platform (as in the generic track) the specific functional analyses are based upon the user requirements developed in workpackage 3.

In order to identify similarities between the test sites, these specifications have been compared. The results from this comparison were then further compared with the generic framework, in order to validate it. This analysis is discussed in more detail in chapter 6.

While the two tracks are distinct, each is dealing with similar issues and as a result there has been a continuous cross-referencing process taking place between the analysis of the test sites and the development of the generic model.

2.2 Methodology

There are several methodologies (e.g. SSADM, JSD, OMT and many others3) that may be used when analysing a complex system. Each methodology has its own characteristics, advantages and disadvantages that may be considered. The methods that are used in the industry also vary, and some methodologies are more common in certain parts of Europe than others. Despite the fast evolution of the information technology industry, the decision to use a certain method is often based on tradition rather than rational analysis. The aim is to find a method that is ”good enough” and that everyone involved in the project can understand.

2_{TR4018 INTACT Project, User needs for integrated telematics applications in road freight transport, Deliverable D3.1,}

European Commission, May 1998

3

Avison D.E., Fitzgerald G, Information Systems Development - Methodologies, Techniques and Tools, Alfred Waller Publishing Ltd., Oxfordshire, 1993

(12)

project these suggestions have been followed. In addition parts from other methodologies (e.g. the dynamic modelling) have been added to make the analysis more useful, and more adapted to the current situation.

2.2.1 General

The analytical methodology adopted by INTACT is consistent with the suggestions of the CONVERGE project. According to CONVERGE the functional architecture should describe the conceptual structure of the logical behaviour of the system. The total architecture model is made up of two fundamental components that together make a powerful tool for system description:

- functional diagrams; - data dictionary.

The functional diagrams are graphical representations of functions and interfaces between functions, i.e. data flows. They portray the system in its functional components. These are commonly known as data flow diagrams (DFDs) and are described further in section 2.2.3.

A data dictionary serves as a written reference giving precise definitions of all data important to a system. It describes the components of the functional diagrams. The data dictionary is described further in annex A2.

In addition, context diagrams are used when needed. This shows the information exchange between the various parties, in order to give an overview of the system. A more thorough description of the context diagrams may be found in section 2.2.2.

The symbols used for the diagrams are shown in figure 2.1.

Figure 2.1: Symbols used in the diagrams for the functional analysis

F.13.1 Transport Booking F.13 Combined Transport Process IF.3.1 IF.3 P.1 Consignor Brakes India Client Database Sub-function Function Information flow Sub-flow

Party inside framework in the context diagram Party outside framework in the context diagram Database

Int.1

Internal information flow

2.2.2 Context analysis

In order to have an overview of the parties that participate in the system, a context diagram may be used. This is a common technique employed to define the scope of a system, and the system and its relationships with the outside world5. Typically it shows the system to be analysed in the center, surrounded by links to various parties.

4

TR1101 CONVERGE Systems Architecture, Enhanced Architecture Guidelines, Deliverable DSA2.2, European

Commission, December 1996.

(13)

For the specific analyses of the pilot demonstrator companies, the context diagram may be very important since each transport company has its own environment. This environment may be similar to other companies, but the partners and relationships to the external world are not identical. The context diagrams may also vary because of they focus on different perspectives. The diagrams are drawn to show, in the most representative way, the specific demonstration tasks that will be performed.

In the generic case, the INTACT framework is the platform from which further analyses have been made. Since it is a generic framework it represents a common view of most of the transport business in Europe, meaning the environment is somewhat idealised. Therefore the INTACT framework itself, which contains a variety of components can be considered as a context diagram. In essence, the context diagram is a way to define the boundaries of the system, by showing what will be included in the analysis and what will be left out.

2.2.3 Functional analysis

As described briefly in the introduction of this chapter, the functional diagrams are graphical representations of functions and interfaces between functions, i.e. data flows. The diagrams show the functions and the exchange of data between the functions. The functional analysis consists primarily of data-flow diagrams (DFD), combined with the descriptions in the data dictionary.

The data flow diagrams includes some specific elements: - data flows;

- functions; - data stores; - parties.

It is quite common for DFDs to also include terminators, such that the model describes the components which create and consume data. In our analysis, and that proposed by CONVERGE, terminators are used to represent organisations and systems that interact with the system model. To obtain a clear and easy to read model, the terminators in this document have been moved to the context diagram, which show the interactions with the environment outside the framework.

An information flow connects the output of a function or a data store to the input of another function or data store. The data that is sent by the flow is not changed, only transferred. To have a successful connection the sending function must use a data format that is understandable by the receiving function. This is one of the main interests for the INTACT project, and therefore the focus will very much be on the information flows.

The functions produce and consume the data that is transferred via the information flows. In the INTACT framework the functions refer to actual functions within the transport business. As a result they should not only be regarded as computerised functions that transforms data values, but also functions which are part of the business process. In effect, the functions in the framework have a clear connection to the real transport operations.

Most IT systems use some form of data store, making this component an important part of the functional analysis. A data store is a (time-delayed) memory function for information. In many cases the data store represents a database management system (DBMS)6.

The parties involved in the system are shown in the context diagram, but are not normally included in the data flow diagrams. However, in INTACT, where several parties are involved, they have been included in the diagrams in order to show the complete picture of the system participants. In a generic

6

TR4018 INTACT Project, Main existing freight telematics systems and compatibility, Internal Report IR4.1, European Commission, May 1998

(14)

forwarder) can perform functions that are considered to be the responsibility of another (e.g. the carrier/fleet manager).

One of the difficulties designing DFDs is to decide what level a DFD should be disaggregated to. The effective solution allows the DFD to be disaggregated to the level that is appropriate for the purpose that the DFD is required7. In the case of the INTACT project and the associated framework, the level of disaggregation is such that it clearly describes the main components of the functions.

To make the functional analysis complete, a data dictionary is added to describe the components. The data dictionary includes metadata (data about data) which describes the data flows, functions and data stores used in the system.

2.2.4 Dynamic analysis

The functional analysis gives an overview of the data flows and the functions in the model, as well as the various parties. However, the representation of the system is static, which may imply some problems in special cases (i.e. describing communication processes). The functional model captures what a system does, without regarding when or if the functions are executed. To obtain a full understanding of how the system works and how the interaction between the functions works, time must also be included in the analysis. The order of the information exchange may be essential for the success of the communication.

As a result the functional analysis is, in some cases, completed using dynamic analysis. Such an analysis is made only where it is considered relevant and necessary for the understanding of the system's behaviour. In most cases the order in which the information is exchanged is more or less obvious. For the generic analysis the dynamics are considered as obvious, but in the specific cases some dynamic analyses may be found.

The dynamics of the system may be described in various ways. In the CONVERGE project an example of dynamic modelling is used, where the dynamics are described via control functions, control flows and control data stores. Control functions are meant to indicate functions that synchronise or co-ordinate the data processing functions and/or other control functions. Control signals are discrete signals, while the control stores have the same role as data stores.

The INTACT project has chosen a method that explicitly shows the exchange of information and the order of the exchange. Using this method the actual steps of how the information is transferred between various parties is clearly shown. An example of the diagram is shown in figure 2.2, on the next page.

7

Avison D.E., Fitzgerald G, Information Systems Development - Methodologies, Techniques and Tools, Alfred Waller Publishing Ltd., Oxfordshire, 1993

(15)

Figure 2.2 - The message exchange between various parties (the figure is from the Patinter case, see annex A4)8

Client Identification

Client Web - server FROTCOM Vehicle

Client permission

Client details & profile

Positions Positions Client Identification Positions requests Positions Positions requests Positions requests Client Profiles Time 8

CEN/TC278/WG2 N124, Road Transport and Traffic Telematics (RTTT), Freight and Fleet Management Systems

(16)

3 Revision of the INTACT framework

In this chapter the INTACT framework is discussed. The framework is a very important part of the generic analysis. It is the central platform for the development of the general data model and it is a feature that is likely to be revised throughout the project.

3.1 Introduction to the INTACT framework

The main objective of the INTACT project is to develop a generic data model to facilitate the realisation of integrated management systems in freight transport and to validate this model through demonstrations at various transport companies in Europe. It is very important to the INTACT project that the systems architecture development follows a common framework. To ensure that this takes place, INTACT has adopted a systems architecture model, which is the result of earlier investigative work originating from a CEN working group.

This pre-standard model was created by the CEN Technical Committee 278 Road Transport and Traffic Telematics, Working Group 2 (TC278/WG2), Freight and Fleet Management systems in January 1996. Since the model has not been adopted as a ‘set standard’, the original work has not substantially progressed. For its part, INTACT has decided to use the TC278/WG2 suggested "terminology and overall architecture" for freight and fleet management. However, this terminology and overall architecture will be adapted according to the needs of the INTACT project, while ensuring that the final version will be suitably flexible, such that it can be completely adapted if and when the existing suggestion becomes a CEN standard.

It is expected that the common framework will: • simplify comparisons between different test sites; • locate the user requirements in a common framework; • locate the applications/tools in a common framework; • facilitate the functional specification;

• simplify the work split when analysing various parts of the telematics systems within a transport company.

The work of the TC278/WG2 identified that within freight and fleet management systems there is a need to define a number of terms9, many of which are commonly used, but which are not commonly defined, and some new terms which are neither defined nor commonly used. In particular the focus was set on: • basic terms;

• functions;

• terms related to a simplified data model of freight fleet management; • terms related to telematics technology.

The list of terms and definitions from the CEN group may be found in annex A1. The work of the CEN group continues and a revised framework has been produced10. Consequently a part of the revision work for the INTACT framework, includes a comparison between the new CEN framework and INTACT framework. This comparison and an evaluation of the changes are presented in section 3.2.2.

9

A term refers to a word or expression used in the freight transport industry and which is included in data models of the transport process.

10

CEN/TC278/WG2 N124 Road Transport and Traffic Telematics (RTTT), Freight and Fleet Management Systems

(FFMS) Reference architecture and terminology, Part 1: High level architecture and terms, July 1997

and CEN/TC278/WG2 N130 Road Transport and Traffic Telematics (RTTT), Freight and Fleet Management Systems

(17)

3.2 Revision

The INTACT framework is not a static model, but one which will be developed throughout the whole project, and altered so that it corresponds accurately to the real world. Since there is no absolute "true" model, it may always be changed. It is an aim of the project to improve the framework by continuous revision.

3.2.1 Considerations and comments to the framework

An important task for the revision is to identify the relevant parts of the model, and leave out parts that are of less interest. It is particularly useful to keep the model as simple as possible11. The more complex the model gets, the more difficult it is to use. However, the framework must also be sufficiently comprehensive to describe the daily operations of the transport business. A too brief framework that does not include important parts of the freight transport business, will not serve the purposes of the INTACT project. It may be difficult to arrive at a model that can cope with this dichotomy. Throughout the INTACT project a pragmatic policy has been adopted. The level of detail is adapted to the needs of the current analysis. For example, invoicing is not included in the model, although invoicing and its associated problems are an important part of the transport business. However, this is a common aspect of all commercial business, but as the INTACT project is concerned with only freight transport, this will not be included. The same holds for insurance, which was excluded from the model for this reason as well.

The framework focuses on business process functions and their related information flows, but not the different the parties involved in a process. As freight transport markets change, the boundaries between the parties become less clear and this is certainly the case compared with a decade ago. The question about which party is doing what is more a matter of market positioning for each company, than an actual system change. The functions being performed are still more or less the same, as are the information flows.

3.2.2 New CEN TC278 proposal

The latest version of the CEN TC278 systems architecture model includes a complete set of new and interesting changes. The changes affect parties, functions as well as information flows. An overview of the functions and parties of the new model is shown in figure 3.1 on the next page.

(18)

Remote Vehicle & Cargo Reporting

Vehicle & Cargo Monitoring F15 F16 P5 Vehicle Intermodal Transport Process F17

P8 Other Transport Mode Operator

Transhipment / Storage Process

F18

P9 Transport Centre Operator

Transport Order Issuing F1 Shipment Progress Control F2 P1Consignor/ Consignee Order Control Order Planning &

Execution F3 F4 Dynamic Dispatching Process Trip / Tour Execution Traffic Information

Fleet / Vehicle Monitoring

Trip / Tour Control F5 F7 F8 F9 F10 P6 Authorities P4 Driver P2 Forwarder

P3 Carrier / Fleet manager

Trip/Tour Planning F6 Traffic Control

P7 Traffic Information Centre Operator

F11 F13 F14 Customs Clearance IF3:F3⇒F1 IF1:F1⇒F3 F12 Social Inspection Technical Inspection

The changes concerning the parties between the new version and the old draft that the INTACT framework relies on are the following:

• Old P.1 Consignor and P.7 Consignee have been combined into P.1 - Consignor / Consignee (Client);

• P.5 - Traffic Manager has been renamed to Traffic Information Centre Operator;

• The authorities, which were originally not included in the draft proposal, now have a central role. Also some new functions have been included in the CEN model:

• Traffic Control (Authorities party); • Technical Inspection (Authorities party); • Social Inspection (Authorities party); • Customs Clearance (Authorities party).

(19)

As a consequence of combining consignor and consignee, the consignee also has the function Transport Order Issuing, similar to the one of the consignor.

3.2.3 Comparison between the new CEN proposal and the INTACT framework

As part of the CEN’s new proposal the consignor (P1) and consignee (P7) functions are combined. This change has been made because both are clients of transport companies. However, for INTACT, they are regarded as having different functions and will remain separate parties in the framework, so as to investigate and map the information flows in the transport business.

In terms of the INTACT framework one new party, the support services supplier (P.11), was added as result of the analysis completed as part of the user requirements workpackage (WP3). This is regarded a relevant party for the transport business and will therefore remain in the framework.

CEN also included external authorities in their framework, while these parties are not retained within the INTACT framework. External authorities cover functions such as traffic control, technical inspection and customs clearance. These are all functions, which take place in the transport business, but their impacts on the daily operations are, at present, limited. However, some developments such as the forthcoming introduction of electronic tachographs will be of interest to the INTACT project and therefore this party is considered on the fringe of the framework.

Even at this stage in the project, the INTACT framework has been expanded to include more functions than were originally provided in the CEN proposal. These additions have arisen as a result of the analysis carried out at the four test site companies and the generic analysis completed in other workpackages. The functions are:

- Invoicing (F.16);

- Cost and performance analysis (F.17); - Consumables cost issuing (F.18).

When analysing the functions focusing on the interactions between them, much exchange of information is revealed. Those findings have resulted in new information flows that are not included in the CEN proposal. The new information flows are shown in table 3.1.

Table 3.1: Added information flows within the INTACT framework.

Code From func.

To func.

Type of information

IF.48 F.7 F.14 Vehicle/Cargo Status Request IF.49 F.12 F.11 Shipping data

IF.50 F.11 F.12 Consignment confirmation

IF.51 F.1 F.2 Issue Order Status Information Concerning Control IF.52 F.2 F.1 Consignor Order Status Information

IF.53 F.11 F.2 Inventory Status IF.54 F.11 F.12 Inventory Status

IF.55 F.3 F.16 Forwarding Orders Information IF.56 F.3 F.4 Forwarding Orders Information IF.57 F.4 F.16 Forwarding order status information

To conclude, the INTACT framework will not be fundamentally changed even after the comparison with the CEN group proposal. However, the comparison exercise was an important means of validating the framework developed thus far.

Collaboration between the INTACT consortium and the participants from the CEN group is proposed, and ideas and information will be exchanged. This will hopefully lead to a better standard, as well as a better INTACT model that will help shape any future standard.

(20)

After the revision of the framework according to section 3.2 the new framework has been built. The revised framework is shown in figure 3.2. The codes that are used for the information flows are listed in table 3.2. Annex A2 also describes the new framework, even more in detail.

Figure 3.2: The revised INTACT framework

P.1 Consignor P.4 Driver F.9 Trip / Route Control F. 1 Transport Order Issuing

P.9 Other Transport Mode Operator

F. 13 Combined Transport

Process

P.6 Transport Center Operator F. 11

Transshipment / Storage Process

F. 3 Order Planning &

Execution P.7 Consignee F. 12 Shipment progress control F. 4 Order Control P.5 Traffic Manager F. 2 Shipment progress control F.10 Traffic Management F. 5 Operational Planning (Dispatching) F.6 Trip / Route Planning F.7 Fleet / Vehicle Monitoring P.8 Vehicle F.14 Remote Vehicle &

Cargo Reporting

F.8 Trip / Route

Execution F.15

Vehicle & Cargo Monitoring

P.3 Carrier / Fleet manager P.2 Forwarder IF.29 IF.30 IF.25 IF.24 IF.23 IF.28 IF.9 IF.1, IF.2 IF.3 IF.21 IF.6, IF.14 IF.15 IF.10 IF.27 IF.18 IF.16,IF.17 IF.31 IF.33 IF.34 IF.19, IF.20 IF.22 IF.32 IF.26 IF.5 IF.4 F. 16 Invoicing F. 17 Cost & Performance

Analysis

IF.35 IF.37

IF.36 IF.38

P11. Support Services Supplier

F.18 Consumables Cost Issuing IF.39 IF.40 IF.41 IF.42 IF.43 IF.44 IF.12 IF.45, IF.46 IF.47 IF.13 IF.48 IF.7 IF.8

IF.49 IF.50, IF.54

IF.51 IF.52 IF.53 IF.55 IF.56 IF.57

(21)

Table 3.2: Codes used for the information flows within the INTACT framework. Code From Func. To Func. Name IF.1 F.1 F.3 Transport Opportunity Presentation IF.2 F.1 F.3 Transport Booking / Transport Instruction IF.3 F.3 F.1 Quotations Information / Instruction Confirmation IF.4 F.2 F.4 Cargo / Consignment Status Request

IF.5 F.4 F.2 Cargo / Consignment Status Report IF.6 F.3 F.5 Pick-Up Delivery List

IF.7 F.1 F.11 Shipping data

IF.8 F.11 F.1 Consignment confirmation IF.9 F.5 F.4 Order Progress Report IF.10 F.4 F.5 Dispatching Status Request IF.11 --- ---

---IF.12 F.6 F.10 Traffic Information Request IF.13 F.7 F.8 Fleet / Vehicle Position Request IF.14 F.3 F.5 On-line Pick-Up Information

IF.15 F.5 F.3 Pick-Up Order Confirmation /Refusal IF.16 F.8 F.6 Trip / RouteStatus Information IF.17 F.8 F.6 Current Traffic Information IF.18 F.8 F.7 Vehicle Position Report IF.19 F.6 F.9 Trip Alteration IF.20 F.6 F.9 Daily Delivery Plan IF.21 F.11 F.4 Status Request

IF.22 F.9 F.6 Trip / Route Change Confirmation / Refusal IF.23 F.4 F.11 Status Reporting

IF.24 F.3 F.11 Request IF.25 F.11 F.3 Acceptance

IF.26 F.12 F.4 Consignment Status Request cf IF.4 IF.27 F.10 F.6 Traffic Situation Report

IF.28 F.4 F.12 Consignment / Reusable Equipment Status Report IF.29 F.3 F.13 Booking instruction, Status Request

IF.30 F.13 F.3 Confirmation or refusal

IF.31 F.14 F.7 Vehicle / Cargo Parameter Message IF:32 F.15 F.8 Vehicle / Cargo Parameter Display(s) IF.33 F.9 F.15 Vehicle / Cargo Parameter Inputs

IF.34 F.15 F.9 Vehicle Current Route / Location Parameters IF.35 F.9 F.17 Trip expenses / Km / Time Report

IF.36 F.9 F.16 Delivery Proof (Documents) IF.37 F.17 F.6 Cost Report

IF.38 F.16 F.1 Invoice IF.39 F.18 F.17 Cost data

IF.40 F.17 F.9 Vehicle running cost data IF.41 F.6 F.17 Statistical data

IF.42 F.5 F.6 Order-vehicle-driver list

IF.43 F.6 F.5 Vehicle status & position (cf. IF.18) IF.44 F.9 F.8 Trip and route plan

IF.45 F.7 F.6 Trip/route deviation info IF.46 F.7 F.6 Statistical data (cf. IF.41)

IF.47 F.6 F.7 Trip/route plan per vehicle/driver (cf. IF.19, IF.20) IF.48 F.7 F.14 Vehicle/Cargo Status Request

IF.49 F.12 F.11 Shipping data

IF.50 F.11 F.12 Consignment confirmation

IF.51 F.1 F.2 Issue Order Status Information Concerning Control IF.52 F.2 F.1 Consignor Order Status Information

IF.53 F.11 F.2 Inventory Status IF.54 F.11 F.12 Inventory Status

IF.55 F.3 F.16 Forwarding Orders Information IF.56 F.3 F.4 Forwarding Orders Information IF.57 F.4 F.16 Forwarding order status information

(22)

The INTACT common framework is useful in many ways: in definitions, modelling and discussions, and should be considered an important tool in the process of creating integrated management systems in freight transport. Furthermore by using this framework it also provides:

• the necessary structure by which previously developed models can be included into the more practical parts of the INTACT project.

• links into the Enhanced System Architecture Guidelines presented by the CONVERGE (Transport Telematics Support and Consensus) project focusing on system architecture, for presenting a model recommended to be used in the actual development of telematics.

The framework is the basis for the generic part of the functional analysis, and therefore includes the components parties, functions and information flows. At a deeper level data stores are also included.

The framework has gone through a revision which resulted into changes. A comparison has been made with a new CEN TC278 document, which led to some small changes and a validation of the model.

(23)

4 Break-down analysis

The break-down analysis is the major part of the generic track of the functional specifications workpackage. In this chapter the work and considerations of the analysis are described. In addition a summarised view of the results is given. A more detailed description of the results of the analysis may be found in the data dictionary in annex A2.

4.1 Approach

As described in the approach and methodology chapter (chapter 2), the break-down analysis is the main task of the generic functional specification. The result of the thorough analysis is a split of the main functions, defined in the generic INTACT framework, into sub-functions. These sub-functions have been defined and analysed, and the relations to other sub-functions have been identified. The relations consist of information flows between the sub-flows.

In order to really understand the functions, as well as the associated information flows, a thorough analysis has been made. The analysis is based on the revised INTACT framework, described in chapter 3.

One difficult problem when making an analysis like the one described in this chapter, is to define the level of detail of the functional split. The actual split into sub-functions depends on the relative importance of the actual function. Since some functions are more crucial than others, or more complex than others, the split into sub-functions is a matter of subjective judgements. Therefore the level of detail in the functional split may vary between the different functions.

As the aim of the INTACT project is to map and analyse the existing transport process and create one generic model, and examine a number of specific cases, it was considered that a useful approach would be to first identify the various parties. This is especially true for modelling the specific cases, as the structure of each participating company and their transport operations is relatively fixed and easy to map. In order to keep a similarity between the specific cases and the general model the same approach was therefore used when building the generic model.

A generic model aims to cover all variants and aspects of the transport process. Assigning all functions to specific parties, as in the INTACT model, will immediately create discussions about the model and its relevance. Some readers will argue that functions are assigned to the wrong party, or do not exist at all, while other will agree with the model. Further, the relations between the parties and the associated information flows are not relevant for all transport processes and environments in which the readers find themselves.

4.2 Analysis of the parties

To obtain a full description of the components of the framework the analysis started with describing the parties involved. These parties have been analysed and discussed when revising the framework (see chapter 3). It is important to clearly identify their role in the process. Experience from the work within the INTACT consortium as well as other international projects, shows that the various terms have different meanings in different parts of Europe. More important is perhaps that the different experts have different understanding of the words. A lot of problems occur because of the communication problem between e.g. computer experts and the hauliers that will actually use the systems.

As a step towards similar interpretations of terms, a transport related dictionary has been made by the CEN TC278 group. This dictionary is to be found in annex A1. Another contribution to obtain a

(24)

which includes definitions of technologies used in the transport telematics area.

The more detailed a framework like the INTACT framework becomes, the more important it is to have a clear understanding of the parties. It is also important to have a view of the context which they appear. Therefore a context analysis has been made for each party, describing the relations to other parties. The INTACT framework diagram itself gives an understanding of each party’s relation to other parties within the framework. Some parties, however, have also information exchange with parties outside the framework. Where this information exchange is of importance, the context diagrams give information of it.

The result of the analysis of the parties may be found in the data dictionary in annex A2. For each party the following may be found:

• a context diagram of the party;

• a description of the party from the framework’s perspective;

• a list of the functions and sub-functions that are performed by the party.

4.3 Functional split

The major work of the break-down analysis is the actual functional split. Each function of the earlier revised INTACT framework (see chapter 3) was split into several sub-functions further describing the processes. A map of the functional split is found in table 4.1.

Table 4.1: Functional split of the original INTACT framework. Assoc. Function Sub- Name

Party Code function

Code Code

P.1 F.1 Transport Order Issuing

F.1.1 Order initialisation

F.1.2 Order Issuing

F.1.3 Order payment

P.1 F.2 Shipment Arrival Control cf F.12

F.2.1 Shipment Status Control

F.2.2 Payment Advice

P.2 F.3 Order Planning and Execution

F.3.1 Order Evaluation

F.3.2 Order Acceptance & Registration

F.3.3 Order Dispatching Transport Center Operator (TCO) F.3.4 Order Dispatching Carrier

F.3.5 Order Dispatching Other Transport Mode Operator (TMO)

P.2 F.4 Order Control

F.4.1 Order Tracking

F.4.2 Order Information

F.4.3 Re-usable Equipment

P.3 F.5 Operational Planning (Dispatching)

F.5.1 Order Entry & Check

F.5.2 Trip Planning

F.5.3 Vehicle / Driver allocation F.5.4 Order Status Control

12

TR4018 INTACT Project, Main existing freight telematics systems and compatibility, Internal Report IR4.1, European Commission, May 1998

(25)

Table A2.4 - continued

P.3 F.6 Trip / Route Planning

F.6.1 Route Calculation

F.6.2 Traffic Information Process Management F.6.3 Transport Statistics

F.6.4 Driver Information

F.6.5 Execution Control

P.3 F.7 Fleet / Vehicle Monitoring

F.7.1 Position & Status Processing

P.4 F.8 Trip / Route Execution

F.8.1 Get Next Trip

F.8.2 Driving

F.8.3 Loading and unloading

F.8.4 Generate Message

F.8.5 Communication system interface

P.4 F.9 Trip / Route Control

F.9.1 Change trip / route plan F.9.2 Collect & report trip / route data F.9.3 Communication system interface

P.5 F.10 Traffic Management

F.10.1 Traffic Information Processing

F.10.2 Request Management

P.6 F.11 Transshipment / Storage Process

F.11.1 Order Information F.11.2 Order despatching F.11.3 Order confirmation F.11.4 Replenishment process

P.7 F.12 Shipment Progress Control (cf F.2)

F.12.1 Order Shipping / Consignment

F.12.2 Order (Un)Loading

P.9 F.13 Combined Transport Process

F.13.1 Transport Booking F.13.2 Operational planning F.13.3 Transport Process Control F.13.4 Order Execution

P.8 F.14 Remote Vehicle & Cargo Reporting

F.14.1 Cargo probes/sensors interface F.14.2 Engine/Vehicle sensors interface F.14.3 Position Sensor Interface

F.14.4 Report Control

F.14.5 Communication system interface

P.8 F.15 Vehicle & Cargo Monitoring

F.15.1 Vehicle & Cargo Monitoring Control

P.2 F.16 Invoicing

F.16.1 POD checking

F.16.2 Invoicing

F.16.3 Distribute Invoices

P.3 F.17 Cost & Performance Analysis

F.17.1 Cost & Performance Processing

P.11 F.18 Consumables Cost Issuing

F.18.1 Consumables Cost Issuing

There is no “absolute” split of the functions into sub-functions. The actual division of a function into smaller elements is a subjective judgement depending on the actual perspective.

Splitting a function into sub-function also have effects on the information flows. An information flow that originally connects two functions, may actually connect several sub-functions to a function. In order to deal with this problem, the information flows are when necessary divided into sub-flows. Also

(26)

numbered outside the INTACT framework coding system. The numbering format is IntIF.x.y, where x is the function code and y is a sequential ordering number. An example of a function split is shown in figure 4.1.

Figure 4.1: The functions are split into several sub-functions. New sub-flows and internal information flows are included.

IF.z

IntIF.x.1

F.x.1 IF.z.1 F.y.a

F.x F.y

F.x.2 IF.z.2 F.y.b

For each function the following parts may be found in the data dictionary (annex A2): • a context diagram showing the context in which the function works;

• a data flow diagram (DFD) showing the sub-functions and the information flows; • a description of the sub-functions;

• a description of the sub-flows (if any);

• a description of the internal information flows.

Finally a description of all original information flows is given to complete the functional specification.

4.4 Functions, sub-functions and relations

The data dictionary is very complex and very technical, and the tables and diagrams are therefore put as an annex to the report (annex A2). In this section, however, a brief summary of the contents of the data dictionary. Instead of giving the actual data as in the annexes, this section discusses is contents in a more general sense.

The original high-level INTACT framework includes 11 parties (actually ten since the authorities have no function) and 18 functions. The functions are connected to each other by several information flows, which have been studied thoroughly. When splitting the functions the complexity of the systems increases rapidly. Each new sub-function means new sub-flows connected with it.

The new low-level framework is too complex to present in one picture. In order to present it somehow, the framework has been divided into smaller presentable charts in this section. Below the actual division is shown.

(27)

Order planning related functions

• F.1 - Transport Order Issuing; • F.3 - Order Planning and Execution; • F.5 - Operational planning (Dispatching); • F.6 - Trip / Route planning.

Order execution related functions

• F.8 - Trip / Route execution; • F.10 - Traffic management;

• F.11 - Transshipment / Storage process; • F.13 - Combined transport process.

Order control related functions

• F.2 - Shipment arrival control; • F.4 - Order control;

• F.7 - Fleet/Vehicle monitoring; • F.9 - Trip / Route control; • F.12 - Shipment Progress control;

• F.14 - Remote Vehicle & Cargo reporting; • F.15 - Vehicle and Cargo monitoring.

Invoicing and cost related functions

• F.16 - Invoicing;

• F.17 - Cost & Performance analysis; • F.18 - Consumables Cost Issuing.

However, as described before, the break-down analysis is very important to get a more detailed understanding of the current situation. It is also a way to further define the contents/purpose of a function. In order to obtain a useful model it has to be aggregated enough to show the details that causes the actual problems.

It is therefore very important to find a suitable level of abstraction when using the INTACT framework on real applications. Parts of less importance to the actual problem may be left out in order to limit the complexity, while other parts that are more in focus of the actual implementation may even be further extended and analysed. The CONVERGE Enhanced Guidelines uses the abbreviation KISS (Keep it

simple, stupid!). There are many examples of implementation projects of telematic systems that have

failed because of a too ambitious model.

4.5 Parties

There are several parties involved in executing a transport, but not all are active in every movement.

The below figure illustrates which parties are considered in the INTACT model:

Figure 4.2: Parties involved in the transport process.

P.1 Consignor P.5 Traffic Manager P.7 Consignee P.4 Driver P.3 Carrier/ Fleet Manager P.2 Forwarder P.6 Transport Center Operator P.8 Vehicle P.9 Other Transport Mode Operator P.10 Authorities P.11 Support Services Provider

(28)

or several time constraints the flow always includes a P.1 Consignor and a P.7 Consignee. In principal these

two parties could complete the transport themselves, normally with the use of a P.8 Vehicle and a P.4 Driver. In some branches of business this is normal, e.g. you own your own trucks and manage your own

distribution. Normally however there are many other parties in the process:

A P.2 Forwarder is often contracted by the consignor or the consignee, depending on which terms of

contract apply in the business relation between them. The forwarder is contracted because he is assumed

to have superior knowledge about how best to complete the transport in question. The forwarder sometimes owns his own trucks or in turn uses a P.3 Carrier/Fleet Manager to take care of the actual

movement. In other instances the forwarder might organise the transport to be conducted by a P.9 Other Transport Mode Operator, e.g. a rail-combi operator. As the focus in this project is on road based

transports the other transport mode operator is regarded as a separate party, even though he can be a fleet manager or even a forwarder. Sometimes the goods to be transported are found in, or pass through, a P.6 Transport Center Operator operating a transhipment business. Using data and information from a P.5 Traffic Manager, the transport process is completed using one or several P.8 Vehicles and P.4 Drivers. Two more peripheral parties are also included as they are important actors in the process, these two are P.10 Authorities and P.11 Support Services Provider.

4.6 Functions and relations

Functions would, as discussed above, be the natural starting point in designing a process, while in the INTACT project, we already have a current situation to analyse. Below is therefore pictured the pairs of functions, ”function couples” in the INTACT model together with a brief description of their relation to one another.

The functions can be grouped in different ways, e.g. whether they appear before, during or after the physical movement or in the way grouped below; according to how they are related to a number of key activities in the process.

The groupings are "approximate" and in some cases it might be argued whether a couple should belong in one group or another.

4.6.1 Order Planning related function couples

The order (F.1) initiates the transport process and the initiator is the P.1 Consignor. The most important

party is however the P.2 Forwarder, being the one receiving the order and also doing the order planning and execution (F.3). The forwarder takes care of arrangements (F.11) with the P.6 Transport Center Operator

and contacts with the P.9 Other Transport Mode Operator (F.13). After the administrative preparations data is

moved to the P.3 Carrier/Fleet Manager who does the operational planning (F.5), the trip planning (F.6) and

the fleet monitoring (F.7).

Figure 4.3: Order Planning related function couples.

F.1 Transport Order Issuing F.3 Order Planning and Execution F.3 Order Planning and Execution F.11 Transshipment/ Storage Process F.3 Order Planning and Execution F.13 Combined Transport Process F.3 Order Planning and Execution F.5 Operational Planning F.5 Operational Planning F.6 Trip/Route Planning F.6 Trip/Route Planning F.7 Fleet/Vehicle Monitoring

The order planning is a complex but very important part of the transport process. The planning of orders and the linking of orders to vehicles is what primarily decides the resource utilisation of the load unit, which is probably the most important factor in running a profitable process. Unfortunately the planning is very sensitive to disturbances and changes, which are in many cases more a rule than an

(29)

exception. The consignors initially don’t know weights, volumes and exact times for pickup, and forwarders can never be certain of travel times between locations for vehicles and possible breakdowns. Therefore the information flows between the parties are very important, and the timeliness and the quality of the data essential to the efficiency of the activities.

4.6.2 Order Execution related functions

Once the physical handling and movement of the goods is to be executed mainly four parties interact, with the P.3 Carrier/Fleet Manager being the spider in the web, the others are P.5 Traffic Manager, P.4 Driver and P.8 Vehicle.

The carrier/fleet manager collects data from various other parties, e.g. traffic information from traffic management (F.10), vehicle information from remote vehicle and cargo reporting (F.14) and trip/route

execution information (F.8) from the driver. All this information goes back into the trip/route planning

(F.6) function, where planning and replanning is an ongoing process.

Figure 4.4: Order Execution related functions.

F.6 Trip/Route Planning F.10 Traffic management F.14 Remote Vehicle and Cargo Report

F.7 Fleet/Vehicle Monitoring F.7 Fleet/Vehicle Monitoring F.8 Trip/Route Execution F.6 Trip/Route Planning F.8 Trip/Route Execution

As the real world changes continually, the order execution information is crucial to allow for a series of pickups, transports and deliveries within agreed time limits. The planning function of the carrier must be able to gather the relevant information and communicate new and changed information to the vehicle and the driver. A lot of work is being undertaken in this area, by the above parties as well as by others. Many vehicle manufacturers are implementing techniques to facilitate navigation and communication as standard equipment in their vehicles.

4.6.3 Order Control related functions

The order control functions are closely related to the order execution functions above, but are more focused on the whereabouts and the status of the shipments. The parties most interested in these functions are the parties that are most affected when deviations from the originally agreed schedule appear, namely P.1 Consignor and P.7 Consignee. The party gathering, processing and delivering the information is P.2 Forwarder in the order control function (F.4). The information comes from the P.3 Carrier/Fleet Manager, operational planning (F.5), P.6 Transport Center Operator gives information from the

transshipment storage process (F.11), and more information is received from P.4 Driver and P.8 Vehicle.

Figure 4.5: Order Control related functions.

F.5 Operational Planning F.4 Order Control F.2 Shipment Progress Ctrl F.4 Order Control F.12 Shipment Progress Ctrl F.4 Order Control F.11 Transshipment/ Storage Process F.4 Order Control F.9 Trip/Route Control F.6 Trip/Route Planning F.9 Trip/Route Control F.8 Trip/Route Execution F.15 Vehicle and Cargo

Monitoring

F.9 Trip/Route

(30)

delivered according to plan and no deviations would occur. However, we know that the world is not ideal and that things happen. As these deviations might have widespread effects on e.g. production in a plant it is important that efficient information structures are available, transferring information about this between all interested actors. Today POD, proof of delivery, is often discussed and many consignors and consignees want to receive PODs to be able to do their own analysis and follow up.

4.6.4 Performance and Cost related functions

The carrier operates under constant pressure to be more efficient, and having a good understanding of the operating costs can assist. The way to be more efficient is to follow up costs and analyse data. Therefore the P.3 Carrier/Fleet Manager should have a function for cost and performance analysis (F.17).

This function receives data and information from P.4 Driver (F.9), its own trip route planning function

(F.6) and from the P.11 Support Services Provider function consumables cost issuing (F.18).

Figure 4.6: Performance and Cost related functions.

F.9 Trip/Route

Control

F.17 Cost and Per-formance Analysis

F.6 Trip/Route

Planning

F.17 Cost and Per-formance Analysis

4.6.5

Invoicing is of course important, and invoicing functions exist with all parties in the model, but the invoicing function ( ) discussed in the INTACT project is the P.2 Forwarder’s

provided to the P.1 Consignor P.7 Consignee, due to terms of payment). The data

P.1 Consignor’s

transport order issuing ( ).

Figure 4.7: Invoicing related functions.

F.9 Trip/Route Control F.16 Invoicing F.1 Transport Order Issuing F.16 Invoicing

4.7 Conclusions

From the break-down analysis within the functional specifications workpackage several conclusion may be drawn:

• with a functional split the complexity of the system increases rapidly;

• the functional split is necessary to understand the processes underneath the normal functions; • when using the INTACT framework, it is important to find a level of abstraction that is detailed

enough to illustrate the problems, but as simple as possible to decrease the complexity (KISS).

Throughout the framework there are a lot of similarities. A transport booking, a position of a consignment etc., may be sent in several information flows in the framework. An important part of the work when designing the conceptual information model in INTACT workpackage 6, will be to identify these similarities. It is expected that similar solutions may be used for similar parts in the framework.

The INTACT framework handles this using single-direction, single purpose information flows. This means that the each information flow only (or mainly) transmits information in one direction. An advantage of this approach is that when referring to an information flow within the framework, it is possible to determine not only the exchanged information, but also the direction. In reality most electronic links mean interchange of information in both directions.

Functional specification for an integrated freight and fleet management system