Functional specification for an integrated freight and fleet management system

Transcription

1 Deliverable 5.1 Functional specification for an integrated freight and fleet management system Part A Status: RP Telematics applications of common interest Project: 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 Abstract Building on the experience gained from the DRIVE-I and DRIVE-II (ATT) projects, the main objective of the 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 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 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 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 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 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. Deliverable 5.1 part A Page I

3 Project Partners Partners in the 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 PATINTER Lda Portugal Deliverable 5.1 part A Page II

4 Executive summary The work presented in the report 1 has been carried out within the functional specification workpackage of the 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 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 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 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 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 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 framework is to obtain a useful tool for the further analysis within the 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 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 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. Deliverable 5.1 part A Page III

5 In the generic track a break down analysis has been made of the revised 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 workpackage 6, where a conceptual information model is to be built. The specific track of the project relies on the pilot projects at the four road freight transport companies within the 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 framework it has been related to the experience from: the test site projects; the results of the questionnaire survey in the users' requirements workpackage. Deliverable 5.1 part A Page IV

6 Table of contents Page 1 Introduction Overall description of the project The Functional Specification Workpackage Structure of the Report 3 2 Approach and methodology Overall structure of the work Methodology General Context analysis Functional analysis Dynamic analysis 7 3 Revision of the framework Introduction to the framework Revision Considerations and comments to the framework The new CEN TC278 proposal Comparisons between the new CEN TC278 proposal and the framework The revised framework Conclusions 15 4 Break-down analysis Approach Analysis of the parties Functional split Functions, sub-functions and relations Parties Functions and relations Order Planning related function couples Order Execution related functions Order Control related functions Performance and Cost related functions Invoicing related functions Conclusions 5 Functional specifications at the test sites Introduction to the test site companies The pilot projects Analysis Identification of similarities between the test sites Context Similarities related to central administration systems in general Similarities related to on board computers and administration systems Similarities related to operational planning systems and on board computers Similarities related to administrative systems and operational planning system Conclusions 28 Deliverable 5.1 part A Page V

7 6 Comparisons of the generic and the specific framework Relations to the framework Parties Functions Information flows The test sites and the user requirements Conclusions and discussion 33 7 Conclusions 34 References 36 Abbreviations 37 Annex A1: Terminology Annex A2: framework Annex A3: Comparison tables Deliverable 5.1 part A Page VI

8 1 Introduction In this chapter an overview is given of the 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 project Building on the experience gained from the DRIVE-I and DRIVE-II (ATT) projects, the main objective of the 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 project structure 4 specific pilot demonstrations user WP3 requirements (case specific) user requirements (generic) compatibility of main IT systems functional WP5 specification for pilots WP3 WP4 building interfaces evaluation method functional specification WP5 WP7 WP8 WP9 pilot demonstration verfication and evaluation of pilots development of conceptual information model WP6 Exploitation plan WP10 conceptual information model P r o j e c t E x t e r n a l m a n a g e m e n t c o m m u n i c a t i o n WP1 WP2 Deliverable 5.1 part A Page 1

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 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 workpackage 6. The functional specification is based on the 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 Deliverable 5.1 part A Page 2

10 generic framework is necessary. The test sites give a feedback to the more theoretical 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 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 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 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 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. Deliverable 5.1 part A Page 3

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 A 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 framework (which was an important output from the user requirements analysis in Workpackage 3 2 ) 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 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 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 others 3 ) 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 Project, User needs for integrated telematics applications in road freight transport, Deliverable D3.1, European Commission, May Avison D.E., Fitzgerald G, Information Systems Development - Methodologies, Techniques and Tools, Alfred Waller Publishing Ltd., Oxfordshire, 1993 Deliverable 5.1 part A Page 4

12 The CONVERGE project 4 give a useful suggestion of a methodology to be used. In the 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 General The analytical methodology adopted by 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 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 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 Combined Transport Process Function F.13.1 Transport Booking IF.3 Sub-function Information flow IF.3.1 Sub-flow Int.1 Internal information flow P.1 Consignor Party inside framework in the context diagram Brakes India Party outside framework in the context diagram Client Database Database 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 world 5. 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 Martin J, Odell J, Object-Oriented Methods - Pragmatic Considerations, Prentice Hall, New Jersey, 1996 Deliverable 5.1 part A Page 5

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 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 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 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 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 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, 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 Project, Main existing freight telematics systems and compatibility, Internal Report IR4.1, European Commission, May 1998 Deliverable 5.1 part A Page 6

14 model the boundaries between the parties are not very strict, and in some cases a party (e.g. a 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 required 7. In the case of the 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 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 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 Deliverable 5.1 part A Page 7

15 Figure The message exchange between various parties (the figure is from the Patinter case, see annex A4) 8 Client Web - server FROTCOM Vehicle Client Identification Client Identification Client details & profile Time Client permission Positions requests Client Profiles Positions requests Positions requests Positions Positions Positions 8 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 Deliverable 5.1 part A Page 8

16 3 Revision of the framework In this chapter the 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 framework The main objective of the 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 project that the systems architecture development follows a common framework. To ensure that this takes place, 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 Since the model has not been adopted as a set standard, the original work has not substantially progressed. For its part, 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 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 terms 9, 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 produced 10. Consequently a part of the revision work for the framework, includes a comparison between the new CEN framework and framework. This comparison and an evaluation of the changes are presented in section 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 (FFMS) Reference architecture and terminology, Part 2: Detailed Architecture, September 1997 Deliverable 5.1 part A Page 9

17 3.2 Revision The 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 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 possible 11. 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 project. It may be difficult to arrive at a model that can cope with this dichotomy. Throughout the 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 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 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. 11 This philosophy is named KISS - Keep It Simple, Stupid! - according to the CONVERGE systems architecture report. Deliverable 5.1 part A Page 10

18 Figure 3.1: The CEN TC278 revised framework. P8 Other Transport Mode Operator F17 Intermodal Transport Process P9 Transport Centre Operator F18 Transhipment / Storage Process P1Consignor/ Consignee F1 Transport Order Issuing F2 Shipment Progress Control IF1:F1 F3 IF3:F3 F1 F3 Order Planning & Execution F4 Order Control P2 Forwarder P7 Traffic Information Centre Operator F10 Traffic Information P6 Authorities F11 Traffic Control F12 Technical Inspection P3 Carrier / Fleet manager F5 Dynamic Dispatching Process F6 Trip/Tour Planning F13 Social Inspection F7 Fleet / Vehicle Monitoring F14 Customs Clearance P5 Vehicle F15 Remote Vehicle & Cargo Reporting F16 Vehicle & Cargo Monitoring F8 Trip / Tour Execution F9 P4 Driver Trip / Tour Control The changes concerning the parties between the new version and the old draft that the 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). Deliverable 5.1 part A Page 11

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 Comparison between the new CEN proposal and the 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, 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 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 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 project and therefore this party is considered on the fringe of the framework. Even at this stage in the project, the 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 framework. CodeFrom To Type of information func. func. IF.48F.7F.14Vehicle/Cargo Status Request IF.49F.12F.11Shipping data IF.50F.11F.12Consignment confirmation IF.51F.1F.2Issue Order Status Information Concerning Control IF.52F.2F.1Consignor Order Status Information IF.53F.11F.2Inventory Status IF.54F.11F.12Inventory Status IF.55F.3F.16Forwarding Orders Information IF.56F.3F.4Forwarding Orders Information IF.57F.4F.16 Forwarding order status information To conclude, the 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 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 model that will help shape any future standard. Deliverable 5.1 part A Page 12

20 3.3 The revised framework 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 framework P.9 Other Transport Mode Operator P.6 Transport Center Operator F. 13 Combined Transport Process IF.24 F. 11 Transshipment / Storage Process IF.7 IF.8 IF.53 IF.30 IF.29 IF.25 IF.49 IF.50, IF.54 P.1 Consignor F. 1 Transport Order Issuing IF.51 IF.52 IF.1, IF.2 IF.3 IF.38 P.2 Forwarder F. 3 Order Planning & Execution IF.55 F. 16 Invoicing IF.56 IF.21 IF.23 P.7 Consignee F. 12 Shipment progress control IF.28 IF.26 F. 2 Shipment progress control IF.4 IF.5 IF.57 F. 4 Order Control P.5 Traffic Manager F.10 Traffic Management IF.45, IF.46 P.3 Carrier / Fleet manager IF.12 IF.27 IF.6, IF.14 F.6 Trip / Route Planning IF.15 IF.42 IF.10 IF.9 F. 5 Operational Planning (Dispatching) IF.43 IF.41 IF.19, IF.20 IF.22 IF.36 F.7 Fleet / Vehicle Monitoring IF.13 IF.47 IF.37 F. 17 Cost & Performance Analysis IF.48 IF.31 IF.18 IF.40 P.8 Vehicle P.4 Driver IF.35 IF.16,IF.17 F.9 Trip / Route Control F.14 Remote Vehicle & Cargo Reporting F.15 Vehicle & Cargo Monitoring IF.32 F.8 Trip / Route Execution IF.44 IF.33 IF.34 P11. Support Services Supplier IF.39 F.18 Consumables Cost Issuing Deliverable 5.1 part A Page 13

21 Table 3.2: Codes used for the information flows within the framework. CodeFrom To Name Func. Func. IF.1F.1F.3Transport Opportunity Presentation IF.2F.1F.3Transport Booking / Transport Instruction IF.3F.3F.1Quotations Information / Instruction Confirmation IF.4F.2F.4Cargo / Consignment Status Request IF.5F.4F.2Cargo / Consignment Status Report IF.6F.3F.5Pick-Up Delivery List IF.7F.1F.11Shipping data IF.8F.11F.1Consignment confirmation IF.9F.5F.4Order Progress Report IF.10F.4F.5Dispatching Status Request IF IF.12F.6F.10Traffic Information Request IF.13F.7F.8Fleet / Vehicle Position Request IF.14F.3F.5On-line Pick-Up Information IF.15F.5F.3Pick-Up Order Confirmation / Refusal IF.16F.8F.6Trip / Route Status Information IF.17F.8F.6Current Traffic Information IF.18F.8F.7Vehicle Position Report IF.19F.6F.9Trip Alteration IF.20F.6F.9Daily Delivery Plan IF.21F.11F.4Status Request IF.22F.9F.6Trip / Route Change Confirmation / Refusal IF.23F.4F.11Status Reporting IF.24F.3F.11Request IF.25F.11F.3Acceptance IF.26F.12F.4Consignment Status Request cf IF.4 IF.27F.10F.6Traffic Situation Report IF.28F.4F.12Consignment / Reusable Equipment Status Report IF.29F.3F.13Booking instruction, Status Request IF.30F.13F.3Confirmation or refusal IF.31F.14F.7Vehicle / Cargo Parameter Message IF:32F.15F.8Vehicle / Cargo Parameter Display(s) IF.33F.9F.15Vehicle / Cargo Parameter Inputs IF.34F.15F.9Vehicle Current Route / Location Parameters IF.35F.9F.17Trip expenses / Km / Time Report IF.36F.9F.16Delivery Proof (Documents) IF.37F.17F.6Cost Report IF.38F.16F.1Invoice IF.39F.18F.17Cost data IF.40F.17F.9Vehicle running cost data IF.41F.6F.17Statistical data IF.42F.5F.6Order-vehicle-driver list IF.43F.6F.5Vehicle status & position (cf. IF.18) IF.44F.9F.8Trip and route plan IF.45F.7F.6Trip/route deviation info IF.46F.7F.6Statistical data (cf. IF.41) IF.47F.6F.7Trip/route plan per vehicle/driver (cf. IF.19, IF.20) IF.48F.7F.14Vehicle/Cargo Status Request IF.49F.12F.11Shipping data IF.50F.11F.12Consignment confirmation IF.51F.1F.2Issue Order Status Information Concerning Control IF.52F.2F.1Consignor Order Status Information IF.53F.11F.2Inventory Status IF.54F.11F.12Inventory Status IF.55F.3F.16Forwarding Orders Information IF.56F.3F.4Forwarding Orders Information IF.57F.4F.16 Forwarding order status information Deliverable 5.1 part A Page 14

22 3.4 Conclusions The 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 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. Deliverable 5.1 part A Page 15

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 A 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 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 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 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 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 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 Deliverable 5.1 part A Page 16

24 common understanding of terms, within the group, was the internal report IR which includes definitions of technologies used in the transport telematics area. The more detailed a framework like the 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 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 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 framework. Assoc.FunctionSub- Name PartyCodefunction Code Code P.1F.1 Transport Order Issuing F.1.1 Order initialisation F.1.2 Order Issuing F.1.3 Order payment P.1F.2 Shipment Arrival Control cf F.12 F.2.1 Shipment Status Control F.2.2 Payment Advice P.2F.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.2F.4 Order Control F.4.1 Order Tracking F.4.2 Order Information F.4.3 Re-usable Equipment P.3F.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 Project, Main existing freight telematics systems and compatibility, Internal Report IR4.1, European Commission, May 1998 Deliverable 5.1 part A Page 17

25 Table A2.4 - continued P.3F.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.3F.7 Fleet / Vehicle Monitoring F.7.1 Position & Status Processing P.4F.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.4F.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.5F.10 Traffic Management F.10.1 Traffic Information Processing F.10.2 Request Management P.6F.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.7F.12 Shipment Progress Control (cf F.2) F.12.1 Order Shipping / Consignment F.12.2 Order (Un)Loading P.9F.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.8F.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.8F.15 Vehicle & Cargo Monitoring F.15.1 Vehicle & Cargo Monitoring Control P.2F.16 Invoicing F.16.1 POD checking F.16.2 Invoicing F.16.3 Distribute Invoices P.3F.17 Cost & Performance Analysis F.17.1 Cost & Performance Processing P.11F.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 Deliverable 5.1 part A Page 18

26 new internal information flows occur, connecting two sub-functions within a function. These are numbered outside the 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. F.x IF.z F.y F.x.1 IF.z.1 F.y.a IntIF.x.1 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 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. Deliverable 5.1 part A Page 19

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 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 model: Figure 4.2: Parties involved in the transport process. P.1 Consignor P.2 Forwarder P.3 Carrier/ Fleet Manager P.5 Traffic Manager P.6 Transport Center Operator P.9 Other Transport Mode Operator P.4 Driver P.8 Vehicle P.7 Consignee P.10 Authorities P.11 Support Services Provider Deliverable 5.1 part A Page 20

28 As the task of a transport is to move something from a point of origin to a point of destination with none 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 project, we already have a current situation to analyse. Below is therefore pictured the pairs of functions, function couples in the 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 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 Deliverable 5.1 part A Page 21

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 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 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 Control Deliverable 5.1 part A Page 22

30 In an ideal world order control functions would not be necessary, as in that case all shipments would be 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 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 Performance Analysis F.6 Trip/Route Planning F.17 Cost and Performance Analysis Invoicing is of course important, and invoicing functions exist with all parties in the model, but the invoicing function ( ) discussed in the project is the P.2 Forwarder s provided to the P.1 Consignor P.7 Consignee, due to terms of payment). The data transport order issuing ( ). Figure 4.7: Invoicing related functions. P.1 Consignor s 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 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 workpackage 6, will be to identify these similarities. It is expected that similar solutions may be used for similar parts in the framework. The 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. Deliverable 5.1 part A Page 23

31 5 Functional specification at the test sites So far this report has mainly considered the generic issues (Track B) related to the project. The framework described in chapter 3 and the generic analysis in chapter 4 are very closely related. In this chapter the case specific issues (Track A) will be discussed, based on information obtained from the test site companies. There are four test sites in the project which involve four road transport companies. At each company various pilot tasks will be performed within the project. A detailed description of the companies and the systems integration that will be completed at each test site can be found in their respective annexes of this report. The deliverable of workpackage 3 may also be a useful reference. 5.1 Introduction to the test site companies The companies that serve as test sites in the project mostly run road based distribution and haulage services. They vary in size and by the types of product they offer. The smallest company has about 100 vehicles while the largest has offices in a number of EU countries and provides significant warehousing, distribution and logistics services. All the companies can be considered as medium and large sized operators and regard telematics applications as a means of achieving improved business efficiency, providing them with a competitive edge in those markets in which they operate. The companies are shown in Table 5.1. Table 5.1 Road freight companies participating in the demonstrations Full name Acronym Location Jan de Rijk Transport B.V. JDR Roosendaal, NL C. van Heezik B.V. Heezik Maarssen, NL PATINTER Portuguesa de Automóveis Transportadores, Lda PATINTER Mangualde, PT Inter City Trucks (Holdings) Ltd. ICT Hythe, UK Since the companies have their own specialisation and work in different environments the user requirements for telematics applications they use and integration they plan to implement also vary. However, even though such differences exist in their individual needs, there are similarities in the expectations they have of telematics systems and these are discussed in more detail in the next section. Currently all the transport companies taking part in the project have achieved reasonable levels of computerised automation in their offices and/or trucks. The technical sophistication of a transport company is an important factor for the successful introduction of new telematics solutions which aim to improve the transport operations. In Table 5.2, an overview of some of the telematics equipment at the test sites is given. A more thorough description of the test site companies is found in the deliverable D3.1, covering the user requirements analysis made in workpackage The pilot projects Each of the test site companies has defined pilot projects that will be performed within the project. The topics for the pilot projects have been chosen to fulfil the user requirements of the demonstration companies. A summary of the solutions to be implemented at each test site is shown in Table 5.2. Deliverable 5.1 part A Page 24

32 Table 5.2 Summary of the solutions to be implemented at each test site Company JDR: Van Heezik: Solution 1. To create an interface between planning system and operational applications Automate the input of logistics trip data into the central system Quotations To create an interface between planning system and operational applications To create an EDI 4. Quotations 1. Connect the freight assignment software with the positioning and messaging system. Allow all customers (in a generic way ) to automatically consult the information about their shipments 3. Automate the transport instructions and the transport confirmations using a remote access where the ails (origin, destination, etc.), receiving also automatically the confirmation or refusal. 1. Build an interface and integrate fuel price data with the main computerised administration system and 2. Provide inventory status information to clients via an EDI gateway. Analysis The objectives of the specific functional analysis were the following: to create a functional specification that will serve as a basis for the design and building of interfaces framework. While the first objective requires that the analysis is adapted to the current situation, the environment second object demands conformity between the test sites, while the last objective requires a similar methodology to be used as in the generic analysis. objective is to solve the actual problems. This requires a very pragmatic point of view, since the analysis has to be understood by all people involved, both the users, the analysts and the software the objectives. The analyses mainly follows the methodology presented in chapter 2, which consist of two separate In some cases dynamic analysis has been added to provide a better description of the system. A more detailed description of the analyses is found in chapter 2. very good way of representing the system. For the Inter City Trucks (ICT) and Patinter case, where also genuine applications are to be developed, an has been added, which follows the Deliverable 5.1 part A Page 25

33 standards in object oriented development. This has not been performed at the other two test sites, since the object-oriented approach gives little benefits for interface solutions. 5.4 Identification of similarities between the test sites The identification of similarities between the test sites in the -project is described in this chapter. The generic framework and the site-specific details are the main input to this chapter. This enables the combination of the specific and generic tracks of the project, in order to assure consistencies in the common framework and between the test sites. In order to describe the similarities, the context of the test site projects will be described, indicating the main similarities between several systems and the interfaces to be built. The next step is to relate these components to the revised framework, as described in chapter 3. This will address parties, functions and information flow (also see Annex A3 in which an overview of all parties, functions and information flows involved at the specific test sites is given). The final section discusses the similarities considered in terms of the development of the conceptual information model in workpackage 6 and the building of the specific test site interfaces in workpackage Context Within the scope of the project the type of systems that are to be integrated have been studied and their similarities identified. What all test sites have in common is the building of interfaces with a system for central administration. However, the exact functionality of their central systems differs. Table 5.1 gives an overview of the companies, the functionalities and the type of interfaces to be built. Table 5.1 : Central administrative systems, functionalities and interfaces to be built Company System Functionalities Interfaces to be built with : ICT Saturn Central administration, planning and inventory system (planned) central database systems of fuel companies generic interface (FTP) mobile communication system De RijkChainwareCentral administration, order management Van HeezikChainwareCentral administration, order management PatinterQuasarFreight assignment and (planned) order management planning system black box system /mobile communication system quotations planning system black box system/ mobile communication system customers (EDI) positioning/ messaging system customers /forwarders systems (Internet) Similarities related to central administrative systems in general The situation in both the Dutch companies is rather similar. They both use Chainware software, consisting of transport, distribution, customs handling and forwarding modules. For the project relevant functionalities are order management (order entry, tracking and information), invoicingfacilities and reusable equipment information. Chainware is primarily a central administrative system and does not support real planning facilities. For these reasons, both companies will implement an operational planning system for the dispatching of orders to trips and tours. Alternatively the operational planning is assigned to a third party carrier. Using an EDI gateway (UNES), Chainware is capable to communicate with the outside world. At the Van Heezik site, an extension of the EDIfacilities with customers and third party carriers is planned; at this site Infodis can act as an Deliverable 5.1 part A Page 26

34 intermediary. The aim for the EDI-project of Jan de Rijk is to improve the EDI-exchanges with customers (for example: to exchange quotations and order confirmation/refusal). In both other companies the situation is different. There is no clear distinction between a separate administrative system and an operational planning system. Patinter s system Quasar is developed by Quadriga and is at this moment mainly a freight assignment system. In the scope of the project, Patinter is planning to expand the functionalities for customers (consignor, consignee and forwarders) with possibilities for order entry (add freight and check details) and shipment progress control (information on the status of freight). With the addition of order management the functionality of Quasar has similarities with (a part of) Chainware, which are primarily related to the order management process. However, there are more differences. They are mainly: Patinter intends to use a web server in building an interface between Quasar and systems of their customers, instead of using an EDI module like Van Heezik and de Rijk; Patinter allows customers direct access (via a password and restricted access) to the Quasar database with orders, to add an order and to check details of the execution. Both Dutch companies do not allow customers access to their order database. Their functionality is limited to sent/receive confirmations/refusals, invoices and status-information in case of arrival or delay of the shipment. In general these differences can be caused by the type of company and transport. For example both Dutch companies have more groupage activities while Patinter has more full loads and therefore more involvement of customers. ICT has a main operating system at the office with a back-office application for accounting (this system is called Saturn). One of the objectives of the project is that Saturn will be used as a controller, gateway and central database for other systems, offering mobile data communication and EDI modules. Using a generic FTP interface, ICT s customer (Brakes India) will have access to a new warehousing and inventory management system at ICT and Genesis. Using the interface Brakes India will be able to check the inventory level at the warehouse and to place orders at ICT for transporting products to the customers of Brakes India in Europe. This situation is in a certain way comparable to the situation of Patinter, where the customer has direct access in Quasar in order to check the status of his freight and to add new freight. Patinter plans to provide access by using an Internet-browser. At ICT the final choice between an EDI or an Internet solution has not yet been decided. The administrative process of automatic invoicing via an EDI-message is a similarity between ICT and Van Heezik. In the situation of ICT, automatic invoicing is planned for Brakes India. At Van Heezik s EDI project, the sending of an automatic invoice and/or additional cost messages is planned for customers and carriers, either direct to the customer or by way of their agent Infodis Similarities related to on board computer and administrative system Table 5.1 shows that Van Heezik and de Rijk are both building interfaces between their central administrative systems and that of their vehicles. These interfaces differ from those linking the operational planning system and the vehicle, because they will not be used for purpose of planning or location, but for the processing of logistic tripdata (the aim is to use these for administrative and statistical reasons like cost and performance analysis, the monitoring of the technical condition of the vehicles, driver s expenses and hours, etc.). These data are saved in the cartridge of the Black Box system in the vehicle and periodically processed by a PC application of the Black Box system. It is also possible to have the data directly available by uploading it via satellite. The interface to be built between the PC application of the Black Box system and the central administrative system takes care of processing the data in order to be used correctly in several modules. At both other test sites the communication between vehicle and administrative system is outside the scope of the -project, although at ICT fuel price information will be available to the driver from the Saturn System. After automatically receiving, processing and comparing fuel prices from fuel Deliverable 5.1 part A Page 27

35 companies, the planned interface automatic produces the final fuel price choice, which is retrieved by the drivers using mobile data communication Similarities related to operational planning systems and on board computers At all test sites, communication between vehicles by using mobile data communication is planned or already in operation. At the Patinter test site, an application to exchange messages and automaticcally monitor the vehicle position has already been developed. Both Dutch companies are planning to develop an interface between the operational planning system and the on board computer; they intend to do this within the scope of the -project. Their requirements on this point are rather similar to the current situation at Patinter: exchanging messages and receiving automatic up-dates with respect to the location of the vehicles. ICT also intends to upgrade the equipment in the vehicle in a way that drivers will receive more information by using in-cab terminals, although this will not be completed within the scope of the -project Similarities related to administrative systems and operational planning system At the test sites of Van Heezik and de Rijk high priority is given to the synchronisation of the data from the operational planning system (refered to as Fleet Management System) and the central administrative system of Chainware. Such as combination of data means information about the execution of orders by the carrier is always up to date and available for order management executed by the forwarding department. This distinction is important for both companies, because the forwarding department has to inform the customers about the status of orders. The carrier can also be a third party. At the test-site of Patinter an interface has to be developed for the synchronisation of the positioning and messaging system (Frotcom) with the central system of Quasar. Although the functionalities of Quasar and Chainware may differ, the data (status of the execution of an order) and the synchronisation process have similarities. By building an interface (using a Web-server) between systems of customers and the Frotcom application, clients have direct access to check the position of the trucks. A possible explanation for the different approach might be that Patinter is more specialised as a carrier and has to inform clients (shippers and forwarding companies) about the exact status of the trip and provide monitoring possibilities to them. 5.5 Conclusions The specific track of the project concentrates on providing a functional specification for systems integration at the four road freight transport companies participating in the consortium. Each company can be considered as a medium or large sized operator and each regards telematics applications as a means of achieving improved business efficiency that provides it with a competitive edge in those markets in which it operates. The objectives of the specific functional analysis were: 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. To explore which similarities exist between the test sites, an analysis was made of the different findings. 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. Deliverable 5.1 part A Page 28

