Hyperconnected Logistic Platform for Heavy-Duty Machinery: Leveraging Physical Internet Principles to Drive the Composting Industry

.


Introduction
The Physical Internet (PI) envisions a universally accessible global logistics system characterized by the integration of physical, digital and operational connections. This is facilitated by the use of encapsulation, interfaces and protocols with the ultimate aim of creating a constantly evolving system that benefits from technological, infrastructural and economic advances [1]. One aspect of the PI vision involves the development of hyperconnected networks across diverse domains. Consequently, the PI approach should be regarded as all-encompassing and not limited to a specific industry. Another particular relevant aspect of the PI vision is the fundamental idea of sharing. Although sharing concepts have been practiced for hundreds of years, new forms of sharing have been emerging, owing to the rapid increase in digitalization and related technologies. This trend has contributed to the rapid growth of the sharing industry in the last decade, with a forecast to grow by more than 25% annually [2][3][4][5][6]. Especially the prevalence of Internet of Things (IoT) and service-oriented architecture have enabled the emergence of sharing Second, the EU has passed a new regulation that makes waste separation and the recycling of organic waste compulsory [22,23]. Therefore, there will be a huge demand for composting (80% increase in the last 20 years) [24]. Traditional methods in this industry will therefore no longer be sufficient.
To overcome these difficulties, the TU Graz and its partners are currently working intensively on solutions, both on aspects of the mechanical engineering domain (development of a fully autonomous electric compost turner, see Figure 1) and on conceptual solutions [25][26][27][28][29]. Our previous work addressed the basic ideas of a sharing platform for compost turners and can thus be considered as a first footstep in this field [30,31]. To achieve the EU's climate targets concerning a circular economy and composting, this paper presents a systematic methodology for designing and developing a hyperconnected HDM-sharing platform based on an Austrian case study. Our approach demonstrates steps and workflows starting from the first idea of the concept up to the technical implementation in terms of a simulation-based case study. The key contributions of this work can thus be summarized.


We proposed a systematic methodology for designing and developing a hyperconnected HDM-sharing platform, serving as a driving force for the composting industry to achieve the climate goals.  We used the Model-Based Systems Engineering approach to model our proposed HDM-sharing platform.  Our study examined a real-world case study of composting plants in Austria by analyzing data within a region of interest.  The proposed platform was implemented using simulation techniques, and we demonstrated how HDM sharing works in the region under consideration.
The rest of this paper is structured as follows. The architecture of the proposed hyperconnected sharing platform is presented in Section 2. In Section 3, the simulation and evaluation of the sharing platform are presented, based on empirical data from Austria. Finally, Section 4 provides a discussion and conclusions, including an extended consideration of the key contributions.

