A Software Architecture for a Transportation Control Tower

Transcription

1 A Software Architecture for a Transportation Control Tower Anne Baumgraß 1, Remco Dijkman 2, Paul Grefen 2, Shaya Pourmirza 2, Hagen Völzer 3, Mathias Weske 1 1 Hasso Plattner Institut, University of Potsdam, Germany 2 Eindhoven University of Technology, The Netherlands 3 IBM Zurich Research Lab, Switzerland A Transportation Control Tower is a software application that facilitates transportation planners with easily monitoring and dispatching transportation resources. This paper presents a software architecture for such an application. It focuses in particular on the novel aspects of the software architecture. These are: the ability to easily configure the monitoring of resources and tasks; the ability to automatically create the statements for monitoring resources and tasks based on the transportation plan; and the ability to dynamically adjust the monitoring statements, based on adjustments to the transportation plan. A prototype of the software architecture is implemented and evaluated on three usage scenarios. Keywords: transportation management, software, transportation management system, control tower, transportation, transportation planning 1. Introduction On a daily basis, planners at transportation companies are working on the assignment of transportation resources to transportation orders. Each transportation order involves a large variety of activities. Of course, these activities include the actual transportation of the goods. However, they also include logistic activities around the transportation, such as collecting an empty container to transport the goods in, temporary storage of the goods, and transshipment. They also include administrative tasks, such as reserving resources of transportation partners, filling out forms, inspection of the goods, and billing. Transportation planners are responsible for planning and monitoring these activities. This task is made more complex by the fact that the transportation plan for a transportation order often changes, for example, due to changes in the availability or cost of transportation resources. This may have a rippling effect on other transportation orders as well. To support these tasks, a transportation planner would benefit from software that helps him monitor the tasks that have been performed for the transportation order, the tasks that still have to be performed, and the transportation resources that are assigned ISSN: xxxxxxxx print/issn xxxxxxxx online c Taylor & Francis DOI: xxxxxxxx

2 2 to, or are available for, the transportation orders. We call such software a transportation control tower analogous to the control towers that monitor transportation resources in aviation. This paper presents an architecture for a transportation control tower. The architecture is based on an analysis of transportation scenarios from practice. The paper focuses on the novel aspects of the architecture: advanced facilities for monitoring transportation resources; advanced facilities for configuring the transportation plan, including transportation, logistics and administrative tasks; and advanced facilities for enacting changes to the transportation plan, especially generating an overview of the changes to the tasks that must be performed. These advanced functions form the contribution of the work. Against this background, the remainder of this paper is structured as follows. Section 2 presents a brief overview of three scenarios that occur in practice and that are the basis for the requirements for a transportation control tower. Section 3 presents an architectural overview of a transportation control tower. Section 4, 5, and 6 zoom in to three of the advanced functions that are supported by a transportation control tower. Finally, Section 7 presents the conclusion and outlook. 2. Usage scenarios This section presents three scenarios that were developed in collaboration with industry partners. The scenarios represent situations that occur on a daily basis and that require advanced (control tower) functionality from transportation management systems to properly support transportation planners. The section ends with an overview of this functionality Multi-modal planning A transportation planner can plan a multi-modal route for a full container load. To do that effectively, the planner needs to have insight into real-time information about the transportation infrastructure, including both the current traffic conditions and transportation-related events, such as the waiting time at customs or the gate at the harbor. Often, transportation companies make use of other partners to do the transportation. To that end, the transportation planner needs insight into the availability of transportation partners. Using this information, the transportation planner can select the trucks that are closest to the pick up location of the goods. These trucks can either be own assets or assets owned by transportation partners or single drivers. After the transportation plan is created, the planner should be able to automatically distribute the transportation plan to the parties that are involved, including transportation partners. Subsequently, the execution of the transportation must be monitored, the geographical position of the resources involved must be tracked, as well as the status of the transportation steps that have been performed and the steps that still must be performed.

