Next Article in Journal
Logistics Education and Behavioral Training Decisions, Time Distortion, and the Prae Ante View
Previous Article in Journal
Towards a Business Model Framework to Increase Collaboration in the Freight Industry
Article Menu

Export Article

Logistics 2018, 2(4), 23; https://doi.org/10.3390/logistics2040023

Article
Identifying Promising Application Areas for Cyber-Physical and Complex Event Processing in Logistics Practice
1
Department of Transport Systems and Logistics, University of Duisburg-Essen, 47057 Duisburg, Germany
2
Colegio de Ciencias y Ingenierías, Universidad San Francisco de Quito, Quito 170901, Ecuador
3
IBM Deutschland GmbH, 40474 Düsseldorf, Germany
*
Author to whom correspondence should be addressed.
Received: 14 August 2018 / Accepted: 15 October 2018 / Published: 17 October 2018

Abstract

:
In the course of the ongoing era of digitization, cyber-physical systems and complex event processing belong to the most discussed technologies nowadays. The huge challenge that digitization is forming to the transportation and logistics sector is largely accepted by the responsible organizations. Despite initial steps being taken towards digitized value-creation, many professionals wonder about how to realize the ideas and stumble with the precise steps to be taken. With the vision of smart logistics in mind and cost-efficient technologies available, they require a systematic methodology to exploit the potentials accompanying digitization. With the help of an effective and targeted workshop procedure, potentially appropriate application areas with promising benefit potentials can be identified effectively. Such a workshop procedure needs to be a stepwise approach in order to carefully consider all the relevant aspects and to allow for organizational acceptance to grow. In three real-world use case examples from different areas of the transportation and logistics industry, promising applications of cyber-physical systems and complex event processing are identified and pertaining event patterns of critical situations developed in order to make realization easier at a later stage. Each use case example exhibits a frequently occurring problem that can be effectively addressed by using the above-mentioned technology.
Keywords:
smart logistics; transportation; transshipment; storage; logistics; cyber-physical systems; complex event processing; process-oriented event model; distributed event-based systems

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.

2. Background Study

2.1. Smart Logistics

The following section will outline the idea of smart logistics only briefly as previous works of the authors have focused on this concept [1,2,3]. In the field of transportation and logistics, the conception of smart logistics is used more common in recent years. Nevertheless, there is not one existing definition for it and that presents a difficulty.
Consequently, there is only a hazy understanding of smart logistics. The predominant ideas move between two concept poles: while one takes an organizational approach, the other one has a technological view. According to [4], the following eight characteristics feature an application, so it can be talked of as smart logistics:
  • “Smart Logistics frees humans from (control) activities that can be delegated to Smart Products and Services”
  • “Smart Logistics are invisible and calm and can therefore be described as transparent”
  • “Smart Logistics are connected, thus communicating and possibly interacting with their environment”
  • “Smart Logistics facilitate state-of-the-art data processing (which may include, but do not require software agents)”
  • “Smart logistics embraces Smart Service as well as Smart Products within Logistics”
  • “Smart Logistics integrates existing logistic technologies, such as material handling systems, and enable these to react and act in a correspondingly smart manner”
  • “Smart Logistics include state-of-the-art billing, payment or licensing as integral component”
  • “Smart Logistics is derived from a technology driven approach, and thereby subject to change”
However, not all eight characteristics need to be fulfilled necessarily [4].
With regard to the technical perspective, smart logistics have to be dedicated to customer needs. In that sense, a holistic overview of planning and control of automated information flows and material flows is advisable. On this basis of and with the help of intelligent technologies, smart logistics is able to evolve into a construct that is regulated automatically and autonomously [5]. Related to the perception of [5], the understanding of smart connected logistics as a merger of manifold technologies that are embedded into already existent processes results [6].
When considering the organizational approach, the potential of smart logistics is particularly visible in processes with a low degree of automation and in the three fundamental logistics process types—storage, transshipment, and transportation [7]. To reach an efficient way for the use of smart logistics one scholar determined the following enablers: people, planning and scheduling, ICT infrastructure and governmental policies. These driving forces need to cooperate and act concurrently [8]. Taking into account what has been said in the section before, the realization of smart logistics in the organizational environment needs a workshop procedure, which again has to exhibit a concise concept of smart logistics.

2.2. Cyber-Physical Systems