Methodology of the Proposed Architecture
The Architecture of the Proposed Platform In order to achieve open information integration starting from the conceptual idea up to the technical realization of the hyperconnected sharing platform, a conceptual framework is presented in this paper. As illustrated in Figure 2, the framework consists of four layers, the Domain Model, the MBSE Model, the Information Sharing Model, and the Agent Based Simulation Platform. The Domain Model (DM), as seen in Figure 3, represents the highest level in the proposed architecture. As commonly found in the relevant literature, the primary focus is now on the system-wide view (see [32] for a more detailed discussion). At this level, the current situation of the given task is analyzed in the first step. Naturally, this includes the involvement of all stakeholders, such as the plant manager, truck drivers and the operator of the composting plant. After the depiction of the current situation, the different viewpoints of the stakeholders for the given task, in this case using the sharing platform for HDM at composting plants, are investigated. The objective is to achieve a precise understanding of how each stakeholder would perceive the sharing system. Each stakeholder's needs, requirements and constraints are identified in detail, as well as the mutual effects of the sharing platform and the stakeholder. Documentation is performed in the form of outlines, flow charts and diagrams. Once the needs, requirements and boundary conditions for all stakeholders have been defined, they need to be incorporated into MBSE in the next step. MBSE Model. At a certain level of complexity, which is a consequence of the large amount of information collected in the DM, it becomes increasingly difficult to maintain a clear understanding of the overall picture. A certain degree of design flexibility is important in the DM in order to enhance creativity. Nevertheless, the collected information, such as requirements, needs and constraints, must now be brought together in a structured fashion. Among other reasons, it is necessary to reduce the level of complexity, and mutual interactions between requirements and needs must be described. We consider an approach based on Model-Based Systems Engineering (MBSE Model) to be suitable for overcoming the above-mentioned challenges [30]. There are numerous approaches and methods in this domain. Due to the practice-oriented design, the ARCADIA methodology is widely accepted in industrial and scientific domains and is therefore employed in the present study. The overall design of the ARCADIA method, consisting of the four layers of Operational, System, Logical and Physical Architecture, is shown in Figure 4, and a detailed discussion of this method can be found in [33,34]. For the implementation of the ARCADIA method, the software Capella TM , version 5.1, is used [35]. The Operational Analysis is the most abstract level in the ARCADIA architecture. The main question of this level to answer is as follows: "What do the users of the future system have to achieve?" The focus is on identifying the needs and goals of the user: "What are their activities? What roles do they need to fulfill, and under which what-if scenarios do they operate?" Many of these questions have already been clarified in the previous DM and only need to be formalized in this step. The big advantage over the previous step is that the MBSE Model is created in the Capella software, allowing all dependencies to be entered directly, resulting in the immediate detection of any contradictions. The Analysis of the System Needs raises the following question: "What does the system have to accomplish for the users?" The aim is thus to identify the capabilities and functions of the system to satisfy operational needs. An external functional analysis is carried out to identify the system functions needed by its users, limited by the non-functional properties requested. Whereas the first two analyses consider the system a black box and are therefore devoted to needing understanding, the following two focus on the solution architecture design, whereby the system is now considered a white box. The key question of the Logical Architecture is, therefore, the following: "How will the system work to fulfill expectations?" An internal functional analysis is performed to identify the sub-functions that must be carried out and put together to establish the "user" functions identified during the previous phase. Furthermore, an identification of the logical components that execute these internal sub-functions is performed, as well as the integration of nonfunctional constraints, such as performance and safety. The Physical Architecture is the fourth and final analysis. This deals with the question of how the system is developed and built. The aim of this level is the same as that of the logical architecture, except that it now defines the final architecture of the system. Functions required for implementation and technical decisions are added, as are the behavioral components (e.g., software components) that perform these functions [33,34]. Because the ARCADIA method is mostly used in a top-down approach, the levels of Operational Analysis, Systems Analysis and Logical Analysis are mandatory. Thus, the consideration of the Physical Analysis is not always necessary and is skipped in the present work, as its focus is on a case study in which no physical realization is required. In summary, the output of the MBSE Model consists of systems, subsystems and their interactions on a logical level.
The Information Sharing Model (ISM) takes all of the above-mentioned information as its input. The aim of this level is to create a platform that integrates the main components of the HDM-sharing platform together. Thus, making this level a crucial part of the overall platform, as discussed by [15]. The "PI Hub Network Development" deals with the question of where optimal facilities ("hubs") should be established so that the HDM can be transported from these hubs (sources) to the respective composting plants (targets) in the best possible time. This phase is governed by the systems boundaries and receives as input the real word geocoordinates of the already existing composting plants, as well as a set of feasible locations where the PI hubs could be constructed. "PI Route Planning" deals with the question of through which specific routes the HDM must be transported to reach the sources in the optimal time. The results are then passed back to the "PI Hub Network Development" through a feedback loop. It is important to note that this layer does not cover the concrete implementation of the components addressed but rather focuses on the information that must be exchanged so that the overall system of the sharing platform ultimately operates consistently ( Figure 5). The Agent-based Simulation Platform is the last level of the proposed architecture, and it is responsible for the implementation of the proposed platform using a discrete event agent-based approached. At this level, the processes, methods, models, algorithms and their implementation are presented. Figure 6 provides a detailed view of this layer, consisting of an agent-based simulation, sources and targets, location planning and routing. There are different notions and definitions of agent-based simulations depending on the discipline [36]. Thus, we follow the approach of [37], which defines an agent as a theoretical, virtual or physical entity. This entity is able to act on itself and on the environment in which it evolves and is able to communicate with other agents. Its behavior is the consequence of its observations, knowledge and interactions with other agents. Its characteristic properties are its role, goals, functionalities, beliefs, decisionmaking ability, communication ability and learning ability [38]. For a more detailed discussion on agent-based simulations, please refer to [39]. We decided to use an agentbased approach because it is considered more powerful for the present use case, as it allows capturing more complex structures and dynamics [40]. The aim of the agent-based simulation, which, in the present case, is for the "Sharing Platform", is the virtual representation of the selected example region. As is explained in detail in the use case (see the Section 3), the composting plants "targets", and the locations for HDM ("hubs" or "sources") are virtually mapped on real road map data. To achieve what is mentioned above, the following steps are required. In the "sources and targets" step, the actual coordinates of composting plants and a set of possible hubs must be determined. The method of how the locations are selected is determined in the previous phases of our proposed architecture. Once the locations have been determined, the next step, "location planning", is to determine the optimal hub positions from the given set of possible hub positions. Hereby, we refer to "optimal hub positions" as those positions where all targets may be reached from the assigned sources within the shortest possible time. From a mathematical-logistical point of view, we use the Capacitated Facility Location Problem for this step. This model is well suited to solve the optimization problem mentioned above [41]. Once the optimal locations for targets (hubs) have been determined, the routes from each source (composting plant) to the respective assigned targets must then be calculated. From a mathematical-logistical point of view, there is a wide range of routing algorithms that might be suitable for such kinds of problems. Again, we refer to the literature for a more in-depth discussion [42][43][44]. Therefore, we use the "multi-depot heterogeneous vehicle routing problem with time windows" (MDHVRPTW) for the present case. This mathematical model is an extension of the classical vehicle routing problem (VRP), which additionally considers time windows (TW) and multi-depots (MD). Time windows denote that the time needed by the HDM to work at the targets (e.g., to turn the compost at the plant) is taken into account. Multi-depots allow the computation of routing from multiple sources to multiple targets. As is evident in the Section 3, this capability is important for the given sharing platform for HDM.

