1. Introduction
Digitization is an ongoing mega-trend fundamentally changing and disrupting the transportation and logistics sector. Along with an aggravated competition and conventional business models increasingly under pressure, involved parties are called to innovate or die. In the light of multiple digital technologies entering the business-to-consumer markets, as well as the business-to-business segments, new services and business models are within reach. However, many logistics companies struggle to develop viable new concepts based on such new technologies in a structured and dedicated manner. Paradoxically, the higher the number of possibly appropriate technologies buzzing around strategic management and decision-makers in the companies, the greater the confusion and helplessness.
A good example of such an evolving technology having failed to make a significant impact in the transportation and logistics industry to date are cyber-physical systems. With the help of a structured workshop procedure and the stepwise development of a solution, prospective users may approach the digital transformation of processes and entire business models in a slow and careful manner.
The six-phase approach presented in this work encompasses the clear identification of the expectations towards the future state, the affected application setting, and the requirements of the solution before then sketching and designing a technical solution, implementing and testing it, and safeguarding the achievement of the predefined goals prior to operational use. The different phases are operationally run in the form of workshops and other interactive communication formats in which the persons that are actually involved in the considered process are supposed to have their say and express their needs to conduct their work more efficiently.
The major objective of the work is to prove the applicability of a workshop procedure of stepwise realizing smart logistics processes with the help of cyber-physical systems and complex event processing which has been developed and tested both in a lab environment and in a real-world environment.
The transportation and logistics sector features a set of promising preconditions for a highly impactful implementation of both technologies in combination. To these belong the highly fragmented character of the industry with few large and thousands of small and medium-sized players, multiple actors and stakeholders involved, heterogeneous system landscapes and process designs, short contracts, little room for (technical and financial) investment, to name a few. All of these lead to a substantial backlog in the light of ongoing digital transformation of the entire sector, whereby small and efficient solutions may already yield considerable gains in efficiency and measurable performance improvements. Details of the goal of the present work will be presented in detail at a later stage.
By means of three use case examples from various areas of the transportation and logistics sector, the ease of application of the workshop procedure and its usefulness are presented and proven. The first use case example refers to the road-borne post-haulage of an international airfreight supply chain process between Europe and China. The new solution allows for better re-planning due to immediate detection of problems. The second use case example deals with the synchronization of the multimodal transshipment in a German dry bulk port in order to improve service levels, raise resource efficiency, and reduce cost. The third use case example shows the storage and retrieval process in the distribution center of a European fashion retailer, leading to increased visibility of the processes and less process errors.
With the results developed in the workshops, the technical realization of the solution may begin, ranging from the sourcing of the different technical components over the programming of the different event patterns to the actual roll-out including deployment, implementation, and testing. Ultimately, the prototypical technical realization is to be followed by the necessary adjustments and modifications prior to the operational use in the respective commercial environments.
3. Workshop Procedure
After having explained the idea of smart logistics, as well as the concepts of cyber-physical systems and complex event processing, the following section refers to a structured workshop procedure in order to deploy the above-mentioned technologies in transportation and logistics processes, and thereby, to realize the vision of smart logistics.
As there has been no structured approach until recently, the methodological approach that is presented by the authors in their latest works aims to connect that vision with the mentioned technological enablers [
1]. The approach foots on six phases, of which three are addressed in the form of workshops and interactive communication with future adopters. The six phases encompass the clear identification of the expectations towards the future state, the affected application setting, and the requirements of the solution before then sketching and designing a technical solution, implementing and testing it, and safeguarding the achievement of the predefined goals prior to operational use. In order to reduce the risk, it does not use only newly developed concepts, but—as far as possible—relies on proven ones. An illustration of the six-phase approach is given in
Figure 1.
After the initial idea generation, Phase One commences with an appropriate environment for the smart logistics process applications to be identified. Furthermore, promising use cases need to be determined and their implementation potential needs to be evaluated. The expenditure must be within a reasonable proportion to the potential benefit. Further, the benefit potential has to be actually exploitable. Lastly, it has to be checked if the smart logistics criteria apply. Whereas, the first four steps of phase one can best be addressed by the decision-makers from practice, the benefit potential and the smart logistics criteria were assessed alongside the workshop moderators, as presented in earlier works [
1]. Scientifically spoken, the inclusion of Schulze’s benefit categorization and Uckelmann’s smart logistics criteria is useful in order to safeguard the suitable character of the respective solution [
4,
23]. In practice, the authors suggest that at least four of the eight characteristics are fulfilled. However, this may be dependent on the specific transportation and logistics process.
Phase Two deals with the design and development of the solution. In this phase, the cyber-physical systems as data sources and complex event processing as a processing mechanic for data are realized. To combine cyber-physical systems and complex event processing, Ref. [
24] proposed the process-oriented event model (PoEM). This approach aims to model real-world entities and the relationships, and to enable event-oriented target planning by monitoring event streams, spotting interesting events in continuous data streams, and comparing the detected events with pre-selected values or thresholds [
24].
In essence, measurements are derived from a data stream of an entity involved in the respective transportation or logistics process. Each measurement is observed and interpreted when comparing them with predefined event profiles. If there is an important event, then the desired state and the actual state are being compared. Any future or current deviation representing the result of the comparison leads to a correspondent action and role. After that, the process owners and decision-makers are informed. The disadvantage of the PoEM model supposedly is its concentration on a single cyber-physical system only. Consequently, its scope is not sufficient for supply networks consisting of various parties. An advancement of the PoEM model was proposed by [
3] by means of the so-called extended process-oriented event model (ePoEM). With the help of this model, business processes, and multiple systems can be included [
2,
3]. As shown in
Figure 1, the nine steps are suggested to be most effective for requirements engineering.
Phase Three functions as a control mechanism for the aimed objectives and the solution’s efficacy. The phase commences when a solution based on CPS and CEP has been designed, developed, implemented, and tested. Despite the most important tasks of the workshop procedure having already been finished in the previous phases, the third phase is constructed to check whether the agreed goals have been reached [
1]. Different questions can arise in this phase. For instance, whether the solution has been implemented successfully or whether the process is running better than before. Most importantly, the key performance indicators of the affected processes need to be considered as part of a target-actual comparison in order to check the effectiveness of the solution and to safeguard the achievement of the predefined goals.
The presented workshop procedure has been validated by various practitioners. For instance, the technical director of a German software company specialized in logistics solutions especially warehouse management systems both for small and medium businesses and larger enterprises have been interviewed. Projects are based on standard software products provided by the company, but usually require extensive customization to suit the facilities, processes and individual preferences of the client. With the examples of two different customers (a cold store for meat products and a larger distribution center for a fashion retailer), the project delivery and requirements engineering methods have been examined. Generally, customers have a very low level of specification detail. Therefore, usually, the first step is to conduct a use case analysis in which roles, activities and systems are discovered. The use cases are detailed in process or activity diagrams, and iteratively improved during workshops. Problems that arise in this setup are that usually the clients center around the “happy path” of the process, i.e., special cases or error handling activities are neglected. This, in turn, leads to missing features in the functional specification or late changes in the software development lifecycle—both of which ought to be prevented. The technical director mentioned that two techniques are helpful to discover caveats. First, the workshop moderator asks for the physical material flow, forcing the participants to think in real processes and less abstract cases. Secondly, one can simulate the process digitally or physically by prepping a meeting room and reenacting processes, as documented.
Innovation potential in running systems is often not discovered until a person in the customer organization realizes cost-saving opportunities. Smart logistics solutions often require some investment and may bear a risk to the running warehouse operation. Therefore, there is a barrier for innovation that requires persuasion of the stakeholders.
All in all, the presented workshop procedure addresses the major concerns and pain points in typical encounters between ICT solution providers and their transportation and logistics customers. Therefore, it is expected to be highly effective.
4. Use Case Examples
In this chapter, the focus will lay on the description of three real-world use case examples in which the above-mentioned structured workshop procedure will be applied upon. Beforehand, there will be some explanations regarding the reasons for selecting these three companies, the goals of the workshop procedure, the goals of the companies, the workshop procedure and the interim and final results of the workshop procedure in the course of the workshops as well as the goals of the authors.
The three companies have been chosen for different reasons. Firstly, the size of the company was a factor. In order to prove that it does not matter whether the company is a global player or if it is a smaller organization and that the workshop procedure is applicable on any size, the authors have searched for candidate companies of different sizes. Ultimately, the three selected companies differ by size indeed and range from approximately 500 to more than 50,000 employees. Secondly, the type of cargo is not a decisive factor for the success of the approach, as the implementation of sensor sources may not seem applicable to all cargo types immediately. Accordingly, the three selected companies handle all kinds of goods from general cargo of smaller and larger size over palletized and unpalletized consignments to dry bulk goods. Thirdly, each of the enterprises operates within different logistics functions and were selected regarding that for the following reasons: to gain a certain degree of representativeness, it was important to have partners who have different core activities within the transportation and logistics sector. The three main functions of logistics are transport, transshipment, and storage. The term “logistics” is one with several different definitions [
25]. Nevertheless, all of those definitions contain similarities. Logistics processes originally comprise of transport, storage, transshipment, and picking. Consequently, three key characteristics or tasks are apparent: dislocation or change of place (transport, transshipment), change or passing of time (storage), and change of arrangement (picking, transshipment) [
25,
26]. Furthermore, [
26] add that such functions are a bypass for the flow of goods and information and they cause an economic use. Important to know is the classification of these functions as services, because goods are only moved but not physically changed. Consequently, to cover the term “logistics” comprehensively, the three use cases were selected from the core logistics functions transport, storage, and transshipment.
The goal of this work is to apply the newly developed and thoroughly tested structured workshop procedure on typical transportation, transshipment, and storage processes for the design and configuration of cyber-physical systems in combination with complex event processing. With both technologies involved, real-world processes can be digitized with the above-mentioned workshop procedure in an easy manner by equipping them with both hardware and software components. One objective is to identify the most urgent problems in the company operations, which also appeared fairly solvable, and to validate these problems by logistics and supply chain practitioners who are confronted by such typical problems every day. Another objective is to derive and define the requirements for a technical implementation of CPS and CEP from actual processes and deviations in order to collect the relevant requirements as correctly and completely as possible. Therefore, the three selected use cases in total are both heterogeneous and universal. As indicated above, the applicability of the workshop procedure for a large multi-national corporation should ideally be the same as for a smaller company with less complex processes and supply chains and a narrower geographic outreach. The only difference between the participating companies lies in the duration of the development process at a large company with complex supply chains or more intricate command structures as many issues resolved by internal checks and consultations. Worth mentioning is also that another objective of this work is to solve identified problems with cyber-physical systems. After the development of the method and the examination of both in a laboratory environment and in a real-world setting, all of which have been published earlier, the focus of the present work is to apply the workshop procedure in real-world use cases and to make use of their effectiveness in order to engage in targeted requirements engineering for useful cyber-physical systems to be deployed in suboptimal logistics process [
1,
2,
3]. Therefore, the development of suitable solutions for the three use cases are to be fostered to the point of actual technical implementation of the solutions that have been designed and developed at the end of each of the respective workshops. In essence, the results of the workshop form the base for the following work including selection, procurement, implementation, and testing of the technical devices and software systems.
The companies on the other side may have objectives of their own that trigger them to engage in these workshops. For most companies, it is already sufficiently interesting to gain a proper documentation and visualization of their own processes because such well-documented process descriptions and visualizations oftentimes do not exist in the companies at all. In some other cases, such documentation and visualization may exist indeed—however, in insufficient form only as some additional information, particularly about informal steps, is missing in the documentation. So, explaining all of this formal and informal knowledge to external persons raises their own awareness of the processes and problems. In addition, a structured recording to visualize a process is valuable to companies as well because it can be re-used for other purposes as well. If the documentation proves to be correct and useful, the companies can certainly use this as a cornerstone for the development of further solutions. Having said that, the companies have been aware about the fact that they do not immediately get a turnkey solution in the form of a cyber-physical system with complex event processing by just having participated in the workshop. On the contrary, they have understood that they have laid the foundations for that and have gone the first steps towards the required and desired solution.
Generally, such a workshop may take from one or a few hours to a half day. The workshops were held at the companies’ premises and had an important role for the utility of the presented workshop procedure. The subject matter of the workshops was the careful examination of a typical process with the help of a well-informed expert who about knows about the current course of the processes and their major shortcomings. So, it is particularly important for the success of the workshops to have knowledgeable participants from the companies who again have been identified and selected by themselves. By including those people who are confronted with specific problems in their companies on a daily basis attending, the likelihood of moving the entire technical development to the right direction and achieving effective and meaningful results in the end is elevated considerably. Apart from the company expert, one or several workshop moderators take part in the workshops, with one leading the interactive conversation with the participant and the other recording and documenting additional information that is mentioned during the workshops. For the performance of such workshops, one or several whiteboards with plenty of room and sufficient equipment for graphical and written explanation of process steps and interdependencies is highly advisable. In the end, every participant is to feel invited to contribute to the development of a common understanding of the process and their current problems.
Concerning the procedure, the participant is asked to explain a certain typical process at first. Ideally, the selected process is a process on which the company can capitalize in the future. The choice of the particular process is part of the responsibility of the participating expert as he or she is the one capable of identifying a promising business process along with their current shortcomings. So, this process should ideally exhibit the most urgent and obvious problems the company has so that the level of suffering and the need of a solution are maximal. At the same time, the selected problem should of manageable scope and appear fairly solvable. In general, the workshop moderators are allowed to ask questions and have their doubts cleared during this step. As it is an essential step, the recording of the current process takes most of the time and concentration of the workshop participants.
Then, the explained process needs to be visualized. In collaboration, the workshop attendees create a process map, which splits the selected process into single steps. It is documented in graphical form, mostly in the form of an activity diagram that is enriched with additional information on the process. The experts receive a properly documented and well-visualized process diagram in the aftermath of the workshop, which again is considered as one of the main benefits for the participating experts.
From the process explanation and documentation, the so-called object map is derived. An object map contains all elements, mainly technical ones, which are involved in a certain process. For instance, it may contain a truck, a forklift, or a dispatcher, all these are actors, which are part of the process. This step of the workshop is to raise the awareness for the process and the interdependencies among the participating parties from a systems theory perspective. The subsequent step is to derive so-called observables from the object map. Observables refer to the object map, which again is closely linked to the process map. Observables are observable items of the recorded objects, such as visible characteristics or measurements. Generally, it is possible to measure different values, like temperature, distance, or position. In this step, all observable items of the recorded objects are collected in order to keep the solution space as large as possible. Precise measurements can be derived from virtually each observable. These measurements may both represent desired states, a tolerance interval, for instance, or undesired ones, e.g., a threshold in case of an emergency.
As a following step, the company experts have to identify the largest or most important pain points emerging within the discussed process. The selection of the pain points rests with the company expert, as he or she is the only one that is capable of assessing the urgency and adequacy. After that, the workshop moderators develop ideas on how to detect the pain points on an event level. To do so, profound knowledge of the involved objects and available measurable items is essential to create event patterns as a digital image of a real problem. For each case of a pain point, it makes sense to determine critical characteristics that must be fulfilled. This can be a predefined threshold that a value is expected to meet or, at least, not to exceed, or a tolerance interval in which a particular measurement value is supposed to range. To use the discovered pain points appropriately, the authors develop rules out of the pain points by translating the identified problems in detectable event patterns. By defining a series of critical measurement values that, alone or together, represent a suboptimal process or a serious problem in the real world, a technical system consisting of CPS and CEP is able to detect critical situations automatically. Hence, the event patterns are then used for scanning the continuous data streams coming from CPS and detecting the critical situations. The event patterns that are looked out for are basically the deductive rules, because they have been deduced from the processes, objects, observables, measurements, pain points, and threshold values that were identified before. A complex event is composed of different singular events, i.e., different individual measurement values. When an event pattern representing a deductive rule is detected, an (automatic) answer to that event is triggered. In a nutshell, when the CEP system detects certain events, which symbolize a real-world problem, in the event stream coming from the CPS, it initiates a reaction. Such a reaction may range from a simple alert on the screen of a decision-maker to a fully automatic trigger of connected hardware systems to change the condition, remedy the situation, and lower the risk eventually.
On completion of the workshops, the companies have their processes documented and visualized in a proper and useful manner, the objects within these processes identified and pertaining observable and measurable items that are assigned to these objects. In addition, the pain points of the selected process are clearly identified. Moreover, the references regarding the rules according to which a deviation or a problem can be detected are given. The same applies to the rules of reaction to each of these problems and deviations.
All in all, the authors did not only intend to have a smoothly working workshop procedure and an efficient way of getting the specific process visualized but also an effective means to get the pain points identified, technical solutions designed, and relevant event patterns set up for later data processing in real time.
Now following, the three use cases will be described thoroughly to convey a good understanding of them at the end of this chapter. While the first use case is about a post-run from an airport to a storage unit, the second use case concentrates on a process in which several handling steps have to be processed. The third use case emphasizes the storage from the unloading of a truck into the storage unit. In this order a look will be taken at transportation process, a transshipment process, and a storage process.
The description procedure will be the same for all three cases. First, there will be an explanation of the purpose of the use case company. Secondly, there will be a zoom-in on the specific processes that were looked at in the real world. Those zoomed in processes will be explained in detail. After that, there will be looked at exceptions that trigger certain events within the process. In the end, this chapter will be closed with a look at the criteria for smart logistics and if the processes are applicable on smart logistics.
4.1. Real-World Use Case Example: Transportation
The first use case example refers to a large multinational company—one of the leading global logistics service providers, which does not only offer transport services via sea, air, and land, but also contract logistics, value-added services, and other solutions. Consequently, the complexity of their processes is high because countless variables have to be taken into account for the decisions to be made and the tasks to be completed to the ultimate satisfaction of the customer. Important for the presented approach is not to look at a transportation process as a whole, for instance, but to focus on a particular fraction of it. Instead of contemplating a global transportation from the origin to the destination, the considered transportation process is divided into legs, which are then considered isolatedly. Furthermore, the process is divided into four general phases: sales and alignment, planning, execution, and completion [
27]. As can be seen in
Figure 2, the considered process in this case refers to the transportation of general cargo. Each box in the figure represents a participant of a typical supply chain who is in charge of a certain process step and in possession of the goods to be hauled. The process starts with a trucker bringing the goods from a shipper company to an airport, possibly with an intermediate handling at the premises of the freight forwarder. From the airport, the goods are flown to the destination airport before a truck forwards the goods to the consignee ultimately. As the whole process is too complex for an examination of the applicability of CPS and CEP, the use case is confined to the post-run from the destination airport to the consignee.
The entire post-run is illustrated as an activity diagram in
Figure 3. The swim lanes represent four parties: consignee, trucker, air carrier, and forwarder. The company of the use case example acts as the forwarder who firstly receives a shipment alert from the air cargo carrier or the airport.
On receiving the shipment alert, the forwarder has to make sure a truck is available for pick-up by the time the goods arrive at the airport, ideally with as little time as possible between landing of the air plane at the airport and arrival of the truck there. As it is a globally operating company, most of the time the forwarder organizes a truck from his own company. It is also possible that the truck is engaged from an independent forwarding agency or a small transportation company. Preferably, the booking confirmation along with an invoice from the shipment agency (trucker) is being forwarded to the forwarder immediately. As a reaction to the issued invoice, the forwarder accepts the same if the terms and contract sum agreed upon are correct. With that step, the forwarder has fulfilled a part of his obligations and the sales and alignment phase comes to an end.
In the next phase of planning, the air carrier needs to release his plans to schedule the pick-up of the cargo. As the air carrier knows when the airplane is going to arrive, he can estimate when and where the goods will be ready for pick-up. Based on this information, the trucker can schedule the arrival of his truck. Therefore, an excellent communication between air carrier and dispatcher, who may belong to either the forwarder or even the trucker, throughout the process is necessary. In order to confirm the pick-up details to the forwarder and to print the loading list, the trucker has to know several things: he must have a truck with the needed capacity and the recognized authorization certification to pass entry control activities at the airport. When the trucker has finally confirmed the pick-up details, the next step for the trucker is to print a load list. The load list serves as an insurance document and as the entrance permit to the airport grounds.
With this step completed, the planning phase is finalized and the next phase, the execution, begins. The execution phase starts with the trucker leaving the premises of his company and driving in direction of the airport. While the waybill is with the truck driver, the forwarder prepares and checks all the needed documents for customs. Notably important is that the forwarder, and not the customs authority, transmits all relevant data to the authorities for data registration and further analysis for statistical purposes.
Responsible for the declaration of customs is the forwarder. The forwarder has to supply the authorities with all of the needed information regarding the import of goods. With that done, the trucker can pick up the goods at the pre-notified gate at the airport and haul the consignments to the consignee. Occasionally, sudden changes regarding the gate or the time of the pick-up may occur. Logically, the communication must be flawless at this point to guarantee the further procedure. As soon as the truck is loaded the actual delivery to the consignee begins.
For the consignee to be ready to receive the goods, the trucker has to pre-advise him with information on the estimated time of arrival. The pre-advising of the shipment marks the beginning of the last phase, the completion. To guarantee a smooth and seamless unloading process at the premises of the consignee, the truck driver informs his dispatcher frequently, who then calls the consignee and tells him of the location of the trucker. With that information, the consignee can estimate when the trucker will be there, so that he can clear space for unloading and also have forklifts and their drivers ready, for example. It could also be possible that the trucker communicates directly with the consignee which would make the process easier for the forwarder as well. When the truck in fact arrives, the liability as well as the ownership for the goods is transferred to the consignee. With an entitled person signing the proof of delivery for the trucker, the delivery is finished. The proof of delivery is a trigger for the payment from the consignee to the forwarder after the forwarder having checked whether the agreed amount of money has been transferred to his banking account successfully. The reception of the due amount marks the end of the entire transaction.
After the process has been portrayed and a process map developed, it is then important to realize that pain points may occur in every process. One step in the right direction is the identification of those pain points before making efforts to minimize or even avoid them. Two of these pain points have been identified by the workshop participants exemplarily. These pain points are translated into so-called exceptions, which are presented hereafter.
The first event illustrates what must happen, so that a dispatcher has to be alerted and this is shown in
Figure 4, which follows the same representation logic as previous works of the authors [
2].
In this case there are two triggers or critical situations, and thus the reactive rule, for the “AlertDispatcher” event. Firstly, the terminal at which the truck is supposed to arrive is unavailable.
Secondly, the observation whether the truck is at the terminal at all must be made. If these two situations are answered negatively, meaning yes for the unavailability of the terminal and no for the observation whether the truck is at the terminal, the dispatcher has to be contacted. However, for both observations to be made, there are some deductive rules to be established. For the terminal as an entity, the occupancy status can be observed and easily measured as the answer is Boolean (and therefore either yes or no). For the truck, it is almost the same. The current position must be observed, and the exact geo-position derived. It is also important to note that both observations have to occur in order to have the dispatcher be alerted. If the terminal is unavailable while the geo-coordinates show that the truck is 200 kilometers far away, the unavailability of the terminal does not have any relevance at this point, and, thus, does not lead to any event-triggered action.
The second complex event (see
Figure 5) is more complicated and concludes in the exception “DispatchTruck” and is in the context of a plane not being able to land at a certain airport due to a heavy thunderstorm. This means that different variables lead to the event of another truck nearer to the new airport being dispatched. Consequently, the reason for the truck dispatch is the complex event of a change of destination. First of all, the pilot must notify the airport that he will land in thirty minutes, for instance. This can easily be observed via the estimated time of arrival, which again is constantly updated based on the speed, the movement rate, the current geo-position, and further influential factors, such as weather or traffic. In the meantime, it will be indicated to the pilot that the airport is closed because a thunderstorm is too heavy. The weather situation at the airport can be observed via the geo-coordinates and respective websites on the internet. Therefore, two single events have to occur to confirm that a destination switch is inevitable. The pilot has to notify the airport about the landing and the airport must be closed. If one or the other does not occur, a switch of destination is not necessary. Also important is the availability of a second truck to pick up the goods, because the pilot will need to approach another airport as alternative destination.
The dispatcher must check the depot and see whether a truck is there. This can be made via the geo-position of the truck. It is worth mentioning that the truck does have to fulfill the specific requirements for the pick-up, just like the previously planned truck. In the end, two deductive rules lead to one reactive rule. This rule along with another deductive rule lead to the final reactive rule, the dispatch of a new truck.
As can be seen in the activity diagram enriched with the exceptions (see
Figure 6), each of the exceptions can occur at various process steps. The above-mentioned complex events “AlertDispatcher” and “DispatchTruck” can be detected by several single events, i.e., signals and values, at different points throughout the entire process. The activity diagram enriched with the exceptions shows exemplarily what exemplary single events can be measured at a certain point of the process. It is important to realize, however, that the single events that are responsible for the creation of a specific pattern of a complex event do not occur at one point of a process or simultaneously. Information is collected throughout and on different stages of the process. For example, to receive all the relevant information on the exception “AlertDispatcher”, you need to know the terminal and its availability together with the truck and the position of the truck. These variables can be detected at three or four different steps of the process. As soon as the forwarder receives the shipment alert, the dispatcher must organize the run from the airport to the consignee. To arrange the proper truck, he needs to know the weight and the dimensions of the load. At the second exception, at which the air carrier schedules the pick-up of the goods, there are other variables considered. The air carrier can see when the airplane´s estimated time of arrival is. With that information, they can assess the time when the trucker might be able to pick up the load. Also observable at this single event is the weather at the airport and the availability at the nearest other airport in case of the heavy thunderstorm, which concludes in the shutdown of the originally planned destination airport. In case of the trucker, it is possible to address the exception of the truck dispatch at the process step “Pick-up goods”. To guarantee the pick-up in time, the truck must be monitored. The geo-position can ideally be tracked throughout the whole process, and thus, the time of arrival estimated. It is also conceivable that a defect on the truck can be detected with the help of cyber-physical systems. A broken axle, for instance, is a frequently occurring defect for which a failure prediction could be valuable.
4.2. Real-World Use Case Example: Transshipment
The second use case example presents a medium-sized rail freight haulage company located in the west of Germany. It mainly transports dry bulk goods, such as coal and ores, and handles those goods at its own ports and storage locations. Furthermore, the enterprise offers solutions regarding rail transport, storage, and customs of bulk goods. Like the first company, this company operates on the entire European continent and is connected to virtually all parts of the world through global supply chains. Yet, the emphasis is not on the transportation, but on the handling processes between different legs. The entire process of this transportation would be from a seaport to a power plant as the final customer, typically via several intermediate steps at which the handling or storage processes take place. The company operates in different environments with heterogeneous transport mode combinations, as is illustrated in
Figure 7. In the following explanation, the focus will be more closely on the process course. The transportation goes from a seaport to another seaport and from there via an inland port to the final customer. Usually, mistakes and deviations happen in a real-world environment all the time. In this case, several handling processes between the different transport modes typically exist. Because of that, it is most important for the company to optimize the handling processes, as these consume a major amount of the total process time. Also, the company offers two kinds of transportation services: pick-up and delivery. On the one hand, there is the pick-up service of loaded barges or trains from the seaport. Typically, the barge receives the bulk goods from the ocean vessel at the seaport before the train takes on the load from the barge at some later point in the process and ships it to its destination. On the other hand, there are also deliveries in which a barge or a train is on the way to the customer for the final delivery of the bulk cargo. Both services are accompanied by empty runs to or from the destination. In addition, both services can be combined in the way that arriving cargo is picked up and directly transported to the final customer.
The exemplary process of the second use case example is portrayed in
Figure 8 and it describes, as mentioned before, a transportation of bulk cargo from a seaport to the consignee. There are several players that are involved in this process apart from the seaport and the consignee: a forwarder, a handling port, a shipper, a rail operator, a barge operator, and an ocean carrier.
The company is acting as the forwarder but it owns the handling port at the same time. The process starts with the consignee having a need for the supply of bulk cargo. He passes those demands to the shipper who organizes the main leg from the consignor’s premises or the origin seaport to the destination seaport and it relays this information back to the consignee. With this knowledge, the consignee can instruct the forwarder with the required information, such as information on shipments and arrival dates. Based on the monthly and weekly customer demand, which may change within a day, the forwarder schedules train exits, barge entries, and storage place occupation for the bulk goods. As the demand may change rapidly, it is important in this case to have a forwarder with a general view of the big picture.
Furthermore, it must be stated that the planning of the replenishment for the customer is made recursively. This means that the forwarder starts his planning in the opposite direction of the actual transport. In general, the communication between employees at the handling port and the ones that are responsible for the customer demand has to be seamless, as sudden adjustments have to be made oftentimes. For the subsequent step, it is important to have the cranes ready for the coal handling and the tracks available for the rail feeder service. Therefore, the handling ports are responsible for the allocation of cranes for the handling of the bulks as well as the allocation of the tracks for the rail feeder service. On completing those planning steps, the actual transport process is initiated, starting with the ocean carrier arriving at the destination seaport. There, it has to be decided whether the goods can be handled directly onto the barge of the barge operator or if the goods have to be stored at the seaport. The reasons for storage at the seaport may be, for instance, no available capacities on the barge or schedule delays. Nevertheless, the result remains the same: the next step is the shipment by barge, either via direct handling or after handling at the seaport. The barge arrives at the handling port where the same questions have to be answered: i.e., whether it is possible to handle the bulk goods directly or whether is it necessary to store the goods and handle them after a certain time when the availability is given.
Either way, after the arrival at the handling port, the goods are being handled onto train wagons where the rail operator is responsible to ship the goods to the plant of the consignee, where the goods will eventually be unloaded. An ideal transportation would consist of only direct handling processes, but that is hardly possible in the real world because sudden changes, not least because of inefficient communication, affect the whole transportation chain and cause delays.
As the process has been explained, two exceptions are being explained to point out to the influence of each possible event for the whole process and the regarding reactions.
The first exception, as illustrated in
Figure 9, is the exception of a direct handling and it only considers the handling from a barge coming from the seaport on a train going to the final customer. The complex event of a direct handling also represents the reactive rule, and for this rule to come into effect, three deductive rules were derived. Accordingly, the question being asked here is how a direct handling can be detected. If the barge arrives at the handling port tomorrow, the train is at the same port tomorrow as well and the occupancy of the crane is low enough to handle both the barge and the train, then a direct handling from the barge to the train is possible. If one of those conditions does not apply, then a direct handling cannot happen. For the barge, the estimated time of arrival can be observed. If the train is at the handling port can be found out via its position and the geo-coordinates of the train can be measured and matched with the ones of the handling port. For the crane, the occupancy percentage can be measured.
The second exception “StoreGoods” (see
Figure 10) is more complex than the first one and it presents the opposite of the previously described one: if the complex event “StoreGoods” is derived, a complex event “DirectHandling” is logically not possible. Four entities have a role in this complex event. The first entity is the vessel. Its estimated time of arrival is observable, date and time are both measurable. From these two indicators, it can be observed that the vessel will arrive tomorrow. At the second entity, the barge, a defect can be observed. The answer to the defect is either yes or no and, therefore, of Boolean nature. The conclusion that the barge is defect is the following observation and leads to the dispatch of another barge which is also a different complex event. Combining the results of the vessel and the barge alone, it can be concluded that a direct handling is not possible. If the process has reached this point, the storage suddenly becomes important. Now, the barge needs to find a pier where it can stay during its clearance. The occupancy of the respective pier can be observed as a Boolean value. The fourth entity is the actual storage. The occupancy and the free capacity are observable and measurable, respectively. As it may happen that a direct handling is not possible, it is important to have enough spare capacity in the storage to store the goods temporarily. So, if a barge is defect, another barge will be dispatched to load the goods from the vessel and will bring them to the storage facility. For the new barge, the same sequence has to be gone through because it could be defect as well.
In
Figure 11, the already known activity diagram with detectable events is shown again. The difference between the previous one and this one is that this time different exceptions are included at certain steps of the process. These single events added up would result in the aforementioned exceptions of “DirectHandling” and “StoreGoods”. It is important to note that the single events do not occur at only one step of the process but at different steps. The combination of detectable exceptions at different times of the process yield the complex events.
Figure 11 shows the events belonging to the respective exceptions within the transshipment use case example. The first single events are at the destination seaport. At this point, it is possible to detect the pier and its occupancy status, as well as the vessel with its position, its arrival time and its possible defect status. However, the pier and the vessel are not directly related to each other. At the process step “shipment by barge”, the barge is the entity whose position, estimated time of arrival and defect status are observable. At the handling port, storage acts as an entity whose the occupancy is observable. Regarding the handling at the handling port in particular, the cranes are the entities whose occupancy is observable. Arranged correctly, these exceptions make up for the two exceptions in this process.
4.3. Real-World Use Case Example: Storage
Similar to the test cases with which the workshop procedure has been validated, the storage use case example deals with storage processes for goods entry and picking processes for goods exit [
29]. The third use case example deals with a fast-growing fashion retail company concentrating on e-commerce but having more and more stores as well. Normally, the goods come from factories all over the world to the distribution centers in Europe from there the goods are being transported to the individual retail stores for sales. In addition, e-commerce allows direct shipments of the goods ordered via internet to the final customers. Despite focusing on a distribution center, the emphasis on this use case is on the storage of the goods at the distribution center though. Therefore, the chosen process explains the process of storage of incoming items in particular.
In general, this process encompasses the trucker, the retail company, and the shipper. Furthermore, the employees fashion retail company is divided into two teams: one for the unloading tasks and one for the picking tasks. The whole process is illustrated in
Figure 12.
First of all, the shipper receives information of an incoming shipment and provides the trucker with all the necessary information accordingly. The trucker then drives to the distribution center to deliver the goods. The employees from the unloading team at the fashion retail company unload the truck. The employees need to follow a specific protocol while unloading: they need to check the security seals at first, then examine the UAT (Universal Air Tracking) label, and finally deposit the goods in the buffer zone. Up to this point, all goods are stored on pallets. For further processing within the distribution center, the goods then need to be depalletized. At the point where the picking team starts working, the items are divided into two groups: small articles and big articles. The small articles mainly come in boxes and are put on a conveyor belt in order to be hauled to the respective destination storage area. The boxes are later taken from the conveyor and are manually carried with a trolley to the final storage place. At the right storage place, the IDs of both the box and the storage place are being scanned before the item is put into the shelf. The big articles, on the other hand, are manually transported to the adjacent buffer zone. The UAT label is scanned again before the big articles themselves are divided into ordinary items or build-to-order articles which need to undergo further checks at an internal service center. While the former are being stored in the storage places, the latter are ideally directly loaded onto another truck for forwarding to the stores.
The exception chosen for the described process, which is shown in
Figure 13, results in the reactive rule “ConfirmStorage”. Also, a reactive rule is the complex event “AlertManager”. For these two rules to occur, three deductive rules must come into effect: the single events “StartHandlingTimer”, “StopHandlingTimer” and “NearRack”.
After the item was scanned and put on the conveyor belt, the observation that the item was transported can be made. At this point, a timer starts which concludes in the event “StartHandlingTimer”. If this time exceeds an allowed tolerance range, a manager has to be alerted to take a look whether there is a problem in the process. If the item reaches the end of the conveyor, it is scanned with a hand-held computer and the observation that the item was scanned can be confirmed. This indicates a seamless sequence up to this point and the single event “StopHandlingTimer” comes into effect. At the same time, the item is put on a trolley and is manually moved towards the storage rack where it needs to be stored. On the item arriving at the right place, the storage place and the item are scanned, which concludes in the single event “NearRack”. Consequently, when this event occurs, the final complex event “ConfirmStorage” has taken place.
In
Figure 14, the activity diagram with the exceptions for the third use case example is illustrated. Again, the pertaining single events are spread around the whole process and they occur at different times as well. The different entities, for example, can be seen at four different process steps at which single events like position or speed information can be detected. The complex event “ConfirmStorage” is consolidated from these single events.
5. Discussion
The synopsis of all three use case examples reveals the huge potential that is hidden in the adoption of cyber-physical systems and complex event processing in transportation and logistics processes. Since the focus has been laid on the largest or most important pain points within the considered processes, the benefit potential resulting from technology-based mitigation or solution approaches is accordingly tremendous. CPS and CEP promise to enlighten opaque areas of transportation and logistics processes by the better visibility of process steps and greater transparency of the progress. Furthermore, they help to coordinate and synchronize processes of different partners of the same supply chain, which again leads to streamlined processes in the supply network, better resource utilization, and reduced cost. Similarly, the use of the technologies allows for swift and effective handling of exceptions and immediate re-planning of processes, e.g., in the form of hiring service providers in the case of emergency.
Comparable cases of implementing either of the technologies in logistics have partly led to similar results. However, the combination of both allows the harvest of the full benefit potential. Detailed examinations of the precise benefits will be conducted after implementing the technologies in practice and collecting experimentation results therein.
The limitations of the study mainly refer to two aspects: representativeness of the selected use case examples and related pain points, as well as validation of the expected results in practice. The representativeness of the selected transportation and logistics processes may be criticized although the authors have emphasized this aspect and, thus, selected prototypical use case examples from transportation, transshipment, and storage processes for the design and configuration of cyber-physical systems in combination with complex event processing. However, particular industries, like the retail industry, the food and agricultural business, or the chemical and pharmaceutical industry exhibit very particular and challenging characteristics of their logistics processes, and, consequently, require modified or entirely different solutions.
As to the validation of the expected results in practice, the effectiveness and usefulness of the resulting technical solutions depend on the quality of the input from the workshops with the experts.
If the experts have not been selected thoroughly enough or the specified pain points have turned out to be less relevant, the usefulness of the solution diminishes correspondingly. Another central topic of this work are the eight characteristics of [
4] regarding smart logistics. With the use cases and the pain points being presented and an effective to-be solution scenario being developed, it needs to be safeguarded whether the criteria of smart logistics apply. As objective criteria are not available, Uckelmann’s eight characteristics are used as smart logistics indicators [
4].
As can be seen in
Table 1, most of the smart logistics criteria do apply to all three use case examples. In the first use case example, the criteria one to four as well as six and eight apply to the transportation use case. Notably, a certain degree of automation and decision-support is realized, which leads to less manual control activities required. The second use case example applies to the same criteria with the exception of the first one to which it does not apply. The synchronization of goods flows by means of transparency and connectivity based on CPS and CEP hints at a smart logistics process. All of the smart logistics criteria except for the first and seventh one apply to the third use case example. Particularly, the inclusion of internet of things and smart packages is a special feature in this storage use case.
Further, it can be immediately seen that solely the seventh characteristic does not apply to any use case, because the use cases simply do not deal with such monetary functions. The characteristic of less control activities only meets the transportation use case example. The developed reactive rule ensures the automated processing of information, which is represented in that specific case by the dispatch of a new truck without manual interference by the dispatcher.
The characteristics of connectivity within smart logistics processes and the facilitated data processing apply to all use case examples, which is reasonable because cyber-physical systems aim to connect processes and complex event processing is a particular form of data processing. The only applicable use case regarding the embracing of smart services and products is the third one because the technologies help to ensure that the products automatically find their way from the conveyor belt to the final storage place with minimal manual involvement and minimal proneness to error. With that final step being booked in the system, transparency is ensured parallelly.