Design and implementation of an integration platform for telematics services

LiU-ITN-TEK-A--08/006--SE

Design and implementation of an

integration platform for

telematics services

Fredrik Jonsson

Lina Larsson

2008-01-29

LiU-ITN-TEK-A--08/006--SE

Design and implementation of an

integration platform for

telematics services

Examensarbete utfört i kommunikations- och transportsystem

vid Tekniska Högskolan vid

Linköpings unversitet

Fredrik Jonsson

Lina Larsson

Handledare Jesper Bonander

Examinator Di Yuan

Norrköping 2008-01-29

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga

extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,

skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för

ickekommersiell forskning och för undervisning. Överföring av upphovsrätten

vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av

dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,

säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ

art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i

den omfattning som god sed kräver vid användning av dokumentet på ovan

beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan

form eller i sådant sammanhang som är kränkande för upphovsmannens litterära

eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se

förlagets hemsida

Copyright

The publishers will keep this document online on the Internet - or its possible

replacement - for a considerable time from the date of publication barring

exceptional circumstances.

The online availability of the document implies a permanent permission for

anyone to read, to download, to print out single copies for your own use and to

use it unchanged for any non-commercial research and educational purpose.

Subsequent transfers of copyright cannot revoke this permission. All other uses

of the document are conditional on the consent of the copyright owner. The

publisher has taken technical and administrative measures to assure authenticity,

security and accessibility.

According to intellectual property law the author has the right to be

mentioned when his/her work is accessed as described above and to be protected

against infringement.

For additional information about the Linköping University Electronic Press

and its procedures for publication and for assurance of document integrity,

please refer to its WWW home page:

Acknowledgements

This work is done on behalf of Cybercom Sweden West for the purpose of investigating the possibilities of system integration between mobile and sta-tionary systems within the transport and logistics sector. Great thanks to the following people:

Jesper Bonander, project supervisor, Cybercom Magnus Carlsson, project sponsor, Cybercom

David Gundleg˚ard, project supervisor, Link¨oping University Johan Hoff, consultant, Cybercom

Niklas Mattsson, consultant, Cybercom Di Yuan, examiner, Link¨oping University

Abstract

Many companies within the transport and logistics sector face problems with integrating telematics and information systems within their organizations. The problem is often the lack of standardiza-tion between different solustandardiza-tion providers. Cybercom Telematics Proxy Platform (TPP) aims to bridge these different systems together by act-ing as a message broker. In the thesis the MSI Group XML format was chosen as the internal format of TPP. As a technical platform Microsoft BizTalk Server was chosen instead of developing a C# ap-plication from scratch. A demo solution with two fictive external systems was developed and proved TPP possible to work as a broker between a mobile and a stationary system.

Contents

1 Introduction 1

1.1 Background . . . 1

1.2 Aim of the project . . . 1

1.3 Problem formulation . . . 1 1.4 Method . . . 2 1.4.1 Data format . . . 2 1.4.2 Demo application . . . 2 1.5 Scope . . . 2 1.5.1 Microsoft platform . . . 2 1.5.2 XML standard . . . 2 1.5.3 Mobile office . . . 2 1.5.4 External systems . . . 3 1.6 Disposition . . . 3 2 The concept of TPP 5 2.1 Motivation . . . 5

2.2 Brief architectural description . . . 6

2.3 Architectural context . . . 7

3 An internal data format 9 3.1 Data representation . . . 9

3.2 Existing XML formats . . . 9

3.2.1 Freightwise . . . 10

3.2.2 Universal Business Language (UBL) . . . 10

3.2.3 Transport XML . . . 10

3.2.4 Pharos Mobile . . . 11

3.2.5 MSI . . . 11

3.2.6 MSI field tests 2006 . . . 12

4 Technical platforms for integration 14 4.1 In-house C# solution . . . 14

4.1.1 Connectivity . . . 14

4.1.2 XML handling and transformation . . . 15

4.1.3 Reliability . . . 15

4.1.4 Routing . . . 15

4.1.5 Process overview and management . . . 15

4.2 BizTalk Server Solution . . . 15

4.2.1 Connectivity through Adapters . . . 16

4.2.3 Reliability . . . 18

4.2.4 ”Routing” by Orchestrations . . . 18

4.2.5 Business Process Management . . . 19

5 System description 20 5.1 Overview . . . 20 5.2 Stationary system . . . 21 5.3 Integrator . . . 22 5.4 TPP core engine . . . 22 5.5 Connector . . . 23 5.6 Mobile system . . . 23

6 User case description 25 6.1 Sending a new order . . . 25

6.1.1 ASP.NET web page and the Order management database 25 6.1.2 Transport planner integrator . . . 27

6.1.3 Core engine orchestration . . . 27

6.1.4 Telematics provider Connector . . . 28

6.1.5 Telematics provider database and PDA application . . 28

6.2 Sending status updates . . . 28

6.2.1 Telematics provider database and PDA application . . 28

6.2.2 Telematics Provider Connector . . . 28

6.2.3 Core engine orchestration . . . 29

6.2.4 Transport planner integrator . . . 29

6.2.5 ASP.NET web page and the Order management database 29 7 Discussion 30 7.1 The relevance of TPP . . . 30

7.2 Choosing a XML-format for telematics . . . 30

7.3 Technical platform for TPP . . . 31

7.4 To make TPP production ready . . . 32

7.5 Extending TPP with in-house tools . . . 32

8 Conclusion 33

References 33

1

Introduction

1.1

Background