Case Study
We intend to ensure that our proposed architecture (see Figure 2) has a certain degree of universality and is therefore not exclusively suitable for a particular application. Hence, a specific use case is considered that substantiates the validity of the architecture.

Applying the Proposed Architecture: The Use Case of Styria/Austria
In the following chapter, the presented architecture is applied, taking the already described province of Styria in Austria as the example region.

Domain Model
As already noted in the introduction, the situation of composting plants in Central Europe is very decentralized. Every village, municipality and town has surrounding composting plants that treat accumulated biogenic waste. This leads to the situation of numerous but therefore also very small composting plants. Because it is important to choose a region that is as representative as possible, we decided to use the province of Styria, which is located in Austria, as an example region. The first level in our presented architecture, the Domain Model, was developed in close collaboration with domain-specific experts from the compost industry. The result was a model for a hyperconnected sharing platform, as shown in Figure 7. The basic idea is to have a truck loaded with HDM, for example, a compost turner, starting from a hub and visiting all composting facilities in a round trip. At the plants, the HDM is unloaded from the truck, performs its work and is reloaded to travel to the next plant. Due to the large number of composting plants in the considered example region, it is necessary that several hubs are foreseen in the hyperconnected sharing platform. The main task of the hubs is the maintenance and the overnight parking of the HDM. The hyperconnected sharing platform currently assumes daytime operation; nigh ime operation could be a possible expansion at some point. The number of hubs, as well as the number of positioned HDM per hub, is selected such that the platform is stable and robust against disturbances. Corresponding optimization algorithms are presented in the following. A special characteristic of the proposed platform is the interconnection of all hubs. This ensures that extraordinary peak loads can be covered by other hubs. Another essential aspect of the Domain Model is that it achieves an understanding of how individual stakeholders perceive the hyperconnected sharing platform. In cooperation with industry experts, the impact of the platform on the individual stakeholders ("composting plant operator", "truck driver" and "sharing coordinator") was assessed. The results were documented in the form of processes and procedures. As mentioned, the platform should only operate during the day; thus, the round trips of the trucks loaded with HDM, as shown in Figure 7, should not exceed one working day.