36 6 Comparisons of the generic and the specific track In this chapter similarities and discrepancies between the pilot projects at the test sites and the generic framework are discussed. More detailed data tables can be found in Annex A3. In the chapter the codes of the components in the framework are used. These codes are listed and explained in Annex A Relations to the Framework In this section the test-sites will be related to the revised common framework, as described in chapter 3 and similarities in terms of parties, functions and information flow will be identified Parties Table 6.1 shows the number of parties that are relevant to each test site, in the context of. These are the key participants in the transport process. The consignor issues the instruction to transport the shipment, which may be directly to a carrier or through a forwarder The carrier/fleet manager transports a shipment and delivers it to the consignee. Table 6.1: Pilot projects per party in the framework Number of projects at the test sites Party 4 (all test sites) P.1 - Consignor P.3 - Carrier / Fleet Manager P.7 - Consignee / Shipper 3 P.2 - Forwarder P.4 - Driver P.8 - Vehicle 2 P.6 - Transport Centre Operator 1 P.11 - Support Services Supplier None P.5 - Traffic Manager P.9 - Other Mode of Transport Operator P.10 - Authorities Driver, vehicle and forwarder are mentioned by three test sites. The driver and vehicle are used by the carrier/fleet manager to transport the shipment. The forwarder instructs a carrier to transport the shipment. The transport centre operator is mentioned by two test-sites. This party has two key functions: to store goods; and to tranship goods. Both ICT and Patinter want to give some of their customers more detailed information about the goods being stored or transhipped. Deliverable 5.1 part A Page 29

37 The support service supplier is only mentioned by one test site. The support service supplier provides services (i.e. fuel, tyres, maintenance etc) to the carrier/fleet manager. In this case, ICT receives actual fuel prices from fuel companies and after processing and comparing, provides modified information to its drivers. The operator of other modes of transport, the traffic manager and the authorities are not mentioned by any of the four test sites. These parties are not directly involved in the interfaces being developed within the -project. The other modes of transport operator is not mentioned, because intermodal transport is not the main business of any of the four test sites companies. Specific traffic information from a traffic manager is, at this moment, not used by the test-sites. Authorities are not an important party, because they are not directly involved in the main process from the test sites. Customs clearance is also not very important, because the main activities from the four test sites are within the EC. To summarise, the test sites encompass the main parties involved in the transport process. Since the companies themselves are carrier/fleet managers and even (partly) forwarders, the other main parties involved are the consignor and consignee and the driver and vehicle Functions Cost & performance analysis is the only function that is to be interfaced at all of the test sites. Table 6.2: Functions in the framework affected by pilot projects Number of test sites Functions 4 (all test sites) (None) F.17 Cost and Performance Analysis F.1 Transport Order Issuing F.3 Order planning and Execution F.5 Operational Planning F.7 Fleet / Vehicle Monitoring F.12 Shipment Progress Control F.14 - Remote Vehicle & Cargo Reporting F.16 Invoicing F.4 Order Control F.6 Trip / Route Planning F.2 - Shipment Progress Control F.8 - Trip / Route Execution F.9 - Trip / Route Control F.11 Transshipment / Storage Process F.18 Consumables Cost Issuing F.10 - Traffic Management F.13 - Combined Transport Process F.15 - Vehicle & Cargo Monitoring One of the consignor s funcitons, transport ordering, is mentioned by three test sites. Shipment progress control is mentioned by ICT and Van Heezik. Order planning and execution, order control and invoicing are mentioned by three test sites. These three functions are performed by the forwarder. Fleet/vehicle monitoring is mentioned by three test sites. Together with cost & performance analysis, and trip/route planning and operational planning (dispatching), which are mentioned by De Rijk and Van Heezik, all of the functions are performed by the carrier/fleet manager. Shipment progress control, the only function performed by the consignee/shipper is mentioned by three test-sites. Deliverable 5.1 part A Page 30

38 Trip/route execution and trip/route control, the functions performed by the driver are mentioned by most test sites. De Rijk and Van Heezik consider the driver and the vehicle external to their system and are mainly concerned with the information flows to and from the driver and vehicle and not in the specific functions performed by these parties. This is the reason why of the two functions of the vehicle, remote vehicle & cargo reporting is mentioned by three test-sites and vehicle & cargo monitoring is not mentioned by the test-sites. Consumables cost issuing, which is the only function which is performed by the support service supplier is mentioned by ICT and Van Heezik. ICT plans to develop an interface to that party. The transhipment/ storage process, which is performed by the transport centre operator is only mentioned by ICT. Traffic management, which is performed by the traffic manager and combined transport process, which is performed by the other mode of transport operator are not mentioned by the test-sites. These two parties are not relevant for the interfaces which are developed at the four test-sites. The functions performed by the authorities are outside the scope of the -project. Summarising the above: Cost & performance analysis appears to be the focus of telematics integration. This is closely linked to fleet/vehicle monitoring and in general communication with the driver/vehicle. The transport companies also want to satisfy the needs of their customers (consignor, consignee) with respect to order planning and execution, shipment progress control and invoicing. Less common but not less important, are the interfaces concerned with consumables cost issuing an and the transhipment/storage process Information flows Although the functions and parties involved per test site have similarities, the specific information flows, defined by the data that have to be translated by the interfaces, are quite dissimilar. The exact content of the flow differs per company, mainly because they are customised to meet the specific conditions or activities of a company. In a broader sense the contents of the information flows may differ, but the functionality is less variable. Similarities in the generic functions F1 Transport Ordering issues and F3 Order planning & execution, are represented by information flows 2, 3 in the generic framework. These flows concerning transport booking instruction and confirmation/refusual are mentioned by three test sites. This indicates the importance of electronic communications with customers. For Van Heezik and De Rijk this flow represents an EDI possibility to communicate on issues of order management. At Patinter this represents the access by Internet to the order database. Similarities between the generic functions F.3-Order Planning & Execution and F.5-Operational planning (Dispatching) are represented the information flows 14 and 15. This refers to the test -sites of Van Heezik and the Rijk, the internal synchronisation of data concerning orders in the order management and the operational planning system. Another information flow with similarities (Van Heezik & Patinter) is the IF38 invoice, sent from F6 Invoicing to the F1. Transport order Issuing. In the common framework the consignor is assumed to be the freight-payer, in practice this could also be the consignee or another forwarder or a third party. Another group of information flows with similarities, are the ones related to the interface between vehicle/driver and the central administrative and/or operational planning system. In relation with the following generic functions, most similar information flows are: IF 35; concerning trip expenses/km s and time reports; the sending of logistic tripdata from the driver to the office. In relation to the framework this concerns the information flow between the Deliverable 5.1 part A Page 31

39 functions F.9-Trip/tour control and F.17-Cost &Performance analysis. This flow is relevant for ICT, Van Heezik and de Rijk; IF 16, 19 and 20; concerning information on the status of the trip/tour and the daily delivery plan. These information flows concern between the functions F8/9. trip/tour execution or control (both belong to the diver) and the functions F6. Trip /tour planning. At van Heezik and de Rijk these are internal flows, at Patinter customers have restricted access to these data. 6.2 The test sites and the user requirements Table 6.1 shows the number parties that are relevant to each test site, in the context of. The list is ordered by frequency, which shows a brief indication of the relative importance of the parties from the test sites point of view. A much more exhaustive analysis was made in the earlier Workpackage 3 of the project 13. A questionnaire survey was sent out to European road freight transport companies, and they were asked, among other things, about their current and planned investments in electronic links with external parties. The graphs in figure 6.1 verify that the transport companies' interest in improved communication with the consignors and consignees (clients). In the same way, the parties that are of less relevance at the test sites are of very little interest to the general carrier. Both the traffic management (information provider) and other mode of transport operator are among parties having the least new investments. Figure 6.1: Current and planned investments in communication exchange with external parties (from the questionnaire survey in WP3). Current communication exchange 70% 60% 50% 40% 30% 20% 10% 0% Customer Supplier Customs Bank Freight forwarder Other mode of transport operator Information provider Planned investments in information exchange 60% 50% 40% 30% 20% 10% 0% Customer Supplier Customs Bank Freight forwarder Other mode of transport operator Information provider 13 TR4018 Project, User needs for integrated telematics applications in road freight transport, Deliverable D3.1, European Commission, May 1998 Deliverable 5.1 part A Page 32

40 The analysis presented in annex A3 shows that all functions except three are covered by the test site projects. The only functions that are not covered are: - F.10 - Traffic Management; - F.13 - Combined Transport Process; - F.15 - Vehicle & Cargo Monitoring. As described previously, the transport companies' interest in new investments in electronic links with other mode of transport companies and information providers, is relatively weak. 6.3 Conclusions and discussion In general the similarities identified in the context of the test sites are consistent with the results of the questionnaire, discussed in deliverable 3.1. Integration of systems is applied to the areas of: on-board computers and the operational planning system and/or the central administrative system; positioning and operational planning system; administrative system and operational system. The technologies used differ between the choice of EDI or Internet solutions. Mobile data communication is used or planned by all the test site companies. As with systems, the functions involved do not vary a great deal, although the final execution in terms of information flows differ, probably caused by differences in activities, specialisations and customer needs per company. The required functionalities do not vary as much, because similarities in the content of the information flow, such as the description of objects (i.e. vehicle related data, orders and drivers), have to be researched during the building of the conceptual information model stage. For the transport companies in the project the main parties involved in the transport process are the consignor, forwarder and consignee/shipper, which is also in line with the results of the literature review and the questionnaire carried out in users' requirement workpackage. The test site companies also indicate that they are more concerned with the information flows between the carrier/fleet manager and the vehicle/driver, than with the information flows within and between the functions carried out by the driver/vehicle. However it should be noted that a more efficient "integration" between the vehicle and the driver may be a mean to improve the integration with other systems. Authorities, other transport mode operator and traffic manager and the functions performed by them are not, at this time, important for the interfaces developed at the four test sites. This does not mean that they are not important for the generic model. At the most it gives an indication of the priority of the transport sector concerning the integration of telematics applications. This leads to the following set of generic functions: Transport Order Issuing; Order planning and execution; Order Control; Operational Planning (Dispatching); Trip/Route Planning; Trip/Route Execution; Trip/Tour Control; Fleet Vehicle Monitoring; Shipment Progress Control; Remote Vehicle & Cargo Reporting; Invoicing; Cost & Performance Analysis. Deliverable 5.1 part A Page 33

41 7 Conclusions This report describes the work carried out within the functional specification workpackage of the project. The objective of the workpackage is to define the functional specification of an integrated management system for road freight transport in two ways: specific for each demonstrator company; generic for the road freight transport sector as a whole. These two streams reflect the two "tracks" of the project. Even though the streams address the same issues, they give answers from different perspectives. This workpackage is an important platform for later work in the project, where demonstration applications will be designed and a generic information model will be built. The method of analysis used in the project is consistent with that set out by the CONVERGE project. According to CONVERGE the functional architecture needs to describe the logical behaviour of the system using a conceptual model. 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 focuses on the site-specific details rather than broader issues. For the generic track the situation is more or less reverse. In this case the framework, which was an important part of the user requirements analysis in workpackage 3, has been used as the platform. The original framework was based on an early draft proposal of the CEN TC278 committee, which has now been updated and replaced by a new version. Therefore a comparison has been made of the framework and the new CEN proposal. The differences have been analysed and considered. The generic analysis consists of three consecutive parts: 1. Revision of the framework. An important task for the revision is to identify components that are relevant to the model and to exclude components that are not necessary or of less interest. It is of great advantage to keep the model as simple as possible. 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. 2. Break-down analysis of the functions within the framework. In the generic track a break-down analysis has been made of the revised framework. All functions have been split into several sub-functions. The information flows between these subfunctions (i.e. inside the original functions) have been identified and mapped. 3. Building a data dictionary with descriptions of the components. From the break-down analysis, all components of the framework have been described and further analysed. The result of this has been a data dictionary, which is a very important input to the workpackage 6, where a conceptual information model is to be built. The specific track of the project concentrates on providing a functional specification for systems integration at the four road freight transport companies participating in the consortium. Each company can be considered as a medium or large sized operator. Each regards telematics applications as a means of achieving improved business efficiency, that provides them with a competitive edge in those markets in which they operate. Deliverable 5.1 part A Page 34

42 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. To explore which similarities exist between the test sites, an analysis was made of the different findings. 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 framework it has been related to the experience from: the test site projects; the results of the questionnaire survey in the users' requirements workpackage. The analysis leads to the following set of generic functions: Transport Order Issuing; Order planning and execution; Order Control; Operational Planning (Dispatching); Trip/Route Planning; Trip/Route Execution; Trip/Tour Control; Fleet Vehicle Monitoring; Shipment Progress Control; Remote Vehicle & Cargo Reporting; Invoicing; Cost & Performance Analysis. Deliverable 5.1 part A Page 35

43 References: EU-reports TR4018 Project, User needs for integrated telematics applications in road freight transport, Deliverable D3.1, European Commission, May 1998 TR4018 Project, Main existing freight telematics systems and compatibility, Internal Report IR4.1, European Commission, May 1998 TR1101 CONVERGE Systems Architecture, Enhanced Architecture Guidelines, Deliverable DSA2.2, European Commission, December Other sources 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 CEN/TC278/WG2 N130 Road Transport and Traffic Telematics (RTTT), Freight and Fleet Management Systems (FFMS) Reference architecture and terminology, Part 2: Detailed Architecture, September 1997 Avison D.E., Fitzgerald G, Information Systems Development - Methodologies, Techniques and Tools, Alfred Waller Publishing Ltd., Oxfordshire, 1993 Martin J, Odell J, Object-Oriented Methods - Pragmatic Considerations, Prentice Hall, New Jersey, 1996 Rumbaugh J, Blaha M, Premerlain W, Eddy F, Lorensen W, Object-Oriented Modeling and Design, Prentice Hall, New Jersey, 1991 Deliverable 5.1 part A Page 36

44 Abbreviations: ATT CONVERGE CEN DBMS DFD DRIVE-I DRIVE-II EDI ExtIF ICT IF IntIF JSD KISS OMT SSADM TC278/WG2 Advanced Transport & Telematics (DRIVE-II) EC-project aimed at standardisation issues European Committee for Standardization Data Base Management System Data Flow Diagram Dedicated Road Infrastructure and Vehicle safety in Europe See ATT Electronic Data Interchange External Information Flow Inter City Trucks Information Flow Internal Information Flow Jackson Systems Development Keep It Simple, Stupid! Object Modelling Technique Structured Systems Analysis and Design Methodology Technical Committee 278 (Road Transport and Traffic Telematics) Working Group 2 (Freight & Fleet Management Systems) Deliverable 5.1 part A Page 37

45 Annexes Deliverable 5.1

46 Annex A1 Terminology Deliverable 5.1

47 A1 Terminology Experience from the work within the project, as well as other international projects, shows that there are large differences in interpretation of keywords. This often leads to misunderstandings and communication problems within the industry, especially where systems designers are involved. Therefore a standardised set of the terms is a very important issue. The CEN/TC 278/WG 2 has made good progress in defining many of terms which are presented in this annex. The terminology used in this report has followed the definitions wherever possible. The list below also includes terms that are not provided by the CEN document. The terms with their definitions are arranged alphabetically. They have been classified into different categories, to facilitate the understanding of the terms and for possible future presentation of their relationships. The letter in the middle column of the table indicates to which category the terms have been allocated. Letter B: Basic terms Letter F: Functions Letter M: Other terms related to Freight Fleet Management Systems Letter T: Terms related to telematics technology Sources other than the CEN WG 2 are given in parentheses after the definition. As a rule, the definitions given by the ELA (European Logistics Association), in their publication Terminology in Logistics, 1994 are used wherever they have been found adequate. These are also reproduced by CEN/TC 273, Logistics. Based on ELA is used to indicate minor modifications from ELA. Also EDIFACT Directories have been consulted as another valuable source. Term Definition Accident B Sudden, un-predicted event which adversely affects the state of a vehicle and/or its occupants (ISO 6813) Agent B A person or organisation authorised to act for or on behalf of another person or organisation. (ELA) Air interface T Data transmission link between a vehicle antenna and the antenna of a terrestrial base station or a satellite. Arrival notice F See Delivery notice Article M A countable physical object, normally given an article number as a key to further information about it. Automatic emergency call F An automatically generated data message from vehicle to operating centre to indicate an emergency situation, triggered by sensors. Availability % B The probability that a unit at a random point in time within a given time interval is in at least a certain degree of preparedness to function or functioning under given running, environmental and maintenance conditions. (ISO) Brake pressure B The available pressure in a vehicle's air braking system. Bulk material M Goods of non countable character, for which volume or weight (mass) must be stated to define its quantity. Cargo B Goods transported or to be transported. (ELA) Cargo identity M Unique designation for the physical units of a goods item. It is often carried on a goods label, e.g. carrying a bar-code, affixed to the units. Cargo monitoring F Recording of data related to the cargo status, e.g. position, humidity, temperature Carrier M The party undertaking transport of goods from one point to another. (ELA) Combined transport B The movement of goods in one and the same loading unit which uses more than one mode of transport without handling the goods itself in changing modes (Based on ELA: intermodal transport) Communication link T A technical system that allows voice and/or data communication between individuals or systems at different locations, or mobile. Deliverable 5.1 Page A1.1

48 Term Definition Communication processor T A computer, as part of a communication link, enabling data communication, e.g. from a vehicle to operating center or vice versa. Consignee M The party such as mentioned in the transport document by whom the goods, cargo or containers are to be received and accepted (based on ELA) Consignment M A goods item or collection of goods items (to be) transported from one or many despatch locations to one or many delivery locations for one consignor to one consignee under the terms of one contract of carriage (EDIFACT) Consignment value M Total value in monetary terms of consignment. Consignment volume M Total volume of consignment including equipment and packaging, in stated units. (preferred: m³) Consignment weight M Total weight of consignment including equipment and packaging, in stated units (preferred: kg) Consignor / Shipper M An individual or organisation that prepares a bill of lading by which a carrier is directed to transport goods from one location to another. (based on ELA) Consolidation B (In transport) The grouping together of smaller consignments of goods into a large consignment for carriage as a larger unit in order to obtain a reduced rate. (ELA) Contract M A legally binding agreement between two parties in which the specific titles, rights, commitments and obligations of both parties are defined. (ELA) Contractor B An individual or organisation that undertakes to perform certain tasks stipulated in a contract. Cost of vehicle per km M The sum of all the necessary sacrifices associated with the operations of a vehicle, expressed in terms of money and at current value pre- or post-calculated over the total anticipated/recorded distance travelled during a calculation period. Dangerous goods M Goods which by their nature are dangerous (e.g. explosive, toxic) Delivery location M Location of consignee or other address, where goods are unloaded, according to consignment note or other instructions. Delivery notice F A message ending a logistical activity by stating the result, e.g. "cargo delivered at destination requested" Delivery time/date - actual - estimated - requested M Date/time on which goods or consignment are delivered at their destination. (code 35 in CL 2005) Date and/or time when the shipper of the goods expects delivery will take place. (code 17 in CL 2005) Date on which buyer requests goods to be delivered. (code 10 in CL 2005) (EDIFACT TRCL 92.1) Dispatcher M A person who performs the detailed allocation and subsequent control of transport resources to individual transport orders. Distance travelled M The distance actually travelled during the current or stated trip. Driver identity M Driver name and unique designation, e.g. personal identity number (PIN) or social security number. Driver's licence M Document proving permission to drive motor vehicle (issued by public authority). (Nordic administrative handbook) Driving hour monitoring Monitoring of compliance with regulations regarding driving, working and rest hours Driving time (loaded, empty) M Duration of driver's current driving period. EDI (Electronic Data Interchange) B (General) The transfer of structured data in electronic form between computer systems in separate organisations (Alternative) Emergency call F Call via telephone from vehicle to operating center to verbally report on an emergency situation. Equipment M (In transport) Material resources necessary to facilitate the transport and handling of cargo. Transport equipment does under the given circumstances not have the ability to move by its own propulsion. E.g. Sea container, trailer, unit load device, pallet. (ELA) Equipment of vehicle, - loading/unloading M Mechanical devices mounted on vehicle to enable loading/unloading, e.g. crane, derricks, rear lift platform Equipment of vehicle, - M See On board communication equipment communication Event T (In systems) Change of state in the world external to the system, which can trigger an action in the system Event driven T System process reacting on an event Deliverable 5.1 Page A1.2

49 Term Definition Fleet B All the vehicles, including drivers, at the disposal of one unit of (business or operation) management for performing the business or operation. Fleet business transactions F Inquiry aquisition, offer calculation and submission, contract settlement, invoicing and payments. Fleet maintenance management F Vehicle data compilation and analysis, maintenance planning, material planning, maintenance ordering and evaluation. Fleet management F Planning, monitoring, controlling and evaluating the movements and operations of a vehicle fleet. Fleet monitoring F Function of following the location and status of the various vehicles in the fleet. (ELA) Fleet operation control F Fleet monitoring, provision of special route guidance, traffic information, changes of tasks and route instructions; consignment or passenger pick-up/delivery instructions; trip, cargo, vehicle and driver status monitoring, vehicle/cargo tracking/tracing; break-down remedy support. Fleet operation evaluation F Monitoring and analysis of vehicle fleet and driver staff cost and performance Fleet operation planning and preparation F Scheduling of vehicles and drivers, preparation, up-dating, checking and transfering of documents, task assignment, load planning, operational route planning, provision of third party information. Formatted message B A set of operational information to be transferred between different parties, formatted according to specific rules, e.g. EDIFACT standards Forwarder M The party arranging the carriage of goods including connected services and/or associated formalities on behalf of a shipper or consignee. (ELA) Freight B 1. Goods in transport from one location to another. 2. The amount of money due for the carriage of goods and payable either in advance or upon delivery. 3. The revenue earned from the movement of cargo. (ELA) Freight and fleet management F The combined activities of freight management and fleet management Freight business transaction F Handling of market inquiries, offer and supplier evaluation, contract settlements including just-in-time requirements, invoicing and payments Freight centre B See Transport centre Freight invoice M The carrier's invoice for transportation charges applicable to a freight shipment. (ELA: Freight bill) Freight management F A set of activities related to the logistics chain from the supplier to the receiver of goods with the associated information and transaction flow Freight operation control F Cargo tracking, shipment and transport status monitoring and reception of delivery information Freight operation evaluation F Cost and performance analysis and elaboration of freight statistics Freight operation planning and preparation F Preparation of transport documents, such as transport orders, customs declarations, dangerous goods declarations and notices of dispatch Fuel consumed M The volume of fuel actually consumed during the current or stated trip. Fuel consumption B The volume rate of fuel consumption under current load conditions. Functional message B A set of operational information to be transferred between different parties, including vehicle and dispatch center. Goods accompanying document M Any document accompanying the goods needed for procedures related to the movement of the goods. Goods item M A separately identifiable quantity of goods, which is recognized for some period of time as a subject of actual or potential handling. Goods label M Form or document for marking, addressing, etc., may be marking label, address label, etc. (SS ) Groupage B (In road transport) The collection of several small consignments and the formation of one large shipment thereof. (ELA) Hazardous Goods M Goods which by its nature is dangerous and/or which is overweight or oversize with respect to transportation and for which special regulations apply Hazardous goods monitoring (HGM) F A set of activities by authorities to monitor and control the transportation of hazardous goods. Hazardous goods communication F Actual real-time reporting of status and location as requested, directly from vehicle to traffic control centre, or indirectly via fleet management centre, and receipt of instructions from fleet management or traffic control centre. Hazardous goods operation management F Haulier and driver activities, related to the proper handling of hazardous goods transport, including the associated information flow Deliverable 5.1 Page A1.3

50 Term Definition Hazardous goods route planning F Activity of creating a route plan taking into account the restrictions related to the cargo and if required obtaining an authorisation from responsible authorities Intermodal change planning and F Selecting transport modes and providing necessary booking. preparation Intermodal transport B Transport where a part of the journey is by rail, inland waterway or sea and any intermediate parts are carried out by road (Based on ELA: combined transport) Intermodal Transport Unit (ITU B Containers, swap bodies or semi-trailers suitable for intermodal transport or UTI) Journey M The movement of a particular consignment from the consignor to the consignee. Level of service (of road traffic) B A qualitative measure describing traffic flowing conditions and their perception by motorists and passengers (CEN/TC 278/WG 8) Load factor / utilisation M The quotient of the actual load of a transport resource (group of transport resources) and the available capacity during a particular period. It indicates the extent to which the capacity is used during a particular period. (Based on ELA) Loading / unloading duration M The time period planned or actual for loading/unloading. Loading location M A location for loading goods. Loading time/date - actual - estimated - requested M The point in time when loading is planned to start or actually started. Date/time at which the cargo is picked up. (EDIFACT TRCL 92.1 code 200 Pickup/collection date/time of cargo, in CL 2005) Date/time when the shipper of the goods expects to start loading Date on which principal requests goods to be loaded. Logistical activity M Abstract concept binding together a goods item and the operations performed on it. It can be given an identity to which messages, related to it, can refer. Logistics B The planning, execution and control - of the movement and placement of people and/or goods, - and the supporting activities related to such movement and placements, within a system organised to achieve specific objectives. (CEN/TC 273) Maintenance B The combination of all technical and corresponding administrative actions intended to retain an item in, or restore it to, a state in which it can perform its required function (stated condition).(ela) Manifest B (in transport) Document which lists complete specifications of the goods loaded for transport to various destinations by a vessel or other means of transport. As a rule cargo manifests are drawn up by the agents in the ports of loading and are based upon the Bills of Lading. Note: For shipping a manifest represents a cumulation of bills of lading for official and administrative purposes. (ELA) Maximum load of vehicle M The maximum weight (mass) of goods which can be loaded into a means of transport. Maximum volume capacity of vehicle M The maximum volume of goods (in m 3) which can be loaded into a means of transport. Means of transport M A self-propelled vehicle, e.g. ship, air-plane or lorry, designed or extra equipped to transport the relevant cargo. Mobile EDI B Exchange of EDI messages to and from a portable or on-board computer, moving or not, with minimum human intervention during an application to application process. Mobile station T Radio terminal for speech and/or data communication in a vehicle. Multi-modal transport B The carriage of goods by at least two different modes of transport (ELA) Number of packages M Number of packages (content and packing) included in a goods item. On board communication equipment T Radio or infrared communication equipment enabling voice and/or data communication between the vehicle, stationary or in motion, and fixed stations. On board computer T A computer mounted in the vehicle, enabling data acquisition, storage, processing, printing and/or communication in the vehicle On board peripherals T Sensors and actuators or other data equipment connected to the on board computer. Package/Parcel M 1. Any physical piece of cargo in relation to transport consisting of the contents and its packing for the purpose of ease of handling by manual or mechanical means. 2. The final product of the packing operation consisting of the packing and its contents to facilitate manual or mechanical handling (ELA) Party M Generic term for the different actors involved in a logistical activity. Pick-up address M See Loading location. Deliverable 5.1 Page A1.4