Cybercom has a long experience of being a competence and solutions provider within the vehicle and transport industry, involving Volvo, Scania, Autoliv and Schenker as customers. The interest in telematics solutions is increasing rapidly and Cybercom has an ambition of being one of the leading providers of competence and platforms. A part of Cybercom’s investment in telemat-ics is the idea of providing a telemattelemat-ics proxy. A proxy is a broker linking systems with different API:s and protocols together. The concept is called the Cybercom Telematics Proxy Platform (TPP) and will be a telematics platform integrating different systems within the transport and logistics in-dustry in a cost-efficient way. The features of this platform can be divided into three areas; Fleet Management, Transport Management and Security, all requiring both integration solutions and tools for monitoring information. Fleet Management involves information about the vehicle like positioning, vehicle diagnostics and driver performance. Transport Management deals with sending transport orders, invoices and routing information and the Se-curity part handles alarm and alert data like geofencing, panic button and surveillance camera. Each of these areas require its own integration manners and tools for monitoring data. This thesis however, will treat the Transport Management part of TPP, focusing mainly on the integration solution. This part will from now on be referred to as TPP.

1.2

Aim of the project

The thesis should explore the Transport Management concept ”Mobile Of-fice”, that is, all information sent between vehicle and transport management system that concerns the administration of a transport. The two foremost objectives are determining a suitable data format to be used for internal communication within TPP and also developing and evaluating a technical solution. To test the solution derived, a functioning demo should be imple-mented. The demo should span from a PDA as a client through TPP and to a fictitious order management system - a standard PC.

1.3

Problem formulation

What would be a suitable specification of an XML-based format for Mobile Office information within TPP? Based on the idea of TPP, what would be an appropriate technical solution?

1.4

Method

The method of approaching these problems was to split the assignment into two parts; finding and investigating a suitable data format and implementing a demo using the format specified or chosen. These tasks were solved partly in parallell during the project, however the search for data formats was of course completed of before the final implementation process began.

1.4.1 Data format

To find and evaluate the XML standards suitable for Mobile Office informa-tion that exist today a survey was done. In addiinforma-tion, interviews were done with representatives from different actors in the transport and logistics in-dustry, each of them experienced within the field of standard interfaces. The evaluation of the formats was based on a set of criterions that were set up.

1.4.2 Demo application

Before implementing the actual demo different approaches were studied. A C# solution was investigated followed by a process of investigating BizTalk Server and its integration possibilities. To finally implement the demo a set of user cases were specified, setting up the desired functionality of the platform.

1.5

Scope

1.5.1 Microsoft platform

The demo was developed using Microsoft Visual Studio. This in turn caused the use of C# as a program language. The existing integration platform used was due to the Microsoft platform Microsoft BizTalk Server. The PDA application was developed for a PDA running Windows CE 5.0, a Windows operating system for embedded and mobile devices.

1.5.2 XML standard

The data format used for information within TPP is based on the XML standard.

1.5.3 Mobile office

• Real-time information exchange between driver and dispatcher - Diving orders

- Route information

- Loading and unloading reports - Invoicing

- Payment

- E-mail, SMS, Instant Messaging (IM) • Onboard navigation

• Cargo handling - Barcode reading - RFID support

A selection of these functions was necessary for the implementation. A deci-sion was made that the new functionality focus area should be sending and receiving transport orders and reporting loading and unloading.

1.5.4 External systems

External systems used in the demo were a standard PC as the server or stationary system and a Windows CE enabled PDA as the client or the mobile system. Links from the external systems to TPP are presumed to be of TCP/IP nature. Priority was given to implementing the actual demo rather than investigating transmission protocols.

1.6

Disposition

• Section 2 gives background and motivation to the thesis, describing the general problems associated with system integration, followed by a conceptual description of TPP.

• Section 3 describes the need of a proper data format and presents some existing formats.

• Section 4 treats technical solutions for integration platforms and sug-gests some solutions for TPP.

• Section 5 presents the solution derived on a conceptual level, with a description of the message flow and the components chosen.

• Section 6 gives a more detailed system description exemplifying a mes-sage flow.

• Section 7 makes the discussion of the solution, giving recommendations and discussing further development.

2

The concept of TPP

2.1

Motivation

The general practice today when implementing a telematics solution in the transport industry is to make a custom integration between the systems that are to be connected. [1] This is generally because that is the fastest way to connect a new system to an organization. Later on however, a system might need to communicate with more than one other party, mobile or stationary. Each pair of these systems then has to be integrated separately. Each new mobile system introduced to the organization has to go through the same process of integration towards its systems. If any system was to be updated in some way, possibly many integrations would need to bee updated too, one for each connected system. Even a relatively small amount of mobile and stationary systems causes a solution that is quite hard to maintain, as illustrated in Figure 1. To avoid the situation with frequent updates, some companies instead choose to minimize the number of involved systems used in their organizations. In doing so, switching to another system later on could be hard, even though that solution would be more profitable. The company becomes limited to very few systems, and adapting to changes in the telematics market could definitely be an exhaustive process.

Enterprise Application Integration is a concept that could be a solution to integration problems. The idea of this solution is to have a middleware installed between the systems. This middleware would act as a message bro-ker, generally a third-party solution that would handle all transfers between parts of the organization or different organizations. The reason for having this middleware would then be to resolve integrations in a structured way and to ease future integrations.

Figure 1: The situation arising when performing one-to-one integrations.

2.2

Brief architectural description

By using the middleware solution, messages in one host would be sent to the other via TPP. The architecture can be described by three types of com-ponents, depicted Figure 2. The parts of TPP that interact with external systems have been defined as connectors and integrators. Connectors and integrators are components interfacing mobile and stationary systems, re-spectively. What characterizes these components is that connectors have analogous ways of being implemented and function despite distinct mobile devices. The same applies on integrators, having somewhat similar ways of being implemented regardless of the type of stationary system. The third component is the core system, the engine that handles the actual integra-tion. Assume a transport planner wishes to send a job order to the driver of a specific vehicle. He or she sends the order from the transport management system, coded in its own format and using its own communication mecha-nism. The TPP integrator receives the message, converts it into an internal format for transport orders and passes the message to the core engine, where it is routed to the right connector facing the receiving peer (i.e. the right vehicle). The connector converts the TPP order message to the local mes-sage type for orders on the PDA. The point of the internal format inside TPP is that it should be able to convert between many external formats, that is, TPP should be able to communicate with many different mobile and stationary systems.