MBSE Model
In accordance with the proposed architecture, those that were still unstructured processes at that time were implemented into the MBSE Model. Through this step, the documentation effort was converted into a digital form by embedding those processes into the Capella software, version 5.1. On the one hand, a reduction in complexity was achieved. On the other hand, a particular characteristic of MBSE could be exploited, namely the possibility to graphically represent dependencies between systems. This allowed the detection of contradictory dependencies that were not obvious in the Domain Model, as it was mainly in a paper form. To give an example, Figure 8 shows an MBSE process chain from the truck team's perspective in the sharing model. The actors ("truck team", "coordinator", "online system" and "composting plant operator") are shown. The functions of the respective systems are shown as green boxes. The various systems and their subsystem exchange data with each other are also shown, although not all connections (green line) are required for the process chain (thick blue line). The systems, functions and the process chain displayed in Figure 8 were already designed in the Domain Model step; the integration of these elements into an MBSE Model now establishes the connection to the overall system. If one changes a function in the depicted view of the "truck team", the result would be instantly updated to all other views, for example, to the "composting plant operator" view. As already indicated, this characteristic of the MBSE Model is essential for reducing interface errors. Another essential point is the determination of a set of possible hub positions, from which the optimal hub locations are later determined by means of optimization procedures. At this point, several options come into question. From a pure mathematical point of view, it would be conceivable to cover the considered example region with a grid whose nodes represent the sought set. However, this entails some disadvantages from a technical-logistical point of view. First, the node could be located in geographically unfavorable places, such as rivers, lakes or mountains. This could still be circumvented by performing manual fine-tuning of the locations. However, a far more serious difficulty arises from the fact that the sites would obviously have to be built at the nodes, which naturally entails substantial investment costs. In order to overcome these challenges, one might consider this ma er from a Physical Internet (PI) perspective. A fundamental idea of the Physical Internet is to leverage existing infrastructure for new concepts [45]. Taking the present case of a hyperconnected sharing platform in Styria as an example, such existing infrastructure might be the sites of Machinery Ring Austria. Its business model is to establish small to medium-sized communities that share equipment in order to mitigate the issue of high investment costs. These communities currently operate in a decentralized manner, but all have a regional base where the equipment-ranging from small household appliances to heavy agricultural machinery-is stored and maintained. Expert interviews with representatives revealed that adopting the existing sites as hubs for a hyperconnected sharing platform for HDM at composting facilities does indeed provide value. Therefore, the set of possible hub positions for the present work was chosen as the locations of Machinery Ring sites in the province of Styria. The locations are depicted in Figure A2 in Appendix B.

Information Sharing Model
Once the processes and workflows have been methodically defined, the information flows must be developed in the Information Sharing Model. For the present case study, this is illustrated in Figure 9. The initial stage involves transmi ing the geographical data consisting of the specific locations, designated as "targets and sources," to the location planning module. Subsequently, the outcomes derived from location planning, which are the optimal hub positions, must be forwarded to the route planning module. Finally, the optimal routing configurations are forwarded to the Agent-based Simulation Platform for further analysis.