3 Freight Shift It happens every day that transportation capacity or demand shifts from one location to another. For example, an airplane that carries 10 containers may have to land at a different airport unexpectedly due to weather conditions. As another example, an airplane may suddenly have more transportation capacity available, because of the cancellation of a transportation order. Such freight-shifts should be detected as quickly as possible to properly act on them. Nowadays, transportation companies often hear about it at a late stage, for example, when the airplane has already landed at another airport. Once the freight-shift has been detected, transportation planners must change the plans around the affected locations. This involves re-planning the resources that were originally planned to pick-up or drop-of the cargo, possibly even if they are already en-route. It also involves re-planning additional capacity to pick-up or drop-of the cargo at the new location Inland Waterways The use of inland waterway transportation usually is associated with transportation cost advantages and positive environmental performance. However, its reliability is influenced by varying water levels which might lead to restrictions or complete close down of the waterway for days. Since such situations can, to an extent, be foreseen, the creation of robust offline plans, which consider the risk of low or high water levels, and careful monitoring and prediction of water levels, can mitigate the need for ad-hoc online replanning. Based on historical data and information about the current water levels and their development, situations in which the planned transportation by inland waterway might lead to problems due to insufficient water depth can be detected. Since this information can be transmitted to the planner in ample time before the start of the transportation, the planned route can still be changed using other transportation alternatives. The choice of other transportation alternatives is facilitated by the consideration of existing alternatives based on schedules as well as on information about the available capacities and routes shared by transportation partners or by assigning free vehicles to new routes Required Functionality The scenarios above, point to a number of requirements that transportation control tower software should support. A detailed analysis of requirements can be found in (Treitl et al. 2014), but on a high level of abstraction, a transportation control tower should support: the provisioning of information on the availability of transportation resources, including own resources, and partner resources; the provisioning of information on infrastructure availability; automated detection and prediction of disruptions of transportation infrastructure and resources; offline planning (before the transportation is executed); online planning (while the transportation is executed and taking real-time information about resource availability and disruption into account); robust planning (taking into account likely changes to a transportation plan);

4 4 multi-party tracking and tracing based on a transportation plan; and automated reconfiguration of the tracking and tracing facilities based on changes to a transportation plan. 3. Architecture overview Considering the requirements that are explained in the previous section, we developed an software architecture for a transportation control tower (van der Velde et al. 2014). Fig. 1 shows the components that are provided by this architecture. User Interface (Planner) User Interface (Device) Process Configurator Asset Planning Route Planning Transportation planning Information Store Event Manager Orchestration Engine Event Source Figure 1. Architecture for a Transportation Control Tower. The architecture is layered and shows the following components. There are user interfaces for both the planner and for devices that drivers of transportation resources use. In addition, there is a process configurator that can be used by a designer, to describe the activities that must be executed for various types and legs of transportation routes in terms of processes. This component will be explained in more detail in Section 4. Through the user interface, the planner has access to various types of planning algorithms. Both the planning algorithms and the user interfaces make use of information that is either accessible from an (external) information store such as a database or via an event manager. The event manager is a publish-subscribe mechanism that can be used to monitor events that are published by event sources, such as boardcomputers of trucks, road management systems, and AIS transponders of ships. This component will be explained in more detail in Section 5. The tasks that must be executed and monitored during the execution of a transportation plan, are determined by composing them based on the transportation plan and the processes that are designed in the process configurator. These tasks are subsequently managed by the orchestration engine, which also takes care of subscribing (and unsubscribing) to events that are relevant in different stages of the transportation plan and must be shown on the various user interfaces. This component is explained in more detail in Section 6.

5 5 4. Configuring the transportation plan In order to plan the fulfilment of a transportation order, a standard, state-of-the-art plannig tool is used to create a, possibly intermodal, routing for the transportation order or each consignment thereof. Such an intermodal routing is an alternating sequence of transportation legs and transshipments that connects the pick-up point with the delivery point of the consignment. Each transportation leg is associated with a unique transportation mode, e.g., road, train, inland waterway. At this description level, the selection of a specific plan optimizes the cost of fulfilling the transportation order, in terms of money, time, and carbon emissions, while taking specific constraints such as delivery deadlines into account. The plan must then be refined into a detailed actionable plan, which we also call a transportation process. This section explains what such a process looks like, how it is used during the execution of the transportation plan in particular to monitor resources and tasks, and how the process can be dynamically adapted when the transportation plan is changed The transportation process Fig. 2 shows a section of an example of a transportation process. This section corresponds to two legs: first an empty container is procured by a truck and then the truck picks up the goods and drives them to a train terminal for further shipment. Figure 2. Initial part of transportation process example. The transportation process in Fig. 2 is depicted using the process modeling standard BPMN 2.0 (Object Management Group 2011), which we extended by transportation specific annotations such as locations, durations, and deadlines. There are two main threads of actions, shown as horizontal pools. The upper pool follows the consignment and the operators handling it, whereas the lower pool follows the planner who is supervising the execution of the transportation process. Planner and operators communicate by dedicated messages that contain transportation documents or other information (e.g., tasks Send documents and Receive documents ). Besides these document exchanges and the actual transportation tasks (e.g. Transport empty container ), the process contains explicit tasks for loading, unloading, transshipment, document processing, and reserving