Figure 2: The solution of a broker handling messages.

2.3

Architectural context

The concept of a proxy, a message broker could architecturally be oriented in numerous ways. [2] In [2], a number of paradigms for distributed computing is presented, that put different applications into certain contexts. TPP as a broker architecture is a Client-Server model in the sense that the client and the server have asymmetric roles in a collaboration process. The client should for example not be able to issue a transport order, only the order management system should have that capability. Another property of this model is that the client specifies requests of a specific service provided by the server, which is in turn answered by the server. The paradigm does not allow the server to initiate communication. However, in TPP that is a decision to be made by the developers. The opposite scenario could happen here; the server might want to send a request to the client, for example asking the client to accept an order, without requesting a specific service from the client.

Although it is possible to put TPP into a client-server context, it is more important to highlight the role of the middleware. One paradigm that could represent the broker solution is The Message-Oriented Middleware (MOM) paradigm. The MOM paradigm describes a solution where a middleware serves as an intermediary among separate processes, through which mes-sages are switched asynchronously. Two message models exist within the paradigm; the Point-to-Point message model, where the sender deposits mes-sages via the middleware into the queue of the receiving process, and the

Publish/Subscribe model, where the sender publishes messages via the mid-dleware that are subscribed by a receiver or a group of receivers. Which mes-sage model that suits TPP depends on the expected functionality of TPP and the development of the solution. The important aspect of the broker solution is the actual intermediary being a connection between the sender and the receiver and its ability to handle heterogeneous systems.

3

An internal data format

3.1

Data representation

In order to send messages between different systems through a platform, a common representation of the data is required. One system may provide one piece of information, while another would provide a different. Generally there is a need for a data format containing tags enough to support any type of data transmitted in that specific system. The platform shouldn’t have to be updated every time a new system with a new message type is connected. The XML standard was chosen for this purpose because it was specified in the project assignment but also because it is a de facto standard for information exchange within data communications. In [3], it is stated that XML facilitates mobile system integration.

What is required for TPP is an XML format capable of handling the information presumed to be sent in a telematics system. This data, the telematics data can be defined as all the information exchanged between ve-hicle and transport planner during a transport. In addition, TPP should be extendable to more functions like sending for example vehicle diagnostics and position data, wherefore the XML format should also support these func-tions. A proper XML format could either be fully developed using our own list of requirements and guesses about relevant data, or an existing format could be used. Many existing formats contain XML tags supporting pure business data, such as invoices and purchase orders. There is a fair differ-ence in integrating systems sending this type of data than systems sending transport-related data. From a Mobile Office point of view it is irrelevant where the invoices should be sent or who issued the original purchase order, and from a business point of view the fuel consumption or exact position of the vehicle are useless information. TPP should focus on real-time telemat-ics information, hence the challenge was to specify a format with sufficient support for that.

3.2

Existing XML formats

Two suggestions were given by the supervisor at Cybercom; MSI-group (Mo-bile Stationary Interface Group) - a Swedish consortium, and ITS (Intelligent Tranportation Systems) - a part of US department of transportation. The standards provided by ITS appeared to be too narrow and divided into differ-ent sectors, such as only Emergency Managemdiffer-ent. ITS focuses on road and traffic, not so much the transport planner and vehicle. A few other standard formats were taken into account. These formats where chosen from a set of

criterions that were set up in order to facilitate the selection from the wide range of XML formats that exists today. The criterions are the following:

• XML - the format should be based on the XML standard • Availability - the format should be available to use at this time

• Transport - the transport part of the format should be sufficient for present and preferably future functions of TPP:

- Handle transport orders and loading/unloading updates - Handle Fleet Management data such as vehicle diagnostics - Handle driver data such as time reporting

3.2.1 Freightwise

Freightwise is a project initiated by EU and German consultancy BMT. EU’s 6th Framework Programme in which Freightwise is being developed within is intended to bring together transport management, traffic and infrastructure management and administration [4]. The project focuses on cooperation between these three sectors to ease the development of solutions and integrate existing systems for intermodal transports. The objective is to shift cargo transports from road to intermodal transports, that is, introducing short sea shipping, inland waterways and rail to the road transports to find the optimal utilization of different transport types for each transport. However, since the standard and framework are to be introduced in 2010 it was not further considered.

3.2.2 Universal Business Language (UBL)

The UBL is an attempt of defining an XML library of business documents such as purchase orders, invoices etc [5]. The format handles the whole order chain from product catalogue to handling of purchase order and issuing of the invoice. It was developed by The Organization for the Advancement of Structured Information Standards (OASIS), a global consortium that devel-ops and supports web service standards and e-business solutions. Having looked at the content of the format, it appears to miss substantial support telematics data, which is required for TPP.

3.2.3 Transport XML

[6]. Transport Job involves all message data that is transmitted before, dur-ing, upon completion of and anytime after a goods transport is performed. The Track&Trace function includes all requests, responses and reports on administrative and operational events, that is for example loading and un-loading. Implementing TPP with Transport XML would solve the basic re-quirement of order handling. TPP however, is meant to be a general solution wherefore this format failed due to its narrowness.

There is a present development of a format called Shortsea XML that is an extension of Transport XML. The format is a message standard for com-munication between all parties in the short sea transport chain [7]. It covers a wider spectrum of services in the order chain than Transport XML, includ-ing for example invoicinclud-ing, customs clearinclud-ing and documentation. However the focus area along with the fact that the format is built on Transport XML which is in turn inappropriate for TPP left this format out of consideration.

3.2.4 Pharos Mobile