51 Term Definition Pick-up date M See Loading time/date Place of arrival B A port, airport or other location at which a means of transport is scheduled to arrive or has arrived. Place of delivery M See Delivery location Place of departure M A port, airport or other location from which a means of transport is scheduled to depart or has departed. (ELA) Polling T The process whereby data stations are invited one at a time to transmit. Polling frequency T Periodicity by which a data acquisition system requests data from one specific data source. Position determination B Autonomous or assisted determination of a vehicle position with reference to a given co-ordinate system. Position of vehicle M See Vehicle position Principal B An individual or organisation that requests certain tasks to be performed (by a contractor) against a relevant form of remuneration, when relevant stipulated in a contract. Road transport vehicle B (Truck, in road transport: Class of automotive vehicles of various sizes and designs for transporting goods.) (Lorry: Motor truck used for the transport of goods.) Road works B Highway maintenance activities which may potentially affect traffic operations (CEN/TC 278/WG 8) Road plan M See: Route plan Route plan M The path to be taken to get from a starting point to a point of destination or to supplement a trip plan. Shipment M A separately identifiable collection of one or more goods items (available to be) transported together from a consignor to a consignee. (Often synonymous with Consignment.) Shipper M See: Consignor. Shipping instructions / Consignment instructions M Instructions from the seller/consignor or the buyer/consignee to a freight forwarder, carrier or his agent, or other provider of a service, enabling the movement of goods and associated activities. The following functions can be covered: - Movement and handling of goods (shipping, forwarding, stowage) - Customs formalities - Distribution of documents - Allocation of documents (freight and charges for the connected operations) - Special instructions (insurance, dangerous goods, goods release, additional documents required). (ELA) Status M Condition of object, person or process at one point in time. Status event M An event that affected the object, person or process so it arrived at its current status. Status reason M An additional piece of information on status event, explaining why the current status was arrived at. Terms of delivery B (General) All the conditions agreed upon between a supplier and a customer with regard to the delivery of goods and/or services. (ELA) Time of delivery M See Delivery time/date Time of departure M Time of actual departure from a stated location. Tour M The totality of trips to be made by a vehicle in one assignment, normally ending at the point of departure Tour plan M A list of trips to be made in a stated (planned) period of time. It states the visits to be made for loading/ unloading and may include route plan. Tracing F Activity, at request, of finding and reconstructing the transport history of a given consignment, vehicle, equipment, package, cargo. Tracking F Activity of systematically monitoring and recording the present location and status of a given consignment, vehicle, equipment, package, cargo. Transport centre B The premises and the facilities, related to freight transport services, e.g. facilities for transhipment, serving a number of transport companies. A transport centre is often owned and operated by several of the companies being served. Transport combination M A complete unit for the provision of transport services, i.e. Means of transport, Equipment and Driver. Transport document M A document needed for procedures related to the transportation (movement) of goods. (ELA) Transport instructions M See Shipping instruction Deliverable 5.1 Page A1.5

52 Term Definition Transport invoice M See Freight invoice. Transport order M A Shipping (Consignment) instruction or the task definition given by a dispatcher to a driver. Transport service provider B A generic term for an actor in transport links of the logistic chain, e.g. carrier, forwarder, agent. Trip M A planned execution of one or more transport orders, from (a visit at) a loading location to (a visit at) an unloading location or to another loading location. Tyre status M A value, indicating the remaining expected life of the set of tyres of the vehicle. UTI B See Intermodal Transport Unit Vehicle and cargo management F A set of activities related to the management of individual vehicles and their cargo. Vehicle area network T Communication system within a vehicle allowing data transfer, acquisition and storage, between various devices. Vehicle identity M Unique designation for a vehicle, e.g. licence plate number, chassis number, internal fleet number. Vehicle management F Management of an individual vehicle in a fleet, considered as a production tool to be combined in fleet management: - maintenance - availability - status - costs Vehicle monitoring F Beyond the contribution to fleet monitoring, it means closer consideration of the aptitude to operate, through diagnosis and predictions relating to driver and vehicle organs Vehicle operation F All activities related to the vehicle journey, such as vehicle, driver and cargo/passenger status monitoring and recording, actual route selection, reception of changed orders and payment of fees Vehicle operation evaluation F Reporting on vehicle cost and performance, driver hours, disturbances and deviations, and the analysis of these reports Vehicle position M The actual position of the vehicle, at the time stated, in co-ordinates (latitude and longitude), in relation to a reference location, or by stating the formal address (stationary vehicle). Vehicle preparation F Physical preparation of the vehicle, trip preparation including the collection of weather and traffic information; checking cargo, storage, equipment and documents Vehicle speed - actual - recent average M The speed of the vehicle as indicated by speedometer or tachograph (in km/h) - momentary value - average over last ten minutes Visit M The stop of a vehicle between trips for loading or unloading cargo (or documents). Waiting time M Difference between time of arrival and time of loading/unloading, respectively, difference between time of loading/unloading and time of departure. Deliverable 5.1 Page A1.6

53 Annex A2 Framework Deliverable 5.1 Page A2.1

54 A2 The Framework A2.1 General This framework was defined and accepted at the workshop in Roosendaal on March 3 rd, The information is based on a draft proposal from the TC278 group within CEN. The standard is not yet accepted and therefore we feel free to adapt it to the current situations. As a framework it is not statically defined, and may be changed during the project. The purpose of the framework is to have a common model to discuss upon within the project. 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. A2.2 Contents In order to design a systems architecture it is necessary to use a common set of descriptors which represent the basic building blocks. This means that all systems architecture structures are being modelled using the same pre-defined blocks, representing all possible parties, functions and information flows in the model. This is consistent with the earlier described functional modelling. It is important to recognise that the model portrays functions and information flows, and not the physical flow of the goods. The basic components that will be used in the data models are shown in figure 2.1. Figure A2.1 Basic building block components Px Party X Py Party Y Pz PartyZ Fa Function A IF.α IF.δ Fb Function B IF.µ Fc Function C As part of it is necessary to define the building block terminology by using either existing - terms, modifying terms or creating new terms. Having defined the terminology, the different blocks will be used to model case specific (Track A) or generic structures (Track B) in road freight transport. The blocks necessary to build the models are: P - Parties There are usually several parties (actors) involved in the movement of goods, and therefore we need to carefully define who is who in the model. They are annotated P i, and are, for example: P.1 Consignor P.2 Forwarder P.3 Carrier and so on Deliverable 5.1 Page A2.2

55 Since a single party can be referred to in a number of ways (i.e. customer, shipper, sender, consignor for the same party), there is a very real risk of misunderstanding whenever discussing goods movements. This potential confusion is reduced when using common definitions in the models, and is further clarified when used in conjunction with particular transport related functions. As a result more emphasis is placed on the functions than the parties in the data model. F - Functions In order to integrate management systems one must focus on functions rather than parties. In the investigation steps however, it is the functions carried out in the model, and the relations and interfaces between them, that are of importance. A lot of work is therefore put into this in the initial stages of the project and the list of functions provided by the TC278/WG2 is expanded and refined by the group. F.1 Transport Order Issuing F.2 Shipment Progress Control F.3 Order Planning and Execution and so on IF Information Flows Information flows are an integral part of any function and it is important that they are mapped in association with the functions they serve. Through this exercise it is possible to establish the relationships between information flows and functions, as well as obtain a more complete picture of the system. From this picture it is possible to identify which interfaces are required in order to integrate or uncouple the various system components. IF.1 Transport Opportunity Presentation IF.2 Transport Booking/Transport Instruction IF.3 Transport Booking Confirmation/Instruction Confirmation and so on A2.3 The Complete Model By organising the different building blocks so that the various parties and functions are linked by way of the information flows, it is possible to illustrate a system as a model. Within the model each block is defined providing a means of understanding the system being described. Even though the model is fairly complex, it is relatively easy to see how the parties, functions and information flows relate to one another, simplifying the task of identifying where most can be gained from integration. The project aims to develop this model more thoroughly over the coming months. It has already begun this work by extending the model such that it considers suppliers to the freight transport industry (i.e. fuel companies, tyre fitters etc.). In starting this process new parties have been defined along with their accompanying functions and information flows. Deliverable 5.1 Page A2.3

56 A2.3.1 Parties The parties described in the framework are shown in table A2.1. Table A2.1: Parties in the framework CodeName P.1Consignor P.2Forwarder P.3Carrier / Fleet manager P.4Driver P.5Traffic Manager P.6Transport Center Operator P.7Consignee P.8Vehicle P.9Other Mode of Transport Operator P.10Authorities P.11Support Services Supplier A2.3.2 Functions The functions described in the framework are the shown in table A2.2. Table A2.2: Functions in the framework Func Code Assoc. Party Code Name F.1P.1Transport Order Issuing F.2P.1Shipment Arrival Control cf F.12 F.3P.2Order Planning and Execution F.4P.2Order Control F.5P.3Operational Planning (Dispatching) F.6P.3Trip / Route Planning F.7P.3Fleet / Vehicle Monitoring F.8P.4Trip / Route Execution F.9P.4Trip / Route Control F.10P.5Traffic Management F.11P.6Transshipment / Storage Process F.12P.7Shipment Progress Control (cf F.2) F.13P.9Combined Transport Process F.14P.8Remote Vehicle & Cargo Reporting F.15P.8Vehicle & Cargo Monitoring F.16P.2Invoicing F.17P.3Cost & Performance Analysis F.18P.11Consumables Cost Issuing A2.3.3 Information flows The information flows in the framework are shown in table A2.3, on the next page. Deliverable 5.1 Page A2.4

57 Table A2.3: Information flows in the framework CodeFrom To Name Func. Func. IF.1F.1F.3Transport Opportunity Presentation IF.2F.1F.3Transport Booking / Transport Instruction IF.3F.3F.1Quotations Information / Instruction Confirmation IF.4F.2F.4Cargo / Consignment Status Request IF.5F.4F.2Cargo / Consignment Status Report IF.6F.3F.5Pick-Up Delivery List IF.7F.1F.11Shipping data IF.8F.11F.1Consignment confirmation IF.9F.5F.4Order Progress Report IF.10F.4F.5Dispatching Status Request IF IF.12F.6F.10Traffic Information Request IF.13F.7F.8Fleet / Vehicle Position Request IF.14F.3F.5On-line Pick-Up Information IF.15F.5F.3Pick-Up Order Confirmation / Refusal IF.16F.8F.6Trip / Route Status Information IF.17F.8F.6Current Traffic Information IF.18F.8F.7Vehicle Position Report IF.19F.6F.9Trip Alteration IF.20F.6F.9Daily Delivery Plan IF.21F.11F.4Status Request IF.22F.9F.6Trip / Route Change Confirmation / Refusal IF.23F.4F.11Status Reporting IF.24F.3F.11Request IF.25F.11F.3Acceptance IF.26F.12F.4Consignment Status Request cf IF.4 IF.27F.10F.6Traffic Situation Report IF.28F.4F.12Consignment / Reusable Equipment Status Report IF.29F.3F.13Booking instruction, Status Request IF.30F.13F.3Confirmation or refusal IF.31F.14F.7Vehicle / Cargo Parameter Message IF:32F.15F.8Vehicle / Cargo Parameter Display(s) IF.33F.9F.15Vehicle / Cargo Parameter Inputs IF.34F.15F.9Vehicle Current Route / Location Parameters IF.35F.9F.17Trip expenses / Km / Time Report IF.36F.9F.16Delivery Proof (Documents) IF.37F.17F.6Cost Report IF.38F.16F.1Invoice IF.39F.18F.17Cost data IF.40F.17F.9Vehicle running cost data IF.41F.6F.17Statistical data IF.42F.5F.6Order-vehicle-driver list IF.43F.6F.5Vehicle status & position (cf. IF.18) IF.44F.9F.8Trip and route plan IF.45F.7F.6Trip/route deviation info IF.46F.7F.6Statistical data (cf. IF.41) IF.47F.6F.7Trip/route plan per vehicle/driver (cf. IF.19, IF.20) IF.48F.7F.14Vehicle/Cargo Status Request IF.49F.12F.11Shipping data IF.50F.11F.12Consignment confirmation IF.51F.1F.2Issue Order Status Information Concerning Control IF.52F.2F.1Consignor Order Status Information IF.53F.11F.2Inventory Status IF.54F.11F.12Inventory Status IF.55F.3F.16Forwarding Orders Information IF.56F.3F.4Forwarding Orders Information IF.57F.4F.16 Forwarding order status information Deliverable 5.1 Page A2.5

58 A2.4 Context The framework describes the procedures in the transport business in a generic way. Only parts that are deemed to be relevant to the project are included. Figure A2.1 shows the context diagram with the relations to the external environment. Figure A2.1: Context diagram of the framework. The Framework External environment P.9 Other Transport Mode Operator P.6 Transport Center Operator Authorities P.1 Consignor P.2 Forwarder P.7 Consignee P.5 Traffic Manager P.3 Carrier Fleet Manager P.8 Vehicle P.4 Driver Financial Services P.11 Support Services Supplier The party authorities includes functions such as traffic control, technical inspection, social inspection and customs clearance. These elements are naturally of interest to the transport business, but have a minor importance to the daily operation. Future authority control including e.g. electronic tachometer information delivery, will make this party of interest also for the framework. Financial issues are crucial for the transport business. These issues are however not unique for the transport business, and therefore the problems will be treated as in other business areas. A2.5 Relations In the generic framework the functions are connected by information flows as shown in figure A2.2, on the next page. The functions are located to certain parties. Deliverable 5.1 Page A2.6

59 Figure 3.2: The revised framework P.9 Other Transport Mode Operator P.6 Transport Center Operator F. 13 Combined Transport Process IF.24 F. 11 Transshipment / Storage Process IF.7 IF.8 IF.53 IF.30 IF.29 IF.25 IF.49 IF.50, IF.54 P.1 Consignor F. 1 Transport Order Issuing IF.51 IF.52 IF.1, IF.2 IF.3 IF.38 P.2 Forwarder F. 3 Order Planning & Execution IF.55 F. 16 Invoicing IF.56 IF.21 IF.23 P.7 Consignee F. 12 Shipment progress control IF.28 IF.26 F. 2 Shipment progress control IF.4 IF.5 IF.57 F. 4 Order Control P.5 Traffic Manager F.10 Traffic Management IF.45, IF.46 P.3 Carrier / Fleet manager IF.12 IF.27 IF.6, IF.14 F.6 Trip / Route Planning IF.15 IF.42 IF.10 IF.9 F. 5 Operational Planning (Dispatching) IF.43 IF.41 IF.19, IF.20 IF.22 IF.36 F.7 Fleet / Vehicle Monitoring IF.13 IF.47 IF.37 F. 17 Cost & Performance Analysis IF.48 IF.31 IF.18 IF.40 P.8 Vehicle P.4 Driver IF.35 IF.16,IF.17 F.9 Trip / Route Control F.14 Remote Vehicle & Cargo Reporting F.15 Vehicle & Cargo Monitoring IF.32 F.8 Trip / Route Execution IF.44 IF.33 IF.34 P11. Support Services Supplier IF.39 F.18 Consumables Cost Issuing Deliverable 5.1 Page A2.7

60 A2.6 Functions and sub-functions In the generic analysis, each function in the framework has been deeply analysed and split into several sub-functions. Each sub-function has be defined and the associated information flows have been identified. This form the generic functional specification, and will be an important output to workpackage 6, where a conceptual information model is to be built. The functions and the sub-functions are found in table A2.4. Table A2.4: The functions and the sub-functions in the framework. Assoc.FunctionSub- Name PartyCodefunction Code Code P.1F.1 Transport Order Issuing F.1.1 Order initialisation F.1.2 Order Issuing F.1.3 Order payment P.1F.2 Shipment Arrival Control cf F.12 F.2.1 Shipment Status Control F.2.2 Payment Advice P.2F.3 Order Planning and Execution F.3.1 Order Evaluation F.3.2 Order Acceptance & Registration F.3.3 Order Dispatching TCO F.3.4 Order Dispatching Carrier F.3.5 Order Dispatching TMO P.2F.4 Order Control F.4.1 Order Tracking F.4.2 Order Information F.4.3 Re-usable Equipment P.3F.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 P.3F.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.3F.7 Fleet / Vehicle Monitoring F.7.1 Position & Status Processing P.4F.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.4F.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 Deliverable 5.1 Page A2.8

61 Table A2.4 - continued P.5F.10 Traffic Management F.10.1 Traffic Information Processing F.10.2 Request Management P.6F.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.7F.12 Shipment Progress Control (cf F.2) F.12.1 Order Shipping / Consignment F.12.2 Order (Un)Loading P.9F.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.8F.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.8F.15 Vehicle & Cargo Monitoring F.15.1 Vehicle & Cargo Monitoring Control P.2F.16 Invoicing F.16.1 POD checking F.16.2 Invoicing F.16.3 Distribute Invoices P.3F.17 Cost & Performance Analysis F.17.1 Cost & Performance Processing P.11F.18 Consumables Cost Issuing F.18.1 Consumables Cost Issuing A2.7 Data dictionary Parties P.1 - Consignor The consignor is the party that issues the instruction to transport a shipment. The consignor can be subdivided into the issuing function and the paying function. The freight payer can be the same as the consignor but the payer function can also coincide with the consignee. The consignor can be an agent. The agent represents the customer and issues the order with the forwarding company. The agent is also a possible party to invoice to. Forwarders and agents often work with AMETA agreements. Deliverable 5.1 Page A2.9

62 P.2 Forwarder P.6 Transport Center Operator P.1 Consignor Function Sub- Name Code function Code F.1 Transport Order Issuing F.1.1 Order Initiation F.1.2 Order Issuing F.1.3 Order payment F.2 Shipment Arrival Control cf F.12 F.2.1 Shipment Status Control F.2.2 Payment Advice P.2 - Forwarder The forwarder is the party that does the account management to the consignor. In many cases the forwarder has signed a contract with a transport obligation. For these clients the forwarder searches a carrier that can transport the shipment. P.9 Other Transport Mode Operator P. 7 Consignee P.6 Transport Center Operator P.4 Driver P.2 Forwarder P.3 Carrier/ Fleet manager P.1 Consignor Deliverable 5.1 Page A2.10

63 Function Sub- Name Code function Code F.3 Order Planning and Execution F.3.1 Order Evaluation F.3.2 Order Acceptance & Registration F.3.3 Order Dispatching TCO F.3.4 Order Dispatching Carrier F.3.5 Order Dispatching TMO F.4 Order Control F.4.1 Order Tracking F.4.2 Order Information F.4.3 Re-usable Equipment F.16 Invoicing F.16.1 POD checking F.16.2 Invoicing F.16.3 Distribute Invoices P.3 - Carrier / Fleet Manager The Carrier / Fleet Manager performs two tasks which are in the following named as Operational Planning (Dispatching) (F.5) and Route Planning (F.6). The Operational Planning (Dispatching) comprises the load optimisation / definition of pick-up and delivery routes, i.e. the grouping of orders to trips, and in a second step the assignment of trips to drivers and to vehicles. The Route Planning contains the calculation of a transport route for each trip and the revolving process of transport execution control. For the Route Calculation (F.6.1), traffic information and former transport cost and performance values are considered. In this respect, the functions Fleet / Vehicle Monitoring (F.7) and Cost & Performance Analysis (F.17) are supporting functions. P.2 Forwarder P.4 Driver P.5 Traffic Manger P.8 Vehicle P.3 Carrier / Fleet Manager P.11 Support Services Supplier Deliverable 5.1 Page A2.11

64 Function Sub- Name Code function Code 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 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 F.7 Fleet / Vehicle Monitoring F.7.1 Position & Status Processing F.17 Cost & Performance Analysis F.17.1 Cost & Performance Processing P.4 - Driver The driver refers to the human driver, driving the vehicle. It is a very important party since he do the actual transport. In the framework a clear distinction has been made between the driver (P.4) and the vehicle (P.8). Naturally there is a lot of interconnections between these two parties and by dividing it into two separate parties the communication interface between them is emphasised. P.3 Carrier / Fleet Manager P.8 Vehicle P.2 Forwarder P.4 Driver Function Sub- Name Code function Code 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 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 Deliverable 5.1 Page A2.12

65 P5 - Traffic Manager The main task of the Traffic Manager can be described as the identification and provision of relevant traffic information for the Carrier / Fleet Manager. To perform this task the Traffic Manager has to receive from different sources, to store and to process (identification, selection) traffic information relevant for the user of this information. Beneath the provision of dynamic traffic information, weather conditions and forecast, road construction work plans or other relevant information services might be considered. The Traffic Manager provides his information on request or continuously to the Carrier / Fleet Manager who makes use of it within the function Route Planning (concrete calculation of a transport route) and forwards the relevant information to the driver. P.3 Carrier / Fleet Manager P.5 Traffic Manager Function Sub- Name Code function Code F.10 Traffic Management F.10.1 Traffic Information Processing F.10.2 Traffic Information Request Management P.6 - Transport Centre Operator Transport Centre Operator is a broad term that represents a number of different functions that may be carried out together at one site or performed in part at any site. Essentially two main functions take place: storage and distribution, and transhipment. The first functions are concerned with warehouse practices which involve the holding of stock at a location before for final distribution. Transhipment deals with the transfer of freight from one vehicle to another (any mix of mode) or into/out of storage. The types of transport centre vary, but they range from one company on a single user site to a number of different companies on a mulit-user site. Within the context of it is the storage and distribution function that is relevant. P.1 Consignor P.2 Forwarder P.7 Consignee P.6 Transport Center Operator Deliverable 5.1 Page A2.13

66 Function Sub- Name Code function Code 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 - Shipper/Consignee The shipper is the party that controls the pick-up of the shipment. The consignee is the party that controls the delivery of the shipment. The loading address is the address where the goods are to be picked up. The unloading address is where the goods are to be delivered. Consignor and shipper or consignor and consignee can coincide. Also shipper and loading address and consignee and unloading address can coincide. P.6 Transport Center Operator P.2 Forwarder P.7 Consignee Assoc. Function Sub- Name Party Code function Code Code P.7 F.12 Shipment Progress Control (cf F.2) F.12.1 Order Shipping / Consignment F.12.2 Order (Un)Loading P.8 - Vehicle The vehicle party refers to the actual truck and the on-board technology systems. These systems are e.g. on-board computers and software, positioning devices, cargo probes/sensors, engine/vehicle sensors etc. Definition and description of such technology systems may be found in the report IR The party vehicle is separated from the actual driver (P.4). The vehicle is the party that monitors the cargo/vehicle sensors and the GPS sensor. This party also sends automatic reports to P.3 (carrier/fleet manager) and display sensors information to P.4 (driver). P.3 send the settings for automatic reporting and P.4 introduce the sensors reference values and route details to be monitored by the vehicle. 14 TR4018 Project, Main existing freight telematics systems and compatibility, Internal Report IR4.1, European Commission, May 1998 Deliverable 5.1 Page A2.14

67 P.3 Carrier / Fleet manager P.4 Driver P.8 Vehicle Function Sub- Name Code function Code 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 F.15 Vehicle & Cargo Monitoring F.15.1 Vehicle & Cargo Monitoring Control P.9 - Other Transport Mode Operator The P.9 block of the generic framework treats the Other Transport Mode operators. Other Transport Mode operators are non road based operators, e.g. mulitomodal rail-road operators, ferries etc. This group of operators are not represented in any of the demonstrators in the project, but should of course be included in the generic model as they are an important part of the network. Even though a majority of transports are truck bound the transports conducted by the Other Transport Mode operators are considerable, and beeing a focused area thay are for several reasons destined to keep or even increase their importance in the future. If looked upon separately the Other Transport Mode operators in themselves can be fitted into the generic framework s other functions. The operator might act as one or several of the other functions, e.g. P.2, P.3 or P.8. Therefore the P.9 block in this study is treated from the perspective of the forwarder (P.2) using his services, focusing on the relations between the forwarder and the Other Transport Mode operator. P.2 Forwarder P.9 Other Transport Mode Operator Deliverable 5.1 Page A2.15

68 Function Sub- Name Code function Code 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.10 - Authorities The authorities actor is not considered relevant to include in the framework. Therefore further analyses has been excluded. P.11 - Support Services Provider The parties which form this group are providers of services that support road transport operations. The group includes parties such as fuel (card) companies, tyre suppliers and fitters, vehicle servicing and maintenance, tank cleaning, trailer servicing and maintenance, container servicing and maintenance and any other businesses that are used as a direct result of operating vehicles (and trailers). One party [fuel (card) companies] is involved in the project and this only relates to the provision of information about the price of fuel. Therefore, general functions associated to this group have not been explored. P.3 Carrier / Fleet manager P.11 Support Service Supplier Assoc. Function Sub- Name Party Code function Code Code P.11 F.18 Consumables Cost Issuing F.18.1 Consumables Cost Issuing Deliverable 5.1 Page A2.16

69 Functions Function F.1-Transport Order Issuing Data Flow Diagram P.1 Consignor F. 1 - Transport Order Issuing IF.8 P.6 Transport Center Operator IF.7 IntIF. 1.1 F. 1.1 Order Initiation IF. 1 Quotations request IF. 3.1 IntIF. 1.2 F. 1.2 Order Issuing IF. 2 IntIF. 1.3 Issued Orders by Consignor IF. 3.2 P. 2 Forwarder IntIF. 1.5 IntIF. 1.4 Order Payments by Consignor IF. 51 F. 1.3 Order Payment IF. 38 F. 2 Shipment progress control IF. 52 Sub-functions F.1.1 Order initialisation description Initialisation of the order by the consignor input IF.3.1 Transpot booking confirmation (refusal) / instruction comfirmation output IntIF.1.1 IF.1 Storage Consignor Quotations Transport opportunity presentation F.1.2 description input output Order Issuing the final order to the forwarder to ship the goods IF.3.2 confirmation of the transport instruction IF.8 Consignment Confirmation IntIF.1.2 information from the Quotations database, to support the order issuing process IF.2 transport instruction to the forwarder IF.7 Shipping Data Deliverable 5.1 Page A2.17

70 F.1.3 Order Payment description this function represents the payment process of the consignment as handled by the forwarder input IF.38 the invoice IF.52 IntIF.1.4 order status information; the trigger to pay the invoice Issue Orders Status Information concerning Payment output IntIF.1.5 the approved payment is stored or send by EDI; this IF can represent the link to the accounting derpartment Internal information flows IntIF. 1.1 Storage Consignor Quotations from F.1.1 Order Initiation to D.S. Quotations requests information all quotations supplied by the several forwarders are stored for i.e. historical use, comparison (..) IntIF. 1.2 Quotations Information (bases for IF.2) from D.S. Quotations requests to F.1.2 Order Issuing information quotations information stored during the initiation process; these quotations are used as input for choosing the right forwarder IntIF. 1.3 Issue Orders by Consignor from F.1.2 Order Issuing to D.S. Issued Orders by Consignor information relevant order information of orders issued and registered by the consignor i.e. order number, goods information, terms of delivery (..) IntIF. 1.4 Issue Orders Status Information concerning Payment from D.S. Issued Orders by Consignor to F.1.3 Order payment information relevant order information concerning the invoices i.e. ordernumber, goods information, terms of delivery, order reference (..) IntIF.1.5 Storage Payment Advice from F.1.3 Order payment to D.S. Order Payment by Consignor information electronic storage of all invoice data Deliverable 5.1 Page A2.18