Following [9], “Cyber-Physical Systems (CPS) are integrations of computation with physical processes. Embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa” [9]. The main objective of a CPS is to act as the intersection of the physical side and the cyber view, but not as their conjunction [10]. Most likely, CPS will have an important part in the future of engineering systems, because of its skill to enhance the capabilities of existing systems easily [11].
The difference between an embedded system and a CPS is that a CPS has a network structure in which both sides, cyber and physical, cooperate. In an embedded system, on the other hand, the focus is on single computational elements. Hence, it can be said that a CPS is an expansion of embedded systems [12]. As most CPS need to comply with constraints in real time and are often system-critical to safety, dependability is a vital characteristic of CPS. There are five points a system needs to adhere with to be called dependable: availability, safety, security, maintainability, and reliability [13].
Consequently, it is not surprising that more and more CPS are integrated in the whole supply chain and not only within individual transportation and logistics processes [7]. With regard to the reference to this domain, people talk of so-called cyber-physical logistics systems or CPLS, which are well adaptable in that respect [14,15].
In essence, the prevalence of CPS will increase when they are seen as facilitators for the combination of machines and products with newer technological developments, like the Internet of Things or Industry 4.0. Additional information regarding CPS and CPLS is presented the authors’ preceding works [1,2,3]. It is worth mentioning that in many logistics 4.0 visions, CPS acts as a means of data capturing. The significance of this role is proportional to the increasing prevalence of cyber-physical systems in commercial practice.

2.3. Complex Event Processing

Footing on established IT sectors, like business intelligence or discrete-event simulation, Complex Event Processing (CEP) has developed towards a major information technology from the first decade of the new millennium [16]. At this point, the software landscape seems to develop towards ubiquity in an event-driven environment [17]. When considering a valid definition of CEP, Luckham refers to the definition of an event, which is “an object that represents or records an activity that happens, or is thought of as happening” [17].
As can be seen, event processing—i.e., computerized signal processing—is not a new phenomenon. Within information systems, events are being used and any type of computerized processing of event objects refers to that. Today, many ordinary business applications and simple alert systems are event-triggered action or based event [17,18,19]. Now, being considered a part of big data analytics, CEP is suitable for the analysis of huge data streams in real time. With CEP, it is possible to detect spatial, temporal, causal, or other interrelations between events [20]. CEP abstracts event patterns and processes these events following certain rules. The rules consist of a deductive event pattern to which needs to be reacted (‘if’) and a part where the wanted reactive action is explained (‘then’). When CPS acts a means of data capturing, CEP takes over the task of processing the captured data. In total, CPS and CEP make up an especially good combination [21]. A more comprehensive portrayal of CEP can be found in the authors’ preceding works [1,2,3,22].

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.

6. Conclusions and Outlook

To draw a conclusion, it can be said that existing technologies can be put into practice to realize smart logistics. Two such technologies to enable smart logistics are cyber-physical systems and complex event processing. Based on the methodological approach that was proposed by the authors in earlier works, the practical application of the workshop procedure is the main focus of this work. Whereas the earlier publications have referred to the design and development of the methodology including the workshop procedure and its testing in both a laboratory environment and a real-world environment, the present paper shows the results of its actual application in logistics practice.
Hence, three real-world use case examples are presented. The first use case describes the process of a road-borne post-haulage of an international airfreight supply chain process between Europe and China in which a multinational logistics provider aims to improve the rescheduling and supply of a new truck in case of a process disruption that affects the planned truck. The second use case pictured the synchronization and digital transformation of the transshipment processes at a German dry bulk port at which the goods arrive by inland barge and depart by rail. The third use case aimed to gain sufficient visibility of the storage and retrieval processes in the distribution center of a European fashion retailer.
In each of the use case examples, the respective workshops resulted in process diagrams of those processes with the highest potential for remedy and optimization presented. In addition, the deductive rules representing the event patterns behind the problems to be detected have been developed. Similarly, the reactive rules that address the problems that can occur within the described processes have also been described.
Consequently, the technical realization would follow seamlessly as the event patterns to search for are available. Hence, the sourcing of the different technical components, the programming of the different event patterns, and the actual roll-out, including deployment, implementation, and testing can be initiated immediately hereafter. The phases of implementation and testing, the monitoring of the effectiveness of the solution, i.e. the so-called phase 3, and of operational use are yet to follow as part of the residual project work.

Author Contributions