Pharos Mobile is an XML format developed by e-com Logistics, subsidiary of Swedish International Freight Association. Like the Universal Business Lan-guage, it is too much focused on business data to suit a telematics platform. The format is not so much aimed for haulage contractors but more for for-warding agents [8]. TPP requires a format that has support for information at the end of the informatics chain, down to the mobile system. A format for forwarding agents likely contains information that is more usable higher in the informatics chain.

3.2.5 MSI

MSI Group is a Swedish consortium that aim to ease the use of mobile and stationary systems within the transport sector [9]. The members of MSI Group are representatives from the transport industry and providers of mobile and stationary systems, such as Volvo, PocketMobile and IBS. The organization was founded through a research project, ”Nyttoskapande IT f¨or ˚akeriverksamheter” in July 2003, founded by Vinnova and coordinated by Viktoriainstitutet AB. The project took form as a survey, involving repre-sentatives from organizations within markets for mobile systems, stationary systems and costumer organizations, intending to highlight the problems ex-perienced with information technology in the transport business. One com-monly experienced problem was the way mobile and stationary systems are put together. User organizations felt limited by the proprietary interfaces provided by the suppliers. The outcome of this survey resulted in the

devel-opment of a standardized interface, Mobile Stationary Interface (MSI). This interface is an XML standard containing tags that support a great amount of the information exchanged in a telematics system. Since the standard was developed all together with the major players in the Swedish transport market, it should be wide enough to meet the requirements from the telem-atics industry today. MSI Group has a more ambitious goal though than MSI being just a data format. The organization wants to develop a com-plete new standard for the communication between mobile and stationary systems. This includes a collaboration protocol specifying how to address another host, session handling and other collaboration aspects. Figure 3 shows a subset of the MSI format.

3.2.6 MSI field tests 2006

Some field tests were done with MSI during summer 2006 proving that MSI works as a format in real systems. The tests were carried out at two sites in-volving two stationary systems - Transport Management Systems (TMS) and one mobile system - Telematics Service Provider (TSP). One TMS involved a third-party integration server in the integration of MSI, and the other used their own infrastructure. The part of the format that was tested was only the Assignment representation of the schema, depicted in Figure 3. The in-formation in this tag contains inin-formation only about the actual transport order. The result of using MSI was that more parties of the integration chain had to adapt to the interface than in the usual case. The typical case when not using MSI is that the TMS uses a proprietary interface that the TSP has to adapt to. The TMS then generally controls the implementation process. With MSI both TMS and TSP had to adapt to the interface, causing certain frustration among the participants of the tests. Furthermore the collabora-tion protocol does not yet in MSI, as stated in seccollabora-tion 3.2.5. This caused much interaction between the TMS and the TSP, pointing on the weight of having such a protocol [10].

Very little can be said about the functionality of MSI after having looked at the test results, since such small representation of the structure was applied on the tests. [11] However, the collaboration protocol in MSI is essential for communication and without it MSI would loose its meaning.

Figure 3: The Assignment tag in MSI, representing a transport order of any kind.

4

Technical platforms for integration

A technical platform in this thesis is defined as the hardware and software combination that manages the requests from the peers. The main functional-ity of TPP is the abilfunctional-ity to manage requests from telematics peers. There are numerous ways of achieving this but the two alternatives considered here are a Web Service solution in C# and a BizTalk Server solution. The following aspects were evaluated in order to find a suitable platform.

• Connectivity - how easy standard protocols and widely available APIs can be used.

• XML handling and transformation - the support for handling and trans-forming XML documents.

• Reliability - the system’s ability to handle errors and unexpected situ-ations.

• Routing - how convenient the support is for a message routing mecha-nism.

• Process overview and management - if it’s possible to overview and track errors and progress.

4.1

In-house C# solution

One way to develop a technical platform is to write it from scratch. This would require plenty of work but lead to great flexibility and control. The technical platform would only have the limitations that are built into it by the TPP programmers. To communicate between connector, core engine and integrators Web Service techniques could be used. This way the system would become more flexible and the different parts of the solution could be hosted at different machines and TPP wouldn’t be bound to the .NET framework because many platforms (i.e. Java) have support for Web Services. Of course other ways of communication could be considered but a Web Service-based solution was seen as the most flexible, however not the technique with best performance.

4.1.1 Connectivity

The .NET platform provides a comprehensive list of APIs to connect to all kinds of ERPs (such as SAP), web services and database systems. Having that said it still requires the developer to handle the communication in many

4.1.2 XML handling and transformation

Support for XML is essential in the .NET framework. Reading, writing and transforming XML data is convenient. With help of XSLT it’s not hard to map one XML document to another form, i.e. from an OEM-format to a standard telematics-format.

4.1.3 Reliability

Being a general programming language, C# would require a solution that needs to build up an own way of handling errors and failures. No messages can be tolerated to be lost due to an internal error of the TPP platform. The mechanism for this needs to be implemented in a structured way that can almost guarantee the reliability. One way to make this work is with unit testing where the programmer writes tests that simulates different cases where problems can occur.

4.1.4 Routing

The routing mechanism in the system would need to be coded into the system. This could lead to a situation where the logic of the routing mechanism could be hard to overview.

4.1.5 Process overview and management

There is no underlying infrastructure to get status information from. Mech-anisms for monitoring the status of the system and manage error will have to be developed at the parts of the system that needs to report errors and status updates. This will require the programmer to imbed code in many different parts of the system. However the reporting and overview can be customized the way the client wants it. This could be an important feature.

4.2

BizTalk Server Solution

Microsoft offers a solution to integration problems through their product BizTalk Server 2006. [12] BizTalk is a set of tools forming an integration platform that enables integration of business processes. The messaging pro-cess in BizTalk is carried out using several components, also referred to as artifacts, and is illustrated in Figure 4. First a message is received with a component called Recieve Adapter. This receive adapter knows how to communicate with for example a Web Service, or a specific line- of-business application (LOB), such as SAP. The message is then passed on to a Recieve

Figure 4: Overview of BizTalk messaging.

