The openTCS software plays a major role in the implementation of the MAS and the planning and control rules. OpenTCS intentionally provides a driving model of a transportation system, manages transport orders, and computes routes for vehicles (The architecture of openTCS2017). Furthermore, OpenTCS provides (hardware) drivers for controlling the AGVs. However, as discussed in Chap- ter 1, openTCS has some limitations such as the absence of evaluating the impact of different settings beforehand.
The MAS and its control rules affect, for example, the dispatcher, scheduler, and router within the openTCS architecture. OpenTCS still functions as a hub in-between the evaluation model and
8.4. Conclusion 119
FIGURE8.2: The architecture of openTCS (The architecture of openTCS2017).
the actual control, but its functions are focussing on controlling the AGV only because our model overtakes the dispatcher, scheduler, and router functionalities.
We suggest to use already existing communication standards (i.e., preferably from openTCS) that allow easy, fast, and secure access through the evaluation model. More specifically, communication protocols should be established for: vehicle routing, vehicle scheduling, parking management, bat- tery management, demand management (through MES), and potroom entities that cause blockades (e.g., additional cranes, buckets, etc.).
8.4
Conclusion
We briefly proposed a few ways of implementing/using the evaluation model, the MAS model, and the planning and control rules. The evaluation model can be used as a stand-alone model by which the only prerequisite is that the user provides inputs. Another implementation option is the integra- tion of the scenario evaluation model, MES, and openTCS.
121
Chapter 9
Conclusions and Recommendations
This chapter discusses the conclusions of this research. Section 9.1 addresses conclusions with respect to the research questions and contains theoretical and practical implications of our study. Section 9.2 contains areas for further research.
9.1
Conclusions
In Section 1.3.4, we stated our ten research questions. The collective answer to these questions satisfy the research goal of this study. Chapter 2 outlined the context in which this study is framed. In Chap- ter 3, we reported a literature study on AGV system design, dynamic scheduling techniques in man- ufacturing environments, multi-agent systems, and operations research applications in the primary aluminium industry. Chapter 4 proposed the designed multi-agent system for planning and control of the AGVs. Chapter 5 continued by discussing the AGV system design. Consequently, Chapter 6 covered the evaluation model of the AGV implementation controlled by the MAS. As part of model verification and validation, Chapter 7 verified and validated the developed evaluation model. Fi- nally, Chapter 8 sketched an implementation plan of the MAS planning and control strategies in AGV systems. For a concise recap of any of the research questions, we refer to the subconclusion in the corresponding chapter.
In this section, we divide our conclusions into two parts. First, we consider a theoretical perspec- tive and discuss the theoretical relevance of our study. Second, we discuss the practical applicability of our study and address how Hencon and its customer may benefit from it.
9.1.1
Theoretical Conclusion
We developed a generic operational planning and control strategy for AGVs involved in anode trans- portation, within the smelting process of primary aluminium manufacturing. Three models are de- signed: a MAS, an AGV system, and a scenario evaluation model which is build by using a discrete- event simulation. A conceptual model is build, which is verified and validated by means of several validation techniques. We suggest that the AGV system and MAS designs, as well as the simulation model is more widely applicable than just to our specific research. Below we discuss the suitability of respectively our MAS, AGV system, and scenario evaluation model designs to other types of systems.
9.1.1.1 Multi-Agent System Design
The developed MAS framework by following the Prometheus methodology resulted into a specifica- tion of capabilities per agent:
• Demand Management (DM): represents the in- and outgoing demand flow. The data may be provided by the MES but as alternative DM include some heuristics.
• Section Management (SM): monitors pick-up and drop-off locations of the pallets in the sec- tions and thereby considers avoiding collisions due to other ongoing activities.
• AGV Parking Management (PM): assigns dwell points to AGVs.
• Vehicle Scheduling (VS): determines when, where, and which AGV should pick-up or drop-off an anode pallet.
• Vehicle Routing (VR): finds the route an AGV should take.
• Conflict Resolution (CR): monitors AGV movements and is responsible for avoiding collisions and resolving conflicts.
• Battery Management (BM: monitors AGVs battery status and determines when and where an AGV should recharge.
The considered instance of agent entities together with its architectural design provides a MAS framework of which the applicability is not necessarily limited to the context of the primary alu- minium industry. A key element of our design is the inclusion of aSection Managementcapability that divides the potroom into subsets of controllable areas in which problems are solved locally. Other systems involving the planning and control of AGVs can be equipped with this agent specification as well. The applicability scope is not only limited to AGVs, but the MAS framework can, for example, also be applied to warehousing systems.
9.1.1.2 AGV System Design
The AGV system design is built by using the AGV decision framework of Le-Anh and Koster (2006). We developed an AGV system design that can generically built and of which the applicability scope may be wider than a selected group of Hencon’s client base. Our AGV system can be used when one considers using alternative layouts or evaluate the impact of other modifications such as a different vehicle routing approach.
9.1.1.3 Scenario Evaluation Model Design
We developed the scenario evaluation model to assess not only current situations but also to exper- iment with alternative operational planning and control strategies and AGV system designs. The generic structure of the model allows us to examine plenteous configurations of planning and control rules.
9.1.2
Practical Conclusion
The practical relevance emerges as Hencon can start to employ the scenario evaluation model to not only enhance customers’ AGV logistics but also their potroom planning and control strategies. Even with a limited set of input parameters and confined information concerning, for example, an- ode demand patterns, the model can provide insights into expected yielded performance. During the implementation phase at a client, the evaluation model may be used to find appropriate AGV planning and control rules customized to specific client’s needs. Moreover, the software may be used to periodically, based on recent developments at the customer site such as potroom expansions or the placement of additional charging stations, re-evaluate scenarios and configurations. Ultimately, Hencon can then use the developed model as a tool for its full-service providing activities.
We verified and validated the model by means of several techniques. As part of the validation, we considered a smelter layout that closely resembles a real smelter layout. In this particular simulation study, we observed that the cycle time of pallets decreases considerably (more than30%) when one uses two AGAPTVs instead of one. The number of jobs delivered too late also decreases when one uses two vehicles instead of one. The performance, however, will likely not always increase when one considers more vehicles in the system. Depending on the characteristics of the smelter layout (i.e., input parameterizations) and the considered simulation experiments, performance indicators such as the number of jobs delivered too late could increase when including more vehicles in the system. For that reason, it is important to properly analyze the results obtained from the simulation model.