71 Function F.2 Shipment Progress Control Data Flow Diagram P.1 - Consignor F.1 Transport Order Issuing F.2 - Shipment Progress Control IF. 51 IF. 52 IF. 4 IntIF. 2.1 F.2.1 Shipment Status Control IF. 5 P.2 Forwarder / Shipper Consignor Status IF.53 IntIF. 2.2 F.2.2 Payment Advice P.6 Transport Centre Operator Sub-functions F.2.1 Shipment Status Control description the consignor of the order and/or the freightpayer are informed about the status of the order, before, during and after the execution input IF.51 order information IF.53 cargo and consignment status report from the forwarder output IntIF.2.1 strorage of the status information in the status datastore IF.4 cargo and consignment status request F.2.2 Payment Advice description the advice of the operational sub-function to the function responsible for the payment of the order input IntIF.2.2 consignor order status information concerning the payment of the order output IF.52 payment advice to the order payment function Internal information flows IntlF.2.1 Storage Consignor Order Status Information from F.2.1 Shipment Status Control to D.S. Consignor Status information statuscodes and status descriptions concerning the consignor IntlF.2.2 Consignor Order Status Information concerning Payment from D.S. Consignor Status to F.2.2 Payment Advice information relevant consignment statuscodes which influende the invoice process Deliverable 5.1 Page A2.19

72 Function F.3 - Order Planning and Execution Flow Diagram P. 2 - Forwarder / Shipper F. 3 Order Planning & Execution IF. 1 IF. 3.1 F. 3.1 Order Evaluation IntIF. 3.1 IntIF. 3.2 IF.55.1 P.1 Consignor Forwarding Quotations F. 16 Invoicing IF. 3.2 IF. 2 F. 3.2 Order Acceptance & Registration IntIF. 3.3 IF.55.2 IntIF. 3.5 IntIF. 3.4 Forwarding Orders IF. 56 IntIF.3.10 F. 4 Order Control IntIF. 3.6 IntIF. 3.9 IntIF. 3.7 IntIF. 3.8 F. 3.3 Order Dispatching TCO F. 3.4 Order Dispatching Carrier F. 3.5 Order Dispatching TMO IF. 14 IF. 24 IF. 25 IF. 6 IF. 15 IF.29 IF. 30 P.6 TCO P. 3 Carrier P. 9 Other TMO Sub-functions F.3.1 Order Evaluation description this function represents the negotiation of the forwarding conditions input IF.1 transport opportunity presentation; request for quotation information IntIF.3.2 quotations information output IF.3.1 confirmation concerning the quotations IntIF3.1 the internal storage of the quotation information F.3.2 Order Acceptance & Registration description the consignor and forwarder agreed upon the conditions and the consignor accepts and registrates the order input IF.2 transport instruction from the consignor IntIF.3.3 quotations information; this information is used to support the acceptance of a financial view output IF.3.2 confirmation of the transport instruction IntIF.3.4 the order registrated is stored in the order database F.3.3 Order Dispatching TCO description the forwarder groups his forwarding orders in a logical sequence and searches for the best transport opportunity; in this case the Transport Centre Operator (TCO) input IF.25 acceptance of the order booked with TCO; refusal IntIF.3.5 forwarding order information, used to inform the TCO output IF.24 pick-up delivery list IntIF.3.6 request for forwarding order information Deliverable 5.1 Page A2.20

73 F.3.4 Order Dispatching Carrier description the forwarder groups his forwarding orders in a logical sequence and searches for the best transport opportunity; in this case the Carrier Centre Operator (TCO) input IF.15 pick-up confirmation; refusal IntIF.3.7 forwarding order information, used to inform the carrier output IF.6 pick-up delivery list IF.14 order information and transport instruction IntIF.3.8 request for forwarding order information F.3.5 Order Dispatching TMO description the forwarder groups his forwarding orders in a logical sequence and searches for the best transport opportunity; in this case the Other Transport Mode Operator (TMO) input IF.30 acceptance of the order booked with TMO; refusal IntIF.3.9 forwarding order information, used to inform the TMO output IF.29 pick-up delivery list IntIF.3.10 request for forwarding order information Internal information flows IntIF.3.1 Storage Forwarder Quotations from F.3.1 Order Evaluation to D.S. Forwarding Quotations information quotations information and prospect data IntIF.3.2 Quotations Information (bases for IF.3.1) from D.S. Forwarding Quotations to F.3.1 Order Evaluation information quotation information needed for aquisition and other commercial activities to the customers IntIF.3.3 Quotations Information (bases for F.3.2) from D.S. Forwarding Quotations to F.3.2 Order Acceptance & Registration information quotation information needed to decide if the order can be accepted IntIF.3.4 Storage Forwarding Orders from F.3.2 Order Acceptance & Registration to D.S. Forwarding Orders information the accepted orders are stored in a consignment database; this database serves all transport modalities i.e. seatransport, haulage, forwarding, transport by train and air (..) IntIF.3.5 Forwarding Orders Information for TCO (bases for IF.24) from D.S. Forwarding Orders to F.3.3 Order Dispatching TCO information this informationflow should be rich enough to supply the TCO with the relevant information for transporting the order IntIF.3.6 Storage Acceptance or refusal from F.3.3 Order Dispatching TCO to D.S. Forwarding Orders information confirmation of the TCO about shipping or not shipping the order IntIF.3.7 Forwarding Orders Information for Carrier (bases for IF. 24) from D.S. Forwarding Orders to F.3.4 Order Dispatching Carrier information this informationflow should be rich enough to supply the Carrier with the relevant information for transporting the order IntIF.3.8 Storage Pick-up Confirmation or Refusal from F.3.4 Order Dispatching Carrier to D.S. Forwarding Orders information confirmation of the Carrier about shipping or not shipping the order Deliverable 5.1 Page A2.21

74 IntIF.3.9 Forwarding Orders for TMO (bases for IF.6 & 14) from Forwarding Orders to F.3.5 Order Dispatching TMO information this informationflow should be rich enough to supply the TMO with the relevant information for transporting the order IntIF.3.10 Storage Confirmation from F.3.5 Order Dispatching TMO to D.S. Forwarding Orders information confirmation of the TMO about shipping or not shipping the order Function F.4 - Order Control Data Flow Diagram P.2 Forwarder F. 3 Order Planning & Execution F.4 - Order Control IF.56 IF.9.1 IntIF.4.1 F. 4.1 Order Tracking IF.10 P.3 Carrier IF.57 Orderstatus F. 16 Invoicing IntIF.4.2 IntIF.4.3 F. 4.2 Order Information IF.5 IF.4 P.1 Consignor Re-usable Equipment IF.21 IF.23 P. 6 Transport Center Operator IntIF.4.4 F. 4.3 Re-usable Equipment IF.9.2 IF.26 IF.28 P.7 Consignee Sub-functions F.4.1 Order Tracking description this function represents the tracking and tracing of the order, based upon the information supplied by the carrier input IF.56 Forwarding order information IF.9.1 Order progress report output IntIF.4.1 IF.10 Update of the status of the order Dispatching status request Deliverable 5.1 Page A2.22

75 F.4.2 Order Information description this function splits up all information to all parties involved input IntIF.4.2 Order status information IntIF.4.3 Re-usable equipment information IF.4 Request for cargo / consignment information from the consignor IF.21 Request for cargo / consignment information from the TCO output IF.5 Cargo / consignment information report IF.23 Status reporting F.4.3 Re-usable Equipment description registration and control of all reusable equipment used, i.e. pallets, crates, boxes (...) input IF.9.2 IF.26 request for re-usable equipment status report Consignment Status Request output IF28 re-usable equipment status report to (in)loading address IntIF.4.4 update re-usable equipment status Internal information flows IntIF.4.1 Update Order Status from F.4.1 Order Tracking to D.S. Orderstatus information order status information supplied by the carrier i.e. loading time, delays, unloading time, arrival (..) IntIF.4.2 Order Status Information from D.S. Orderstatus to F.4.2 Order Information information order status information i.e. loading time, delays, unloading time, arrival (..) IntIF.4.3 Re-usable Equipment Information from D.S. Re-usable Equipment to F.4.2 Order Information information status information about the number and quality and ownership of re-usable equipment i.e. crates, pallets, boxes, drums (..) to inform all parties who could possible be the owner of the equipment. IntIF.4.4 Update Re-usable Equipment Information from F.4.3 Re-usable Equipment to D.S. Re-usable Equipment information status information about the number and quality and ownership of re-usable equipment i.e. crates, pallets, boxes, drums (..) Function F.5 - Operational Planning (Dispatching) This function is the starting point of the planning activities on the carries level as soon as the orders and the resources are known. The Operational Planning results in a trip/driver /vehicle list (IF.42) which is delivered to F.6 for the (dynamic) route calculation and control. Deliverable 5.1 Page A2.23

76 Data Flow Diagram P.2 Forwarder IF.14 IF.6 IF.15 P.3 Carrrier / Fleet Manager F.5 - Operational Planning (Dispatching) IntIF.5.8 F.5.1 Order Entry & Check IF.10 IF.9 IntIF.5.4 Transport orders IntIF.5.1 Road & distance network Basic data IntIF.5.5 IntIF.5.9 IntIF.5.10 F.5.2 Trip Planning IntIF.5.2 F.5.4 Order Statues Control IntIF.5.6 Trips Driver data Vehicle data IntIF.5.7 IntIF.5.3 IntIF.5.12 IntIF.5.11 F.5.3 Vehicle / Driver Allocation IF.43.1 IF.42 IF.43.2 F.6 Route Planning Sub-functions F.5.1 Description Input Output Order Entry & Check Reception, control and acceptance or refusal of transport order IntIF.5.1 Order refusal information IF.6 Pick-up delivery list IF.14 On-line pick-up information IF.15 IntIF.5.4 IntIF.5.8 Pick-up order refusal Transport order Basic data Deliverable 5.1 Page A2.24

77 F.5.2 Description Input Output Trip Planning Grouping of orders to trips for load optimisation and depot based pick-up and delivery IntIF.5.2 Not executed transport orders IntIF.5.5 Transport Orders IntIF.5.9 Road & distance network IntIF.5.10 Basic data IntIF.5.1 IntIF.5.6 Order refusal information Trips F.5.3 Description Input Output Vehicle/Driver allocation Assignment of drivers and vehicles to trips IntIF.5.7 Trips IntIF.5.11 Driver data IntIF.5.12 Vehicle data IF.43.1 Vehicle/Driver status IF.42 IntIF.5.3 Trip/Driver/Vehicle List Planning status F.5.4 Description Input Output Order Status Control Control of order execution, provision of order status to P.2 and forwarding of transport orders not executed IF.10 Dispatching Status Request IF.43.2 Trip Status IntIF.5.3 Planning status IF.9 IntIF.5.2 Order Progress Report Not executed transport orders Internal information flows IntIF.5.1 Order refusal information from F Trip Planning to F Order Entry & Check information List of refused orders IntIF.5.2 from to information IntIF.5.3 from to information IntIF.5.4 from to information IntIF.5.5 from to information IntIF.5.6 from to information Not executed transport orders F Order status control F Trip Planning List of not executed transport orders Planning status F Vehicle / Driver Allocation F Order Status Control Allocated vehicles / drivers Transport Order F Order Entry & Check Transport Orders database Transport order to be executed Transport Orders Transport Orders database F Trip Planning Transport orders to be executed Trips F Trip Planning Trips data base Planned trips Deliverable 5.1 Page A2.25

78 IntIF.5.7 from to information IntIF.5.8 from to information IntIF.5.9 from to information IntIF.5.10 from to information IntIF.5.11 from to information IntIF.5.12 from to information Trips Trips data base F Vehicle / Driver Allocation Planned trips Basic data F Order Entry & Check Basic database Basic data for trip planning Road & distance network Road & distance network database F Trip Planning Data about the road and distance network Basic data Basic database F Trip Planning Basic data for trip planning Driver data Driver database F Vehicle / Driver Allocation Information about the drivers Vehicle data Vehicle database F Vehicle / Driver Allocation Information about the vehicles Function F6 - Route Planning This function comprises the dynamic transport route planning in time and space considering traffic information and cost & performance parameters as well as the circle of transport execution control. Deliverable 5.1 Page A2.26

79 Data Flow Diagram P.3 Carrier / Fleet Manager F.5 Operational Planning (Dispatching) F.6 Route Planning Road & distance network P.5 Traffic Manager IF.27 IntIF.6.4 IF.42 IF.43 IF.12 F.6.2 Traffic Information Process Management IntIF.6.1 F.6.1 Route Calculation IF.17 F.6.3 Transport Statistics IntIF.6.2 IntIF.6.3 IF.46 IF.37 F.6.4 Driver Inforamtion F.6.5 Execution Control IF.41 IF.47 IF.20 F.7 Fleet / Vehicle Monitoring IF.22 F.17 Cost & Performance Analysis IF.45 IF.16 IF.19 P.4 Driver Sub-functions F.6.1 Description Input Route Calculation Exact transport route calculation / re-calculation (time and space) on the basis of the trip/driver/vehicle list considering traffic information and cost and performance parameters IF.42 Trip/driver/vehicle list IF.37 Cost report (rec. Freight price) IntIF.6.1 Traffic Information IntIF.6.3 Not executed trip (/driver/vehicle list) IntIF.6.4 Road & Distamce data Output IntIF.6.2 Trip/Route plan F.6.2 Description Input Output Traffic Information Process Management Traffic information request, reception and management for relevant transport routes on the carriers level IntIF.6.2 Trip/Route plan IF.27 Traffic situation report IF.17 Current traffic information IF.12 IntIF.6.1 Traffic information request Traffic information Deliverable 5.1 Page A2.27

80 F.6.3 Transport Statistics Description F.6 internal on-line storage of transport data and provision to F.17 Input IntIF.6.2 IF.46 Trip/Route plan Statistical data Output IF.41 Statistical data F.6.4 Driver Information Description Generation and forwarding of appropriate transport information to P.4 Driver Input IntIF.6.2 Trip/Route plan Output IF.19 IF.20 IF.47 Trip alteration Daily delivery plan Trip/Route plan per vehicle/driver F.6.5 Description Input Output Execution Control Comparison of trip/route plan with driver information or monitoring deviation IntIF.6.2 Trip/Route plan IF.16 Trip/Route status information IF.22 Trip/Route change confirmation/refusal IF.45 Trip/Route deviation information IntIF.6.3 IF.43 Not executed trip/route plan Vehicle/driver status (a) and Trip status (b) Internal information flows IntIF.6.1 Traffic Information from F Traffic Information Process Management to F Route Calculation information Route identifier, time, event position, traffic situation IntIF.6.2 Trip/Route plan from F Route Calculation to F.6.4 Driver information / F.6.2 Traffic Information Process Management / F.6.3 Transport Statistics / F.6.5 Execution Control information Trip/vehicle identifier, loading/unloading list, route description (time and space), cargo information IntIF.6.3 from to information Not executed trip/route plan F Execution Control F Route Calculation Trip/route plan, Deviation information, Flag/Explanation IntIF.6.4 from to information Road & Distamce data Road & Distance Network database F Route Calculation Route and distance data Deliverable 5.1 Page A2.28

81 Function F.7 - Fleet / Vehicle Monitoring Controlling the vehicles and cargo by their position and status in relation to time and order assignment according to the detailed trip/route plan. Data Flow Diagram P.3 Carrier / Fleet Manager F.6 Route Planning IF.45 IF.46 IF.47 F.7 Fleet / Vehicle Monitoring F.7.1 Position & Status Processing IntIF.7.1 IntIF.7.2 Trip / Route data base IF.31 IF.48 IF.18 IF.13 P.8 Vehicle P.4 Driver Sub-functions F.7.1 Description Input Output Position & Status Processing Comparison on actual vehicle, driver and cargo status information with calculated trip/route plan; identification of deviation and provision of statistical data IF.18 Vehicle position report IF.31 Vehicle/cargo parameter message IF.47 Trip/route plan per vehicle/driver IntIF.7.2 Trip/route data IF.13 IF.45 IF.46 IF.48 IntIF.7.1 Fleet/vehicle position request Trip/route deviation information Statistical data Vehicle/Cargo Status Request Trip/route data Internal information flows IntIF.7.1 Trip / route data from F Position & Status Processing to Trip / Route data base information Data about the trip and route Deliverable 5.1 Page A2.29

82 IntIF.7.2 from to information Trip / route data Trip / Route data base F Position & Status Processing Data about the trip and route Function F.8 - Trip / Route Execution Data Flow Diagram P.3 Carrier / Fleet Manager P.4 Driver F.9 Trip / Route Control IF.13 IF.44 IF.18 F.8 Trip / Route Execution F.8.1 Get next trip IntIF.8.1 F.8.2 Driving IntIF.8.2 F.8.3 Loading and Unloading P.8 Vehicle IF.32 IntIF.8.3 IntIF.8.4 IntIF.8.5 IntIF.8.6 IF.58 Trip database P.3 Carrier / Fleet Manager IF.17 IF.16 IF.18 IntIF.8.7 IntIF.8.8 IntIF.8.9 F.8.5 Comunication system interface IntIF.8.13 IntIF.8.10 IntIF.8.11 IntIF.8.12 F.8.4 Generate message Sub-functions F8.1 Get next Trip Description: Get next trip from Trip / route plan Input: IF 44 Trip and route plan Output: IntIF.8.1 Next trip F8.2 Driving Description: Driving to the next location Input: IntIF.8.1 Next trip IF.18 Vehicle position IF 32 Vehicle / cargo parameters display Output: IntIF.8.4 Traffic information IntIF.8.5 Trip data (e.g. expenses) IntIF.8.2 Next stop IntIF.8.3 Vehicle location Deliverable 5.1 Page A2.30

83 F8.3 Loading and unloading Description: Loading and unloading cargo Input: IntIF.8.2 Next stop Output: IntIF.8.6 Trip data (delays, acceptance, arrival,...etc.) F8.4 Generate message Description: This function decides when messages has to be sent to P.3 (carrier/fleet manager). This function creates the reports and information messages Input: IntIF.8.9 Trip data information IntIF.8.8 Traffic information IntIF.8.7 Vehicle location IntIF.8.13 Vehicle position request Output: IntIF.8.11 Trip / Tour status information IntIF.8.10 Traffic information IntIF.8.12 Vehicle position report F8.5 Communication system interface Description: Converts data to the specific kind of communication system Input: IntIF.8.11 Trip / Tour status information IntIF.8.10 Current Traffic Information IF 13 Vehicle position request IntIF.8.12 Vehicle position report Output: IF 17 Current Traffic Information IF 16 Trip / Tour status information IntIF.8.13 Vehicle position request IF 18 Vehicle position report Internal information flows IntIF.8.1 Next trip From: F.8.1 Get next trip To: F.8.2 Driving Information: - Information about next trip IntIF.8.2 Next stop From: F.8.2 Driving To: F.8.3 Loading and unloading Information: - Next place to stop for loading and unloading IntIF.8.3 Vehicle location From: F.8.2 Driving To: Trip database Information: - Vehicle current position IntIF.8.4 Current Traffic information From: F.8.2 Driving To: Trip database Information: - Current Traffic Information IntIF.8.5 Trip data From: F.8.2 Driving To: Trip database Information: - Trip data information (e.g. expenses) IntIF.8.6 Trip data From: F.8.3 Loading and unloading To: Tripdata database Information: - Trip data (delays, acceptance, arrival,...etc.) Deliverable 5.1 Page A2.31

84 IntIF.8.7 Vehicle location From: Trip database To: F.8.4 Generate message Information: - Vehicle current position IntIF.8.8 Current Traffic information From: Trip database To: F.8.4 Generate message Information: - Current Traffic Information (e.g. accidents) IntIF.8.9 Trip data information From: Trip database To: F.8.4 Generate message Information: - Trip data information required for status report IntIF.8.10 Current Traffic information From: F.8.4 Generate message To: F.8.5 Cummunication system interface Information: - Current Traffic Information - Destination Parameters - Command to transmit Traffic Information IntIF.8.11 Trip / Tour status information From: F.8.4 Generate message To: F.8.5 Cummunication system interface Information: - Trip / Tour status information - Destination Parameters - Command to transmit status information IntIF.8.12 Vehicle position report From: F.8.4 Generate message To: F.8.5 Cummunication system interface Information: - Vehicle current position - Destination Parameters - Command to transmit vehicle position report IntIF.8.13 Position request From: F.8.5 Cummunication system interface To: F.8.4 Generate Message Information: - Request for current position Deliverable 5.1 Page A2.32

85 Function F.9 - Trip / Route Control Data Flow Diagram Radio Stations ExtIF.9.1 P.4 - Driver F.9 - Trip / Route Control IF.22 IF.19 F.9.3 Communication system interface IntIF.9.2 IntIF.9.1 P.3 Carrier / Fleet manager IF.20 IF.40 F.9.1 Change Trip / Route IntIF.9.3 IntIF.9.4 Trip Route IF.44 F.8 Trip / Route Execution IF.35 IF.34.1 F.9.2 Collect & Report trip / route data IF.58 IF.33 IF.36 IF.34.2 P.8 Vehicle P.2 Forwarder Sub-functions F9.1 Change trip / route plan Description: Make changes to daily delivery plan Input: IF.20 Daily delivery plan IF.40 Vehicle running costs IF.34.1 Vehicle location IntIF.9.2 Trip alteration Output: IntIF.9.1 Trip / Route Change Confirmation / Refusal IntIF.9.3 Trip / Route plan IF.33 Vehicle / cargo parameters input F9.2 Collect & report trip / route data Description: Collect information concerning trips and make trip expenses km time report. Input: IF.34.2 Trip / route data IntIF.9.4 Trip / route plan Output: IF.35 Trip expenses km time report IF.36 Proof of delivery Deliverable 5.1 Page A2.33

86 F9.3 Communication system interface Description: Converts data to the specific kind of communication system Input: IntIF.9.1 Trip / Route Change Confirmation / Refusal IF.19 Trip alteration ExtIF.9.1 Traffic info 1 Output: IF.22 Trip / Route Change Confirmation / Refusal IntIF.9.2 Trip alteration External information flows ExtIF.9.1 Traffic info 1 From: Radio stations To: F.9.3 Cummunication system interface Information: - General traffic information Internal information flows IntIF.9.1 Trip / Route Change Confirmation /Refusal From: F.9.1 Change trip / route plan To: F.9.3 Communication system interface Information: -Trip / Route Change Confirmation /Refusal -Destination parameters -Command to transmit Trip / Route Change Confirmation /Refusal IntIF.9.2 Trip alteration From: F.9.3 Cummunication system interface To: F.9.1 Change trip / route plan Information: - Trip alteration IntIF.9.3 Trip / route plan From: F.9.1 Change trip / route plan To: Trip / route database Information: - Trip / route plan IntIF.9.4 Trip / Route plan From: Trip / route database To: F.9.2 Collect trip / route data Information: - Trip / Route plan Deliverable 5.1 Page A2.34

87 Function F.10 - Traffic Management Data Flow Diagram Traffic Information Sources ExtIF.10.1 ExtIF.10.2 P.5 Traffic Manager F.10 Traffic Management IntIF.10.3 F.10.1 Traffic Information Processing Database IntIF.10.4 IntIF.10.1 IntIF.10.2 F.10.2 Traffic Information Request Management IF.12 IF.27 P.3 Carrier / Fleet Manager Sub-functions F.10.1 Description Input Output Traffic Information Processing Identification and selection of relevant traffic information ExtIF.10.2 Traffic information IntIF.10.1 Information request IntIF.10.4 Vehicle status/position data IntIF.10.2 IntIF.10.3 Relevant traffic information Vehicle status/position request F.10.2 Description Input Output Traffic Information Request Management Reception of traffic information request and initiation of collection and selection process IF.12 Traffic information request IntIF.10.2 Relevant traffic information IntIF.10.1 Information request ExtIF.10.1 Traffic information request IF.27 Traffic situation report Deliverable 5.1 Page A2.35

88 External information flows ExtIF.10.1 Traffic information request from F Traffic Information Request Management to Traffic information sources information Request of traffic information ExtIF.10.2 from to information Traffic information Traffic information sources F Traffic Information Request Management "Unfiltered" traffic information Internal information flows IntIF.10.1 Information request from F Traffic Information Request Management to F Traffic Information Processing information Request for traffic information IntIF.10.2 from to information IntIF.10.3 from to information IntIF.10.4 from to information Relevant traffic information F Traffic Information Processing F Traffic Information Request Management "Filtered" relevant traffic information Vehicle status/position request F Traffic Information Processing Database Request of status/positions Vehicle status/position Database F Traffic Information Processing List of vehicles/status/positions that might be affected by the traffic message. Deliverable 5.1 Page A2.36

89 Function F.11 - Transshipment / Storage Process Data Flow Diagram P.6 Transport Centre Operator F.11 - Transshipment / Storage Process IntIF.11.2 F.11.1 Order Information IF.49 P.7 Consignee IntIF.11.1 IntIF.11.3 Re-usable equipement IF.50 IF.54 P.2 Forwarder IF.21 IF.23 F.11.2 Order Despatching IntIF.11.5 IntIF.11.4 IntIF.11.6 IF.24 F.11.3 Order Confirmation IF.25 IntIF.11.7 Inventory IF.53 IntIF.11.8 IF.8 F.11.4 Replenishment Information IF.7 P.1 Consignor Sub-functions F.11.1 Description: Input: Output: Order Information Receive consignment request from Consignee IF.49 - Consignment request Reusable equipment information/status IntIF Consignment request to Order Despatching IntIF Reusable equipment information to Reusable Equipment Database F.11.2 Description: Input: Output: F.11.3 Description: Input: Output: Order Despatching Prepare and despatch consignment information IntIF Consignment request IntIF Reusable equipment information IntIF Consignment information IntIF Reusable equipment information Order Confirmation Send out details of consignment to be despatched IntIF Consignment information IF.54 - Confirmation of consignment IF.2 - Transport order IntIF Consignment data Deliverable 5.1 Page A2.37

90 F11.4 Replenishment information Description: Receive stock replenishment information from Consignor Input: IF.7 - Stock replenishment data from Consignor Output: IntIF Stock replenishment information to Inventory Database Internal information flows IntIF.11.1 Reusable Equipment Information From: F Order information To: Reusable equipment database Information: Details of Reusable equipment in system IntIF.11.2 From: To: Information: IntIF.11.3 From: To: Information: IntIF From: To: Information: IntIF From: To: Information: IntIF From: To: Information: IntIF From: To: Information: IntIF From: To: Information: Consignment information F Order information F Order despatching Consignment order Reusable equipment information Reusable equipment database F Order despatching Details of Reusable equipment in system Stockholding Status Request F Order despatching function Inventory database Request for stockholding status Stockholding Status Request Inventory database F Order despatching function Provision of stockholding status Order Information F Order despatching F Order confirmation Consignment order Inventory Update Information F Order confirmation function Inventory database Consignment order Stock Replenishment Information F Replenishment information Inventory database Shipment information Deliverable 5.1 Page A2.38