Pipeline, that can change it in different ways. For example, the message is transformed from its external format to an XML message, which is supposed to be used within BizTalk. The message is then stored in an SQL Server database called MessageBox. The BizTalk Orchestrations, which is the busi-ness layer of the engine, picks up the message from the MessageBox and processes it before it is passed on to the Send Pipeline which transforms the message to the format required by its destination and sends it via a Send Adapter. The whole concept of communicating with other applications relies on the BizTalk send and receive ports. Ports can contain adapters, pipelines and data mappings. A description of these components is presented below.

4.2.1 Connectivity through Adapters

Adapters are implementations of communication mechanisms, such as proto-cols [13]. One can choose to use the built-in adapters in BizTalk or create a customized adapter. The adapters provided by BizTalk stretches from Base EDI to FILE and FTP to HTTP, POP3, SMTP and SAP.

4.2.2 XML-handling and transformation

Pipelines BizTalk communicates with applications by sending messages of different kinds such as purchase orders, invoices and so on. Doing so, gener-ally these messages need to be processed in some way in order for BizTalk to handle them correctly. For example the internal language inside BizTalk is XML, and since not all applications outside understand XML, Bizalk needs to translate the messages from any format into XML format. This is then

Figure 5: The Recieve pipeline.

components, each handling a particular part of the processing. The Recieve Pipeline for example consists of the following components; Decode, Disas-semble, Validate and Resolve Party, Figure 5. BizTalk provides some default pipelines, including a send/recieve pair that can be used to handle messages that are already in the form of XML. There is also a graphical tool called Pipeline Designer that is used to develop custom pipelines. With this tool the developer can drag and drop components to whatever behavior desired by the pipeline.

Data mappings Pipelines do the transformation of external messages to an XML format; however, the developer is responsible for specifying this for-mat. This is done with XML Schema Definition Language (XSD), a way to describe what data an XML document should contain. The elements of the schema can be defined graphically using BizTalk Editor as well as imported from files or Web Services. Often information in incoming messages needs to be passed on to outgoing messages and therefore, a mapping of the mes-sages is required. This can be done as soon as the mesmes-sages have an XML representation. A map in BizTalk is a graphical relation between two XML schemas, created in BizTalk Mapper, defining the connections between the source and destination schema. The World Wide Web Consortium (W3C) has defined the Extensible Stylesheet Language Transformation (XSLT) as a way to describe transformations between different XML schemes. BizTalk maps are therefore implemented as XSLT transformations. Transformations are made by drawing a line between elements in the source and destination schema or, in the more complex case using a functoid on the link. A functoid is a component performing a certain programming-like task, like concatenat-ing strconcatenat-ings or loopconcatenat-ing through a table. A simple map is illustrated in Figure 6

Figure 6: A BizTalk map using functoids.

4.2.3 Reliability

BizTalk is designed to never lose a message. If an error occurs in one part of the system the message will be stored in the message box and an error message will be created. The administrator can track down the reason of the failure and the message can be resent when the BizTalk application works properly again.

4.2.4 ”Routing” by Orchestrations

Creating business processes generally requires collaboration between devel-opers and business people. BizTalk supports this collaboration providing the developer tool inside Visual Studio, but also an add-in of this tool to Visio, Microsoft Office diagramming software. An orchestration made in Visual Studio can be imported into the Visio- based tool and vice versa. This was both developers and business people can communicate and collaborate in the development of an automated business process. In Visual Studio however, an orchestration is made via BizTalk Orchestration Designer by putting to-gether different shapes that toto-gether form the business process. These shapes can be seen as business actions, ways to transform and transfer the messages entering the orchestration, Figure 7. In this way, advanced business imposed routing can be made. On the other hand messages can be sent straight from one port to another without be handled by an orchestration. This will in-crease performance but obviously take out all flexibility; hence no routing is being made.

Figure 7: An orchestration handling a purchase order.

4.2.5 Business Process Management

Apart from seeing integration in BizTalk only as developing a message bro-ker, one can refer to it in a larger context as Business Process Management (BPM). In BizTalk BPM in turn contains two important technologies: Busi-ness Rule Engine (BRE) and BusiBusi-ness Activity Monitoring (BAM). The BRE is used when applications require complex set of rules to execute, too com-plex for the orchestration designer to handle. The BRE is then connected via the orchestration to take care of this process. The BAM services allow real-time data to be monitored not only by technicians, but also by normal people, users of the system. The information can be viewed through tools such as for example Microsoft Excel and Office Performance Point Server.

5

System description

5.1

Overview

Figure 8: Overview of the TPP solution.

The demo application consists of a set of BizTalk applications forming the actual platform and a mobile and a stationary system representing the client and server side, Figure 8. The XML format used is the format developed by the MSI Group.

Orders are generated in the stationary system and stored in an order management database. The TPP integrator listens to the order manage-ment database and picks up new messages. It transforms the message into the internal MSI format and forwards it to the routing engine. In the rout-ing engine the message gets directed to the connector where the message is transformed, this time to the external a format that corresponds with the telematics provider database. The message gets inserted into the database.

The PDA loads its content from the database. When the PDA user makes changes, a message gets generated and goes through the same procedure only reversed. This will be called the reversed flow from now on.

This chapter will try to give an understanding of the architecture of this demonstration implementation of the TPP. Figure 9 gives an overview of the different components and the message flow in the system. More technical details can be found in the next chapter.

Figure 9: Architectual details. The thin arrows show the message flow and the thick arrows indicate references between different BizTalk applications.

5.2

Stationary system

The stationary system is represented by a web site with a database as data provider. This database will be referred to as the order management database. The web site is only communicating with the database and is de-signed to be sealed system, i.e. no API:s or similar integration possibilities exists.

When new orders arrive to the order management system they don’t have trucks assigned to them. Hence the user needs to choose an order and assign a truck to it. When a truck is assigned to an order it causes a status change of that order in the database. This can be viewed in Figure 10.

5.3