C.A. has contributed to the manuscript by providing the initial concept and the research design, carrying out and recording the workshops, processing and analyzing the findings both from a logistics and a software engineering perspective, and writing parts of the manuscript. F.E.A.O. has contributed to the manuscript by providing the initial concept and the research design as well as processing and analyzing the findings from them from a logistics perspective. H.I. took part in this work by carrying out and recording the workshops, processing and analyzing the findings from them, and writing parts of the manuscript. J.O. has participated in this work by organizing and carrying out workshops, processing and analyzing the findings from a software engineering perspective, and writing parts of the manuscript. B.N. has contributed to the manuscript by providing the initial concept and the research design and supporting to organize the workshops.

Funding

The research leading to a part of these results has received funding from the European Union’s Seventh Framework Programme FP7/2007-2013 under grant agreement 285598 (FInest) as well as the EFRE.NRW (2014–2020) Joint Research Funding Programme of the European Union (EFRE) and the Ministry of Economy, Energy, Industry, and Handicrafts of the German Federal State of North Rhine-Westphalia (NRW) under grant agreement 0-4000-17 (CPS.HUB NRW).

Acknowledgments

The authors express their gratitude towards Anne Biehl geb. Lüdering, Božo Bjelopera, Viviana Elizabeth Ortiz Ruiz, Udo Salewski, and Michael Zahlmann as well as to those colleagues at the respective participant organizations that have supported this work actively by means of inspiring discussions, fruitful collaboration, and attentive proof-reading.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Alias, C.; Zahlmann, M.; Alarcón Olalla, F.E.; Iwersen, H.; Noche, B. Designing Smart Logistics Processes Using Cyber-Physical Systems and Complex Event Processing. (to appear). In Mobility in Times of Change: Past, Present, Future (to Appear); Proff, H., Jovic, J., Eds.; Springer Fachmedien Wiesbaden: Wiesbaden, Germany, 2019. [Google Scholar]
  2. Ollesch, J.; Hesenius, M.; Gruhn, V.; Alias, C. Real-time Event Processing for Smart Logistics Networks. In Mobilität und Digitale Transformation: Technische und Wirtschaftliche Aspekte; Proff, H., Fojcik, T.M., Eds.; Springer Fachmedien Wiesbaden: Wiesbaden, Germany, 2018; pp. 517–532. [Google Scholar]
  3. Ollesch, J.; Hesenius, M.; Gruhn, V.; Alias, C. The Requirements Engineering Perspective on Events in Cyber-Physical Systems. In Proceedings of the 11th ACM International Conference on Distributed and Event-Based Systems, Barcelona, Spain, 19–23 June 2017; ACM Press: New York, NY, USA, 2017; pp. 349–350. [Google Scholar]
  4. Uckelmann, D. A Definition Approach to Smart Logistics. In Next Generation Teletraffic and Wired/Wireless Advanced Networking, Proceedings of the 8th International Conference NEW2AN and 1st Russian Conference on Smart Spaces, St. Petersburg, Russia, 3–5 September 2008; Hutchison, D., Balandin, S., Kanade, T., Kittler, J., Kleinberg, J.M., Koucheryavy, Y., Mattern, F., Mitchell, J.C., Moltchanov, D., Naor, M., et al., Eds.; Springer: Berlin/Heidelberg, Germany, 2008; pp. 273–284. [Google Scholar]
  5. Straube, F. Smarte Logistik: Hebel der Digitalisierung: Berlin, Germany. Available online: https://www.bvl.de/wissen/logistik-bereiche/smarte-logistik (accessed on 1 August 2018).
  6. Gregor, T.; Krajčovič, M.; Więcek, D. Smart Connected Logistics. Procedia Eng. 2017, 192, 265–270. [Google Scholar] [CrossRef]
  7. Kohnhauser, V.; Schobesberger, M.; Siller, M.; Peterwagner, C. Wege zu Smart Logistics. Integration von Informations- und Kommunikationstechnologien in KMU. Salzburger Managementstudien No. 3: Salzburg, Austria. 2017. Available online: http://www.fh-salzburg.ac.at/fileadmin/fh/forschung/bwi/documents/Publikationen/Salzburger_Managementstudien_Nr._3.pdf (accessed on 1 August 2018).
  8. Van Woensel, T. Smart Logistics; Inaugural Lecture: Eindhoven, The Netherlands, 2012. [Google Scholar]
  9. Lee, E.A. Cyber Physical Systems: Design Challenges. In Proceedings of the 11th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC), Orlando, FL, USA, 5–7 May 2008; IEEE: Piscataway, NJ, USA, 2008; pp. 363–369. [Google Scholar]
  10. Lee, E.A.; Seshia, S.A. Introduction to Embedded Systems: A Cyber Physical Systems Approach, 1st ed.; MIT Press: Cambridge, MA, USA, 2012. [Google Scholar]
  11. Baheti, R.; Gill, H. Cyber-physical Systems. Impact Control Technol. 2011, 42, 161–166. [Google Scholar]
  12. Leitão, P.; Colombo, A.W.; Karnouskos, S. Industrial automation based on cyber-physical systems technologies: Prototype implementations and challenges. Comput. Ind. 2016, 81, 11–25. [Google Scholar] [CrossRef][Green Version]
  13. Marwedel, P. Embedded System Design: Embedded Systems Foundations of Cyber-Physical Systems, 2nd ed.; Springer: Dordrecht, The Netherlands; New York, NY, USA, 2011. [Google Scholar]
  14. Hribernik, K.; Warden, T.; Thoben, K.-D.; Herzog, O. An Internet of Things for Transport Logistics: An Approach to Connecting the Information and Material Flows in Autonomous Cooperating Logistics Processes. In Proceedings of the 12th International Conference on Modern Information Technology & Innovation Processes of the Enterprises, Aalborg, Denmark, 29–31 August 2010; Hvolby, H.-H., Gundelund, C.H., Nielsen, P., Nielsen, I.E., Dukovska-Popovska, I., Steger-Jensen, K., Eds.; Aalborg University: Aalborg, Denmark, 2010; pp. 54–67. [Google Scholar]
  15. Seitz, K.-F.; Nyhuis, P. Cyber-Physical Production Systems Combined with Logistic Models—A Learning Factory Concept for an Improved Production Planning and Control. Procedia CIRP 2015, 32, 92–97. [Google Scholar] [CrossRef]
  16. Hedtstück, U. Complex Event Processing. Verarbeitung von Ereignismustern in Datenströmen; Springer Vieweg: Berlin, Germany, 2017. [Google Scholar]
  17. Luckham, D.C. Event Processing for Business. Organizing the Real Time Strategy Enterprise; Wiley: Hoboken, NJ, USA, 2012. [Google Scholar]
  18. Etzion, O.; Niblett, P. Event Processing in Action; Manning: Greenwich, CT, USA, 2011. [Google Scholar]
  19. Luckham, D.C. The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems, 6th ed.; Springer: Berlin, Germany, 2013. [Google Scholar]
  20. Bruns, R.; Dunkel, J. Complex Event Processing: Komplexe Analyse von Massiven Datenströmen Mit CEP; Springer Vieweg: Wiesbaden, Germany, 2015. [Google Scholar]
  21. Talcott, C. Cyber-Physical Systems and Events. In Software-Intensive Systems and New Computing Paradigms: Challenges and Visions; Wirsing, M., Banâtre, J.-P., Hölzl, M., Rauschmayer, A., Eds.; Springer: Berlin/Heidelberg, Germany, 2008; pp. 101–115. [Google Scholar]
  22. Alias, C.; Lederman Rawet, V.; Ratton Neto, H.X.; Neirão Reymão, J.E. Investigating into the Prevalence of Complex Event Processing and Predictive Analytics in the Transportation and Logistics Sector: Initial Findings from Scientific Literature. In Proceedings of the 10th Mediterranean Conference on Information Systems (MCIS), Paphos, Cyprus, 4–6 September 2016; AIS Electronic Library: Milan, Italy, 2016. [Google Scholar]
  23. Schulze, U. Informationstechnologieeinsatz im Supply Chain Management. Eine Konzeptionelle und Empirische Untersuchung zu Nutzenwirkungen und Nutzenmessung; Gabler Verlag/GWV Fachverlage GmbH: Wiesbaden, Germany, 2009. [Google Scholar]
  24. Patri, O.P.; Sorathia, V.S.; Panangadan, A.V.; Prasanna, V.K. The process-oriented event model (PoEM). In Proceedings of the 8th ACM International Conference on Distributed and Event-based Systems, Mumbai, India, 26–29 May 2014; Bellur, U., Kothari, R., Eds.; ACM Press: New York, NY, USA, 2014; pp. 154–165. [Google Scholar]
  25. Arnold, D. Handbuch Logistik, 3rd ed.; Springer: Berlin, Germany, 2008. [Google Scholar]
  26. Vahrenkamp, R.; Siepermann, C. Logistik: Management und Strategien, 5th ed.; Oldenbourg: Munich, Germany, 2005. [Google Scholar]
  27. Rialland, A.; Alias, C. D2.4 Initial Experimentation Specification and Evaluation Methodologies for Selected Use Case Scenarios: Finest—Future Internet Enabled Optimisation of Transport and Logistics Networks. Project Deliverable. Available online: http://cordis.europa.eu/fp7/ict/netinnovation/deliverables/finest/finest-d24.pdf (accessed on 1 August 2018).
  28. Rialland, A.; Ramstad, L.S. D2.3 Detailed Specification of Use Case Scenarios: Finest—Future Internet Enabled Optimisation of Transport and Logistics Networks. Project Deliverable. Available online: http://cordis.europa.eu/fp7/ict/netinnovation/deliverables/finest/finest-d23.pdf (accessed on 1 August 2018).
  29. Alias, C.; Özgür, Ç.; Jawale, M.; Noche, B. Analyzing the Potential of Future-Internet-Based Logistics Control Tower Solutions in Warehouses. In Proceedings of the 2014 IEEE International Conference on Service Operations and Logistics, and Informatics, Qingdao, China, 8–10 October 2014; IEEE: Piscataway, NJ, USA, 2014; pp. 452–457. [Google Scholar]