6 6 capacity. Later in the process, not shown in Fig. 2, there are additional tasks concerning customs inspection, invoicing and payment and further administrative tasks. Some tasks are ordered explicitly, e.g., Load empty container and Transport empty container, whereas others, e.g., Reserve truck and Reserve train are independent from each other, i.e., they may be executed in any order, which is signified by the + decorated diamond in the diagram. Additional ordering may be imposed by lead- or lag time constraints. For example, the Reserve truck task must be completed at least 60 minutes before the Transport by truck task is started. This is denoted by a corresponding annotation linked to both tasks How the transportation process is used Once a model of transportation process is created, such as the one in Fig. 2, it can be used for multiple purposes. One of the most common uses of process models is process automation using a process engine. Each individual task may be supported by an IT system, such as resource reservation, document management, or accounting and the process model can technically integrate these systems using standard technology for transforming and passing on data between the systems and managing the state of the process. Furthermore, an automated process can easily collect useful data such as the actual time used for a specific task. Such data can help to improve planning in the future and to optimize operations. In this paper, however, we focus on how the process model is used for status tracking. Since the execution follows the process model, the process model can help to show, at each point in time, the current progress. We distinguish process status, task status, and schedule status. The process status shows for a particular point in time, which tasks have been completed, which tasks are currently running and which tasks have not yet started but still may be started in the future. The process status can be visualized for example, by depicting each of these task classes in a different color in the process model. The task status shows the current progress of a particular running task in more detail, which we apply only to actual transportation tasks, e.g., Drive from A to B by truck. Based on some specific status tracking service, e.g., a GPS tracking service for trucks, we can visualize the progress on a dedicated geographical map based on the routing information in the transportation plan that is associated with a particular transportation task. Finally, the schedule status relates the process and task status to the current time, i.e., it says whether execution is on, ahead, or behind schedule. If the execution is behind schedule, another measure estimates how likely a transgression of the final or an intermediate deadline becomes. If this likelihood exceeds a certain threshold, an alert can be shown to catch the attention of the supervising planner. These deadline alerts, the GPS tracking events as well as other useful monitoring information such as weather alerts or traffic congestions are generated in the event aggregation engine, cf. Sect. 5. The process execution subscribes (and unsubscribes) to these specific event sources at runtime by dedicated commands which are attached to tasks or group of tasks in the process model. These event subscription annotation can be added manually to the process model or generated from other annotations. For example, the GPS subscription commands can be generated automatically for the tasks that are classified as transportation tasks using a generic variable truckid that refers to the truck that will be assigned to that task.