Agent-based Simulation Platform
After the information flows have been clarified, the technically concrete models and optimization algorithms are implemented in the Agent-based Simulation Platform. As input data, the positions for hubs defined in the previous steps as well as the positions for the considered composting plants in the example region are required. These positions are shown in Figures A1 and A2 in Appendix B. Based on these data, location planning determines the optimal positions for the hubs. This is performed by applying the Capacitated Facility Location Problem. Apart from the positions of the composting facilities and a set of possible hub positions, capacity M of the hubs is also taken as input. In this context, capacity M determines the number of composting plants that the truck loaded with HDM can visit within a set period of time t_max. As defined in the Domain Model, the time span is set in this case to one working day, i.e., t_max = 10 h. Capacity M therefore depends first on the travel time of a round trip, which is the time the truck spends traveling from one composting plant to the next. Second, the time the HDM spends at each composting site to perform its work, t_K, is a major influencing factor. The former can be taken as an estimated percentage p of the total time t_max. The la er, the time t_K, can be estimated using statistical methods. Thus, the maximum capacity M follows: The numerical estimation for t_K is obtained by applying the methodology presented in [30] and heavily depends on the scenario under investigation, as is discussed in the following section. For enhanced comprehension, a brief example is given. Assuming that, on average, it takes the HDM a total of 57 min to perform the work at a composting plant, we yield a value of t_K = 57 min. With the assumption that 30% of the total working time is allocated to the travel time (thus, p = 0.3), an estimation for the capacity can be given with = 7.37. Because the capacity can only be an integer, we subsequently receive a numerical value of M = 7. At this point, it should be again explicitly emphasized that the above-mentioned considerations are assumptions. On the one hand, it is impossible to determine the exact travel time without first knowing the exact positions of the hubs. At the same time, it is equally impossible to calculate the positions of the hubs without having an assumption for the travel duration. As already shown in the methodological architecture in Figure 6, this approach must be regarded as an iterative procedure [46]. The implementation of our optimization approach was inspired by the work of Pedroso et al., and the result is shown in Figure 10 and can be interpreted as follows [47]. The Capacitated Facility Location Problem (CFLP) procedure, shown in Figure 10, selected the optimal sources based on a set of possible sources (see Appendix B, Figure  A2 and Appendix A for a more in-depth discussion on the CFLP). These optimal locations are shown as large colored nodes with a house symbol. Sources that were not selected as optimal are shown as large purple nodes. These are not considered in the following. The composting plants are represented as small nodes. Each of these nodes is the same color as that of the sources to which they have been assigned by the algorithm. The routes, which represent the fastest connection from the source to the target, are colored black. As can be seen in the figure, the entire Capacitated Vehicle Routing Problem was calculated based on the real existing road network in the example region of Styria. Furthermore, vehicle profiles were applied, which, among other factors, also take the maximum speeds on the roads into account. The figure clearly shows that the positions were calculated on the basis of individual, star-shaped trips. Thus, the logical next step is to calculate the round trips using the previously determined positions as input.
The result of the routing, specifically the "multi-depot heterogeneous vehicle routing problem with time windows" (MDHVRPTW), is shown in Figure 11. The previously determined optimal hub positions are plo ed as large red circles. The small circles are the composting plants, which are again painted in the color of their associated hub. The routes of the trucks loaded with HDM are clearly marked in the respective color. As a boundary condition, it was again set that a maximum of seven composting plants can be visited from each hub to fulfill the earlier set condition that the round trips must be completed within one working day. It should be noted at this point that the assignment of the composting plants to their respective hubs has changed since the previous step. This is a logical consequence of the fact that location planning assumes star-shaped trips, and the aim of the routing is to achieve optimal round trips. Furthermore, it should be mentioned that the routing step focuses on the consideration of the entire region of interest; the routes from all sources to all targets were computed using optimization. However, the timerelated components of the system are missing. To address these aspects, the results of the previous steps, namely sources and targets, location planning and routing, are integrated into an agent-based simulation. Figure 11. Results of routing. Optimal round trips starting from hubs to a maximum of seven composting plants within one working day. Figure 12 shows a screenshot of the agent-based simulation performed in the AnyLogic software, version 8.8. The composting facility "targets" under consideration are shown as small green house symbols. The hub positions selected in the location planning step are yellow, larger house symbols. Trucks loaded with HDM are shown as small red vehicle icons. The sources, targets, trucks and orders were modeled as agents in AnyLogic. The trucks agent consisted of a very basic state chart, containing the states of idle and travelling. Each time, the truck agent receives an order, the state swaps to traveling, and a message of the current time is sent out. These data are the basis for the later evaluation of the time stamps. The order that agents receive is input from the previous route planning step, implemented via the open-source Python AnyLogic Pipeline. Thus, the trucks travel along optimal round trips, as calculated in the routing step. As indicated, the main output of the agent-based simulation is the timestamps of the trucks or, more specifically, the time at which the trucks started, the time when they visited their assigned plants and, of course, the time when they returned to their respective hubs. This information proves to be essential for the following simulation-based scenario investigation. Figure 12. Results from location planning (optimal hub locations) and routing (optimal round trips) were integrated into the agent-based simulation.