Figure 1. Methodology of realizing smart logistics processes with the help of Cyber-Physical Systems (CPS) and Complex Event Processing (CEP) [1].
Figure 1. Methodology of realizing smart logistics processes with the help of Cyber-Physical Systems (CPS) and Complex Event Processing (CEP) [1].
Logistics 02 00023 g001
Figure 2. Focus area of the considered air transportation chain following [28].
Figure 2. Focus area of the considered air transportation chain following [28].
Logistics 02 00023 g002
Figure 3. Activity diagram of the transportation use case example.
Figure 3. Activity diagram of the transportation use case example.
Logistics 02 00023 g003
Figure 4. Exception “AlertDispatcher”.
Figure 4. Exception “AlertDispatcher”.
Logistics 02 00023 g004
Figure 5. Exception “DispatchTruck”.
Figure 5. Exception “DispatchTruck”.
Logistics 02 00023 g005
Figure 6. Activity diagram of the transportation use case example with exception-related events.
Figure 6. Activity diagram of the transportation use case example with exception-related events.
Logistics 02 00023 g006
Figure 7. Focus area of the considered transshipment process.
Figure 7. Focus area of the considered transshipment process.
Logistics 02 00023 g007
Figure 8. Activity diagram of the transshipment use case example.
Figure 8. Activity diagram of the transshipment use case example.
Logistics 02 00023 g008
Figure 9. Exception “DirectHandling”.
Figure 9. Exception “DirectHandling”.
Logistics 02 00023 g009
Figure 10. Exception “StoreGoods”.
Figure 10. Exception “StoreGoods”.
Logistics 02 00023 g010
Figure 11. Activity diagram of the transshipment use case example with exception-related events.
Figure 11. Activity diagram of the transshipment use case example with exception-related events.
Logistics 02 00023 g011
Figure 12. Activity diagram of the storage use case example.
Figure 12. Activity diagram of the storage use case example.
Logistics 02 00023 g012
Figure 13. Exception “ConfirmStorage”.
Figure 13. Exception “ConfirmStorage”.
Logistics 02 00023 g013
Figure 14. Activity diagram of the storage use case example with exception-related events.
Figure 14. Activity diagram of the storage use case example with exception-related events.
Logistics 02 00023 g014
Table 1. Suitability for smart logistics of the considered use case examples.
Table 1. Suitability for smart logistics of the considered use case examples.
Smart Logistics CriteriaUse Case Example TransportationUse Case Example Transshipment Use Case Example Storage
Less control activities
Transparent
Connected
Facilitate data processing
Embrace smart services and products
Integrates existing logistics technologies
Payment and invoice methods
Technology driven approach
Suitability for Smart Logistics

© 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Logistics EISSN 2305-6290 Published by MDPI AG, Basel, Switzerland RSS E-Mail Table of Contents Alert
Back to Top