So far this report has mainly considered the generic issues (Track B) related to the INTACT project. The INTACT 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 INTACT project which involve four road transport companies. At each company various pilot tasks will be performed within the INTACT 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 INTACT 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 INTACT 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 INTACT deliverable D3.1, covering the user requirements analysis made in workpackage 3.
5.2
The pilot projects
Each of the test site companies has defined pilot projects that will be performed within the INTACT 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.
Company Solution JDR:
1. To create an interface between planning system and operational applications Automate the input of logistics trip data into the central system
Quotations Van Heezik:
To create an interface between planning system and operational applications 2.
3. 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
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 INTACT-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 INTACT 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 7.
5.4.1 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 (planned) central database
• inventory system
• systems of fuel companies • generic interface (FTP) • mobile communication system De Rijk Chainware Central administration, order
management
• planning system
• black box system /mobile communication system
• quotations Van Heezik Chainware Central administration, order
management
• planning system
• black box system/ mobile communication system
• customers (EDI) Patinter Quasar Freight assignment and
(planned) order management
• positioning/ messaging system
• customers /forwarders systems (Internet)
5.4.2 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 INTACT project relevant functionalities are order management (order entry, tracking and information), invoicing- facilities 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 EDI- facilities with customers and third party carriers is planned; at this site Infodis can act as an
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 INTACT 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 INTACT 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.
5.4.3 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 INTACT-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
companies, the planned interface automatic produces the final fuel price choice, which is retrieved by the drivers using mobile data communication.
5.4.4 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 INTACT-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 INTACT-project.
5.4.5 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 INTACT project concentrates on providing a functional specification for systems integration at the four road freight transport companies participating in the INTACT 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.