Integrator

The integrator’s receive adapter listens to the order management database for orders with status ”Pending assignment”, that is, orders waiting to be con-firmed by the assigned driver. When a order has been read by the database and picked up by the receive adapter a flag called ”Sent” in the database is set, meaning the order has been sent and will not be sent again, even though it still has ”Pending assignment” as status. The messages are then mapped into the MSI format. This is done with a BizTalk map.

In the reversed flow the PDA sends order status updates, every time the transport job has proceeded, i.e. goods are picked up. These update messages are then mapped from MSI back to database format and inserted in a ”status change” table. The tasks of the integrator are illustrated in Figure 11.

Figure 11: The integrator and its tasks.

5.4

TPP core engine

The core engine is meant to handle the routing of messages to different con-nectors depending on the receiver’s system. Since there is only one mobile system in this demo, the only thing the orchestrations do is to transfer mes-sages between the integrator and the connector.

What is worth mentioning though, when looking at Figure 9 is that in-tegrators, connectors and core engine use the MSI Schema library to create MSI messages. By doing so, it is ensured that a MSI message in one part of TPP will be the same in any other part. It eases the upgrade of MSI to newer versions in the future. Figure 12 illustrates the core engine message flow.

Figure 12: Rouing engine and its message flow.

5.5

Connector

The connector has somewhat the same function as the integrator but handles only mobile systems. It transforms the MSI message to a format that can be inserted into the telematics provider database, and performs the insert. In the reversed flow the receive adapter checks for status updates in the telematics provider database. It picks up the any new status and transforms it into a MSI message and sends it to the core engine. This is shown in Figure 13.

Figure 13: The connector and its tasks.

5.6

Mobile system

The PDA application shows all orders assigned to the driver of the vehicle. Order data, such as pick-up and drop-off location and time, can be accessed

through the PDA application. When the driver performs an activity that changes the status of the order he or she reports that in the application. All data is stored in the telematics provider database. It fetches information about orders on regular basis and inserts status updates into the database, depicted in Figure 14.

6

User case description

6.1

Sending a new order

6.1.1 ASP.NET web page and the Order management database

Figure 15: Overview of all orders

The stationary system is an ASP.NET web application, shown in Figure 15. All communication with the database is carried out using stored proce-dures. Stored procedures are subroutines that applications can use to access relational databases without making the direct queries.

All the information connected to an order is collected from the order management database and presented on the web site using a stored procedure called SelectOrderById. This stored procedure is shown in Figure 16.

When an order is first added to the order database (e.g. ERP), it receives the flag ”‘sent” which is then set to false. This indicates that this order hasn’t been sent through the TPP integrator, which assumes that the order database can be changed to work with TPP. Another solution to this problem is presented in the case of the Telematics provider database.

When a user assigns an order to a truck the status of the order changes, the new status is also logged to a table with status changes. ”Sent” is still set to false at this time. The order management database is a Microsoft SQL Server. Since the order management system is fictive, the structure of the Order management database is based on an assumption of the need of information for the functionality on the web page. Figure 17 gives a view of the relations in the database.

Figure 18: One of the mapping views from the mapping of order management database XML to MSI-XML.

6.1.2 Transport planner integrator

Because SQL Server is used for storing information in the Order Management system, the BizTalk SQL adapters are used. The integrator consists of a Send and Receive adapter, and an XML Transmit and XML Receive pipeline, one adapter and pipeline for every direction of the message flow.

When a order has been read from the database and picked up by the receive adapter the ”sent” flag is set to true, meaning the order has been sent and will not be read again, even though it still has Pending assignment as status.

The database query for getting new orders returns it result as a XML document, representing the database format used by the stationary system. The mapping between the database XML-format and MSI is done by BizTalk mapping, see Figure 18. This is a tool where the developer graphically draws the relationship between data tags in the different XML-documents.

6.1.3 Core engine orchestration

After the transformation to MSI the order goes through the core engine orchestration where nothing happens with the message. In a more complex case with more systems involved, it might have been necessary to implement

routing logics here.

6.1.4 Telematics provider Connector

Like the integrator the connector is implemented like a two-way BizTalk SQL Adapter and a two-way pipeline, that is an XML Receive and XML Transmit pipeline.

When a new order has been sent through TPP the XML Transmit pipeline transforms it into a XML representation the input to a stored procedure with the name InsertNewOrder. It creates the new order, adds the orders rows (the goods) and adds a new row in a table called ”LastKnownStatus”.

The ”LastKnownStatus” table keeps track of the status of the order, more on this in the next section.

6.1.5 Telematics provider database and PDA application

The telematics provider database belongs to the mobile system and is con-tinuously filled with orders throughout a demo process, hence there are no orders in this database from the beginning.

The PDA application is implemented in C# for Windows CE 5.0. The PDA communicates directly with the telematics provider database, wherefore nothing is stored locally in the PDA. The PDA application checks for new orders to collect when the user clicks the ”Unassigned” button.

6.2

Sending status updates

6.2.1 Telematics provider database and PDA application

When the driver updates the status in the application the order changes in the database. Note however that the status doesn’t change in the ”Last-KnownStatus” table. When a driver clicks ”Delivered” on the application, he or she can sign the order and the signature is stored in byte code in the database.

6.2.2 Telematics Provider Connector

The connector calls a stored procedure in the Telematics Provider Database that checks if there are any orders where the status in the order table differs from the one in ”LastKnownStatus” table. This would indicate that the status have changed since the last check. The stored procedure returns the status update and updates ”LastKnownStatus” table with the new update,

When it finds a status update it forwards it as a new message type to XML Receive pipeline where it will be transformed into MSI-XML and sent further through TPP.

6.2.3 Core engine orchestration

In this case there is one orchestration for the reversed flow that doesn’t do more than transfer the status update to the integrator.

6.2.4 Transport planner integrator

