## 3 Use-Case Introduction  
In this paper, a fleet of Automated Guided Vehicles (AGVs) on a factory floor is considered as a running example. The factory consists of a set of machines and storage units. Each machine requests material for starting the production process and requires the produced goods and potential for products to be carried away. Those factory-internal logistic requests are collected by a manufacturing execution system (MES) and translated to transport tasks. The transport tasks are sent to a fleet of AGVs. The fleet shall realize goals such as quick transport job fulfillment, avoidance of machine stops due to a lack of material and equal wear and tear of all vehicles. The distribution of the tasks to individual vehicles has a strong impact on the goals' fulfillment. A common approach for task distribution is the usage of a centralized fleet management unit. The central control unit collects status data of each AGV, analyzes them and sends instructions such as the next tasks or operation details to each AGV individually. While a central control unit provides some benefits such as straightforward development and saving of computational power for the members of the fleet, it also has some disadvantages, such as acting as a single point of failure and leading to the shut down of the whole fleet for system maintenance.  
Instead of only following instructions given by a central control unit, AGVs need to coordinate their actions individually. Hence, decentralized fleet management is considered. For this purpose, each AGV is equipped with a communication module that enables the exchange of messages among AGVs via a publish-subscribe communication framework. The task distribution process is negotiated between fleet members through a bidding process. Every transport task is announced by the MES. Each AGV calculates its bid value based on a globally shared bidding algorithm and local parameters such as battery level, number of open tasks already taken over by the AGV and current location in the factory. The bidding procedure can be selected from a catalog of global strategies, varying, e.g., in the number of AGVs included in the negotiation process and the importance of the different goals of the fleet. Additionally, each AGV offers a set of local strategies, which determine details of the AGV behavior in addition to the tasks that it should fulfill. Local strategies in contradiction to global strategy are used to optimize the behavior of each AGV individually. Strategies are realized by adapting and modifying configurations on each individual AGV. To realize that, AGVs are constructed in a Service-Oriented Architecture, which facilitates the exchange system and service information between fleet participants through an orchestration service called SystemDiscovery [51]. SystemDiscovery stores information about local services alongside the information about services, which can also be provided by other fleet members. Those services are used to adapt and generate configurations. Connecting interfaces of different services from various systems for local reconfiguration is called Service-Oriented Reconfiguration (SoR) [52]. To adapt a system, SoR is in charge of blueprints that describe the connection abilities between potential services. Thus, a configuration can be created and optimized at run-time without the integration of hardware or software modules. The possibility for changes in the negotiation process and in the local configuration of AGVs allows the fleet to react dynamically to situations in the factory.