Keywords

1 Introduction

In the era of modern manufacturing supply chain management (SCM) is becoming more and more complex [1]. Main reasons for this growing complexity are the geographical expansion of the supply chain networks, a huge amount of data (e.g. produced from tracing) which affects the supply chain decisions (e.g. how to manage an anomaly), and the need to increase the speed of decision-making tools due to the advancements of just-in-time delivery practices [2]. In addition, some of the traditional challenges in the SCM still persist and are more emphasized due to the mentioned advancements. One of these challenges is the transportation cost which is increased by the geographical complexity and extensive networks as well as sustainability concerns [3]. Another traditional challenge is the scheduling of orders, transport modes, and unloading points in the inbound and outbound supply chains. This challenge is in particular evident in large industries with a lot of inbound and outbound flows where it is difficult to schedule and re-schedule the plans in case of unexpected disruption events. In order to better address the mentioned challenges, the modern factories are transforming their logistics in a collaborative network where suppliers, trucks, dock managers and production plants share information about the status of the inbound resources for the optimization of the overall system [4]. Such a strong collaborative network is crucial for companies willing to respond to the challenges posed by the globalization [5, 6]. In particular, it allows to quickly take decisions along the whole value chain, thus contributing to a more and more highly dynamic supply chain which in turn is a key factor for the I4.0 logistics [7].

This collaborative network can be realized in its full potential only if it is supported by digital tools capable to exchange and share information among each-other [8]. However, the traditional manufacturing tools are typically based on specific data model and the heterogeneity (also called variety) of these models hinders the tools interoperability, i.e. their capability to exchange information, thus also jeopardizing the cooperation of the involved resources within the overall network [9]. In addition, it is still open so far the debate on which kind of data integration can enhance performance of the supply chain [10]. In order to overcome the issue of data heterogeneity, this paper aims at the development of an experimental platform for integration between traceability systems and management tools and optimization tools within the inbound logistics of automotive assembly plant. The platform leverages the use of a messages-oriented middleware for integration of tracking components with decision-support tools. Thus, thanks to middleware, an optimization tool can exchange significant information with other factory’s digital tools (e.g. for production simulation and optimization), thus allowing to re-schedule (e.g. when a disruption event happens) the inbound dock plans and select the best transport modes from the supplier to the docks of the assembly plant.

The remainder of the paper is structured as follows. Section 2 introduces the case study and its problem of interoperability. Section 3 presents the approach and its validation. Section 4 describes the results obtained leveraging the proposed approach. Finally, Sect. 5 draws the conclusions and summarizes the main outcomes.

2 The Case Study

The case study is set in an automotive assembly plant and it focuses on the management of inbound logistics whenever a disruption occurs. The latter could happen in the supplier’s side, in the transport modes, and in the unloading docks. In case of any of these disruption events, the manager of the supply chain needs to make recovery decisions to reduce the adverse effects of the delay. In addition, the disruptions that happen in the production could have an impact on the decisions in the inbound logistics and therefore, these disruptions should also be considered. The problem that must be faced consists of two main decisions in the inbound logistics of the assembly plant:

  1. 1.

    Dock re-scheduling;

  2. 2.

    Transportation mode selection.

Before a disruption event happens, a dock schedule exists where a set of trucks are assigned to a set of docks for a specific planning horizon. As a result of a disruption event, it is needed to take a decision to re-schedule the assignments, while the second decision considers the possibility of changing the transport mode of the delayed orders with faster modes. The two decisions are interconnected in the way that the arrival time of the orders to the docks changes by influencing the change of the transport modes. The final decision on the dock re-scheduling and transport selection depends on the trade-off between different costs. Transport cost is the cost of using alternative transport modes. Dock setup cost is the cost of employing additional docks. Buffer cost is the cost of using internal transport means for transferring the specific components (part numbers) from the docks to the assembly line. Extra resource cost is the cost of using more resources than the available ones at the docks. Truck waiting cost is the cost of waiting truck in the dockyard when there are no free docks. Finally, the cost of production re-scheduling is the cost when a part number is not available in the assembly line in the planned time, and therefore, a re-scheduling in the production is necessary. The desired solution is a re-scheduled dock plan and transport plan where the sum of all the costs is minimized.

The solution for this problem proposed within the European research project DISRUPT [11] is to use an optimization model for the inbound logistics where the objective function is the minimization of all the costs as follows [12]:

Minimize (Additional costs caused by the disruption events) = Minimize (Transport cost + Dock setup cost + Buffer cost + Extra resource cost).

The input data for the optimization model are the data related to the inbound logistics combined with data resulting of the analysis of other tools. To handle the disruption and its impact on the inbound logistics decisions, three tools collaborate and propose the final solution as follows:

  1. 1.

    Simulation tool;

  2. 2.

    Optimization tool of the inbound logistics;

  3. 3.

    Optimization tool of production scheduling.

The Simulation tool is first applied to quantify the effects of the disruption on the Key Performance Indicators (KPIs). The most important KPI is Job per Hour (JPH). If the impact of disruption on the JPH is negligible, this is considered as the outcome of the analysis. No further analysis is needed in this case. Otherwise, if the effect is not negligible, the optimization tools are required to minimize the negative consequences of the disruption on the JPH. Generally, two scenarios for inbound logistics tool are possible based on the disruption type as follows (Fig. 1):

Fig. 1.
figure 1

Application of inbound logistics tool in different disruption events