The status update gets transformed to an XML-document that corresponds to the input of the InsertNewStatus stored procedure. A special case occurs when a confirmation of order delivery is being sent. The signature of the receiving customer has to be transmitted to the web application database. In order to transmit an image based on byte code it has to be converted to BASE64, which is a way to represent byte information in a text file (such as an XML file). In the order management database the BASE64 encoded image is converted back to byte code and stored in the order table.

6.2.5 ASP.NET web page and the Order management database In the reversed flow, new status updates are received from the telematics system. These are inserted into the change of status table and the order is updated with the new status.

When the customer confirms the delivery by signing the order an text-coded image gets transmitted text-coded as BASE64. It needs to be detext-coded in order to be inserted into the Order management database. This is done within the database with a function which analyses the BASE64-text and substitutes the characters to corresponding byte code.

7

Discussion

7.1

The relevance of TPP

The interviews held with representatives from the transport and logistics in-dustry indicate that integrating different telematics systems is indeed some-thing that many companies strive to achieve. The technical challenges to make this happen are not considered difficult in small parts but at large complex and time consuming. This often leads to less integrations actually being performed and information not getting interweaved. The cost of inte-gration stops the introduction of new cost-saving telematics systems. There is an urge for means of easing the integration within the field of telematics. TPP could definitely facilitate the merging of data from all different telem-atics and information systems used in organizations. It might not solve the overall problem of seamless communication between different OEMs, integra-tions would obviously still have to be performed. The integraintegra-tions performed would however be more cost-efficient than without an integration platform at all.

7.2

Choosing a XML-format for telematics

The goal of having a standard format for TPP is to be able to represent as much transport-related information as possible. When a new telematics service is introduced it should be likely that the information related to this service already have support in the format. Otherwise the format would have to be expanded to handle the new information. Every time a rewrite of the format is needed, all components of the system that relies on the format would have to be adjusted to work with the new format. Avoiding that sort of rewriting is one of the purposes with TPP, hence a format that is expected to need expansion is not acceptable.

An in-house format covering completely all message data in a telematics system would take too long time to develop and is beyond the scope of this project. Developing a format or extending an existing format would mean collecting a tremendous amount of data, since the whole transport industry would have to be investigated in order to find what information is suitable to a system. Developing a specific format to solve only the problems faced today would not achieve the goal of TPP being an all-round telematics solution. Finding an already existing format was consequently the only alternative. During the research of existing formats it became clear that most standard initiatives focus on solving problems involving the business transactions

be-between transport service provider and executor of the transport. Several existing standards have basic support for telematics. However, due to their sole focus on another problem it they don’t seem appropriate for telematics applications.

The only format that had telematics as its main scope and purpose was MSI. This data format focuses only on the communication between mobile and stationary systems from a transport and logistics point of view. If MSI-group’s long-term vision with MSI would be reality today the integration part of TPP would not be requested by customers. The MSI vision would solve the problems with integrating different systems. However, as that is not yet reality and will probably not be for another few years, there is still a need for TPP. Additionally as TPP uses the MSI format internally it is fully prepared to be a broker between non-MSI systems and MSI-enabled systems. Apart from being a broker in environments with many dynamic systems that could be one of the more important applications of TPP.

7.3

Technical platform for TPP

While exploring alternatives for the technical platform it gradually became clear that BizTalk, being an integration platform, had all the capabilities needed for TPP. While a demo of a small information flow in C# also was de-veloped it was clear that the fail safety mechanisms in BizTalk vastly exceeds anything that could be developed within this thesis. Being a more robust product, BizTalk requires more from the hardware and handles much fewer messages per second. However, it supports load balancing and as hardware prices keeps dropping it shouldn’t be a problem handling as many messages as needed. In the trade-off between performance and hardware prices in the sense of doing the right thing or doing it fast, it is true for the server market today that hardware prices is less than the price of developing even more complex code in order to improve performance. By using a third-party product as a part of the solution some of the profit from selling the solution would benefit this third part instead of benefiting Cybercom. On the other hand the development cost is greatly reduced and so is the risk of developing a product that will not sell well enough on the market. This is a trade-off that all companies have to face and in this case the complexity of developing an own solution, however possible, might cost more to develop and maintain than buying. As no major design or architecture changes had to be done in order to use BizTalk it was rather easy to choose that for TPP.

7.4

To make TPP production ready

The system suggested in this thesis is only to be considered a proof of concept. It is also limited to handle a small portion of the capabilities of the MSI format. When a real production environment is to be integrated a deeper analysis has to be done and the need has to be estimated. TPP then has to be extended to work with the new set of requirements. The customer might use a system with built-in ”adapters” to which BizTalk can’t communicate. In this case an adapter must either be bought if it exists, developed by the TPP team or the system must be extended to communicate with a standard protocol that BizTalk supports. Depending on how many ingoing systems the solution has, the routing mechanism has to be adjusted to route messages to the right recipients. The business logic of the customer company has to be implemented in the orchestration as well. With every project that utilizes TPP the functionality will grow and following projects will benefit from both actual BizTalk projects as well as knowledge acquired in previous implementations. In the long term TPP could be a bundle of almost ready components that can be put together and customized to fit the next project at hand. After a while the MSI format will be more or less fully covered in TPP and it can serve as a proxy between an MSI network of MSI-enabled hosts and a environment with non-MSI hosts.

7.5

Extending TPP with in-house tools

A parallel project to this thesis was to develop a suite of tools to process and visualize information about vehicles and transport orders. The natural wish and concern is whether it would be possible to integrate the two projects and gain any synergy. The main idea was that the information that flowed through the integration platform would be stored in the middle and be acces-sible for these tools. However, TPP at this stage only consists of a integration platform and doesn’t store any data internally. If the tools suite should be used with TPP it has to be integrated in the same way as any other fleet management or stationary system would. That being said, it would of course be easier because the development teams share both locations and possibly members. The in-house tools could also be built in a way that it easier than other systems to integrate and takes advantage of TPP’s strengths.

