Due to diverse and increased demands, logistics needs to move towards being more context-aware. Logistic planning and execution will benefit immensely by use of (real-time) contextual data, such as data about weather, traffic, and resources. Resulting benefits include better flexibility, lower greenhouse gas emission, reduced costs, and optimum usage of transport modalities. This paper demonstrates the benefits and investigates the interoperability challenges of integrating contextual data in synchromodal transport. A data format for incoming contextual data is presented.
In accordance with the guidelines and vision of the EU, logistics in Europe has to be made more efficient and
flexible. This is necessary to decrease the pressure on roads, better utilize existing infrastructure, and reduce Green
House Gas (GHG) emissions. The underlining message of the vision document
Optimal usage of different modalities is the idea behind Synchromodal Logistics Services (SLS). In SLS, the
decision for a next route or stoppage is taken as late as possible. It implies that although the delivery time of a
consignment is usually constrained, the intermediate modes of transport and the number and places of stopovers are
not fixed when the shipment begins. Rather, they depend on various factors, including but not limited to weather and
traffic conditions, change in demand, consolidation of different shipments
Context (or situational) awareness in logistics is increasingly becoming critical. It means that a route plan is decided taking into account as much as possible the current context, i.e. the circumstances and factors that influence the execution of logistic activities. It also implies that if some unexpected situation occurs, a swift response can be taken and the current route plan can be adapted. Learning from past trends and anticipating future events also falls under context awareness. Context data is made available to logistic companies via different data sources, ranging from devices that produce raw data (e.g. sensors) to information service providers that offer sophisticated information from processed data (see Table 1).
Copyright © 2015 by the paper’s authors. Copying permitted only for private and academic purposes.
Three basic challenges exist regarding the usage of context data from diverse sources for SLS. Firstly, data is represented with different encodings, use various formats, and are exchanged with different protocols, which raises syntactic or technical interoperability issues. Secondly, data from different sources can actually refer to the same entity or condition. For example, as an unexpected event, assume that traffic is slow due to snowfall. The information for this event can be provided by sensors on the roads, from a weather website in the form of a RSS feed, from a logistics control tower, or even from social media. Still, this data needs to aggregated if used to derive more reliable or complete results. Thirdly, there is a continuous flow of large amounts of data. Most relevant data has to be captured so that necessary deductions can be made from it. Moreover, this has to done preferably in real-time.
Data Weather Location
Traffic information Water level Disasters
In this paper we focus on the first aspect of interoperability challenges for SLS. We propose a common data format with which contextual information from various sources can be represented in a consistent manner to meet the challenge of technical interoperability. We also demonstrate the usage of the data format by business processes of a typical logistic company using an example case. The rest of the paper is structured as follows: Section 2 presents background information; Section 3 presents the problem analysis; Section 4 discusses our solution approach; Section 5 shows an application of the proposed common data format; Section 6 presents a brief discussion of our results; and Section 7 closes with concluding remarks.
There exist many actors in SLS. Apart from the consignee and the consignor, there are brokers, warehouses, customs, context information providers, and so on (see Figure 1). The business processes of actors are interdependent. For example, LSPs coordinate with warehouses to collect or deliver shipments, but LSPs also interact with context services providers, either following some contractual agreement or using public interfaces, to receive information about the conditions of some planned logistic activity. Frequent transfer of data and process collaboration is required between these actors. The data has to be consistent and interoperable for a smooth logistic flow. For the success of SLS, all actors have to work together during some phase and/or on some aspect relevant to logistic operation. For this purpose, there must be fixed terms of engagement, clear contracts, service level agreements, and also transparent rules for profit-loss sharing between partners. This is so because, by definition, plans (and modes of transport) can change frequently in SLS. If terms of engagement are not clear between collaborating partners, the success of SLS is hampered. The partners must have a common vocabulary for referring to entities and events in logistics domain to avoid semantic errors.
A 4PL is a LSP which aggregates logistic services from different partners and offers it to the customer as one
integrated service. Based on the discussion above, it follows directly, that a 4PL would have to face serious
interoperability challenges in fulfilling a consignment as it uses the resources of different LSPs and context data
originating from different data sources and owned by different context service providers. There exist numerous
solutions in literature to deal with interoperability problems (in logistics). For example, One Common Framework
The logistic domain in EU is very fragmented, i.e., there exist many consortia, unions, virtual clusters, and alliances
based on the size of companies, national or regional preferences, diverse customer segments, technology usage and
type of consignments
The interoperability concerns for any 4PL will not be confined to technology and information alone, rather they
are present at the following levels
In the following section we provide a simple ontology which can be shared between the 4PL and the LSPs to identify events and disruptions. Also we introduce a data format which incorporates the data from different data sources so that it can be used for SLS.
Information about disruptions from various data sources may be of different types and in different formats. To solve this problem, below we first present an ontology for disruptions, which would allow information interoperability. Then we develop a common message format based on requirement of SLS for technical interoperability.
External data sources make information about various events accessible to the 4PL (Table 1). Not every event requires a renewed plan for shipment. Also, not every event would need manual attention from the 4PL or requires that the 4PL informs the LSPs. We first define an event as an unexpected occurrence which may or may not affect a current or future shipment. A disruption is an event which adversely affects a current or future shipment (Figure 3). For example, a road blockage due to an accident would delay the delivery time of a shipment, therefore it is a disruption. When the roadblock is cleared, that is also an event, but no longer a disruption. Every exception is further classified into Permanent Disruption, Temporary Disruption, and Other Disruption. Temporary disruption and other disruption may or may not require a change in planning. In this case the unavailability time of a route/location is either brief compared to the delivery time (temporary disruption) or is currently unknown, e.g. waiting for customs clearance. A permanent disruption requires a change in planning, because the unavailability time of the route or location is significant compared to the delivery time. In Figure 3 (right side) we show how one disruption might change into another disruption due to a new event (more information).
Prior to the shipment being sent, the 4PL plans the tentative route(s) for the shipment. Then, it requests for the current context data from external sources for those routes which satisfy a set of defined criteria (e.g. least polluting, cheapest, minimum stopovers). The data source would then reply with a message containing the current context data with respect to these routes. Routes which have a disruption at any point along them, would be excluded from final possible routes. The external data sources could also reply with a normal event message indicating no exception along the requested routes. Thus messages from the data sources can be divided into three basic types: 1. Normal event message. 2. Exception message, indicating a disruption at one or more locations. 3. An update message for a previous disruption
Based on these three messages the planning module of the 4PL can either do nothing (i.e. follow the current plan), re-plan, request more information, or request human intervention.
In Table 2, we propose a common message format for context information from various data sources.
The fields of this format are such they provide necessary and sufficient information for the planning module of the 4PL. – Header: Each message should have an unique ID, so that it is possible to distinguish between any two messages. Time Stamp indicates the time at which this message was sent. Type denotes the type of the message, i.e. Update message, Normal event message or Exception Message. – Source Information: The 4PL would have a list of accepted sources and the kinds of events they can measure. Source ID contains the data source name. The source ID will give information about the authenticity of the data source. Source Location indicates the location of the data source. – Location: The place where the event has occurred. Geo Location indicates the geographical location (or name of the location) and Location Type mentions what kind of location it is. AN example of the Location field is <Rotterdam, Inland Water Terminal2>. – Time: Time attributes are Start Time, Duration, and End Time of the event. As events are unexpected, the duration time (or end time) are usually not known in advance. But if it is known or can be determined based on similar historical events then it can used by the planning module. – Priority: Certain types of events can be more important, and therefore this field can be used to distinguish between different grades of importance. – Probability: This field is used to distinguish between different levels of probability for the (forecasted, i.e. with a future starting time) event to happen. In case of the event has already happened, like an accident that occurred, the probability field can be set to 1. – Value: This field contains any value which tells us about the property that the data source measures, For example, if a sensor measures the visibility on the road then a possible value can be 100 m.
In this section, we show the usage of data format by a 4PL process. The example message shown in Table 3, is sent by source S012 which is located at Inland Terminal2 in Enschede. This message informs of an exception, on the same day, starting at 16:00 hrs. and lasting for 24 hrs. The priority and probability of the disruption are high. 9. Inform LSPs requests the list of all LSPs associated with the affected OrderID(s) from the Orders Database. 10. Inform LSPs sends the information of the affected order(s) and the duration of the disruption to the LSPs. 11. Inform LSPs calls the Planning Module. The planning module uses the OrderID, LocationName/Type, Start Time, End Time, and the Orders Database to plan a new route. If no optimum plan can be found, it can happen that the Planning Module decides to continue to with the existing plan. 12. The new plan is sent to the appropriate set of LSPs.
In the preceding sections we have mentioned the need of using context data for SLS. We also commented on major interoperability concerns. We conclude that most interoperability frameworks in logistics are lacking over the use of contextual data for planning and execution. For SLS this data is essential.
Clear decision-making at all levels, as shown in Fig 2, is key for successful SLS. A 4PL organization and its partners must have a common business vocabulary, otherwise it would eventually lead to confusion and loss of trust. The partners should also try to make use of open and clear syntax and semantics (in business, information, and technology), so that entry of a new partners is not impeded. EDI is the de-facto method of exchanging information in logistics. Yet, the messages from data sources must be in XML to make their usage more widely applicable and accepted.
We have made the assumption that while planning a route for an order, the 4PL receives information about events from data sources. There are several patterns that can be used to realize this. For example, the 4PL may poll data sources using a request-response pattern, or it may subscribe to data sources regarding specific events of interest. In the latter case, the 4PL may receive regular updates (time-based) or is only informed when certain criteria regarding the events of interest are met (content-based, e.g. a weather forecast if snowfall of more than 10 cm is expected, or a traffic update if a traffic jam of more than 5 km occurs).
Our data format does not contain an information field regarding the cause of the disruption. This can be implemented in a future extension of the format. The advantage of including the cause of the disruption is that any recurring cause can be known in advance and appropriate actions can be taken to avoid it. This is an on-going research and using various evaluation methods like interviews and questionnaires with practitioners are planned to make improvements to the data format.
In this paper, we have put forward the challenges of using real-time data for Synchromodal Logistic Services (SLS). We discussed our approach for handling large amounts of context data from diverse data sources and also to extract relevant SLS-related information from it. This work is part of is an ongoing research effort and various features will become more clear as the research progresses. We have introduced a data format which can be implemented for various data sources for context data and demonstrated its usage in a 4PL process for SLS with the help of an example.
This research is part of the project on IT services for Synchromodality (Synchromodal-IT) and has been sponsored by the Dutch Institute for Advanced Logistics (Dinalog).