Experimental Evaluation and Comparison
Within the present study, three simulation-based scenarios are analyzed. Before the specific results are discussed, a brief overview of the scenarios is given.

Overview of the Conducted Simulation-Based Scenario Investigation
The first scenario assumes the participation of small and medium-sized composting facilities. This approach aims to provide an accessible and cost-effective solution for smaller composting plants that may not have the financial resources to purchase the machinery needed to compete effectively in the market. Including these smaller and medium-sized facilities is especially important, as they handle composting at local, communal scales, thus contributing to increasing the composting rate required to achieve the climate goals. The data basis for the simulation scenarios presented here was created through empirical studies that investigated the situation of composting facilities in the Central European region. The aim of these studies was to determine the average amount of time required by composting companies for utilizing heavy-duty machinery on a daily basis. The information obtained was used to develop profiles of composting plants, which are used in the present scenario analysis. Percentiles were used to rank the composting facilities by size and performance. This facilitated the establishment of a profile for smallscale composting facilities, defined as the 0th to 20th percentiles. The classification for medium-scale composting facilities covers the 20th to 80th percentile range, whereas large-scale composting facilities are situated within the 80th to 100th percentiles.
The second scenario assumes that all composting plants participate in the HDM platform to an equal extent. The objective of this scenario is to investigate the feasibility and performance of the platform, assuming that all heavy machinery required for composting is shared among composting plants of all sizes. More specifically, this scenario explores the effects of the involvement of small, medium and large composting facilities on the platform. It is worth noting that the duration of machinery usage varies for the different sizes of facilities, with larger facilities needing the machinery for a longer period of time than that required by smaller facilities. Accordingly, this factor is taken into consideration in the scenario to ensure that the shared machinery meets the requirements of all participating composting plants.
The third scenario is based on the assumption that small and medium-sized composting plants are dependent on the HDM platform because they do not have the financial means to be able to purchase the required heavy machinery themselves. The larger facilities are assumed to already possess the necessary equipment and therefore do not need to participate in the platform. Nevertheless, the utilization of the machinery in these large plants is generally low, mainly because they are usually operated primarily during the morning. This results in the equipment remaining unused in the afternoons. As mentioned in the introduction, a key principle of the Physical Internet concept is to leverage the use of underutilized resources. Because the heavy-duty machinery of large composting companies remains idle in the afternoon, this underutilized resource can be leveraged in accordance with the PI concept. Scenario 3 thus assumes that these large companies act as PI hubs during this period. A brief summary of the aforementioned scenarios can be found in Table 1. Small, medium and big plants participate to an equal extent. Machinery usage varies for the different sizes of plants, with larger facilities needing the machinery for a longer period of time than that required by smaller facilities.

Scenario 3: Region-Wide Hyperconnected Network Leveraging PI Assets
Small and medium-sized composting plants require the HDM platform and therefore participate full-time. Big plants already possess the necessary equipment and are not interested in the platform. However, they act as PI hubs in the afternoon by providing heavy-duty machinery for composting.