Full size image
  1. 1.

    The disruption is in the production process (e.g., machine failure). In this case, if the disruption can be managed by the optimization tool of the production schedule, it is not needed to apply the inbound logistics optimizer. The outcome is the updated production schedule. If the disruption is not manageable solely by production scheduling tool, Inbound logistics tool should be used. Apart from the other input data, the re-scheduling cost is obtained by the communication of different alternative dock schedules with the production scheduling tool.

  2. 2.

    The disruption is in the inbound logistics (e.g., the accident of the transport mode). In this case, the disruption should be managed directly by the inbound logistics tool with the communication of data with the production scheduling tool.

Finally, an optimized dock schedule and transport plan are provided to the supply chain manager who is the final decision maker of the inbound logistics. Behind each state of the workflow, there are different modules, performing different functions. The interactions among different digital tools and software applications are essential to the efficient solution of the optimization model.

3 An Overview of the Platform Architecture

In order to overcome the problem of the interoperability, this section investigates the potential of a solution based on a three layers architecture, where the layers are the following (Fig. 2):

Fig. 2.
figure 2

The architecture of the platform

Full size image

  • Real Factory;

  • DISRUPT Platform Cloud;

  • Virtual Factory Tools.

The Real Factory comprises the world of the factory, including all aspects inherent the logistic of the fleet of the trucks and the plant production. The DISRUPT Platform Cloud, which is one of the main outcomes of the DISRUPT project [13], is the middle-tier of entire system which aims at the integration of all the factory’s tools data. In particular, it contains two macro-modules (Event Dispatcher and Digital Twin) that allow to integrate the data generated by the layer of the Real Factory under the form of data streams (Factory Telemetry) [14]. Specifically, the Digital Twin is a virtual model which represents a faithful mirror of the Real Factory, persisted on two structured databases: Event Disrupt Database (containing the logic to raise the events) and Synchro Factory Database (containing the information related to the supply chain management) [15]. On the base of the information included in the Digital Twin, the Event Dispatcher raises the events in case of scheduling delays and forward them to upper Layer. The Event Dispatcher leverages a messages-oriented middleware which acts as a glue among the various connected digital tools [16]. Under these conditions, these tools can also run on different platforms and operating systems, as the interoperability is guaranteed by the middleware. Finally, on the top of the architecture, the layer of the Virtual Factory Tools comprises various Factory decision-support tools including an Optimizer for Inbound Logistics and an Optimizer for the production scheduling which leverage the events triggered by Event Dispatcher.

3.1 An Example of the Use of the Platform

In order to illustrate, through an example, the use of the above described platform to integrate a specific tool within the collaborative network, this section focuses on the Inbound Logistics Optimizer tool. As described previously, this tool is an optimization model which aims to re-schedule the inbound dock plans and select the best transport modes from the supplier to the docks of the assembly plant when a disruption event happens. The Inbound Logistics Optimizer software architecture is designed foreseeing both a synchronous and asynchronous (or event base) communication with the virtual model of the Real Factory. In addition, it includes a model handler, which represents the core mathematical model of the whole Inbound Logistics Optimizer tool.

In particular, such tool is composed by the following modules (Fig. 3): (1) Handler Cplex Model, described through the software application Cplex OptimizerFootnote 1, which represents the optimization model based on the current status of the factory. By extracting the updated input parameters, this model finds a solution pool with alternative updated dock schedules and transport plans. Afterwards, based on the related decision variables, it calculates the KPIs for each alternative solution. (2) Synchro Factory Database Adapter Library (written in Java), which provides a set of different REST API Web services. In particular, the latter enables the Inbound Logistics Optimizer tool to communicate with the DISRUPT Platform Cloud and to use the CRUD (Create, Read, Update, Delete) operations in order to interact with the databases to create, read, update and delete the static and dynamic data, stored on Cloud platform. (3) Client Event-Bus (written in Java), which represents the module needed to provide information consistency among the different tools that compose the Virtual Factory Tools layer. The Client Event-BusFootnote 2 is based on the Publish/Subscribe messaging pattern, in which a message is delivered from a producer to any number of consumers. Messages are delivered to the queue destination, and then to all active consumers who have subscribed to this queue.

Fig. 3.
figure 3

Inbound Logistic Optimizer software architecture

Full size image

4 Results

In the proposed approach, through the middleware, a set of input parameters and disruptions are communicated to the Inbound Logistics Optimizer. The optimizer solves the problem by proposing a set of re-scheduled dock plans with the minimum cost as well as the related KPIs. These outcomes are in turn communicated to the middleware, which transmits them to other modules. Exploiting this integration, a set of feasible solutions is provided to the decision-maker in an efficient way. In particular, the results of the inbound logistics optimizer can be divided into three parts as follows:

  1. 1.

    Updated dock schedule

  2. 2.

    Transport selection

  3. 3.

    KPIs.

Figure 4 represents an overview of the results. Alternative solutions are provided to allow the decision maker to choose among the solution alternatives (sub-optimal solutions) which are not satisfied in the optimum solution, based on different cost types. The KPIs are the costs of extra dock setup (DSC), truck waiting (WC), buffer (BC1, BC2), extra resource (ARC) and transportation (TC).

Fig. 4.
figure 4

Representation of KPIs for alternative solutions of the inbound logistics optimizer (Optimal: best result with the minimum cost, sub-optimal: alternative results with higher costs)

Full size image

5 Conclusion

The potential of an approach based on a message-oriented middleware was investigated in this paper to enhance cooperation and collaboration of digital tools supporting logistics within a manufacturing company. The evaluation of the approach in a test environment has demonstrated its validity.

Future works will address the deployment of the proposed solution within the production environment where all the digital tools are deployed and can interact each other. The production environment will give the opportunity to verify the approach under real condition. As the project is still ongoing, the idea is addressing these works in the future months, before the end of the project. Another aspect that must be investigated in the future is the evaluation of the proposed approach within other case studies. It is expected an easy transfer technology from one case study to another thanks to the integration capability of the adopted middleware.