91 Function F.12 - Shipment Progress Control Data Flow Diagram IF.49 P.7 - Consignee IF.50 IF.54 P.6 Transport Centre Operator F.12 - Shipment Progress Control IntIF.12.1 F.12.1 Shipping & Receiving IF.26 IF.28.1 Expected Goods P.2 Forwarder IntIF.12.2 F.12.2 Loading & Unloading IF.28.2 Sub-functions F.12.1 description input Order Shipping / Consignment the shipper is the sender of the goods, the consignee the receiver; both parties can differ from the loading and unloading addresses lf.28.1 consignment status report IF.50 consignment confirmation IF.54 inventory status output lf.26 consignment status request IntlF.12.1 goods and re-usable equipment information IF.49 shipping data F.12.2 Order (Un)Loading description where the goods are physically loaded and unloaded; the reusable equipment is directly related to the cargo flow input lf.28.2 re-usable equipment status report from forwarder IntlF.12.2 re-usable equipment status request output not in scope of the project Sub-flows IF Consignment Status Report cf IF.5 from P.2 Forwarder to F.12.1 Shipping & Receiving information the forwarder supllies alle parties involved with status information about the goods shipped IF Re-usable Equipment Status Report from F.4.3 Re-usable Equipment to F.12.2 Loading & Unloading information equipment information ment for the logistic adresses Deliverable 5.1 Page A2.39

92 Internal information flows IntlF.12.1 Goods and Re-usable Equipment Status Information from F.12.1 Shipping & Receiving to D.S. Expected Goods information goods information including planned times of delivery IntlF.12.2 Re-usable Equipment Status Information Request from D.S. Expected Goods to F.12.2 Loading & Unloading information goods information including planned times of delivery Function F.13 - Combined Transport Process Data Flow Diagram P.9 Other Transport Mode Operator F.13 Combined Transport Process P.2 Forwarder IF.30.2 IF.29.2 IF.29.1 IF.30.1 F.13.1 Transport Booking IntIF.13.1 IntIF.13.2 F.13.2 Operational Planning IntIF.13.4 IntIF.13.3 IntIF.13.5 Order & Consignment Database IntIF.13.9 IntIF.13.7 IntIF.13.8 F.13.3 Transport Process Control IntIF.13.6 F.13.4 Order Execution Sub-functions F.13.1 Description: Input: Output: Transport Booking Receives a transport booking order from the forwarder The interface towards the forwarder IF Transport booking/instruction IntIF Order confirmation IntIF Transport Instruction IF Order confirmation IntIF Transport booking/instruction Deliverable 5.1 Page A2.40

93 F.13.2 Description: Input: Output: F.13.3 Description: Input: Output: F.13.4 Description: Input: Output: Operational Planning Plan the transport according based on the Transport Booking information The information used before or after insertion into database IntIF Transport booking/instruction IntIF Resource availability IntIF Order confirmation IntIF Transport booking/instruction Transport Process Control Control the progress of the transport IF Status request from forwarder IntIF Status confirmation from order and consignment database IntIF Status request to order and consignment database IF Status report to forwarder Order Execution Execute the order according to instruction IntIF Transport instruction from order database or operational planning IntIF Order execution confirmation to database or operational planning Sub-flows IF.29.1: From: To: Information: IF.29.2 From: To: Information: IF.30.1: From: To: Information: IF.30.2: From: To: Information: Transport Booking/Instruction P.2 - Forwarder F Transport Booking Transport booking and instructions (in one or more messages) Transport Status Request P.2 - Forwarder F Transport Process Control Order identification Transport Booking confirmation F Transport Booking P.2 - Forwarder Confirmation of the transport booking Transport Status Report P Transport Process Control P.2 - Forwarder Order status and progress information Internal information flows IntIF.13.1: Transport Booking/Instruction From: F Transport Booking To: F Operational Planning Information: Transport booking and instructions, possibly as a pre-booking and confirmed booking Deliverable 5.1 Page A2.41

94 IntIF.13.2: From: To: Information: IntIF.13.3: From: To: Information: Order confirmation F Operational Planning F Transport Booking Order confirmation from operational planning Transport booking/instruction F Transport Booking Order and Consignment Database Order information from the transport booking IntIF.13.4: Transport Instruction From: F Operational Planning To: Order and Consignment Database Information: Transport instructions, with booking status Remark: This flow may go via the F Transport booking IntIF.13.5: From: To: Information: IntIF.13.6 From: To: Information: IntIF.13.7 From: To: Information: Order confirmation Order and Consignment Database F Operational Planning Order confirmation from database Transport Status Request F Transport Process Control Order and Consignment Database Order identification Transport Status Report Order and Consignment Database F Transport Process Control Order status and progress information IntIF.13.8 Transport Instruction From: Order and Consignment Database To: F Order Execution Information: Transport instructions Remark: This flow may go via the F Operational planning Deliverable 5.1 Page A2.42

95 Function F.14 - Remote Vehicle & Cargo Reporting Data Flow Diagram Cargo probes/ sensors - Temperature - Humidity... Position Sensors (GPS) Engine/Vehicle Sensors - Tachograph - Fuel Probe... ExtIF.14.1 ExtIF.14.2 ExtIF.14.5 ExtIF.14.4 ExtIF.14.3 P.8 - Vehicle 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 (GPS) Interface IntIF.14.1 IntIF.14.2 IntIF.14.3 Sensors values, Position and ParameterDatabase IntIF.14.4 IntIF.14.5 F.14.5 Communication System Interface IntIF.14.6 IntIF.14.7 IntIF.14.8 IntIF F.14.4 Report Control IntIF IntIF.14.9 IF.48 IF.31 Reporting Parameters Database P.3 Carrier / Fleet Manager Deliverable 5.1 Page A2.43

96 Sub-functions F.14.1 Description: Input: Output: Note: Cargo probes/sensors interface Provides the interface between cargo sensors and report control. Allows report control to always know the sensors' values This interface must be specific for every particular sensor. ExtIF Signals provided by cargo sensors ExtIF Specific sensors requests (according to specific protocol) Sensors values IntIF Cargo sensors values These sensors are specified according to the kind of goods to be transported. F.14.2 Description: Input: Output: F.14.3 Description: Input: Output: Engine/Vehicle sensors interface This function provides the interface between the engine/vehicle sensors and the report control. This interface must be specific for every particular sensor. ExtIF Signals provided by Engine/Vehicle sensors ExtIF Specific sensors requests (according to specific protocol) Sensors values IntIF Engine / Vehicle Sensor values Position sensor interface Provide the interface between GPS and Report control. Interpret the GPS protocol and obtain the relevant values. ExtIF Information provided by GPS (in GPS protocol) IntIF Latitude, Longitude and Velocity. Current time F Report control Description: Input: Output: This function decides when reports have to be sent to Carrier/Fleet manager (P.3) according to the rules for triggering reports (sensors alarm values, time schedule, etc.). This function creates the reports to send using the values from sensors. IntIF.14.4, IntIF.14.5, IntIF.14.8, IntIF Sensors current values. Vehicle location parameters. IntIF Automatic reporting parameters (sensors alarm values, schedule, etc.). IntIF Report about vehicle and cargo status. IntIF Vehicle position report F.14.5 Description: Input: Output: Communication system interface Converts a generic cargo/vehicle status report or position report according to the specific kind of communication system. (GSM, Radio, Trucking, etc.). Receive automatic reporting parameters and save them in a database. Generic report (IF.48, IntIF.14.6, IntIF.14.7) IF Cargo / Vehicle status report IF Vehicle position report IntIF Automatic reporting parameters IntIF Vehicle Position Request IntIF Cargo Parameters Request Sub-flows IF.31.1 From: To: Information: Vehicle position report F.14.5 Communication system interface Carrier / Fleet Manager (F.7 Fleet/Vehicle Monitoring) -Report containing a collection of positions -Vehicle ID Deliverable 5.1 Page A2.44

97 IF.31.2 From: To: Information: Cargo & engine/vehicle status F.14.5 Communications system interface Carrier / Fleet Manager (F.7 Fleet/Vehicle Monitoring) Sensors cargo & vehicle status Vehicle ID External information flows ExtIF.14.1 Cargo sensors status request From: F14.1 Cargo probes/sensors interface To: Cargo probes/sensors Information: Specific Sensor command ExtIF.14.2 From: To: Information: Cargo sensor status Cargo probes/sensors F.14.1 Cargo probes/sensors interface Sensor value (Temperature, etc.) ExtIF.14.3 From: To: Information: ExtIF.14.4 From: To: Information: ExtIF.14.5 From: To: Information: Position sensor status GPS F.14.3 Position sensor interface -Latitude, Longitude, Velocity, timestamp. -Sensor status (data valid/invalid ) Engine/vehicle sensor request F.14.2 Engine/vehicle sensors interface Engine/vehicle sensors Specific Sensor command Engine/vehicle sensor status Engine/vehicle sensors F.14.2 Engine/vehicle sensors interface Sensor value (Km, fuel, etc.) Internal information flows IntIF.14.1 From: To: Information: Cargo sensors values F.14.1 Cargo probes/sensors interface Sensors values database Sensor ID Current sensor measure (depending on sensor) Time stamp of measure IntIF.14.2 From: To: Information: Engine/vehicle sensor values F.14.2 Cargo probes/sensors interface Sensors values database Sensor ID Current sensor measure (depending on sensor) Time stamp of measure Deliverable 5.1 Page A2.45

98 IntIF.14.3 From: To: Information: IntIF.14.4 From: To: Vehicle location parameters F.14.3 Position sensor interface Positions values Database -Latitude, Longitude, Velocity -Timestamp Vehicle/Cargo sensor values or collections Sensors values Database F.14.4 Report control Information: (Sensor ID, sensor value, time) 1 (Sensor ID, sensor value, time) n IntIF.14.5 From: To: Vehicle location and collection of locations Positions Database F.14.4 Report control Information: (Latitude, Longitude, velocity and time) 1 (Latitude, Longitude, velocity and time) n IntIF14.6 From: To: Information: IntIF.14.7 From: To: Information: IntIF.14.8 From: To: Information: IntIF.14.9 From: To: Order to send cargo & engine/vehicle status F.14.4 Report control F.14.5 Communications system interface Sensors cargo & vehicle status Destination parameters Vehicle ID Command to transmit report Vehicle position report F.14.4 Report control F.14.5 Communication system interface -Report containing a collection of positions -Vehicle ID Vehicle position request F.14.5 Communication system interface F.14.4 Report control -Position Request (Message) Automatic reporting parameters F.14.5 Communication system interface Reporting Parameters Database Information: Sensor ID + sensor alarm values (for each of the sensors ) Automatic report schedule Destination parameters Deliverable 5.1 Page A2.46

99 IntIF From: To: Automatic reporting parameters Reporting Parameters Database F.14.4 Report control Information: Sensor ID + sensor alarm values (for each of the sensors ) Automatic report schedule Destination parameters IntIF From: To: Information: Cargo Parameters Request F.14.5 Communication system interface F.14.4 Report control -Sensor ID Function F.15 - Vehicle & Cargo Monitoring Data Flow Diagram P.8 Vehicle F.15 Vehicle & Cargo Monitoring IF.33 P.4 Driver F.15.1 Vehicle & Cargo monitoring control IF.32 IF.34 IntIF.15.2 IntIF.15.1 Sensors values, Position and ParameterDatabase Sub-functions Function: Description: Input: Output: F 15.1 Vehicle & Cargo monitoring control This function compares the current sensor values with the desired reference values and according to the deviation may inform the driver. Compares the desired route with the current progress position and depending on the current time may inform the driver that the trip is delayed or advanced in time. IntIF Sensor values or collections of values stored in database IF.33 - Vehicle/ cargo parameters (reference values) provided by the driver (F.9 trip/route control) and stored in database. Route and position parameters provided by the driver (F.9) and stored in database according to each specific trip. IF.32 - Vehicle/Cargo parameters display(s) IF.34 - Vehicle location parameters Deliverable 5.1 Page A2.47

100 Internal information flows IntIF 15.1 From: To: Vehicle location and collection of locations Database F.15.1 Vehicle & Cargo monitoring control Information: (Latitude, Longitude, velocity and time) 1 (Latitude, Longitude, velocity and time) n IntIF 15.2 From: To: Vehicle/Cargo sensor values or collections Database F.15.1 Vehicle & Cargo monitoring control Information: (Sensor ID, sensor value, time) 1 (Sensor ID, sensor value, time) n Function F.16 - Invoicing Data Flow Diagram P.4 Driver IF.36 P.2 - Forwarder F.16 - Invoicing F.16.1 POD check IntIF.16.1 IntIF.16.2 Forwarding Orders IF.55.1 F.3 Order Planning & Execution F.16.2 Invoicing IF.55.2 IF.57 IntIF.16.3 Invoices F.16.3 Distribute Invoices IntIF.16.4 F.4 Order Control IF.38 P.1 Consignor Deliverable 5.1 Page A2.48

101 Sub-functions F.16.1 POD Check description this function represents the mapping of the physical POD supplied by the driver with the forwarding status information input lf.36 POD (documents) output IntlF.16.1 result of the POD mapping, stored in the forwarding database F.16.2 Invoicing description contains the complete sales invoice procedure of the forwarding orders and creates the actual invoices input IF.55.2 quotations information; special rates and special agreements as agreed in the function F.3.1. IF.57 forwarding order status information IntlF.16.2 forwarding order information output IntlF.16.3 invoices, and invoice information F.16.3 Distribute Invoices description the invoices are gathered, sorted and prepared for distribution to the freight payers input IntlF.16.4 invoice information output lf.38 dsitributed invoice (document or EDI) Internal information flows IntlF.16.1 POD Status from F.16.1 POD check to D.S. Forwarding Orders information the result of the POD check is stored in the consignment database IntlF.16.2 Forwarding Order Information Request for Invoicing from D.S. Forwarding Orders to F.16.2 Invoicing information the result of the POD check is used as a trigger in the invoicing process IntlF.16.3 Storage Invoices from F.16.2 Invoicing to D.S. Invoices information the invoices created are stored in the invoice database; contents all invoice information IntlF.16.4 Invoice Information Request from D.S. Invoices to F.16.3 Distribute Invoices information all invoice data as required on the invoice document Deliverable 5.1 Page A2.49

102 Function F 17 - Cost & Performance Analysis Internal and external data collection on trip / route performance and cost and comparison Data Flow Diagram P.3 - Carrier / Fleet Manager F.6 Route Planning IF.37 IF.41 F.17 - Cost & Performance Analysis F.17.1 Cost & Performance Processing IntIF.17.1 IntIF.17.2 Performance data base IF.39 IF.40 IF.35 P.11 Support Service Supplier P.4 Driver Sub-functions F.17.1 Description Input Output Cost & Performance Processing Calculation of cost and performance data on the basis of internal and external transport data IF.39 Cost data IF.35 Trip Expences / Km / Time Report IF.41 Statistical data IntIF.17.2 Cost & performance data IF.37 IF.40 IntIF.17.1 Cost report (recommended freight price) Vehicle running cost data Cost & performance data query Information flows IntlF.17.1 Cost & performance data request from F Cost & Performance Processing to Performance database information Cost & performance data query IntlF.17.2 from to information Cost & performance data Performance database F Cost & Performance Processing Cost & performance data Deliverable 5.1 Page A2.50

103 Function F.18 - Consumables Cost Issuing Data Flow Diagram P.11 - Support Services Supplier F.18 - Consumables Cost Issuing F.18.1 Consumables Cost Issuing IF.39 P.3 Carrier / Fleet manager Sub-functions F18.1 Consumables Cost Issuing Description: Provision of of current fuel prices by diesel fuel companies Input: Output: IF.39 - Fuel price data Deliverable 5.1 Page A2.51

104 Information Flows IF.1 Transport Opportunity Presentation From F.1.1 Order Initiation To F.3.1 Order Evaluation Information Request for freight charges, possibilities, quotations etc. IF.2 Transport Instruction From F.1.2 Order Issuing To F.3.2 Order Acceptance & Registration Information Actual transport booking IF.3 Quotations Information / Instruction Confirmation From IF.3.1 F.3.1 Order Evaluation IF.3.2 F.3.2 Order Acceptance & Registration To IF.3.1 F.1.1 Order Initiation IF.3.2 F.1.2 Order Issuing Information Information of freight charges, possibilities, quotations etc. (IF.3.1) Acceptance/confirmation or refusal of the transportbooking (IF.3.2) IF.4 Cargo/Consignment Status Request From F.2.1 Shipment Status Control To F.4.2 Order Information Information Request for status information of the shipment, tracking ands tracing IF.5 Cargo/Consignment Status Report From F.4.2 Order Information To F.2.1 Shipment Status Control Information Order status report IF. 6 Pick-up Delivery List From F.3.4 Order Dispatching Carries To F.5.1 Order Entry & Check Information Set of order information with the request of i.e. transport possibilities, rates, space, elapstimes (..) IF.7 Shipping data From: F.1.2 Order issuing To: F.11.4 Replenishment Information Information: Advice of inventory being despatched IF.8 Consignment Confirmation From: F.11 (Inventory Database) To: F.1.2 Order Issuing Information: Confirmation of stock being despatched Deliverable 5.1 Page A2.52

105 IF.9 Order Progress Report From F.5.4 Order Status Control To IF9.1: F.4.1 Order Tracking IF9.2: F.4.3 Reusable Equipment Information Contents the execution data of the shipments IF. 10 Dispatching Status Request From F.4.1 Order Tracking To F.5.4 Order Status Control Information Request from the forwarder to the carrier to inform about the status of the transport (IF.11 - not used) IF.12 Traffic Information Request From F.6.2 Traffic Information Process Management To F.10.2 Traffic Information Request Management Information Request for traffic information IF.13 Fleet/vehicle position request From F.7.1 Position & Status Processing To F.8.2 Driving Information Trip/vehicle/driver identifier IF. 14 On-line Pick-up Information From F.3.2 Order Dispatching Carrier To F.5.1 Order Entry & Check Information Order information and transport instruction IF. 15 Pick-up Confirmation / Refusal From F.5.1 Order Entry & Check To F.3.2 Order Dispatching Carrier Information Confirmation or refusal of the order offered by the forwarder IF.16 Trip/route status information From F.8.5 Communication System Interface To F.6.5 Execution Control Information Trip/vehicle identifier, load status, vehicle position, time, 'specific messages' IF.17 Current traffic information From F.8.5 Communication System Interface To F.6.2 Traffic Information Process Management Information Trip/vehicle identifier, time, vehicle position, actual traffic situation IF.18 Vehicle position report From F.8.5 Communication System Interface To F.7.1 Position & Status Processing Information Trip/vehicle identifier, load status, vehicle position, time Deliverable 5.1 Page A2.53

106 IF.19 Trip alteration From F.6.4 Driver Information To F.9.3 Collect & Report Trip Information 'Trip/route plan' (see description Int.6.2), explanation on modification IF.20 Daily delivery plan From F.6.4 Driver Information To F.9.1 Communication System Interface Information 'Trip/route plan' IF.21 Status Request From F.11.2 Order dispatching To F.4.2 Order Information Information Request of status information IF.22 Trip/route change confirmation/refusal From F.9.3 Collect & Report Trip To F.6.5 Execution Control Information Trip/vehicle identifier, Flag/Explanation IF. 23 Status Reporting From F.4.2 Order Information To F.11.2 Order dispatching Information Report of order information and status information IF. 24 Request From F.3.3 Order Dispatching To F.11.3 Order Confirmation Information Set of order information with the request of i.e. transport possibilities, rates, space, elapstimes (..) IF. 25 Confirmation or refusal From F.11.3 Order Confirmation To F.3.3 Order Dispatching TCO Information Confirmation or refusal of the order offered by the forwarder IF. 26 Consignment Status Request cf IF.4 From F.12.1 Shipping & Receiving To F.4.2 Order Information Information Request from the consignor to the forwarder to inform about the status of the transport IF.27 Traffic Situation Report From F.10.2 Traffic Information Request Management To F.6.2 Traffic Information Process Management Information Information about traffic situation IF. 28 Consignment/Reusable Equipment Status Report From F.4.3 Re-usable Equipment To IF.28.1 F.12.1 Shipping & Receiving IF.28.2 F.12.2 Loading & Unloading Information The forwarder supplies all parties involved with status information about the goods shipped (IF.28.1). Equipment information meant for the logistic addresses (IF.28.2) Deliverable 5.1 Page A2.54

107 IF. 29 Booking Instruction, Status Request From F.3.5 Order Dispatching To IF.29.1 F.13.1 Transport Booking IF.29.2 F.13.3 Transport Process Control Information Set of order information with the request of i.e. warehouse possibilities, rates, space, elapse times (..) IF. 30 Confirmation or refusal TMO From IF.30.1 F.13.1 Transport Booking IF.30.2 F.13.3 Transport Process Control To F.3.5 Order Dispatching TMO Information Confirmation or refusal of the order offered by the forwarder IF.31 Vehicle/cargo parameter message From F.14.5 Communication System Interface To F.7.1 Position & Status Processing Information Trip/vehicle identifier, vehicle parameter values, cargo parameter values IF.32 Vehicle/cargo Parameter Displays From: F.15.1 Vehicle & Cargo monitoring control To: F.8.5 Communication System Interface Information: Alarm messages, sensors current values IF.33 Vehicle/Cargo parameters inputs From: F.9.2 Change Trip / Route To: F.15.1 Vehicle and Cargo Control Information: Sensor desired value (max/min) Sensor ID Expected route details (Interest points and arriving times) IF.34 Vehicle current route/location Parameters From: F.15.1 Vehicle & Cargo monitoring control To: IF.34.1 F.9.1 Communication System Interface IF.34.2 F.9.2 Change Trip / Route Information: Vehicle location (lat., long.). Route execution status (Delays, etc.). IF.35 Trip Expenses / km / time report From F.9.1 Change Trip / Route To F.17.1 Cost & Performance Processing Information Information about expenses, distances, times etc IF. 36 Delivery Proof (documents) From F.9.2 Change Trip / Route To F.16.1 POD Check Information document with signature of the receiver of the goods that goods are received in good condition Deliverable 5.1 Page A2.55

108 IF.37 Cost Report From F.17.1 Cost & Performance Processing To F.6.1 Route Calculation Information Information to calculate cost of transport IF. 38 Invoice From F.16.3 Distribute Invoices To F.1.3 Order payment Information Invoice data i.e. rates, amounts, invoice references IF.39 Cost Data From F.18.1 Consumables Cost Issuing To F.17.1 Cost and Performance Processing Information Costs for transshipment/storage services IF.40 Vehicle Running Cost Data From F.17.1 Cost and Performance Processing To F.9.1 Communication System Interface Information Information to driver on costs for running the vehicle and freight IF.41 Statistical Data From F.6.1 Transport Statistics To F.17.1 Cost and Performance Processing Information Various statistcal data, e.g. feedback on cost reports IF.42 Order Vehicle Driver List From F.5.3 Vehicle / Driver Calculation To F.6.1 Route Calculation Information List of order assignments to vehicles/drivers IF.43 Vehicle Status and Position From F.6.5 Execution Control To IF.43.1 F.5.3 Vehicle / Driver Calculation IF.43.2 F.5.4 Order Status Control Information Position of vehicle, deviations and status IF.44 Trip and Route Plan From F.9 (Trip / Route database) To F.8.1 Get Next Trip Information Trip and route plan data IF.45 Trip/route deviation information From F.7.1 Position & Status Processing To F.6.5 Execution Control Information Trip/vehicle identifier, actual time, position, loading status, vehicle parameters, cargo parameters (different from expected values) IF.46 Statistical data From F.7.1 Position & Status Processing To F.6.3 Transport Statistics Information Trip/vehicle identifier, record of: time, position, loading status, vehicle parameters, cargo parameters Deliverable 5.1 Page A2.56

109 IF.47 Trip/route plan per vehicle/driver From F.6.4 Driver information To F.7.1 Position & Status Processing Information Trip/route plan IF.48 Vehicle / Cargo Status Request From: F.7.1 Position & Status Processing To: F.14.5 Communication System Interface Information: Specific command (depending on protocol). Note: Vehicle sensor status request is similar to cargo sensor status request. IF.49 Shipping data From: F.12.1 Shipping & Receiving To: F.11.1 Order Information Information: Advice of inventory being despatched IF.50 Consignment Confirmation From: F.11 (Inventory Database) To: F.12.1 Shipping & Receiving Information: Confirmation of stock being despatched IF. 51 Issue Orders Status Information Concerning Control From F.1 (Issued Orders by Consignor) To F.2.1 Shipment Status Control Information relevant order information of orders issued and registered by the consignor i.e. ordernumber, goods information, terms of delivery (..) IF. 52 Consignor Order Status Information From F.2.2 Payment Advice To F.1.3 Order payment Information Advice (status) concerning the payment of the invoice; this status can be the trigger to pay the invoice IF.53 Inventory Status From: F.11 (Inventory Database) To: F.2.1 Shipment Status Control Information: Status report of stockholding at a distribution point IF.54 Inventory Status From: F.11 (Inventory Database) To: F.12.1 Shipping & Receiving Information: Status report of stockholding at distribution point Deliverable 5.1 Page A2.57

110 IF. 55 Forwarding Orders Information (bases for F.16) From IF.55.1 F.3 (Forwarding Quotations) IF.55.2 F.3 (Forwarding Orders) To IF.55.1 F.16 (Forwarding Orders) IF.55.2 F.16.2 Invoicing Information order information to serve the invoicing process IF. 56 Forwarding Orders Information (bases for F.4) From F.3. (Forwarding Orders) To F.4.1 Order Tracking Information order information to base the tracking and tracing on IF. 57 Forwarding order status information From F.4 (Order Status) To F.16.2 Invoicing Information Order and status information Deliverable 5.1 Page A2.58

111 Annex A3 Comparison Tables Deliverable 5.1 Page A3.1