Presentation and Graphical Visualization of the Obtained Outcomes
Scenario 1 deals with the case in which only small and medium composting plants participate in the platform. As can be clearly observed in the statistical analysis in Figure  13a, a total of six round trips are necessary to serve all plants. These round trips start and end at a PI hub, marked as a red circle in the map of Figure 13a. It is well visible that none of these round trips needs more than 10 h, and therefore, all composting sites can be served within the given time limit. Thus, this scenario can be considered successful. In Scenario 2, the conditions vary, as it not only encompasses small and medium-scale composting facilities but also integrates large-scale plants. Consequently, an increased number of round trips is inevitably necessary. As can be seen on the map and the corresponding statistical evaluation in Figure 13b, a total of eight round trips are required for this scenario. When examining the statistical evaluation, it is immediately apparent that round trip no. 3 exceeds the specified time limit of 10 h. Moreover, a closer look reveals that both round trips no. 4 and no. 5 require significantly less time than that which is available. As already mentioned in Section 2, the aim of the optimization is to find the best possible routes so that the sum of the time required for all round trips is minimized. As is clearly evident from round trip no 3, this is not sufficient in the present case. Therefore, a constraint is introduced, which additionally limits the individual trips to a time limit of a maximum of 10 h. The results of this additional constraint in Scenario 2 are presented in Figure 13c. Examining the map in Figure 13c, it can be clearly observed that the routes have changed due to the added constraint. However, it is interesting to note that, not only have the routes of those trips that exceeded the time limit in the previous scenario changed, but now the routing of all trips has been adapted. As can be seen in the corresponding statistics, the time limit can be kept for all trips due to the adapted routing. Thus, this scenario can also be considered successful.
Scenario 3 is of particular importance in the context of this study. Based on the fundamental approach of the Physical Internet vision, namely to leverage unused resources within new domains, large composting companies provide their machines in the afternoon and thus serve as PI hubs. Therefore, in the PI hubs location planning phase, the optimization task gets adapted and is now defined as follows: "Given a set of possible hub locations, find the optimal number and position of hubs so that all targets can be served, whereby the positions of large composting plants must be chosen as hubs".
The result of the PI hub location planning phase is shown in Figure 14a. The purple markers represent the locations that were not selected as optimal hubs and that will therefore no longer be considered. The large colored markers represent the chosen hubs, with the smaller, equally colored markers representing the corresponding composting Legend facilities. The PI hub location planning phase computation indicates that, in addition to large composting facilities, only a single hub needs to be constructed. This hub is shown in Figure 14a as a marker outlined in a red circle. Whether this claim holds up is now being investigated in PI-based network development.  Figure 14b illustrates the outcomes of the PI-based network development. In this scenario, routing considers the fact that trips originating from big composting plant hubs are operational only during the afternoon, encompassing a duration of 5 h. In contrast, the newly constructed hub, as in the preceding scenario, functions throughout the day by covering a total of 10 h. In the statistical analysis presented in Figure 14b, it is evident that the specified timeframes are maintained, with the exception of minor deviations observed in trips no. 1 and no. 9. These deviations, although minimal, are further examined in the discussion section. Overall, Scenario 3 demonstrates a high degree of success. The findings effectively illustrate that the implementation of a single hub, coupled with the utilization of pre-existing resources, is sufficient to serve all composting facilities participating in the HDM platform.
The following section provides a concise comparison of the three investigated scenarios. To visually represent this comparison, the ratio of the number of PI hubs to be constructed to the number of composting plants served was calculated. Figure 15 displays the results for all three scenarios. It is immediately evident that Scenario 1, with 6.2 plants per PI hub, closely resembles Scenario 2, which has 5.8 served plants per PI hub. In terms of percentages, Scenario 2 is 7% less efficient than Scenario 1, although the difference is relatively small. The comparison with Scenario 3 is especially noteworthy. As already discussed in detail, significant potential could be exploited by leveraging large composting plants toward PI hubs. Because all large composting plants are already equipped with the necessary machinery, only one new hub needs to be constructed, resulting in a 746% improvement compared to Scenario 1. It is important to note that this comparison is not comprehensive. Indeed, the values presented in Figure 15 should be viewed as an incentive to highlight the considerable potential of such a hyperconnected network.