8

Conclusion

The TPP demo was developed and built throughout this project using the MSI Group XML data format for internal communication. This means that all external systems, mobile or stationary, proprietary data formats are trans-lated into the MSI format and then sent to the destination system where they are translated into the local system’s own data format. By using the MSI data format as foundation TPP becomes reliable and extendable within the field of telematics. Even though the demo described in this thesis is not ready for production the architecture could be used as a blue print for building a TPP implementation to solve a real world problem. The Microsoft BizTalk integration platform offers stable basis on which TPP gets interaction with everything from ERPs to database systems and fileservers. It also simplifies the handling of XML messages sent through TPP and makes the solution more fail-safe compared to be using an in-house developed integration plat-form.

References

[1] Linthicum, D, Enterprise application integration, Addison-Wesley, Mas-sachusetts 1999

[2] Distributed Computing - Principles ans Applications, M. L. Liu, Pearson Addison-Wesley, California Polytechnic State University, San Luis Obispo, 2004.

[3] Towards Seamless System Integration in Road Haulage Firms, Gohar-pour and Seifzadeh, G¨oteborgs Universitet 2005

[4] http://freightwise.info/cms/ 2007-09-26

[5] http://www.oasis-open.org/committees/tc home.php?wg abbrev=ubl 2007-09-26

[6] http://www.norstella.no/getfile.php/175829.177/transportXML3.2EnglishApr1805.pdf 2007-09-26

[7] http://www.shortseaxml.org/ 2007-09-26

[8] Interview with Rikard Lindgren, univeristy lecturer, Viktoriainstitutet, 2007-09-27

[9] http://www.msigroup.se/index.asp?page=content/organisation 2007-09-27

[10] Test results of MSI 0.18, Magnus Andersson, Viktoriainstitutet 2007-02-20

[11] Interview with Magnus Andersson (phone), PhD at Viktoriainstitutet 2007-11-05

[12] Introducing Microsoft BizTalk Server 2006 R2, David Chappell, Chap-pell and Associates, August 2007

[13] Understanding Microsoft BizTalk Server 2006 R2, David Chappell, Chappell and Associates, August 2005

Glossary

.NET - The Microsoft .NET Framework is a software component that is a part of Microsoft Windows operating systems. It provides a large body of pre-coded solutions to common program requirements, and manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering, and is intended to be used by most new applications created for the Windows platform.

API - An application programming interface (API) is a source code interface that an operating system or library provides to support requests for services to be made of it by computer programs.

BizTalk Server - is a business process management (BPM) server. Through the use of ”adapters” which are tailored to communicate with different soft-ware systems used in a large enterprise, it enables companies to automate and integrate business processes.

Broker - Negotiator between external independent systems, often with dif-ferent communication protocols.

C# - is an object-oriented programming language developed by Microsoft as part of the .NET. It has a procedural, object-oriented syntax based on C++ and includes aspects of several other programming languages (most notably Delphi and Java) with a particular emphasis on simplification.

ERP - Enterprise Resource Planning (ERP) systems integrate (or attempt to integrate) all data and processes of an organization into a unified system. A typical ERP system will use multiple components of computer software and hardware to achieve the integration. A key ingredient of most ERP systems is the use of a unified database to store data for the various system modules. Middleware - see Broker.

Mobile Office - the concept of managing office-related task mobile or in a vehicle.

OEM - Original equipment manufacturer, is a term that refers to containment-based re-branding, namely where one company uses a component of another company within its product, or sells the product of another company under its own brand. OEM refers to the company that originally manufactured the product.

PDA - Personal digital assistants are handheld computers, but have become much more versatile over the years. PDAs are also known as small computers or palmtop computers.

Protocol - In computing, a protocol is a convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints.

SAP - The world’s largest supplier of ERP-systems

SQL Server - Microsoft SQL Server is a relational database management system (RDBMS) produced by Microsoft. Its primary query language is Transact-SQL, an implementation of the ANSI/ISO standard Structured Query Language (SQL) used by both Microsoft and Sybase.

Stored Procedure - is a subroutine available to applications accessing a rela-tional database system. Stored procedures (sometimes called a sproc or SP) are actually stored in the database.

TCP/IP - (also refered to as the ”Internet protocol suite”) is the set of communication protocols that implement the protocol stack on which the Internet and most commercial networks run.

TMS - Transport Management System, generally the stationary system. TPP - Telematics Proxy Platform, a broker platform between telematics sys-tems developed by Cybercom. In this thesis, TPP refers to the integration part of the platform.

TSP - Telematics Service Provider, generally the stationary system.

Updategram - An updategram is a piece of XML data that contains informa-tion about how to modify data in a database, expressed as an insert, update, or delete operation of existing records.

Visio - Microsoft Visio is diagramming software for Microsoft Windows. It uses vector graphics to create diagrams.

Visual Studio - Microsoft Visual Studio is the flagship Integrated Develop-ment EnvironDevelop-ment (IDE) from Microsoft. It can be used to develop console and GUI applications along with Windows Forms applications, web sites, web applications, and web services in both native code as well as managed code for all platforms supported by Microsoft Windows, Windows Mobile, .NET Framework, .NET Compact Framework.

W3C - The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web (abbreviated WWW or W3). Web Service - A Web service (also Web Service) is defined by the W3C as ”a software system designed to support interoperable Machine to Machine interaction over a network.” Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a re-mote system hosting the requested services.

Windows CE 5.0 - is a variation of Microsoft’s Windows operating system for minimalistic computers and embedded systems.

XML - The Extensible Markup Language (XML) is a general-purpose markup language.

XSD - XML Schema Definition is one of several XML schema languages. It was the first separate schema language for XML to achieve Recommendation status by the W3C.

XSLT - Extensible Stylesheet Language Transformations (XSLT) is an XML-based language used for the transformation of XML documents into other XML or ”human-readable” documents.