112 A3 Comparison tables - the generic framework and the test sites In this annex the results of the comparisons between the generic framework and the test sites is presented. The presentation is in table form, a discussion of the result is found in chapter 6. The tables focus on the existence of the item within the test sites. Table A3.1: Parties existing within the test sites Parties De Rijk ICT Heezik Patinter P.1 Consignor x x x x P.2 Forwarder x 0 x x P.3 Carrier / Fleet manager x x x x P.4 Driver x x x 0 P.5 Traffic Manager P.6 Transport Center Operator 0 x 0 0 P.7 Consignee x x x x P.8 Vehicle x 0 x 0 P.9 Other Mode of Transport Operator P.10 Authorities P.11 Support Services Supplier 0 x 0 0 Table A3.2: Functions existing within the test sites Functions De Rijk ICT Heezik Patinter F.1 Transport Order Issuing x 0 x x F.2 Shipment Arrival Control cf F x F.3 Order Planning and Execution x 0 x x F.4 Order Control x 0 x 0 F.5 Operational Planning (Dispatching) x 0 x x F.6 Trip / Route Planning x 0 x 0 F.7 Fleet / Vehicle Monitoring x 0 x x F.8 Trip / Route Execution x F.9 Trip / Route Control x F.10 Traffic Management F.11 Transshipment / Storage Process 0 x 0 0 F.12 Shipment Progress Control (cf F.2) x 0 x x F.13 Combined Transport Process F.14 Remote Vehicle & Cargo Reporting x 0 x x F.15 Vehicle & Cargo Monitoring F.16 Invoicing x 0 x x F.17 Cost & Performance Analysis x x x x F.18 Consumables Cost Issuing 0 x 0 0 Table A3.3: Information flows existing within the test sites Nr. From To Fxx Information flows: name De Rijk ICT Heezik Patinter Fxx IF.1 F.1 F.3 Transport Opportunity Presentation x IF.2 F.1 F.3 Transport Booking / Transport Instruction x 0 x x IF.3 F.3 F.1 Quotations Information / Instruction Confirmation x 0 x x IF.4 F.2 F.4 Cargo / Consignment Status Request x IF.5 F.4 F.2 Cargo / Consignment Status Report 0 0 x x IF.6 F.3 F.5 Pick-Up Delivery List IF.7 F.1 F.11 Shipping data 0 x 0 0 IF.8 F.11 F.1 Consignment confirmation 0 x 0 0 Deliverable 5.1 Page A3.2

113 Table continued IF.9 F.5 F.4 Order Progress Report x IF.10 F.4 F.5 Dispatching Status Request IF IF.12 F.6 F.10 Traffic Information Request IF:13 F.7 F.8 Fleet / Vehicle Position Request 0 0 x x IF.14 F.3 F.5 On-line Pick-Up Information x 0 x 0 IF.15 F.5 F.3 Pick-Up Order Refusal x 0 x 0 IF.16 F.8 F.6 Trip / Tour Status Information x 0 x 0 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 x 0 x 0 IF.20 F.6 F.9 Daily Delivery Plan x 0 0 x IF.21 F.11 F.4 Status request 0 x 0 0 IF.22 F.9 F.6 Trip / Route Change Confirmation / Refusal x IF.23 F.4 F.11 Status Reporting x 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 x IF.27 F.10 F.6 Traffic Situation Report IF.28 F.4 F.12 Consignment Status Report cf IF x IF.29 F.3 F.13 Booking instruction, Status Request IF.30 F.13 F.3 Confirmation or refusal x IF.31 F.14 F.7 Vehicle / Cargo Parameter Message 0 0 x 0 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 x IF.35 F.9 F.17 Trip expenses / Km / Time Report x x x x IF.36 F.9 F.16 Delivery Proof (Documents) x IF.37 F.17 F.6 Costs Report IF.38 F.16 F.1 Invoice 0 0 x x IF.39 F.18 F.17 Cost data 0 x 0 0 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 0 x 0 x IF.49 F.12 F.11 Shipping data 0 x 0 0 IF.50 F.11 F.12 Consignment confirmation 0 x 0 0 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 0 x 0 0 IF.54 F.11 F.12 Inventory Status 0 x 0 0 IF.55 F.3 F.16 Forwarding Orders Information x 0 x 0 IF.56 F.3 F.4 Forwarding Orders Information x 0 x 0 IF.57 F.4 F.16 Forwarding order status information x Deliverable 5.1 Page A3.3

114 Deliverable 5.1 Functional specification for an integrated freight and fleet management system Part B Status: RP Telematics applications of common interest Project: 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

115 Acknowledgement: This deliverable has been completed with the help of all 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 B. Project Partners Partners in the 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 PATINTER Lda Portugal Deliverable 5.1 Page II

116 Introduction This report contains the test site reports describing the functional specification of the four test sites within the project. This report is part B of the report D5.1 - Functional specification for an integrated freight and fleet management system. Contents: Annex A4: Functional specification at Inter City Trucks (UK) Annex A5: Functional specification at Patinter (PT) Annex A6: Functional specification at Jan de Rijk (NL) Annex A7: Functional specification at C. van Heezik (NL) Deliverable 5.1 Page III

117 Annex A4 Inter City Trucks Deliverable 5.1

118 A4 Functional specification at Inter City Trucks (UK) 1 Introduction This report is the breakdown of the functional specification for the software interfaces at Inter City Trucks (ICT) test-site. It uses the user requirements deliverable D3.1 from WP3 and incorporates subsequent discussions with the relevant parties involved as reference. The interfaces described will facilitate the integration of the different systems which ICT wishes to link within the project during the design and implementation phases of the project. The concept of the ICT interfaces and main parties involved are described in Section 2. Section 3 gives the breakdown of the functional specifications including the detailed processes provided by each function and the data that will be used to interface between the functions and any external systems. Wherever practical, data flow diagrams (DFDs) have been broken down into sub-levels of smaller components. In Section 4, the data stores are described. Section 5 summarises the information flows. Section 6 provides the dynamic interactions within the system. 2 Context of the Interfaces at ICT The diagram in Figure A4.1 below describes the context of the interfaces at ICT. Figure A4.1: Context diagram of interfaces for ICT P.4 Driver P.1 Consignees GENESIS BRAKES INDIA Fuel choice Driver Instructions Inventory Inventory Inventory ICT Duty manager Inventory Fuel price ICT Interfaces Inventory Fuel price SATURN SYSTEM Fuel choice Data comms Fuel choice Fuel price Fuel price Inventory Data comms P.11 Support Service Supplier P.11 Support Service Supplier ENIGMA SYSTEM BLACKWOOD SYSTEM The ICT interfaces will provide and manage information that is essential to maintaining cost-efficient transport. The main output of the system is drivers running sheet, which is compiled from information contained in a number of databases related to customers, vehicles, drivers, trailers and delivery points. It is planned that two software applications will be independently integrated with existing computer systems. Deliverable 5.1 Page A4.1

119 Inventory data. ICT will use an inventory and warehouse management system in collaboration with Genesis International Ltd. The inventory system will provide information about stockholding of automotive components that are distributed in Europe (including UK) by ICT and Genesis. Genesis and ICT will allow input of a manufacturer s (Brakes India [BI]) production programme, shipment from a distant source, and arrival in the UK warehouse (stock level), delivery to consignee. Data can be entered and viewed by the manufacturer and warehouse keeper, while relevant information will be electronically forwarded to the consumers of these products. By providing such access to BI and its customers, both will have better knowledge of the stockholding position and they will not have to rely on ICT and Genesis to provide this information manually. Fuel price data. Two fuel card companies (AS24 and IDS) provide information about the price of fuel at their service stations throughout Europe. This information is used by ICT after it is analysed and compared to inform drivers where it is cheapest for them to refuel en route. The information is presently given to drivers using paper, which quickly becomes out of date due to the constantly fluctuating fuel prices and exchange rates. The aim of the automated interface is to provide this information to a mailbox on a regularly updated basis, such that the drivers will be able to poll the actual information. Mobile data communications equipment supplied by Enigma Systems uses GSM-data, GSM-SMS and in future Orbcomm LEO satellites. This system offers full data communications between the ICT office and its drivers (and vice versa). Specific features that are to be part of the system comprise stamped vehicle location (in text) and current kilometre reading from the speedometer on each message received in the office. This information will be useful to the planning staff for cargo and cost management. 2.1 Parties involved Within the context of the project, eight different organisations and three software applications will be involved in one way or another in the transport process and the use of the interfaces and system integration at ICT. These parties are: ICT (Duty Manager and Driver/Vehicle); Genesis International Ltd; Brakes India (BI); Saturn Operations Systems; Enigma Vehicle Systems and GMSI; 2 Fuel companies (AS24 and IDS); Blackwood Computer Systems. The relationships between the parties are shown in Figure A4.2 on the next page. Deliverable 5.1 Page A4.2

120 Figure A4.2: Parties and their relationships in ICT Interfaces Systems Suppliers Distribution and transport Saturn System Genesis ICT Enigma System Blackwood System Brakes India AS24 FuelCo IDS Fuel Co Customers Fuel Suppliers Saturn Operations Systems - this company is the supplier of the main computerised administration system at ICT. Enigma Vehicle Systems - this company is the supplier of the mobile data communications and vehicle location system that is installed at ICT. Blackwood computer (BWC) system: BWC is the hardware and software supplier of the inventory management system to Genesis and ICT and is based at Cwmbran in south Wales. ICT- this company is the main end-user of the interfaces. It is largely a transport company and distributes goods for customers throughout Europe. Genesis International Ltd - this company is part of the ICT Group and carries out distribution services from it warehouse in South Wales. Fuel companies - two companies, AS24 and IDS, are fuel card companies that are used by ICT and its drivers when they refuel Other Parties Customers - In the first instance it is the goal that BI s customers will eventually receive inventory information via the inventory interface. ICT Duty Manager manages the system at ICT, inputs data manually and can overrule driver instructions and fuel choice. ICT duty manager has the general duty of sending information and instructions to ICT drivers at a supervisory user level. He also receives information from drivers via the Enigma and Saturn systems. Deliverable 5.1 Page A4.3

121 ICT Driver receives instructions and fuel choice information from the ICT Duty Manager via the Enigma system s mobile communications. Deliverable 5.1 Page A4.4

122 3 Functional Modelling Figure A4.3 below is the first level data flow diagram (DFD) of the ICT functions. Figure A4.3: First Level diagram of the ICT Interfaces P.4 Driver ICT Duty Manager Fuel Database Inventory Database P.1 Consignees GENESIS BRAKES INDIA Fuel choice Fuel price Fuel choice Fuel choice Fuel price Fuel price Inventory Data F1: Generic FTP Interface Inventory Data Inventory Data 5 Inventory Data 5 Inventory Data 3 Inventory Data 4 Inventory Data 1 Inventory Data 2 F2: Fuel Interface Fuel choice Fuel price SATURN SYSTEM Inventory Data F4: Inventory Interface Fuel choice Fuel choice IF.39 IF.39 F3 Mobile Communications Interface Inventory Data Data comms P.11 Support Service Supplier P.11 Support Service Supplier ENIGMA SYSTEM BLACKWOOD SYSTEM The four interfaces at ICT will permit the interaction between the ICT duty manager, ICT drivers, BI customers, Blackwood inventory management system, Enigma system and the Saturn system. It will provide and use data to/from BI, customers, Genesis and the computer systems so that some data fields are posted to a mailbox from which they can be monitored by the manager and retrieved by the drivers using mobile data communications. Broadly, the four functions that are relevant to the project can be classified as communications and central planning. ICT will use the Saturn system as the core component of its information technology requirements. The goal is that the system will act as a central database, controller and gateway for other peripheral systems, namely: Mobile data communications using the GSM-SMS cellular telephone- and/or the forthcoming Low Earth Orbit (LEO) data satellite networks; Electronic data interchange modules that will facilitate direct electronic connections to customers and suppliers. Deliverable 5.1 Page A4.5

123 In order to pick up instructions on running sheets drivers currently have to go physically to ICT office at Hythe. The information on the running sheet provides details about where to pick up or deliver goods, buy fuel, receive directions or special instructions, etc. In return, drivers, using the same sheet, provide information concerning fuel up-lifts, other expenses, and distances travelled which are then loaded and emptied to the office administration. F1- Generic FTP Communications Interface Once the drivers have started their trip they can contact the office using GSM-SMS mobile telephones in their vehicles, which also permits them to receive limited text messages. ICT is in the process of upgrading this equipment to include in-cab data terminals and vehicle location capability (using GPS). After the upgrade is completed it is planned that drivers will receive much more information via the incab terminals, reducing the need for them to visit the office. F2- Enigma System and Mobile communications Interface The application used by ICT is made by GMSI, and supplied by Enigma Vehicle Systems. The system comprises the GMSI Dispatch software and in-vehicle units, running on a Windows 95 or NT platform, with the capability to interface with MS Access and other applications and provide information to planning staff on a local or wide area network and to provide a capability for drivers to provide specific status reports concerning confirmation of shipping goods (i.e. when the vehicle has taken a cross- Channel ferry), confirmation of delivery and to obtain dynamically updated fuel price information. F3-Fuel Interface ICT will provide all necessary fuel uplift information to drivers using this system. In addition to this information there is the potential to develop this interface into one that will act as a means of permit the supply of more detailed information about service stations, the facilities they offer and important details such as open hours and fuel availability. F4-Inventory Interface and Blackwood inventory management system This system will show current stockholding of automotive components held by ICT and Genesis, and replenishment shipments that have been dispatched from the manufacturer and are due for arrival in the UK. The system will therefore show the actual and virtual stockholding that is in the supply chain. Deliverable 5.1 Page A4.6

124 4 Functional Breakdown 4.1 F1: Generic FTP Interface Figure A4.4 gives the second level DFD of the Generic FTP Interface Figure A4.4: Second Level Diagram of F1-Generic FTP Interface Function Ict Duty Manager Consignee Database P.1 Consignees Genesis Brakes India Enigma System Fuel price Fuel price IF.1.2 & 1.3 F1.1 Access System Inventory Inventory Inventory Inventory Data 3 Inventory Data 4 Inventory Data 1 Inventory Data 2 Fuel price F1.2 Process Mobile Comms Data Fuel price Fuel Choice Saturn System Inventory Other Inventory Data F1.4 Process Inventory Data Fuel price Inventory Data Fuel Choice Fuel Price Data F1.3 Process Fuel Data IF.39 Inventory FTP Database Inventory Data IF.39 Fuel Prices Database P.11 Support Service Supplier P.11 Support Service Supplier BLACKWOOD SYSTEM The generic FTP interface will permit access to and the interaction between the ICT duty manager, drivers, customers and the Saturn system. It will provide and use data to/from the Saturn System so that: some data fields are posted to a mailbox from which they can be monitored by the manager and retrieved by the drivers using mobile data communications; all data fields will be posted to a database within the Saturn System to show the calculations and input variables. Broadly, the processes involved are: Access the system; Process Mobile communications data; Process Fuel data; Process Inventory data. Deliverable 5.1 Page A4.7

125 4.1.1 F1.1: Access system This process allows the ICT manager and customers to access the system. In order to pick up instructions on running sheets drivers currently have to go physically to ICT office at Hythe. The information on the running sheet provides details about where to pick up or deliver goods, buy fuel, receive directions or special instructions, etc. In return, drivers, using the same sheet, provide information concerning fuel up-lifts, other expenses, and distances travelled which are then loaded and emptied to the office administration. The process will allow the system to provide and manage information that is essential to maintaining cost efficient transport. An output of the interface is drivers running sheet, which is compiled from information contained a number of databases related to customers, vehicles, drivers, trailers and delivery points F1.2: Process Mobile Communications data This process will allow the GMSI supplied by Enigma Vehicle Systems. The Enigma system comprises the GMSI Dispatch software and in-vehicle units, running on a Windows 95 or NT platform, with the capability to interface with MS Access and other applications and provide information to planning staff on a local or wide area network. Mobile data communications can be achieved using GSM-data, GSM- SMS and Orbcomm LEO satellites. Full implementation of the system will be completed by August ICT will use the Saturn system as the core component of its information technology requirements in the future. The goal is that the system will act as a central database, controller and gateway for other peripheral systems, namely that once the drivers have started their trip they can contact the office using GSM-SMS mobile telephones in their vehicles, which also permits them to receive limited text messages. ICT is in the process of upgrading this equipment to include in-cab data terminals and vehicle location capability (using GPS). After the upgrade is completed it is planned that drivers will receive much more information via the in-cab terminals, reducing the need for them to visit the office F1.3: Process fuel data This process will allow ICT to provide all necessary trip and fuel uplift information to drivers using this system and to provide a capability for drivers to provide specific status reports concerning confirmation of shipping goods (i.e. when the vehicle has taken a cross-channel ferry), confirmation of delivery and to obtain dynamically updated fuel price information F1.4: Process inventory data This process will show current stockholding of automotive components held by ICT and Genesis, and replenishment shipments that have been dispatched from the manufacturer and are due for arrival in the UK. The system will therefore show the actual and virtual stockholding that is in the supply chain. Deliverable 5.1 Page A4.8

126 4.2 F3: Fuel interface Figure A4.5 is the second level DFD of the Fuel Interface. Figure A4.5: Second level diagram of F2- Fuel Interface Function ICT Duty Manager Fuel Choice Database ENIGMA System Manual input Fuel choice Fuel prices Fuel choice F2.2 Process Fuel prices Final price 2 Final price 1 F2.3 Compare Final Fuel prices Fuel prices Fuel prices Fuel choice F2.1 Receive Fuel prices Saturn System Fuel price P.11 Support Service Supplier Fuel price P.11 Support Service Supplier The Fuel Interface will permit the receipt of fuel price data in an electronic format from two fuel card companies - IDS and AS24. It will also permit integration of this data into the data communications system so that relevant fuel information can be posted to a mailbox from which it can be retrieved by drivers using the Enigma system. At this stage it is planned that currency exchange rate data will be input manually F2.1: Receive Fuel Price List ICT will receive data direct from fuel companies, notably IDS and AS24. The information they provide gives up-to-date, local currency prices of fuel across Europe; however, this is currently sent to ICT by fax. The data are entered manually into a spreadsheet at ICT, and comparison in Stirling equivalent is computed using the local cost price, exchange rates, discounts, and VAT. Actual pump price information is given to drivers as part of their instructions and is used to recommend the refuelling depots they should use. Fuel price updates cannot be easily given to drivers after they have departed on a trip. Deliverable 5.1 Page A4.9

127 4.2.2 F2.2: Process Fuel Price The received fuel price list will be analysed. This operation will be automated such that information is received electronically, converted using an algorithm that is part of the interface and the recalculated information deposited in an out box which can be remotely accessed by drivers using the mobile data communications equipment in their vehicles. The automation of this process offers ICT potential cost savings for fuel and the time it takes to provide this information to its drivers F2.3: Compare Final Fuel prices This process compares the final prices from the various companies. The processed fuel price data (for the driver) can be directly placed into a directory located in the communications software, eliminating the need to use Saturn as a communications conduit. Database will be located within Saturn. We need to confirm how fuel data will be retrieved from AS24 system Mapping to the Generic Architecture Parties P.11 - Support Services Provider The parties which form this group are providers of services that support road transport operations. The group includes parties such as fuel (card) companies, tyre suppliers and fitters, vehicle servicing and maintenance, tank cleaning, trailer servicing and maintenance, container servicing and maintenance and any other businesses that are used as a direct result of operating vehicles (and trailers). One party [fuel (card) companies] is involved in the project and this only relates to the provision of information about the price of fuel. Therefore, general functions associated to this group have not been explored. Figure A4.6: Fuel price context diagram P.3 Carrier / Fleet manager IF.35 P.4 Driver F.17.1 Cost Analysis IF.39 P. 11 Support Services Supplier F.18.1 Fuel Price Issuing Deliverable 5.1 Page A4.10

128 Figure A4.7: Fuel price data model P.3 Carrier / Fleet manager IF.35 P.4 Driver F.17.1 Cost Analysis INT 17.1 Fuel Cost IF.39 F.18.1 Consumables Cost Issuing P. 11 Support Services Supplier 4.3 F3: Mobile Communications Interface Figure A4.8: Second Level diagram of F3-Mobile Comms Interface Function Deliverable 5.1 Page A4.11

129 ICT Duty Manager Fuel choice P.4 Driver F3.2 Send Fuel Choice Fuel choice Fuel Choice Database Fuel choice Fuel choice F3.1 Receive Mobile Comms data Fuel choice Saturn System comms data Enigma System Fuel price 1 Fuel price 1 F2 : Fuel Interface Fuel choice Figure A4.7 provides the second-level DFD of the Mobile Comms Interface. The Mobile Comms Interface involves interface and systems integration that will permit the Enigma system to exchange administrative data with the Saturn system. In particular, this interface will also facilitate the transfer of information concerning fuel prices, collection / delivery instructions, status reports and position information to drivers on the road F3.1: Receive Comms data This process will receive comms protocol from the Enigma system F3.2: Receive Fuel Choice This process will receive the computed fuel choice from the Fuel interface F3.3: Send Driver instructions This process will allow the sending of the fuel choice and other driver instructions to drivers. UoW will take special interest in this interface but it will not develop interfaces to facilitate the exchange of data between these systems. The development of the interface will be carried out by Enigma and Saturn Operations Systems. 4.4 F4: Inventory Interface The second-level DFD for the Inventory Interface is shown in Figure A4.8. Deliverable 5.1 Page A4.12

130 Figure A4.9: Second Level Diagram of F4-Inventory Interface ICT Duty Manager P.1 Consignees Genesis Brakes India Inventory Inventory Inventory Inventory Inventory Inventory F4.4 Store Inventory Inventory Inventory F4.5 Send Inventory F4.1 Receive Inventory Inventory Database F4.3 Secure Inventory data Inventory F4.2 Process Inventory Inventory Inventory BLACKWOOD SYSTEM This function involves the interface and systems integration that will permit BI to access stockholding data retained in the warehouse management software package that is to be installed by Genesis and ICT. ICT would create a gateway through which a customer, Brakes India (BI), could remotely access information about stockholding of automotive components, which ICT distributes F4.1: Receive Inventory There will be two sources of information regarding inventory, BI and Genesis/ICT. In the case of BI, data concerning component replenishment will be sent to Genesis electronically in a format yet to be decided (i.e EDI). The interface will then direct the data to either the Genesis or ICT element of the inventory management system, with the aim of updating the stock position automatically. Information originating from Genesis or ICT (i.e. number of components dispatched) will be input manually to the system so to keep the stock position fully up to date. This sub-system is closely linked to the installation of the inventory management system, but it is possible that the EDI gateway could be effected in isolation as a pre-cursor to linking with the inventory system via the Saturn system. Whilst EDI has been mentioned as the means of access in order to investigate the current position of stockholding, other interfacing methods, notably using the Internet, will also be examined, in order to provide a cheap, practical and up-gradable solution F4.2: Process Inventory The different data inputs received from BI and Genesis/ICT will be processed for input or export from the inventory system. Deliverable 5.1 Page A4.13

131 4.4.3 F4.3: Secure Inventory For data that is to be exported to BI and possibly BI s customers it will be necessary to secure the processed data using an encryption software F4.4: Store Inventory This process will store the secured data in a database F4.5: Send Inventory This process will send inventory information to BI and its customers. The data sets that each party receives will be unique. Deliverable 5.1 Page A4.14

132 Figure A4.10: Provision of inventory data ICT warehouse s/w Genesis warehouse s/w Central database Files exported using Zetafax comms or FTP Files imported using FTP or direct modem link Customer A Customer B Brakes India The despatch notes (referred to as invoices by BI) received from Brakes India are generated using INGRES RDBMS in India. The information is made available via a satellite link to ICT in the UK. It is hoped that two of BI s customers will be able to access this data held by Genesis and ICT giving a pipeline view of what is coming from India. ICT will deliver as per customer schedules. Customers need to know the current stock of all part numbers in the warehouses (at Hythe and Cwmbran) and also what is in the pipeline. BI will have feedback based on customer schedules and what is at warehouses and in the pipeline the quantities they have to produce and dispatch of each part number in the coming weeks. Invoices from ICT will be automatically sent to BI every 15 days. Central database is a consolidation of selected fields from ICT/Genesis Warehouse s/w Export files from Central D/base need to be compiled automatically triggered by clock Export files could be flat-files or db format. Import files from Brakes India need to pass untouched to ICT or Gen Mapping to generic Architecture. P.6 Transport Centre Operator Transport Centre Operator is a broad term that represents a number of different functions that may be carried out together at one site or performed in part at any site. Essentially two main functions take place: storage and distribution, and transhipment. The first functions are concerned with warehouse practices which involve the holding of stock at a location before for final distribution. Transhipment deals with the transfer of freight from one vehicle to another (any mix of mode) or into/out of storage. Deliverable 5.1 Page A4.15

133 The types of transport centre vary, but they range from one company on a single user site to a number of different companies on a mulit-user site. Within the context of it is the storage and distribution function that is relevant. Figure A4.11: Inventory information data model - Context diagram P.6 Transport Centre Operator IF.7 F.11 Storage / distribution process IF.54 F.19 Transhipment process IF.50 IF.2 IF.49 P.3. Carrier / fleet manager P.7 Consignee P.1 Consignor IF.8 F.1 Transport Order Issuing F.2 Shipment progress control Figure A4.12: Inventory information data model IF.54 INT F.11.1 Order Information IF.49 P.7 Consignee F.11.2 Order Despatching INT INT INT INT Re-usable equipment IF.50 INT F.11.3 Order Confirmation INT Inventory INT IF.8 IF.2 P.6 Transport Centre Operator F.11.4 Replenishment Information IF.7 P.1 Consignor P3. Carrier / Fleet management Deliverable 5.1 Page A4.16

134 5 Information Flows in ICT Interfaces The list of information flows within the ICT interfaces is summarised as follows: Information Flow IDS fuel price AS24 fuel price AS24 Final price IDS final price Fuel Choice Driver instructions Comms data Inventory Description The price list of fuel supplied by IDS The price list of fuel supplied by AS24 The computed final price for AS24 based on discounts and VAT refunds etc The computed final price for IDS based on discounts and VAT refunds etc The final choice of fuel station decided by ICT Manager Instructions sent to ICT drivers Communications protocol used by Enigma systems Manufacturers Parts inventory 6 Data Storage and Object Modelling This section presents the data storage and methods used by the object models at ICT. Data storage Customer Fuel database Fuel choice Inventory database Description The customers for ICT, Genesis, and Brakes India Fuel price list as received at ICT from all the fuel card companies The name location of the final choice made by the ICT duty Manager and sent to the ICT driver Parts inventory as processed by ICT 6.1 Data storage in Inventory Interface The detailed description including the fields for the Inventory Interface is described here: Inventory Batch Number (referred to as invoice number) Part Number Quantity in stock Customer name (ID Number) Call quantity - quantity requested by customer Delivery dates of call qty Qty delivered Deliverable 5.1 Page A4.17

135 6.2 Storage in Fuel Interface: AS24 Data Format Local Price net of VAT DISCOUNT VAT recovery (%) VAT recovery costs (per litre) Cost price (local currency) Cost price in Exchange rate 6.3 Storage in Fuel Interface: IDS Data Format ICT Vehicle vehicle number Registration number vehicle type cost centre code vehicle/trailer ID charter ID reefer ID technical information (trip) time used (trip) kms driven ICT Driver driver number name Licenses cost centre code salary information (trip) time worked (trip) activities worked (trip) expenses made 6.4 Other IDS Fuel Objects The following is a summary of the data that IDS [1] believe should be available to Trucking Organisations and Drivers, to enable them to best select their route. It was considered that the customers need extra information over and above the price, for their decision on which sites to utilise. (The price being assessed as the 4 th on the clients list of concerns) The sort of information that might impact on their decision would be in the area of:- Added value; Cost savings (including Net of Vat Invoicing); Information Provision (eg Transactions) Accuracy of the price information; General desire to do business with certain organisations. The information then falls into two categories. Needed by the driver, for the driver specific reasons, on the road; Weighting by Customer Head office. This would need to be held in their own system, maintained by them, to contain their perceived value associated with dealing with particular organisations, in particular countries. They might best translate this into a financial value per litre. We would see that the information would best be held at a central location, from which the registered customers could access the information, though they could access each of the vendors in turn to pick up the data. Deliverable 5.1 Page A4.18