7 How the transportation process is created and dynamically adapted Before a process model can be used for status tracking, we have to create it by refining a given transportation plan. To this end, we follow the idea that a process model is composed of process snippets, where we have essentially one snippet for each segment, i.e., leg or transshipment, of the transportation routing. For example, in Fig. 2, the vertical dashed red lines show the boundaries of the snippets. Thus, a snippet constitutes the re-usable model of how a particular leg is operationalized, i.e., whenever a particular segment is used by a particular LSP, it is performed in a way a specific process snippet prescribes. Thus, the process snippet can, once it is initially created, be stored in a dedicated snippet repository and retrieved whenever a specific segment occurs in any routing for any transportation order. Therefore, the transportation process for a particular routing can be created, by (1) looking at each segment of the routing and retrieving a matching snippet for each segment from the repository (2) glueing the snippets together into a full process model. In order to match snippets with routing segments, the snippets get indexed with attributes of the corresponding routing segment. Examples of relevant attributes are the transportation mode and whether the segment is a transshipment. All the above functions, i.e., creating a snippet from scratch, registering it to the repository using index attributes, searching for snippets with transportation routing segments and composing snippets together, are integrated into our process development tool, which we call the Process Development Workbench. The workbench is connected, cf. Fig. 1 to the plan proposer, from which it receives a routing and to the process engine, to which it deploys a fully composed process model, cf. Section 6. In case a transportation plan has to be changed at runtime, say due to an unexpected disrupting event, an online planning tool creates a new transportation plan, from which in turn a new process can be created as above. In our architecture, the new process is again deployed while the process engine takes care of any potential problems that may arise due to the runtime changes, cf. Section Monitoring the transportation plan As business processes are executed in different locations, times, and by a variety of people and devices, especially in logistics, enabling business process monitoring through event processing is not trivial but comes with numerous benefits (Luckham 2011, Cabanillas et al. 2013, Herzberg et al. 2013). In the scope of the GET Service project, we implemented an event manager (Baumgrass et al. 2014) responsible for collecting events from different sources and processing them. Through this event manager, we offer a unified interface to clients, planners, information providers, and other stakeholders for subscribing to occurrence(s) of events that they are interested in. Thereby, it is able to extract events from messages in different formats exchanged between the stakeholders and to publish transportation-related events. Furthermore, the event manager provides a standard message queuing service to distribute events to the stakeholders. In this paper, we focus on the usage of event subscriptions during transportation execution and refer the interested reader for the technical details of the event manager to (Baumgrass et al. 2014) and the tutorials at The implemented event manager builds on Esper (Bernhardt and Vasseur 2007). Esper is an open source component for event processing and event stream analysis with various

8 8 techniques for filtering, aggregating, analysing and reacting to events. Its SQL-like event processing language (EPL) is one of the most expressive querying languages for complex event processing (EsperTech 2014). Therefore, the event manager provides event subscriptions in Esper s EPL. To this end, we mainly require the following course of actions to enable event subscriptions in the GET Service platform (see Fig. 1): (1) Register the event types that define the structure and semantics of events provided by the connected event sources. (2) Define the event types for transportation-related events. (3) Specify aggregation rules that define how events are combined to transportationrelated events. For example, the movement of a truck may be identified by analysing whether the geographical coordinates of two subsequent GPS events from a truck change. (4) Event subscriptions in Esper s EPL are send to the event manager by the orchestration engine, see Section 6. The Esper engine integrated in the event manager registers each event subscription via listeners. These listeners get informed if the subscription matches observed events from relevant event sources with the specified conditions defined by the subscription (e.g., events occurring in a certain time interval). As mentioned in Section 4, event subscription annotations are generated or added manually to process models. In the following, we will elaborate on the usage of event subscription templates and aggregation rules for an automated generation of event subscriptions for logistic processes. For the usage scenarios in Section 2, we assume that all required event types are registered in the event manager. Therefore, we are able to provide event subscription templates, which are integrated in the process models as annotations (see Section 4) and which are used to subscribe to the event manager via the orchestration engine (see Section 6). These templates include pre-defined parts of event subscriptions, are easy to complement for planners, and, therefore, used to unburden the planner from writing subscriptions in Esper s EPL from scratch. Furthermore, these templates might even be used to completely automate the event subscription by the process orchestration engine during run-time. A selection of templates to illustrate the automated generation of event subscriptions is provided in Listing 1. Listing 1 Examples for event subscriptions using Esper. Subs1: SELECT FROM V e h i c l e P o s i t i o n U p d a t e Subs2: SELECT FROM V e h i c l e P o s i t i o n U p d a t e ( o p e r a t o r I D=$truckID ) Subs3: SELECT FROM V e h i c l e P o s i t i o n U p d a t e. w i n : t i m e ( $ t i m e I n t e r v a l ) OUTPUT EVERY $ t i m e I n t e r v a l Using the subscription Subs1, a planner will be notified in real-time about all events of type VehiclePositionUpdate. This event type is the general event type for all location updates of vehicles, e.g. trucks, aeroplanes or vessels, in the GET Service project. This event type comes with an attribute to identify the specific vehicle for which the event occurred, named operatorid. Thus, we are able to use Esper s filtering capabilities to reduce updates to the vehicles (e.g. a specific truck that is assigned to a task given by its id as $truckid) that are currently involved in a transportation as shown in Subs2. At run-time the specific id is replaced by the orchestration engine as described below. In case, position updates of vehicles are not required as continuous output but only in a fixed interval, we can define the output interval via Esper as shown in Subs3. For example, defining the $timeinterval as 5 minutes, the subscription Subs3 limits the output row