Discussion
In the present work, a systematic methodology for the development of a hyperconnected logistic platform for HDM in the composting industry was presented. Following a top-down approach, starting from the top, the most abstract level of the architecture (Domain Model) and the further levels (MBSE Model and Information Sharing Model) up to the technically concrete Agent-based Simulation Platform were presented. Afterward, the technical feasibility of the proposed architecture was demonstrated through the technical implementation of the presented methods.
The proposed architecture provided a clear approach for the development of a hyperconnected HDM sharing platform, which enables access to composting machines for multiple, especially smaller, composting plants, ultimately contributing to increasing the composting rate and thus achieving climate goals. The platform was deliberately designed in such a way that, while following a clearly defined procedure, the crucial role of creativity, especially at the beginning, was not undermined. Another key aspect of the architecture is its interdisciplinary approach. Successful development is inconceivable without the engagement of stakeholders from all disciplines involved in the hyperconnected sharing platform. Therefore, as discussed in detail in the Section 2, it is essential to have all stakeholders participating in the very first level of the architecture, the Domain Model. Furthermore, this participation ensures that essential decisions and information that affect the overall system, such as boundary conditions, are passed on from the top layers to the underlying layers. This results in a reduction in interface errors at the technical implementation level, because these interfaces have already been defined jointly by all stakeholders at higher levels. In the use case of the example region of Styria, the key aspects of the proposed architecture were implemented successfully. In cooperation with all stakeholders, the Domain Model was developed, which defined the basic functionality of the sharing model. The resulting data were then formalized in the MBSE Model. The Information Sharing Model could be exploited to negotiate the individual components together. Finally, at the technical-specific level, the implementation of location planning, routing and agent-based simulation was realized. Although it is obvious that the key aspects of the sharing system were successfully implemented, it is mainly the minor aspects that require a more critical assessment. To give a specific example, one may mention policy restrictions that have not yet been incorporated into the presented hyperconnected sharing platform. In the example region of Styria, such restrictions would include driving restrictions for heavy commuter traffic on selected country roads. This is due to the fact that political efforts are being undertaken to require the prioritized usage of highways and freeways. Of course, the inclusion of these restrictions is not in contradiction with the proposed architecture; nevertheless, their inclusion would affect the results of the current use case, as certain routes would have to be excluded in the "routing" step.
From a managerial perspective, the hyperconnected sharing platform has several interesting impacts. On the one hand, it seems promising that the deployment of the platform in an example region leads to an increase in high-quality compost as a product. Smaller enterprises may especially benefit, as these are often not in a financial position to invest in costly machinery, which is absolutely necessary for the production of highquality compost. Further, it is quite conceivable that the platform will a ract new players who are not yet active in this industry.
Although a comprehensive economic evaluation is not within the scope of the present work, it is nevertheless worth mentioning certain considerations regarding achievable productivity gains of the platform on a system-wide level. It should be noted that the composting of agricultural waste, such as wood and greenery, is still of minor importance in the Central European region. A traditional and widespread way of disposing green waste in the spring is the Easter bonfire, in which communities collect green cu ings to burn afterward in the bonfire. To address this environmental catastrophe, there must be a more widespread change in a itude, as emphasized in Figure 16. It is essential to recognize that the composting of green waste is not only absolutely critical for environmental reasons but can also bring economic benefits. The heavy-duty machines required to achieve these goals can be provided by the platform presented in this paper. Large industrial composting plants, which already possess such equipment, are capable of producing and selling more than 20 different types of high-quality soils. Due to the constantly increasing demands of customers, including the departments of the public green spaces of cities and municipalities, there is a huge demand for those highquality soils. As industrial composting plants have successfully demonstrated, these highquality products can generate significantly more profit than that of low-quality compost. The overall aim is therefore to raise general awareness of the fact that compost is not just waste but rather a high-quality product that should ultimately be sold to consumers. This incentive effect could be exploited, for example, to integrate smaller farms into the hyperconnected sharing platform. Naturally, if the platform grows as a result, the number of corresponding HDM and hubs must be increased. This process can be achieved in a systematic and methodical way by iteratively following the proposed architecture.
The introduction of the proposed hyperconnected sharing platform in this paper does by no means claim to be exhaustive. The authors are convinced that there are still many open topics remaining, among which a few are briefly outlined in the following.
One key issue that affects all levels, starting from the Domain Model to the Agent-based Simulation Platform, is the question of whether the participants of the sharing model can express preferences regarding the arrival time of the HDM. This is a critical issue, as it obviously conflicts with the most optimal route planning in the form of a round trip. If participants are given the opportunity to determine the time when the truck loaded with the HDM should reach their respective composting plant, the truck would thus no longer be able to travel the fastest possible round trip across all plants. One way to address this challenge could be the introduction of weighting functions. In this way, the preferences of plant operators can be respected, while at the same time avoiding commi ing too much to the operators, by assigning appropriate weights in the optimization algorithms. Although early a empts on this topic are already in progress, much work remains to be conducted until publishable results are obtained. Further aspects include the economic assessment of the hyperconnected sharing platform, which was deliberately omi ed in the context of the present publication. Such an assessment would require the platform to be analyzed from an analytical and economic perspective rather than from a technical and logistical point of view, as was conducted in the present work.