136 Relatively static information (Updated Daily, Despatched Daily) Site ID and Name. This may be the site number of the card issuer, with the country identified by the IIN/ISO number of the national organisation operating the site. This may also have associated a central registry site number, which enables the multiple vendors on a physical site to be grouped; Site Location, GPS Position Ref, Grid Ref. Post Code are all options; Facilities available: WC; Shower; Beverages; Snacks; Meals; Shop; Hotel; Telephone; Fax; Electronic/Internet Connection; Truck Wash; Service; Spares; Parking. Standard Opening Hours; Standard Product Availability: Derv; Gas Oil/Red Diesel; Lubricants. Link To Back-up site information. Routine Variable Information (Updated Occasionally, Despatched Day of Change) Price Info: Site No; Product; Effective; Date/Time; Price; Currency; VAT Percentage. Exceptional Variable Info (Updated when Known, Despatched Immediately) Site Closure: Site; Date/Time to Date/Time. Product/Service Unavailability: Site; Product/Service; Date/Time to Date/Time. Exchange rates and even prices can change dependant on the contract. Therefore replacement information will need to be sent after formal invoicing. Despatch sequence numbers are extremely useful for allowing receiving organisations to check the completeness of the data they have loaded. This allows them to investigate the possible reasons for the apparent incompleteness. (Such as not received, not loaded, incomplete batches, and dozens more) Deliverable 5.1 Page A4.19

137 6.5 Transactions in IDS The following data layouts are in use by all the organisations providing transactions to KPGB for IDS and our retail card system. The layout and content have served the company well for many years. 6.6 Transaction file The following information will be required for loading into their database. The file to be a flat ASCII variable format file with each field followed by a pipe character, and each transaction terminated by <CR><LF>. The separator to appear even if no data appears for a field. Leading zeros can be suppressed on numeric fields, but not on character fields holding numbers. The file identity should be "DTXXmmdd.eee", where XX is the organisation code, dd and mm are the day and month that the file was created, and eee the uniqueness of multiple files in a day. 6.7 Transaction File Layout - Outlet Location - Issuer ID - Customer Acc. No. - Card No. - Date: DDMMYY - Time: HHMMSS - Transaction Code - Product (diesel, kerosine, gasoline, lubricant, other) - Mileage (km) - Truck No. - Pump No. - Transaction No. - Batch Sequence No*} - Transmission Date - Update tr sequence Storage in Inventory Interface The inventory is the aim for BI, Genesis, and customers. Inventory Batch Number (referred to as invoice number) Part Number Quantity in stock Customer name (ID Number) Call quantity - quantity requested by customer Delivery dates of call qty Qty delivered Replenishment information from BI Batch Number (referred to as invoice number) Part Number Deliverable 5.1 Page A4.20

138 Quantity being shipped Delivery date 7 Methods and Dynamic Interactions The diagrams in Figures A4.9-A4.13 depict the time dynamics between the parties/objects within the interfaces F1-F4. The methods will be specified as the detailed processes. 7.1 Interactions in F1-Generic FTP Interface Not yet specified. 7.2 Interactions in F2- Mobile Comms Interface Figure A4.13: Dynamic Modelling of F3-Mobile Communication Interface ICT Communication Object Enigma Send permanent data Dispatch permanent data receive fuel price data Dispatch fuel data Consult Tracking Information Send Tracking information Send Tracking information Time Interactions in F3-Fuel Interface Figure A4.14: Dynamic Modelling of F2-Fuel Interface Deliverable 5.1 Page A4.21

139 Fuel Co ICT Fuel Object receive fuel price data process fuel price data Secure fuel price data store fuel data in a trace/log file compare final fuel prices Time Deliverable 5.1 Page A4.22

140 7.2.2 Interactions in F4-Inventory Interface Figure A4.15: Dynamic Modelling of F4-Inventory Interface Genesis/ BI Blackwood Customer Inventory Object Receive Inventory Process Inventory Secure inventory Store inventory Send inventory Time Requestinventory Send Inventory 8 Proposed Implementation Plans Windows NT will be used as development platform and the application software will operate in this environment. Data file structures will be in DBF, multi-user and multi-tasking. External communications will be via FTP. FTP would seem most appropriate given information already located on or picked up by a web server. BWC will accept a file in any format and restructure it as necessary. There is heavy traffic on the Internet access from Bombay. Instead a special arrangement has been proposed to use a dedicated telephone line using a special satellite link. The communications software applications to be used at ICT will be one of the following: EDI, Internet, mobile communications. A warehouse / inventory management system will be employed. The concerns of customers are: To know WHERE the product is; To know what the current level is. There will be a database for each interface living on the FTP server. Each of the customers will need data that can be uploaded from the FTP server. The customer can access only their own data. An encryption software might therefore be employed in order to encrypt at source and decrypt on receipt. For simplicity, only minimal functionality and direct communications link will be employed as only a limited number of customers will be involved. BWC will write a software programme to produce a stock/pallet control system on Windows environment. BWC will output: Stock reports, picking lists, Delivery notes, Stock audit forms. Deliverable 5.1 Page A4.23

141 9 Conclusions This document has used the user requirements document to produce logical functional specification for the test specific sites. Specific details have not been described however the functional specification document has achieved the following descriptions: processes in the functions; data and their relationships; inputs needed; outputs generated; Interfaces to other interface functions. Deliverable 5.1 Page A4.24

142 Annex A5 Patinter Deliverable 5.1

143 A5 Functional specification at Patinter (PT) Introduction This document describes the functional, dynamic and object modelling for the interfaces to be implemented in Patinter. To completely understand this document please consult the framework and the annex concerning Patinter's site in the deliverable 3.1. Functional modelling Context Diagram 1 The diagram describes Patinter's architecture and the relations between the main existent systems. Figure A5.1: Context Diagram VEHICLE Telecom service BASE (Patinter) Consignor Forwarder Consignee Positionning system On board communication system + Data processing system Base communication management system Internet Browser Assignment and order management software Interfaces to be implemented during Principal Information System 1 For more details see deliverable 3.1 Deliverable 5.1 Page A5.1