9 9 to every 5 minutes (output every 5 minutes) that only contains the events of the last 5 minutes (VehiclePositionUpdate.win:time(5 minutes)). In the GET Service project, we decided to mainly work with high-level and transportation-related events for which we provide subscription templates. This makes the templates more generic and easier to maintain. To obtain such high-level events, aggregation rules are defined in the event manager that combines events occurring together in sequence, in parallel, or without an order. For this reason, aggregation rules are also more complex as their objective is to combine event information contained in different events, eventually coming from different event sources with different attributes. Examples of aggregation rules are provided in Listing 2. Listing 2 Examples for aggregation rules using Esper. Aggr1: INSERT INTO T r a n s p o r t a t i o n F i n i s h e d SELECT FROM V e h i c l e L o c a t i o n E v e n t ( o p e r a t o r I D= $truckid, l a t i t u d e=$ l a t i t u d e, l o n g i t u d e=$ l o n g i t u d e ) Aggr2: INSERT INTO V e h i c l e P o s i t i o n U p d a t e SELECT v2. FROM PATTERN [EVERY v1= V e h i c l e L o c a t i o n E v e n t > v2=v e h i c l e L o c a t i o n E v e n t ( o p e r a torid=v1. operatorid ) ] WHERE ( v1. l a t i t u d e!=v2. l a t i t u d e OR v1. l o n g i t u d e!=v2. l o n g i t u d e ) Aggr3: INSERT INTO V e h i c l e N o t D e p a r t e d SELECT FROM PATTERN [EVERY v1=v e h i c l e L o c a t i o n E v e n t > v2=v e h i c l e L o c a t i o n E v e n t ( operatorid=v1. operatorid, v1. l a t i t u d e=v2. l a t i t u d e, v1. l o n g i t u d e=v2. l o n g i t u d e ) ] WHERE current timestamp > $ d e a d l i n e Aggr4: INSERT INTO T a s k N o t E x e c u t e d SELECT FROM PATTERN [EVERY a=t a s k L o g ( taskname = $taskname, t a s k S t a t e = Enable ) > ( t i m e r : i n t e r v a l ( $ d e a d l i n e current timestamp ) AND NOT T a s k L o g ( taskname=a. taskname, t a s k S t a t e = Terminated ) ) ] Aggregation rule Aggr1 generates events of type TransportationFinished, when a truck ($truckid) arrives at a certain geographical position ($latitude and $longitude) represented by an event of type VehicleLocationEvent. An orchestration engine may subscribe, for example, to TransportationFinished to enable or start (multiple) subsequent tasks. In Esper, we may also define pattern that specify one or more combinations of events. For example, Aggr2 defines a pattern to check whether the position of an operator (e.g. a truck) changes in two subsequent location events (VehicleLocationEvent -> VehicleLocationEvent). Similarly, we are able to aggregate subsequent events with unchanged locations to events of type VehicleNotDeparted, whenever the time the sequence was detected exceeds a pre-defined deadline (WHERE current timestamp > $deadline), see aggregation rule Aggr3. In other words, we are able to check whether a vehicle did not move till a certain deadline. Assuming the event manager receives events from task execution (event type TaskLog), we may also define a pattern to identify whether a task has not been executed. Through Esper, we are able to check for the occurrence of events of a certain type using certain conditions in a given time interval. In the aggregation rule Aggr4, we look out for a certain time (timer:interval($deadline - current timestamp) after a task was enabled (TaskLog(taskName = $taskname, taskstate = Enable )) in which no event of the same task was received for its termination (NOT TaskLog(taskName=a.taskName, taskstate = Terminated )). 6. Enacting and changing the transportation plan The orchestration engine takes the composed transportation process that it receives from the process configuration component, cf. Section 4.3, and ensures that the tasks specified therein are properly executed and monitored. When a change is made to an already

10 10 running transportation order, the orchestration engine must take care of cancellation of running tasks, and compensation of tasks that were already executed Enacting the transportation plan An orchestration engine provides a means to enact transportation processes, by generating instances of a transportation process. This instance contains the transportation tasks that need to be carried out either by a human (e.g. the reserve truck task for the transportation process from Fig. 2 could be performed by a planner), or automatically (e.g. the create CMR task for the transportation process from Fig. 2 could be performed automatically based on available information). The orchestration engine has a task handler to monitor the state of transportation tasks that are derived from the transportation order and to enable different users, e.g. a planner, to perform the tasks that need to be done. The task handler of the orchestration engine is illustrated in the Fig. 3. To the right it shows the process instance that is being executed and above that, the tasks that can currently be performed by the person that is logged in. When the state of a task changes, e.g. from planned to executing or from executing to completed, this change is recorded within the orchestration engine. In addition to that, the monitored resources may vary per process or per task. In order to receive notifications from the monitoring component about the resources that must be monitored, the orchestration engine has to subscribe to predefined queries, as they are explained in Section 5. The transportation process itself as well as all of its tasks can be annotated by these predefined queries. If the transportation process is annotated with the query, this query will be subscribed to when the transportation process is instantiated. It will be unsubscribed from when the process is completed. If a task is annotated with the query, this query will be subscribed to when this task is ready for execution. It will then be unsubscribed from when the task is completed. In addition to these two cases, a query subscription for a group of tasks is also possible. Events in the transportation process are mostly based on the events received from the monitoring component. For example, when a specific truck arrives at the destination, the monitoring component notifies the orchestration engine that the drive task is finished. After the subscription phase, the orchestration engine listens to the received notifications. These notifications can be received once or multiple times. For example, if the orchestration engine subscribes to receive a finish driving notification, the response will be received once. However, if it subscribes to receive the Geo-position of a truck continuously to display it on a screen, the responses will be received multiple times since the location is changing due to the fact that the truck is moving. Fig. 3 illustrates this. It shows how the current position of a truck is shown on a screen, based on a subscription that is sent to the monitoring component, when the drive task starts. However, Fig. 3 shows only one transportation order, while the orchestration engine is able to carry out multiple and different orders simultaneously. This feature is shown in the Fig. 4, where eight different transportation orders are being performed at the same time. The tranportation orders are shown to the left of the screen. Clicking one of the transportation orders brings up the detailed view from Fig. 3.

11 11 Figure 3. An Executing Transportation Order Figure 4. Multiple Transportation Orders in the Orchestration Engine 6.2. Changing the transportation plan In addition to the mentioned notifications from the monitoring component that do not have any effect on the design of the transportation plan, the orchestration engine may receive some unexpected notifications while the transportation plan is executing. These notifications may cause some changes in the design of currently running transportation plan. The orchestration engine needs to be able to handle such changes even when the execution of the transportation plan has already started. For example, consider a situation in which there is unforeseen construction on part of the railway track, and consequently, the trains are completely eliminated from their original plan. Based on the real-time data, the monitoring component is informed about this situation and notifies the orchestration engine. The orchestration engine notifies the planner, who changes the original transportation plan, by removing the rail leg of the transportation and inserting a truck leg. He then deploys the updated version of the

12 12 transportation plan to the orchestration engine. This change is happening while some tasks of the original transportation plan have been already performed, i.e. they are in the completed states. When deploying and instantiating the updated version of the transportation plan, the orchestration engine needs to dynamically reconfigure the state of the newly created instance, based on the last known state of the original transportation plan. This procedure is called instance migration. However, instance migration is not always possible. In such cases, one possible solution can be migrating the instance to the closest possible state, called migration point. Usually, this procedure requires some roll-backs and cancellations of the tasks that have been done in the original transportation plan. Returning to the example, some tasks such as reserve train capacity require cancellation. In addition, some custom declarations need to be re-submitted due to the change in the original plan, and consequently, a rollback is required in order to enable the re-execution of this task. Finally, an available truck should be selected that is as close as possible to the latest Geo-position of the transporting goods to take over the rail transportation with the minimum side-effects on the important criteria such as carbon emission and transfer time. To the best of our knowledge, there is no industrial or academic orchestration engine designed that is able to dynamically perform such instance migration. In order to select an appropriate orchestration engine for the further development, we have surveyed the existing engine in (Pourmirza et al. 2014). Furthermore, in our previous work (Pourmirza and Dijkman 2014), we have developed an algorithm that facilitates the change in the detailed transportation plan, while the abstract-view of the plan remains the same before and after the change. 7. Conclusion and outlook This paper presented an architecture for a transportation control tower, which is a software application that transportation planners can use to manage and monitor their transportation orders. The paper focused in particular on the three innovative components of the transportation control tower: An advanced monitoring component for subscribing to transportation related events generated, for example, by the boardcomputers of trucks. An advanced component for creating a process to enact a transportation plan, including tasks for managing the actual transportation, transportation-related activities and administrative activities. An advanced component for enacting the transportation plan, and automatically subscribing to transportation related events depending on the tasks that are being executed. The architecture has been implemented in a prototype, of which a demo is available on-line 1. Currently, the the architecture supports a workflow for a transportation planner, in which the transportation planner can create a plan for a transportation order. The plan states the actual transportation activities that must be carried out: drive from A to B, sail from B to C, etc. Based on the plan, a process can be created that specifies the tasks that must be carried to enact the plan in detail. The process contains tasks such as: reserve 1

13 REFERENCES 13 truck, fill out forms, drive from A to B, etc. The process can contain statements on the transportation related events that are interesting to monitor during the various tasks. For example, it can state that the Geo-position of the truck is interesting during the drive from A to B task. The architecture can enact the process, by tracking the states of the tasks that are being executed, supporting the planner in executing these tasks (e.g. by facilitating data-entry and messaging tasks), and displaying the transportation related events that arrive according to the subscriptions in the process. In future work, we will develop a means to automatically derive a transportation process from a transportation plan. Currently, the transportation process can be composed from so-called process snippets that correspond to the various modes of transportation, but this composition must still be done manually. In addition, we will develop means to support the automatic migration of a transportation process into a new transportation process in case the transportation plan changes. Such migration would involve migrating the state of tasks in the original process, including the information that is stored during their execution. Acknowledgement The research leading to these results is part of the GET Service project ( getservice-project.eu) and has received funding from the European Commission under the 7th Framework Programme (FP7) for Research and Technological Development under grant agreement n o References Baumgrass, A., et al., Conceptual architecture specification of an information aggregation engine, Deliverable report, GET Service, Service Platform for Green European Transportation. [online] [Accessed 31 July 2014 from: getservice-project.eu/en/project/public-deliverables]. Bernhardt, T. and Vasseur, A., Esper: Event Stream Processing and Correlation. [online] [Accessed 31 July 2014 from: Cabanillas, C., et al., Towards the Enhancement of Business Process Monitoring for Complex Logistics Chains. In: 11th International Conference on Business Process Management Workshop on Process-Aware Logistics Systems, LNBIP 171 Springer. EsperTech, as of July Esper - Complex Event Processing. [online] [Accessed 31 July 2014 from: Herzberg, N., Meyer, A., and Weske, M., An Event Processing Platform for Business Process Management. In: Enterprise Distributed Object Computing Conference (EDOC) IEEE, Luckham, D.C., Event processing for business: organizing the real-time enterprise. John Wiley & Sons. Object Management Group, Business process model and notation (BPMN) v2.0 (formal/ ). [online] [Accessed 31 July 2014 from: Pourmirza, S. and Dijkman, R., A Survey of Orchestration Engines, Deliverable report 7.1, GET Service, Service Platform for Green European Transportation. [on-

14 14 REFERENCES line] [Accessed 31 July 2014 from: public-deliverables]. Pourmirza, S., Dijkman, R., and Grefen, P., Switching Parties in a Collaboration at Run-time. In: Enterprise Distributed Object Computing Conference (EDOC) IEEE. Treitl, S., et al., Use Cases, Success Criteria and Usage Scenarios, Deliverable report 1.2, GET Service, Service Platform for Green European Transportation. [online] [Accessed 31 July 2014 from: public-deliverables]. van der Velde, M., et al., GET Architecture Definition, Deliverable D2.2.1, GET Service, Service Platform for Green European Transportation. [online] [Accessed 31 July 2014 from: public-deliverables].