144 Context diagram mapped to Framework (using Patinter's global data flow diagram) 2 The figure below is the data flow diagram that describes the current situation in the test site of Patinter. The interfaces marked in red will be implemented during the project. The description of the functions and information flows can be found in the framework. Figure A5.2: Patinter data flow diagram and planed interfaces (circled). P.1 Consignor P.2 Forwarder P.7 Consignee IF.3 F.1 Transport Order Issuing F.12 Shipment Progress Control Interface 2 IF.1,IF.2 IF 38 P3 Carrier / Fleet manager Interface 3 IF.4, IF.26 IF.5, IF.28 F.3 Order Planning & Execution IF 37 F.17 Cost Analysis F.16 Invoicing IF.6, IF.14 IF.15 Interface 1 F. 5 Dynamic Dispatching Process IF43 IF.42 F.7 Fleet/Vehicle Monitoring IF.23 IF. 35 IF.13 IF. 20 P. 8 Vehicle P.4 Driver IF. 36 F.14 Remote Vehicle & Cargo Reporting IF.48 IF.31 IF.18 F.8 Trip/Tour Execution F.9 Trip/Tour Control 2 For more details consult deliverable 3.1 Deliverable 5.1 Page A5.2

145 First Level Data Flow Diagram (Concerning the areas to be implemented during ) Figure A5.3: First level data flow diagram Base communication management system (FrotCom) F.3 Interface Frotcom - Web server F.1 Interface Quasar-Frotcom Web Server Internet Browser Assignment and order management software (Quasar) F.2 Interface Quasar - Web Server Brief description about the current systems (QUASAR, FROTCOM) - QUASAR This application developed by Quadriga is used in freight assignment and fleet operational management. It helps organising fleet status, freights in course or pending and reports. - FROTCOM This other application, also developed by Quadriga, is used to exchange written messages with the drivers and to monitor the vehicles positions. The interfaces intend to automate some operations related to: - sharing information with customers; - sharing information between the two applications. Deliverable 5.1 Page A5.3

146 Second Level data flow This section describes the sub-functions and information flows internal to the main functions referred in the first level data flow. Interface Quasar-Frotcom (F.1) Interface Quasar-Frotcom diagram Figure A5.4: Interface Quasar-Frotcom diagram Quasar database Associations control (Terminal - Vehicle ) Last known Position Positions Interface Terminal ID Association (Terminal ID <-> Vehicle ID) Positions Vehicle ID Freight Information + Vehicle ID Automatic messages control (Freight Information - Origin/Destination ) Association (Terminal ID <-> Vehicle ID) Freight details Message (from base to vehicle) Association (Terminal ID <-> Vehicle ID) Frotcom database Sub-functions description: Function: Associations control (Terminal Vehicle ) Description: Controls the association between vehicles (information used by QUASAR) and terminals (information used by FROTCOM to identify the in-vehicle mobile data terminal) Input: Vehicle ID Terminal ID Output: Association (1 vehicle 1 terminal) Deliverable 5.1 Page A5.4

147 Function: Description: Input: Output: Positions interface Updates periodically the QUASAR vehicle position field with the last known position received by FROTCOM. So when a QUASAR user consults the information concerning a vehicle also knows its last position. Positions details Association (1 vehicle 1 terminal) Vehicle's last known position Function: Description: Input: Output: Automatic messages control Creates a specific cargo message using the next freight information and sends it to the vehicle terminal using FROTCOM. Freight Information + Vehicle ID Association (1 vehicle 1 terminal) Freight details message (origin, destination, time schedule, etc.) Information flows description: Information flow: From: To: Information: Information flow: From: To: Information: Information flow: From: To: Information: Vehicle ID QUASAR database Associations control Vehicle ID (License plate) Terminal ID FROTCOM database Associations control Terminal identity (telephone or transceiver number) Association (Terminal ID Vehicle ID) Associations control FROTCOM database FROTCOM database Positions interface Automatic messages control Terminal details with associated vehicle ID Information flow: From: To: Information: Information flow: From: To: Information: Information flow: From: To: Positions FROTCOM database Positions interface Position details (lat., long., timestamp, text information) Terminal ID Last known position Positions interface QUASAR database Position details (lat., long., timestamp, text information) Vehicle ID Freight information + vehicle ID QUASAR database Automatic messages control Deliverable 5.1 Page A5.5

148 Information: Information flow: From: To: Information: Origin, destination, time schedule, client ID, Vehicle ID Freight details message Automatic messages control FROTCOM database Text message containing freight details Terminal ID Mapping to Generic Architecture. Figure A5.5 Interface QUASAR-FROTCOM mapped to framework P3 Carrier / Fleet manager Quasar IF.6, IF.14 IF.15 Frotcom F. 5 Dynamic Dispatching Process IF43 IF.42 F.7 Fleet/Vehicle Monitoring Deliverable 5.1 Page A5.6

149 Interface Quasar Web Server (F.2) Figure A5.6: Interface Quasar Web Server (F.2) diagram Quasar database Current freight details Freight status control Client details & Profiles Client profile management Web - C.G.I (Quasar-Interface) New freight details Freight status and Details New freight details Common Interest Places Freight Status and Details New freight details Client details Client details & Profiles Freight Status and Details New freight details Client Identification Temporary freights database Sub-functions description: Function: Description: Input: Output: Function: Description: Input: Output: Freight status control Checks the freight details from QUASAR database and according to detail changes, decides which is the current freight status (accepted, refused waiting, etc.); Interfaces with QUASAR database to update and translate the new coming freight proposals to QUASAR's format. New freight details Current freight details New freight details Freight status and details Users profile management Defines or alters the rights or privileges of each client. (consult freight information only or allow new freight request) Client details Client details & profiles Deliverable 5.1 Page A5.7

150 Function: Description: Input: Output: Web - C.G.I (Quasar Interface) Verifies and gives permissions to clients; Transforms the freight details and status into HTML; Receives and stores the new freight proposal presented by customer after translating it from HTML. New freight details Freight status and details Common interest places Client identification Client details & Profile New freight details Freight status and details Information flows description: Information flow: From: To: Information: New freight details External client Web- C.G.I. Temporary freights database Freight status control Web- C.G.I. Temporary freights database Freight status control QUASAR database Origin, destination, time schedule, client ID. Information flow: From: To: Information: Client identification External client Web- C.G.I. Username, password, Client ID. Information flow: From: To: Information: Information flow: From: To: Information: Information flow: From: To: Information: Freight status and details Web- C.G.I. Temporary freights database Freight status control External client Web- C.G.I. Temporary freights database Origin, destination, time schedule, client ID. Freight status (accepted, refused, waiting) Client details QUASAR database Client profile management Client ID, name, phone number, Client details & Profiles Client profile management QUASAR database QUASAR database Web C.G.I. Client ID, name, phone number, Username, password, permissions Deliverable 5.1 Page A5.8

151 Information flow: From: To: Information: Common interest places QUASAR database Web C.G.I. Web C.G.I. QUASAR database Place ID, name, latitude, longitude. Mapping to Generic Architecture. Figure A5.7: Interface QUASAR-WEB SERVER mapped to framework P.1 Consignor P.2 Forwarder P.7 Consignee F.1 Transport Order Issuing Web Server & Internet Browser IF.3 IF.1,IF.2 P3 Carrier / Fleet manager Quasar F.3 Order Planning & Execution Deliverable 5.1 Page A5.9

152 Interface Frotcom Web Server (F.3) Figure A5.8: Interface Frotcom Web Server Diagram (F.3) User profiles and temporary freights Database Freigth Status and details Client details & Profiles Client-terminal association control Terminal ID & Vehicle ID Frotcom database Terminal ID & Vehicle ID Positions Requests Positions Client details & Profiles Web - C.G.I (Frotcom Interface) Association (Client + Terminal) Client Profiles Positions Requests Positions Association (Client + Terminal) Client Identification Associations database (Terminal + Client) Sub-functions description: Function: Description: Input: Output: Client-terminal association control Controls the association between clients and terminals; Defines which vehicles the client can consult. Freight Status Client details & Profiles Terminal ID & Vehicle ID Association Client Terminal Function: Description: Input: Web - C.G.I (FROTCOM Interface) Verifies and gives permissions to clients; Organises the positions and converts them to HTML; Transforms the position requests from clients into Frotcom positions requests. Positions Positions requests Client identification Client details & Profile Deliverable 5.1 Page A5.10

153 Output: Positions (in HTML format) Positions requests Client profiles Information flows description: Information flow: From: To: Information: Information flow: From: To: Information: Information flow: From: To: Information: Information flow: From: To: Information: Association (client + terminal) Associations database (client + terminal) Client-terminal association control Associations database Web C.G.I. Terminal ID, Client Id Position requests External client Web C.G.I Web C.G.I. FROTCOM database Terminal ID Positions FROTCOM database Web C.G.I Web C.G.I. External client latitude, longitude, text describing the position and timestamp Terminal ID Terminal ID & Vehicle ID FROTCOM database Web C.G.I. Client-terminal association Terminal ID and respective vehicle ID Note: The remaining information flows descriptions are the same previously referred in F2 (Interface Quasar Web Server). Deliverable 5.1 Page A5.11

154 Mapping to Generic Architecture. Figure A5.9: Interface FROTCOM WEB SERVER mapped to framework P.1 Consignor P.2 Forwarder P.7 Consignee F.12 Shipment Progress Control Web Server & Internet Browser IF.4, IF.26 IF.5, IF.28 P3 Carrier / Fleet manager Frotcom F.7 Fleet/Vehicle Monitoring Object modelling This section describes the most important objects, their attributes and relevant methods. Freight Object Freight Freight ID Freight status Origin Destination Pick up timestamp Delivery timestamp Client ID Vehicle ID Cargo type Volume Weight Refuse freight Accept freight (Vehicle ID) Update current status Main methods description: - Refuse freight: Delete freight from QUASAR database. - Accept freight: Change Vehicle ID to new Vehicle ID. - Update current status: Change the freight status in temporary freight database to refused, accepted or waiting, depending of QUASAR database situation. Deliverable 5.1 Page A5.12

155 Terminal Object Terminal Terminal ID Terminal type Terminal communications number Specific settings Vehicle ID Request position Send text message (Text) Associate(Vehicle ID) Main methods description: - Request position: Send a request position message to terminal/vehicle. - Send text messages (Text): Send specific text to terminal/vehicle. - Associate (Vehicle ID): Define what is the vehicle where the terminal is installed. Client Object Client Client ID Name Address Tel. Fax. Username Password Permissions Max position requests Position requests count Validate Client (Username, password) Consult vehicle positions (Client ID) Consult freight status Make position Request (vehicle/terminal ID) Propose new freight Main methods description: - Validate Client (Username, password): Accept or refuse according to username and password. - Consult vehicle positions (Client Id): Find and list vehicle positions related to specific client. This method uses the associations database to know which are the vehicles related to this specific client. - Consult freights status (Client ID): Find and list freight status related to this specific client. - Make position request (vehicle/terminal ID): Verify that the client can make a position request and if so then call terminal request position method. Update the position requests count. - Propose new freight: Fill details for a new freight and put them in the temporary freight database. Deliverable 5.1 Page A5.13

156 Position Object Position Latitude Longitude Velocity Direction Timestamp Position text description Terminal ID Update text description Main methods description: - Update text description Construct a string containing the description of geographical information ( e.g. 30 KM West of Use the FROTCOM database to calculate the distance between the position and the nearest Point of Interest. Deliverable 5.1 Page A5.14

157 Dynamic modelling This section describes the dynamic modelling of the three principal functions. F1 Interface QUASAR-FROTCOM Figure A5.10: Dynamic modelling diagram Vehicle FROTCOM QUASAR Manager Time Position request Position Terminal ID Vehicle ID & Terminal ID association Last known Position Freight information & Vehicle ID Freight details Message Freight details Message Deliverable 5.1 Page A5.15

158 F2 Interface QUASAR-WEB Server Figure A5.11: Dynamic modelling diagram Client Web - server QUASAR Manager Client Identification Client Identification Client details & profile Time Client permission new freight details new freight details new freight details change freight details Freight details & Status Freight details & Status Deliverable 5.1 Page A5.16

159 F2 Interface FROTCOM-WEB Server Figure A5.12: Dynamic modelling diagram Client Web - server FROTCOM Vehicle Client Identification Client Identification Client details & profile Time Client permission Positions requests Client Profiles Positions requests Positions requests Positions Positions Positions Deliverable 5.1 Page A5.17

160 Annex A6 Jan de Rijk Deliverable 5.1

161 A6 Functional specification at Jan de Rijk (NL) 1 Introduction This document describes the functional specification for demonstrator Jan de Rijk Roosendaal (NL). The specification contains a context diagram, an extended explanation of the dataflows diagrams (DFD), an overview of the dynamic interactionflow of information and a brief description of the methods referring to the datastores. The scope of the description is directly related to the general framework and the document produced in WP3. 2 Context diagram This diagram illustrates the context of the interfaces at Jan de Rijk based on the User Requirements. Figure A6.1: Context Diagram of Interfaces to be built for Jan de Rijk Fleet Management System Black-Box Communication System IF.C IF.D Jan de Rijk IF.B IF.A Chainware Quotations module Chainware Transport module The information processes A, B, C and D are basic interactions between Jan de Rijk and the software functions, included in the project. The explanation per interaction is : IF.A IF.B IF.C IF.D Interchains Chainware central administrative transport system to/from Jan de Rijk Interchains Chainware central administrative quotations system to/from Jan de Rijk fleet management data from/to FMS to/from Jan de Rijk black-box communication from BBS to Jan de Rijk Deliverable 5.1 Page A6.1

162 3 Data Flow Diagram (level 2) 3.1 DFD model The Data Flow Diagram (DFD) describes the relation between functions and data storage. The DFD is based on the general framework and a sub-set of the generic functional specification. Figure A6.2 : DFD (part 1) of interfaces to be built for Jan de Rijk P.1 Consignor P.2 Forwarder P.7 Shipper/Consignee F.1.1 Consignor IF.2 IF.3 F.3.1 Order entry F.4.2 Order Information F.12.1 Shipper/ Consignee F.1.2 Freightpayer Orders F.4.3 Reusable Equipment IF.49 F.12.2 (Un)Loading address Reusable equipment F.16 Invoicing Orderstatus F.4.1 Order Tracking F.3.2 Order dispatching IF.48 P.3 Carrier / Fleet Manager Deliverable 5.1 Page A6.2

163 Figure A6.3 : DFD (part 2) of interfaces to be built for Jan de Rijk P.2 Forwarder IF.9 IF.14 IF.15 IF.48 P.3 Carrier / Fleet Manager F.5.2 Cargo Information Accepted Orders F.5.1 Order Acceptance F.17.4 Invoicing Trip/Cargo status F.6.1 Trip Planning F.17.1 Precalculation F.17.2 Postcalculation Trips Vehicles / Drivers F.7.1 Fleet / Vehicle Monitoring F.7.2 Cargo Monitoring F.6.2 Transport Planning F.17.3 Tripdata Processing IF.31 IF.16 IF.22 IF.20 IF.19 IF.35.1 P.8 Vehicle P.4 Driver IF.35.2 Deliverable 5.1 Page A6.3

164 3.2 DFD Parties P.1 Consignor The consignor is the party that issues the instruction to transport a shipment. The consignor can be subdivided into the issuing function and the paying function. The freight payer can be the same as the consignor but the payer function can also coincide with the consignee. P.2 Forwarder The forwarder is the party that does the account management to the consignor. In many cases the forwarder has signed a contract with a transport obligation. For these clients the forwarder searches a carrier that can transport the shipment. P.3 Carrier/Fleet manager The carrier has two main functions: grouping shipments into trips and assigning trailers, trucks and drivers to the trips. This last function can be outsourced to another party. So ideally the P.3 party should be subdivided into a grouping partner and a transporting partner. In case of the specific projects there is no direct need to divide P.3 in two separate parts. P.4 Driver The driver communicates via the boardcomputer either via Mobile Data Communication or via the data cartridge. The driver is considered external to the system. P.7 Shipper/Consignee The shipper is the party that controls the pick-up of the shipment. The consignee is the party that controls the delivery of the shipment. The loading address is the address where the goods are to be picked up. The unloading address is where the goods are to be delivered. Consignor and shipper or consignor and consignee can coincide. Also shipper and loading address and consignee and unloading address can coincide. P.8 Vehicle and Cargo All functions of the vehicle and cargo that are controlled and/or reported automatically via the boardcomputer reside in this party. The vehicle /cargo is considered external to the system. Deliverable 5.1 Page A6.4

165 3.3 DFD functions The DFD is an abstract model of the general framework. Only the most relevant functions for Jan de Rijk are included in the model. The first number of the sub-functions refers to the main function of the general model. The list below has been split up according to the schemes part 1 and part 2. part party funct. meaning -1 - P.1 F.1.1 Consignor F.1.2 Freight payer P.2 F.3.1 Order entry F.3.2 Order dispatching F.4.1 Order tracking F.4.2 Order information F.4.3 Reusable equipment P.7 F.12.1 Shipper/consignee F.12.2 Loading/Unloading address F.16 Invoicing P.3 F.5.1 Order Acceptance F.5.2 Cargo Information F.6.1 Trip Planning F.6.2 Transport Planning F.17.1 Precalculation F.17.2 Postcalculation F.17.3 Tripdata Processing F.17.4 Invoicing The description, input and output for each sub-function is as follows: F.1.1 description input output Consignor the initialisation of the consignment, where the principal contacts the forwarder in case of quotations or transport bookings - booking confirmation (refusal) - order information - request for transport information - request for quotations - freight charges - transport booking F.1.2 description input output Freight payer this function represents the payment process of the consignment as handled by the forwarder - invoice - order information none, not in scope of the model Deliverable 5.1 Page A6.5

166 F.3.1 description input output Order entry this function represents the handling of the quotations, the acceptance and registration of the order - request for transport information - request for quotations - transport booking - transport information - quotations - booking confirmation (refusal) - forwarding order F.3.2 description input output Order dispatching the forwarder groups his forwarding orders in a logical sequence and searches for the best transport opportunity (carrier) - forwarding order - confirmation of the carrier - transport instruction - order refusal - invoice from carrier - additional costs from carrier F.4.1 description input output Order tracking keeps track of the operational status of an order i.e. loaded, transhipped, unloaded (...) - cargo status information - order status information F.4.2 description input output Order information this is an information split-up function to all parties involved - order status information - POD information - equipment information - order status information to shipper / consignee - POD information to consignor - equipment information to shipper / consignee F.4.3 description input output Reusable equipment registration and control of all reusable equipment used, i.e. pallets, crates, boxes (...) - equipment data related to the execution of the trip - equipment data mentioned for (un)loading activities Deliverable 5.1 Page A6.6

167 F.12.1 description input output Shipper/Consignee the shipper is the sender of the goods, the consignee the receiver; both parties can differ from the loading and unloading addresses - order status information to shipper / consignee - equipment information to shipper / consignee none, not in scope of the model F.12.2 description input output Loading/unloading address where the goods are physically loaded and unloaded; the reusable equipment is directly related to the cargo flow - equipment data mentioned for (un)loading activities none, not in scope of the model F.16 Invoicing description contains the complete sales invoice procedure of the forwarding orders and creates the actual invoices input - order status information - POD documents - equipment data mentioned for (un)loading activities output none, not in scope of the model F.5.1 description input output Order Acceptance at this point the forwarding department of the carrier evaluates the order sent by the forwarder, and accepts or refuses the order - transport instruction by the forwarder - transport information - an accepted order by the carrier F.5.2 description input output Cargo Information the cargo information represents the condition of the goods in the vehicle during the execution of the trip and the status of the reusable equipment - status information concerning the vehicle - status information concerning the cargo - cargo status information - information about the possible groupage of goods (trip planning) - information about the (economic) availability of the vehicle F.6.1 description input output Trip Planning the tripplanning process contains the groupage of consignments into trips, without (officially) knowing what material or resources are involved - new consignments, accepted by the forwarding dept of the carrier - current trip status for extra groupage of new consignments - trip information - trip result information Deliverable 5.1 Page A6.7

168 F.6.2 description input output Transport Planning this function assigns material and resources to a trip; both can be internal or external chartering - trip information - trip status information - consignment information - availability of resources and material - (un)loading orders to driver - planning information (driver/vehicle related to trip) - allocating availability of resources and material F.17.1 description input output Precalculation calculating costs and charges on the trip bases on estimated figures - trip data - pre-calculated charges - consignment based - pre-calculated costs - price per hour (drivers) - price per km (vehicles) - chartering - pre-calculated trip result F.17.2 description input output Postcalculation calculating costs and charges on the trip based on actual figures - (modified) trip data - postcalculated charges - consignment based (invoiced consignments) - postcalculated costs - price per hour (drivers) - price per km (vehicles) - chartering - post-calculated trip result F.17.3 description input output Tripdata processing (black-box) information from the driver and the vehicle is processed into the organisation and related to the trips planned - drivers information (hours, expenses) - cargo information (goods, equipment) - vehicle information (fuel, kms) - (trip) driver data - (trip) vehicle data - (trip) equipment data Deliverable 5.1 Page A6.8

169 F.17.4 description input output Invoicing invoicing of carrier activities and extra expenses to the forwarder; in case of one company this often is called internal invoicing - trip data - (internal) invoice - extra expenses 3.4 DFD data storage The data storage defined is a abstract logical modelling of the Chainware database. The next logical storage s are included in the model. data storage Orders Reusable equipment Orderstatus Trip/Cargo status Accepted Orders Trips Vehicle/Drivers contents all consignments accepted by the forwarder reusable equipment used in transport process status of the consignment status of the trip and cargo all consignments accepted by the carrier all trips to be executed by the carrier availability and data of resources and materials Below is a description for each type of data storage of the fields that are currently being supported by Chainware. Orders consignment number departmentcode handlingcode operational period employee (adm) principal reference loading date/time unloading date/time shipper loading place consignee unloading place agent customs data COD id goods information - marks and numbers - quantity - type of package - commodity - gross weight Deliverable 5.1 Page A6.9

170 - nett weight - cubic meters - loading meters - volume weight - dimensions - goods value cost and charges - activity - purchase / sales ID - relation (debtor/creditor) - currency - exchange rate - tariff - amount in [curr] - invoice information - financial period - reference accounting system - status code transport instructions trip reference documents - type of document - date created - document number - way printed (EDI/printer) - status code tracking and tracing free descriptions reusable equipment status code Reusable equipment consignment number trip number date quantity type of package type of logistic address (code) logistic address quality code status code Orderstatus consignment number date/time place tracking and tracing code description status code Accepted Orders same as orders Deliverable 5.1 Page A6.10

171 Trip/Cargo status trip number date/time place tracking and tracing code description status code Trips trip number departmentcode handlingcode operational period employee (owner) place of departure place of destination date/time of departure date/time of arrival vehicle code trailer code equipment code driver 1 code driver 2 code charter consignments planned cost and charges - activity - purchase / sales ID - relation (debtor/creditor) - currency - exchange rate - tariff - amount in [curr] - invoice information - financial period - reference accounting system - status code documents - type of document - date created - document number - way printed (EDI/printer) - status code tracking and tracing reusable equipment status code Deliverable 5.1 Page A6.11

172 Vehicle vehicle number registration number vehicle type cost centre code vehicle/trailer ID charter ID reefer ID technical information (trip) time used (trip) kms driven (trip) fuel used Driver driver number name licenses cost centre code salary information (trip) time worked (trip) activities worked (trip) expenses made 3.5 DFD Information Flows The different information processes can be described as follows: IF IF.14 IF.15 IF.16 IF.19 IF.20 IF.31 IF IF.35.1 IF.35.2 IF.48 IF.49 IF IF.2 IF.3 FMS system On-line Pick-up information Pick-Up order confirmation of refusal Activity Report & reusable equipment Trip alteration Daily Delivery Plan (Loading/Unloading orders) Vehicle / Cargo information (Location information) BBS system Expenses, Time Report, Fuel Report, Reusable equipment Km s Reusable equipment information Overview Reusable Equipment Quotations Transport Instruction Instruction Confirmation The origin, destination and contents for each informationflows is as follows: The EDI indication that is stated behind some of the descriptions, refers to the numbering of the messages within the EDI project, as described in the User Requirements. IF.14 from to information On-line Pick-up information order dispatching order acceptance - order information - transport instruction IF.15 from to information Pick-Up order confirmation or refusal order acceptance order dispatching - acceptance of the order - freight charges - refusal Deliverable 5.1 Page A6.12

173 IF.16 from to information IF.19 from to information IF.20 from to information IF.31 from to information IF.35.1 from to information IF.35.2 from to information Activity Report & reusable equipment driver cargo monitoring - cargo condition - cargo status - reusable equipment - drivers information Trip alteration transport planning driver - order information - tripplanning (times, places, routes... ) - cargo - reusable equipment Daily Delivery Plan (Loading/Unloading orders) transport planning driver - order information - tripplanning (times, places, routes... ) - cargo - reusable equipment Vehicle / Cargo information (Location information) vehicle fleet vehicle monitoring - location of the vehicle - technical vehicle information Expenses, Time Report, Fuel Report, Reusable equipment driver trip data processing - hours worked (time sheet) - expenses made - equipment - cargo information Km s vehicle trip data processing - km s driven - fuel used - technical vehicle information IF.48 from to information Reusable equipment information tripdata processing reusable equipment - number of packages - types of packages - condition - POD Deliverable 5.1 Page A6.13

174 IF.49 from to information IF.2 from to information IF.3 from to information Overview Reusable Equipment reusable equipment loading / unloading address - statistic information Transport Instruction consignor order entry - request for transport information - request for quotations - freight charges - transport booking Instruction Confirmation order entry consignor - transport information - quotations - transport booking confirmation - transport booking refusal 4 Dynamic interactions 4.1 Interactions FMS interface Figure A6.4 : Dynamic Modelling of FMS interface P.2 Forwarder P.3 Carrier P.4 Driver & P.8 Vehicle IF.15 T I M E IF.9 Deliverable 5.1 Page A6.14

175 IF IF.14 IF.15 IF.20 IF.19 IF.16 IF.31 IF.9 Meaning On-line Pick-up information Pick-Up order confirmation of refusal Daily Delivery Plan (Loading/Unloading orders) Trip Alteration Activity Report + reusable equipment Vehicle / Cargo information (Location information) (On-line) order progress report 4.2 Interactions Black-Box System interface Figure A6.5 : Dynamic Modelling of BBC interface P.7 (Un) Loading address P.2 Forwarder P.3 Carrier P.4 Driver & P.8 Vehicle IF.48 IF.35.1 IF.35.2 T I M E IF.49 IF IF.35.1 IF.35.2 IF.48 IF.49 Meaning Expenses, Time Report, Fuel Report, Reusable equipment Km s Reusable equipment information Overview Reusable Equipment 4.3 Interactions Quotations interface Figure A6.6 : Dynamic Modelling of Quotations Interface P.1 Consignor P.2 Forwarder IF.2 IF.3 T I M E Deliverable 5.1 Page A6.15

176 IF IF.2 IF.3 Meaning Transport Instruction Instruction Confirmation 5 Methods data storage Orders Reusable equipment Orderstatus Trip/Cargo status Accepted Orders Trips Vehicle/Drivers contents all consignments accepted by the forwarder reusable equipment used in transport process status of the consignment status of the trip and cargo all consignments accepted by the carrier all trips to be executed by the carrier availability and data of resources and materials The datastores are influenced by the following software routines : Orders entering and maintaining general consignment data entering and maintaining costs and charges entering and maintaining transport instructions entering and maintaining documents entering and maintaining goods data entering and maintaining trip data entering and maintaining tracking and tracing per order entering and maintaining free descriptions entering and maintaining reusable equipment (order level) processing status Reusable equipment entering and maintaining reusable equipment (order level) entering and maintaining reusable equipment (trip level) Orderstatus processing (trip and order level) entering and maintaining status (trip and order level) Trip/Cargo status processing (trip and order level) entering and maintaining status (trip and order level) Accepted orders same as Orders Deliverable 5.1 Page A6.16

177 Trips entering and maintaining general trip data entering and maintaining costs and charges entering and maintaining documents entering and maintaining consignment planning entering and maintaining tracking and tracing per trip processing tracking and tracing per order entering and maintaining reusable equipment (trip level) processing tripresults processing status Vehicle/Drivers entering and maintaining available drivers entering and maintaining available vehicles entering and maintaining time sheet drivers, expenses entering and maintaining kms, fuel Deliverable 5.1 Page A6.17

178 Annex A7 C. van Heezik Deliverable 5.1

179 A7 Test Site Report: Van Heezik (NL) Introduction This document describes the functional specification for the user requirements that have been laid down in the User Requirements report. The project at the test site C. van Heezik focuses on two major points: 1. integrated Electronic Data Interchange (EDI) with external parties; 2. implementation and integration of a Fleet and Cargo Management System (FMCS). These two subprojects share the same goals: equip the dispatchers with tools that enable them to monitor the fleet and the status of the consignments on their desktop without having to make phone calls to subcontractors and/or drivers. This will give them the information and the time to inform their clients pro actively on the status of a shipment. The FMCS also will support them in increasing the efficiency and quality of the planning. The result aimed at is to improve the relations with the clients and to raise the transport efficiency. The two subprojects have some interfaces in common. A transportation company has many relations with subcontractors. In order to have a good load balance on the transport means, the shipments or trips are either outsourced to a subcontractor or processed by an internal department. In the case of outsourcing the external parties will be linked to the forwarder systems (Interchain) via an EDI interface. In the case of processing by an internal department the forwarder systems (Interchain) will be linked directly to the carrier systems (FMCS). The interface between the sub-systems then is implicit and is effectuated by means of synchronising the databases of the subsystems. Context diagram This diagram illustrates the context of the interfaces at Van Heezik based on the User Requirements. Figure A7.1: Context diagram EDI Operations IDScustomers and carriers Fleet & Cargo Management System Trip planning Route planning Customers Infodis Chainware Carriers Datacartridge management Deliverable 5.1 Page A7.1

180 Data Flow Diagram DFD model The Data Flow Diagram (DFD) describes the relation between functions and data storage. The DFD is based on the general framework and presents the second level DFD for C. van Heezik. Figure A7.2: DFD (part 1) of interfaces to be built for Van Heezik P.1 Consignor P.2 Forwarder P.7 Shipper/Consignee F.1.1 Consignment initiation F.1.2 Freight payment handling IF.2 IF.3 IF.38.1 F.3.1 Order entry IF.50 Orders F.4.2 Order Information F.4.3 Reusable Equipment Registration IF.5 IF.49 F.12.1 Shipping/ Receiving Consignment F.12.2 Loading/Unloading goods IF.38.2 Reusable equipment F.16 Invoicing Orderstatus F.4.1 Order Tracking F.3.2 Order dispatching IF.9 IF. 51 IF.14 IF.15 IF.52 IF.53 IF.48 P.3 Carrier / Fleet Manager Deliverable 5.1 Page A7.2

181 Figure A7.3: DFD (part 2) of interfaces to be built for Van Heezik P.2 Forwarder IF.9 IF.51 IF.14 IF.15 IF.52 IF.53 IF.48 P.3 Carrier / Fleet Manager F.5.2 Cargo Information Accepted Orders F.5.1 Order Acceptance F.17.4 Invoicing Trip/Cargo status F.6.1 Trip Planning F.17.1 Precalculation F.17.2 Postcalculation Trips Vehicles / Drivers F.7.1 Vehicle / Cargo Monitoring F.7.2 Shipment Monitoring F.6.2 Transport Planning F.17.3 Tripdata Processing IF.13 IF.31 IF.16 IF.19 P.8 Vehicle P.4 Driver IF.35.1 IF.35.2 DFD parties At C. van Heezik the following parties can be distinguished: P.1 Consignor The consignor is the party that issues the instruction to transport a shipment. The consignor can be subdivided into the issuing function and the paying function. The freight payer can be the same as the consignor but the payer function can also coincide with the consignee. P.2 Forwarder The forwarder is the party that does the account management to the consignor. In many cases the forwarder has signed a contract with a transport obligation. For these clients the forwarder searches a carrier who can transport the shipment. P.3 Carrier/Fleet manager The carrier has two main functions: grouping shipments into trips and assigning trailers, trucks and drivers to the trips. This last function can be outsourced to another party. So ideally the P.3 party should be subdivided into a grouping partner and a Deliverable 5.1 Page A7.3

182 transporting partner. However the Fleet and Cargo Management System that Van Heezik wants to install covers both functions. So for the Intact-project we will not subdivide this party. P.4 Driver The driver communicates via the boardcomputer either via Mobile Data Communication or via the data cartridge. The driver is considered external to the system. P.6 Transport Center Operator Not considered. P.7 Shipper/Consignee The shipper is the party that controls the pick-up of the shipment. The Consignee is the party that controls the delivery of the shipment. The loading address is the address where the goods are to be picked up. The unloading address is where the goods are to be delivered. Consignor and shipper or consignor and consignee can coincide. Also shipper and loading address and consignee and unloading address can coincide. P.8 Vehicle and Cargo All functions of the vehicle and cargo that are controlled and/or reported automatically via the boardcomputer reside in this party. The vehicle /cargo is considered external to the system. Functions The DFD for C. van Heezik is an abstract of the general framework. Only the most relevant functions (or processes) for Van Heezik are included in the model. The first number of the sub-functions refers to the main function of the general model. The list below has been split up according to the schemes part 1 and part 2. Part party funct. subfunc. Meaning -1 - P.1 Consignor F.1 Transport Order Issuing F.1.1 Consignment initiation F.1.2 Freight payment handling P.2 Forwarder F.3 Order Planning & Execution F.3.1 Order entry F.3.2 Order dispatching F.4 Order Control F.4.1 Order tracking F.4.2 Order information F.4.3 Reusable equipment registration P.7 Shipper/consignee F.12 Shipment Progress Control F.12.1 Shipping/receiving consignments F.12.2 Loading/Unloading goods F.16 Invoicing P.3 Carrier / Fleet Manager F.5 Operational Planning (Dispatching) F.5.1 Order Acceptance F.5.2 Cargo Information Deliverable 5.1 Page A7.4

183 F.6 Trip / Route Planning F.6.1 Trip Planning F.6.2 Transport Planning F.17 Cost & Performance Analysis F.17.1 Precalculation F.17.2 Postcalculation F.17.3 Tripdata Processing F.17.4 Invoicing The description, input and output for each sub-function is as follows: function description input output function description input output function description input output function description input output function description input output function description input output F.1.1 Consignment initiation the initialization of the consignment, where the principal orders the forwarder to transport goods - booking confirmation (refusal) - order information - request for transport information - request for quotations - transport booking F.1.2. Freight payment handling this function represents the payment handling of the consignment (freight payer is not necessarily the consignor) - invoice - payment - payment refusal F.3.1 Order entry this function represents the handling of the quotations, the acceptance and registration of the order - transport booking - order - booking confirmation (refusal) F.3.2 Order dispatching chooses a carrier (either inside or outside the company) to transport the shipment - order - confirmation or refusal of the carrier - additional costs - invoice - transport instruction - freight charge information F.4.1 Order tracking keeps track of the operational status of an order (loaded, transhipped, unloaded, etc.) - consignment status information - order status information F.4.2 Order information supplier of order information (status and/or proof of delivery) - order status information - POD information - reusable equipment information - order status information to shipper / consignee - POD information to consignor Deliverable 5.1 Page A7.5

184 function description input output function description input output function description input output function description input output function description input output function description input output function description input output F.4.3 Reusable equipment registration registration and control of all reusable equipment used, i.e. pallets, crates, boxes - reusable equipment data related to the execution of the trip - reusable equipment overview and statistics F.12.1 Shipping/Receiving consignments ships/receives the consignment and/or documents. Usually a seller/buyer relation - order status information to shipper / consignee - reusable equipment information to shipper / consignee - none F.12.2 Loading/unloading goods Loads/unloads the goods - reusable equipment data overview - none F.16 Invoicing prepares and sends the invoices for the freight charges - order status information - order information (including freight charges) - additional cost message to the consignor - invoice to the freight payer F.5.1 Order Acceptance accepts or refuses a transportation order - transport instruction by the forwarder - confirmation with freight charge or refusal F.5.2 Cargo Information provides information about the status of a shipment, the condition of the cargo and about the reusable equipment - trip status information - consignment status information - reusable equipment information F.6.1 Trip Planning groups shipments into trips or finds a best fit for a pickup shipment - accepted orders - current trip status for pickup assignments - trip information - trip result information function F.6.2 Transport Planning description assigns trucks, trailers and drivers to a trip or hires capacity from another transport operator. input - trip information - trip status information for economic availability - consignment information - technical availability of resources and material output - (un)loading orders to driver (download into boardcomputer or via MDC) - planning information (driver/vehicle related to trip) - allocating availability of resources and material function description input output F.17.1 Precalculation calculating costs before executing the trip to support the decision making process. One possibility is reporting on the marginal costs of picking up and delivering the shipment based on the calculated extra time and kilometers - pre-calculated trip data - pricing information on hours, km s and charters - freight charges - pre-calculated trip result Deliverable 5.1 Page A7.6

185 function description input output function description input output function description input output F.17.2 Post-calculation calculating costs and charges after executing the trip - real trip data - pricing information on hours, km s and charters - freight charges - post-calculated trip result F.17.3 Tripdata processing (black-box) information from the driver and the vehicle is processed and related to the trips planned - drivers information (hours, expenses) - cargo information (goods, reusable equipment) - vehicle information (fuel, km s) - (trip) driver data - (trip) vehicle data - (trip) reusable equipment data F.17.4 Invoicing invoicing of carrier activities and extra expenses to the forwarder; in the case of one company, this could be an internal invoice - trip data - (internal) invoice - extra expenses Assignment of functions to suppliers The functions in the domain P.2 Forwarder are covered by Interchain. The functions within P.3 Carrier/Fleet manager are covered by PTV with the exception of F.17.2 Postcalculation (Interchain), F.17.4 Invoicing (Interchain) and F.17.3 Tripdata Processing (MobiCoach). Data stores The data stores are an important issue in the Van Heezik project. The FMCS and Chainware products will keep their data stores synchronised. For instance whenever an order is entered in Chainware, the information is directly taken over by FMCS. And whenever a status of a consignment is changed the status is immediately taken over by Chainware. Mechanisms will have to be build to synchronise the data stores Orders, Trips, Trip/Cargo status and Vehicle/Drivers between PTV and Interchain. The following points need elaboration in the technical specification: definition of data that can be used and/or modified by the Fleet and Cargo Management System; mechanisms to control the integrity and consistency in the databases. The data storage defined is an abstract of the logical model of the Chainware database. The following data stores are included in the model. data store Orders Reusable equipment Order status Trip/Cargo status Accepted Orders Trips contents all consignments accepted by the forwarder reusable equipment used in transport process operational status of the consignment status of the trip and cargo all consignments accepted by the carrier all trips (to be) executed by the carrier Deliverable 5.1 Page A7.7

186 Vehicle/Drivers availability and data of resources and materials Below is a description of each type of data storage of the fields that currently supported by Chainware. Orders consignment number departmentcode handlingcode operational period employee (adm) principal reference loading date/time unloading date/time shipper loading place consignee unloading place agent customs data COD id goods information - marks and numbers - quantity - type of package - commodity - gross weight - nett weight - cubic meters - loading meters - volume weight 3 - dimensions - goods value cost and charges - activity - purchase / sales ID - relation (debtor/creditor) - currency - exchange rate - tariff - amount in [curr] - invoice information - financial period - reference accounting system - status code transport instructions trip reference documents - type of document - date created - document number - way printed (EDI/printer) - status code tracking and tracing Deliverable 5.1 Page A7.8

187 status code Reusable equipment consignment number date quantity type of package type of logistic address (code) logistic address quality code status code Order status consignment number date/time place tracking and tracing code description status code Trip/Cargo status trip number date/time place tracking and tracing code description status code Accepted Orders same as orders Trips trip number departmentcode handlingcode operational period employee (owner) place of departure place of destination date/time of departure date/time of arrival vehicle code trailer code equipment code driver 1 code driver 2 code charter consignments planned cost and charges - activity - purchase / sales ID - relation (debtor/creditor) Deliverable 5.1 Page A7.9

188 - currency - exchange rate - tariff - amount in [curr] - invoice information - financial period - reference accounting system - status code documents - type of document - date created - document number - way printed (EDI/printer) - status code tracking and tracing status code Vehicle vehicle number registration number vehicle type cost centre code vehicle/trailer ID charter ID reefer ID technical information (trip) time used (trip) kms driven (trip) fuel used Driver driver number name licenses cost centre code salary information (trip) time worked (trip) activities worked (trip) expenses made Information Flows The origin, destination and contents for each information flow is given below. Also the supplier who will be responsible for the construction of the interface is given. The information that is important for the demonstrator project is printed in italic. In some cases functions can reside in the same company or in different companies. When functions are external to each other the information is exchanged via EDI. When functions reside in the same company the information exchange will be an on-line process via data store synchronisation. If applicable this distinction is made clear. The EDI indication that is stated behind some of the descriptions, refers to the numbering of the messages within the EDI project, as described in the User Requirements. Interface IF.2 Transport Instruction (EDI 1) who Interchain from consignment initiation to order entry information - request for transport information - request for quotations - transport booking Deliverable 5.1 Page A7.10

189 Deliverable 5.1 Page A7.11

190 Interface IF.3 Instruction Confirmation (EDI 2) who Interchain from order entry to consignment initiation information - transport information - quotations - transport booking confirmation - transport booking refusal Interface IF.5 Consignment Status Report (EDI 6) who Interchain from order information to shipper/consignee information - order information - order status information (i.e. delay, arrival) Interface IF.9a Consignment Status Report (EDI 5) IF.9.b On-line order progress report who IF.9a Interchain IF.9b Data store synchronisation from cargo information to order tracking information - cargo information - cargo status information (i.e. delay, arrival) Interface IF.14.a Transport Instruction (EDI 3) IF.14.b On-line Pick-up information who IF.14a Interchain IF.14b Data store synchronisation from order dispatching to order acceptance information - order information - transport instruction Interface IF.15 Instruction Confirmation (EDI 4) who Interchain from order acceptance to order dispatching information - confirmation of the instruction with freight charge - refusal Interface who from to information Interface who from to information IF.16 Activity Report + reusable equipment (MDC) PTV driver cargo monitoring - shipment status (loading / unloading) - reusable equipment - working hours - free text message IF.19 Loading/Unloading orders (Download or MDC) PTV transport planning driver - order information, like addresses and goods - tripplanning (times, places, routes... ) - reusable equipment - free text message Deliverable 5.1 Page A7.12

191 Interface who from to information Interface who from to information IF.31 Location information (MDC) PTV vehicle fleet vehicle monitoring - location of the vehicle - kilometres - cargo information (temperature) - technical vehicle information IF.35.1 Expenses, Time Report, Fuel Report, Reusable equipment IF.35.2 Km s MobiCoach 35.1 vehicle 35.2 driver trip data processing km s driven fuel used technical vehicle information hours worked (time sheet) expenses made equipment cargo information Interface IF.38.1 Additional Cost Message (EDI 8) IF.38.2 Invoice (EDI 12) who Interchain from invoicing to 38.1 consignment initiation 38.2 freight payment handling information additional cost warning message invoice freight charges Interface who from to information Interface who from to information IF.48 Reusable equipment information To be decided tripdata processing reusable equipment registration - number of packages - types of packages - condition - POD IF.49 Overview Reusable Equipment To be decided reusable equipment registration loading / unloading address - statistic information Interface IF.50 Proof of Delivery, including reusable equipmt info (EDI 10) who Interchain from order information to consignment initiation information - information about delivery of the consignment - damage reporting - reusable equipment Deliverable 5.1 Page A7.13

192 Interface IF.51.a Proof of Delivery, including reusable equipmt info (EDI 9) IF.51.b On-line POD, including reusable equipment info who IF.51a Interchain IF.51b Data store synchronisation from cargo information to reusable equipment registration information - information about delivery consignment - damage reporting - reusable equipment Interface IF.52 Additional Cost Message (EDI 7) who Interchain from invoicing to order dispatching information - explanation of cause - charges Interface IF.53 Invoice (EDI 11) who Interchain from invoicing to order dispatching information - shipment identification - charges The priorities with respect to Interchain are: 1. Data store synchronisation with Ordis; 2. IF.2 Transport Instruction (EDI 1); 3. IF.3 Instruction Confirmation (EDI 2); 4. IF.5 Consignment Status Report (EDI 6); 5. IF.14 Transport Instruction (EDI 3); 6. IF.50 Proof of Delivery, including reusable equipment info (EDI 10) 7. IF.9 Consignment Status Report (EDI 5); 8. IF.51 Proof of Delivery, including reusable equipment info (EDI 9); 9. IF.38.1 Additional Cost Message (EDI 8); 10. IF.38.2 Invoice (EDI 12); 11. IF.52 Additional Cost Message (EDI 7); 12. IF.53 Invoice (EDI 11); 13. IF.15 Instruction Confirmation (EDI 4); 14. Reusable equipment information; 15. Upgrading of the existing interface with the external trip data processing system; 16. Quotations database; 17. Registration of shipments with barcoding. Deliverable 5.1 Page A7.14

193 Dynamic Modelling Interaction between forwarder, carrier and driver The dynamic model of the interactions between the forwarder, the carrier and the driver is: Figure A7.4 : Dynamic Model of interactions between the forwarder, carrier and driver P.2 Forwarder P.3 Carrier P.4 Driver & P.8 Vehicle IF.14 IF.15 IF.9 IF.51 IF.48 IF.52 IF.53 IF.19 IF.16 IF.35 T I M E Interfaces IF.9.a IF.9.b IF.14.a IF.14.b IF.15 IF.16 IF.18 IF.19 IF.35.1 IF.35.2 IF.48 IF.51.a IF.51.b IF.52 IF.53 Consignment Status Report (EDI) On-line order progress report Transport Instruction (EDI) On-line Pick-up information Instruction Confirmation (EDI) Activity Report + reusable equipment (MDC) Position and cargo (temperature) information (MDC) Loading/Unloading orders (Download or MDC) Expenses, Time Report, Fuel Report, Reusable equipment Km s Reusable equipment information Proof of Delivery, including reusable equipment info (EDI) On-line POD, including reusable equipment info Additional Cost Message (EDI) Invoice (EDI) Deliverable 5.1 Page A7.15

194 Dynamic model of EDI message exchange Figure A7.5 : Dynamic Model of EDI message exchange P.1 Consignor P.7 Shipper/Consignee P.2 Forwarder P. 3 Carrier IF.2 IF.3 IF.14 IF.15 IF.9 T I M E IF.5 IF.38.1 IF.52 IF.52 IF.51 IF.50 IF.53 IF.38.2 Interfaces IF.2 IF.3 IF.5 IF.9.a IF.15 IF.38.1 IF.38.2 IF.50 IF.51.a IF.52 IF.53 Transport Instruction (EDI) Instruction Confirmation (EDI) Consignment Status Report (EDI) Consignment Status Report (EDI) Instruction Confirmation (EDI) Additional Cost Message (EDI) Invoice (EDI) Proof of Delivery, including reusable equipment info (EDI) Proof of Delivery, including reusable equipment info (EDI) Additional Cost Message (EDI) Invoice (EDI) Deliverable 5.1 Page A7.16