2. Basic Approach of (Intelligent) Decentralized Automation The factory automation is structured hierarchically in form of an “automation pyramid,” in which each level performs special automation functions. Individual automation devices/systems, such as field devices, PLC, HMI, and control systems, are specifically attributed to individual levels (Table 1). Data generated in industrial production are strictly attributed to the different levels, transferred via interfaces, and aggregated or abstracted. Level acc. IEC62264 Label Typical Systems Tasks (excerpt) 4 Enterprise level Enterprise Resource Planning Systems Rough production planning Order processing , l ogisti cs 3 Production level Manufacturing Execution, or Warehouse Management System s Order management: detailed planning, control, and monitoring of production or material flow Management of plant information, reports, alarms Management of resources, personnel, and quality Maintenance and material inventory management 2 Process control level Process control, HMI, and SCADA systems Superordinate process control and monitoring (for continuous, batch, or discrete processes) Operation, monitoring, measurement archiving Recipe administration and implementation 1 Automation level PLCs, motion contro l lers Control, Monitoring and diagnostics for the equipment and machines to be automated Field level I / O -modules, field devices, field bus Collection and processing of information from the technological process through sensors Active process intervention through actuators Table 1. Automation Levels and Systems. Initially, approaches for the decentralization of systems within factory automation occurred primarily at the hardware level based on PLC and field bus systems with process oriented automation functions (e.g., systems for decentralized periphery such as SIMATIC ET 200, or for DCS, such as PCS7). An essential objective here was the reduction of cabling and thus of the hardware cost. The consistent further development of these concepts led to intelligent field devices and the distribution of process oriented process control functions. Such decentralization, however, applied mainly to Level 1 Systems with process-oriented functions. In the meantime, numerous research projects develop decentralized concepts that include also the higher levels of the classic automation pyramid, such as production control systems and material flow computers reaching level 2 & 3 systems. The basic idea of these approaches is to modularize “central” process control tasks and to decentralize them to basic control unit types: Independent functional automation units representing and controlling the resources of a factory Independent production process units representing and controlling the processed objects within the factory (e.g., a manufactured workpieces, products or transported goods) Decentralized process control is achieved by situation-based interaction of controlling units of resources, as well as those of processed objects, resulting in a dynamic online setting for the process. For implementation of such approaches, mainly agent-systems are applied.

3. Use Cases of Decentralized Automation Systems in Factory Automation There are various reasons for research and development of decentralized automation technologies. However, decentralized automation systems do not have an advantage per se, but must rather be regarded as means to achieve certain benefits and objectives. Examples for the benefits are: Increase of the flexibility and improvement of the adaptability of the automation system Higher efficiency (throughput, use of resources, degree of automation) Reduction of communication effort Increased robustness and reliability by local troubleshooting Reduction of complexity for integration of resources/machines Faster setup and reconfiguration The following two applications of decentralized automation were developed in the framework of the research projects PABADIS'PROMISE and Internet of Things. They are representative for approaches in decentralized factory automation and can be found in a similar manner in other approaches (Shen et. al, 2006; Bussmann, 1998; Tönshoff & Woelk, 2001; Hall, 2005). 3.1. Flexible, Decentralized Production Systems Accelerated innovation, shorter product life cycles, and more variants combined with small batch sizes represent new tasks for production automation. In the future, production plant suppliers must provide the following functionalities in addition to the actual automation: Production flexibility through individual production planning, and optimization Vertical integration of information and functions at the control, MES, and ERP levels Fast reconfiguration and scalable capacity through dynamic resource integration (“Plug’n’Produce”) In the European research project PABADIS'PROMISE, an architectural basis for flexible and vertically seamless production automation was developed. Key features of the approach are: Product driven definition of control processes instead of machine centered definition Merging of the previously hierarchically separated tasks of control and MES systems Decentralization of the automation functions into independent, cooperating units. In this approach, the product to be manufactured represents the set point, while the control system is based on an explicit description of product data and production processes (machine independent working processes and parameters). Machine interfaces are described accordingly in a behavior-oriented manner. The integrated description model serving as basis represents an expansion of the IEC/ISO 62264 Standard (Diep et. al., 2007). Based on these descriptions, the product-specific, on-the-fly configuration of the specific production processes of the production system and the dynamic integration of additional modules at runtime are implemented by means of software agents and RFID technology. Machines and production orders are represented by a logically and physically decentralized agent network (see Fig. 1), which coordinates the production process dynamically according to machine functions, degree of utilization, and error status, as well as allows the seamless online access from the ERP level to the field level (Lüder, et al., 2007). Fig. 1 depicts an example of decentralized control of an automotive production line where the approach was prototyped. 3.2. Flexible, Decentralized Intralogistics Systems The term intralogistics refers to the logistical flow of goods and data "inside the four walls" of a plant. A typical example of an intralogistics system is an automatic high bay warehouse for storage and retrieval of goods in combination with an automated transport system that moves these goods within the plant. Currently, such systems are designed to fulfill a specialized and more or less static workflow. In the future, there will be a stronger demand to support or quickly adapt to different workflows to increase flexibility and adaptability both in the warehouse and in the transport area. A practical application example is the increasing third-party business in the intralogistics area in which logistics companies perform storage and shipping services for one or more customers. Because of the mostly short contract relationship, the necessity results to adapt such a facility quickly and in an optimized manner to new customers and their requirements. Considering contemporary facility designs, this would result in frequent reconstructions. Due to high efforts, such a reconstruction is often only done in a limited manner, for which reason a part of the benefit potential of the facility will not be achieved. By means of a cost effective provision of a higher flexibility through a convertible facility, third-party logistics suppliers may achieve a significant cost advantage. Requirements on increased flexibility and adaptability of automation solutions are for example providing additional storage capacity, supporting the storage and transport of new types of boxes, introducing new storage and picking strategies, including new sources and destinations in the transportation system. These adaptions must be supported effectively by a more efficient engineering of the related disciplines, such as mechanical, field control, and process control engineering. There is the notion that higher flexibility can be achieved through an efficient modularization of the intralogistics system, along with suitable engineering processes. The "Internet of Things" research project addresses these demands by developing a new modularization concept. Up to now, modularization is aiming mostly at the creation of modules within each of the abovementioned disciplines, i.e., modularization is done horizontally as shown in Fig. 2 (left), where every discipline creates its "optimum" modules and standards that help to improve the level of integration between those discipline-specific modules. The problem here is that the integration between the systems of the different disciplines – and, therefore, the integration of the entire facility – is not addressed through such horizontal approach and, therefore, must be implemented specifically for each project. This fact leads, according to experience, to substantial additional costs, particularly during the commissioning phase. The "Internet of Things" project introduces the concept of mechatronic modularization, stating that modularization is oriented towards the physical structure of intralogistics systems, and it is designed vertically with each module containing parts of the mechanical, field control, and process control engineering disciplines; see Fig. 2 (mid). This modularization concept is applied in a consistent and uniform manner to all engineering tasks that have to be performed during the lifecycle of an intralogistics system, in the design phase as well as in the commissioning and the reconfiguration phases. An example of such a mechatronic module within the transport system could be a divert module that sends a box either straight on or causes it to turn left or right. The mechanical part of the module is the divert itself. The field control part comprises, among others, the control logic required for switching the divert to straight or left/right along with the sensors and actuators. The process control level contains routing capabilities that analyze the transport destination of the box and decide if it should move straight on or not, see Fig. 3. In contemporary intralogistics systems, the functionality of the process control level is implemented in a Material Flow Control (MFC) System. Once this functionality is also integrated into the concept of the mechatronic modularization, it means the dissection of the previously centralized MFC System into autonomous modules. This procedure is necessary since the modules must be easily combinable with each other and, therefore, must not have interdependences with each other. Existing, possibly complex interdependences should remain encapsulated within the modules and not appear outside of the modules (cohesion). The total functionality is dissected into independent partial functionalities, which are integrated again at runtime. For this purpose, the automation functions of the system must be dissected at all levels; see Fig. 2 (right), which leads to the decentralization of the system as shown in (Elger, 2007). By doing this, the automation pyramid in the classical sense is largely dissolved. Decisions previously taken centrally are now taken at runtime by interaction between the individual modules. The concept of the Internet of Things research project (Internet of Things, 2009) is that modules provide mechanisms for two-way identification, for coordination among each other, and with the environs, for determination of decisions, or additionally for the dynamic adaptation to changed conditions. An example is a box to be conveyed in the intralogistics system that communicates its identification at each divert and identifies its target location by RFID to the divert module. The divert module now communicates with other material handling modules in the intralogistics system, such as other diverts, conveyors, and merges, in order to determine which path the box must take to reach the target location. The use of pre-integrated modules, the encapsulation of the functionalities, as well as the ability of the modules for identification and coordination among each other, lead to the fact, that modules can, referring to automation engineering, be integrated with each other to an entire facility on a “Plug&Play” basis. This allows supporting the mentioned requirements for flexibility regarding construction and reconfiguration of facilities.

4. Essential Aspects in the Life Cycle of Factory Automation Systems For a comprehensive analysis of a decentralized automation approach, such as the one mentioned above, we need to map it into the context where it is applied – the industrial life cycle. We especially focused our work on the design, realization, installation, and commissioning phases for plants. In the following, the essential aspects of these phases are explained. Factory automation systems – like all other industrial facilities – are complex mechatronic systems according to (VDI 2206), consisting of the synergetic integration of different technical components and partial systems, which together fulfill a specific function. By doing so, the number of identical systems is substantially reduced for larger, more complex solutions; while devices and their components are mostly sold as ready products, factories are generally a one of a kind installation constructed under contract based on specific customer requirements. For the installation of a factory, specialists of many technical disciplines participate, such as mechanical engineering, process engineering, energy and automation engineering, informatics, etc., whose extensive knowledge and activities have to be integrated in the project. Within the context of our work, the term Engineering is understood to represent the entire technical working process within a plant project, starting with the concept, and including Detailed Design, Realization, Installation, and Commissioning up to the transfer of the factory Fig. 4). This process contains, particularly, the selection, design, and integration of the components or partial systems of the subsections to an integrated mechatronic system. The objectives of the Engineering are (1) to secure an error-free interaction of the integrated components relating to the overall function, and (2) the implementation in a predictable and efficient project development process. The factory and solution business encompasses the business and technical cooperation of many participants through an often fragmented value-added chain in connection with a high share of purchased components and services that must all be integrated in the context of a project. Table 2 shows schematically the most important stakeholders in the industrial life cycle, their particular deliverables/assets, and their different business goals. The effects of an innovative automation concept must be considered separately for each player. It is important to notice that decentralized automation does not only affect the technology, but also changes the respective planning processes and models. The value-adding parameters in the engineering phases cannot be found in the technology itself, but in their application in plant design and implementation. The most important challenges in plant engineering are (Löwen & Wagner, 2009): More efficient development and faster time-to-operate by efficient work share, interdisciplinary cooperation, and continuity in the life cycle Reduction of project risk and safeguarding of the project through systematic engineering and continuous validation throughout the project, as well as through cooperation and exchange of information in the supply chain Effect of quantity and increase of quality through repetitive use of modular solutions Consequently, we identified the need to develop appropriate engineering methods and processes for decentralized factory automation systems and to show how they address the challenges listed above. This is the subject of the following chapters. Stake-holder Component Supplier Equipment / M a chine Supplier System Integrator Plant Operator / Owner Desc ription Provides automation technology, devices , & components Builds machines / plant equipment by using comp o nents Builds plants, integrates equipment and components Designs products, defines production require ments & workflows Deliverables / Assets Sensors, drives, PLC, panels, control and MES systems Robots, CNC or assembly machines, conveyor systems Technical plant & automation solution Product model, production process, rough material flow Example Depiction of Deliverables / Assets Business Goals Value added by flexible, integrable components and systems Value added by in tegration of comp o nents to marketable machines Value added by specific integration of systems, equi p ment & components Flexible, optimized production process, availability and capacity utilization Scope Make-to-Stock, large numbers Wide application scope Make-to-Stock / Adapt-to-Order Domain scope Make-to-Order Project-oriented Production scope (ERP to production execution level) Table 2. Stakeholders in the Industrial Life Cycle.

5. Engineering of Decentralized Factory Automation Systems 5.1. Engineering of a Production Line When working on decentralized solutions for automated factory systems, the question was how to plan, design and implement such decentralized automation solutions. For the solution of this problem, an engineering model was developed that describes the possible processes for the engineering of decentralized production automation systems under consideration of mechatronic modules. In order to provide a reference, existing engineering projects were analyzed first and a generalized engineering process for factory automation was documented (Fig. 5) with basic tasks described in Table 3. P hase Basic E ngineering T asks Example Results Process Planning Define manufacturing steps and their physical and logical order Plant Layout & Structure Planning Derive plant layout from the process description Specify machine types by means of required manufacturing capabilities Specify material transport Detailed Design Specify technical details of plant equipment, instrumentation, and automation (parallel proceeding of all involved technical disciplines) Automation engineering: extend layout by control devices, detail production steps, implement control Purchasing & Manufacturing Purchase / manufacture devices, equipment, and machines Construct and implement toward functional units (all involved technical disciplines ) Construction & Commissioning Integrate functional units toward complete plant Verify and optimize machine and process capability MES / ERP Integration MES: specify the interfaces between control system and MES system; configure MES system based on the layout and the manufacturing process ERP: specify the data for exchange; implement the necessary interfaces and communication Table 3. Phases and Tasks of the Basic Process for Manufacturing System Engineering. 5.2. Engineering of a Decentralized Production Line For the case of the development of a facility with decentralized automation, the previously connected automation functionality, in the course of engineering, must be distributed to the individual technical resources (machines, etc.). This corresponds to the principle of vertical (mechatronic) modules as described in Chapter 3.2. For an efficient design of the engineering process, these modules must integrate all system specific parts of a facility resource, as well as must be used consistently. In order to avoid the effort for the specific dissection of the facility into individual mechatronic modules for each individual project, these modules must be specified in advance and provided as comprehensively as possible. The project-specific engineering process based on these principles is presented as an overview in Table 4 and explained thereafter. Plant Operator System Integrator Process Planning Plant Layout and Structure Planning Detailed Design Construction & Commissioning Use of pre-defined generic production activities Define hierarchies and dependencies Use of a pool of predefined mechatronic modules Match available modules with required production activities Control engineering: configure module functionality Program additional control functionality Control integration via Plug-and-Play Virtual commissioning Table 4. Engineering of a Decentralized Production Line – Overview of Phases. Process Planning As previously, the production process for the product to be produced is described by a specification of the production steps by the operator of the production. In addition, the production process has to be structured hierarchically in production steps, and the predecessor-successor relation, as well as parallel processing between production steps, must be described. Likewise, the machine functionalities for the performance of a production step has to be characterized. This concerns both the control functionality and the kinematic behavior of machines. All mentioned additional steps serve for the preparation of the efficient implementation of the subsequent steps. Plant Layout and Structure Planning Based on these informations and the available mechatronic modules, the system integrator derives the facility parts to be installed and their technical interrelationship. Mechatronic modules that offer the desired functionalities are attributed to each production step. For this purpose, the mechatronic modules will be selected from a library that may also contain complete process step realizing production cells. For selection and matching, the predefined production functions of the mechatronic modules are used. If the production process was specified comprehensively as described in Process Planning, the Plant Layout and Structure Planing may be performed in a supported or automated manner. In addition to the pre-specified, mechanical and electronic data, the mechatronic module also contains predefined control applications for the realisation of the production functions. In addition, the specific data of the utilized mechatronic modules for the geometrical positioning in the facility, their kinematic behavior, and their geometries in the 3D factory layout has to be substantiated. Furthermore, the interdependence is considered for the dimensioning of mechanics and electrics, e.g., for the layout of the power of motors. Detailed Design In the next step, the configuration of the predefined control functionalities of the utilized mechatronic modules is done in accordance with the specific process parameters, and, if necessary, the programming of auxiliary functions is performed. In addition, the connections between mechatronic modules and the corresponding parameterizations of these connections have to be specified: Connection of electrical, pneumatic, and hydraulic systems. Connection of the communication devices to communication networks. Connection of material flow relations. The connections are generated automatically or manually, depending on to what extent the connections have been specified in advance. PLC and HMI programs are usually generated automatically from the control applications of mechatronic modules. In this planning phase, the design or the adaptation of the facility mechanics (CAD) and the electrical design (CAE) are also done unless large extends have been already predefined in the mechatronic modules. MES/ERP Integration In this planning phase, initially, the interfaces between the predefined process control and MES functions of the mechatronic modules on the one side and the facility MES level on the other side are designed. Engineering data that have to be considered in the design of the MES modules and the facility MES functions are the production process with its specified production steps, the facility layout, and the technical relations of the mechatronic modules in the facility. Once this information is available in a comprehensive manner, the essential tasks can be partially automated. Additionally, control applications have to be adapted to specific MES functionalities – for instance, the scheduling of production – if support still exists. Once the MES functionalities are designed, the parameterization of the interfaces to the ERP system and the synchronization of relevant data between the MES and the ERP system are performed. Construction & Commissioning As the real used facility resources correspond to pre-integrated mechatronic modules, they can be provided in a manner in which they can be integrated into the automation system via plug and play. After corresponding adaptation, these facility parts can be used immediately. Predevelopment of Mechatronic Modules The essential precondition for the feasibility of the engineering of production facilities according to the described procedure is that, in the run-up, mechatronic modules are prepared in order to be available as a template in a library for the facility planner. This task requires an additional project independent phase and corresponds to a predevelopment (Fig. 6). During the design of these facility and project independent mechatronic modules, the following information must be specified and provided in an integrated manner: Description of the mechanical parts, e.g., in CAD layout. Description of the behaviors of the facility resource, such as kinematic behavior. Description of the machine functionalities that the resource offers for the design of production steps (function oriented view). Description of the automatisation portions: control and communication interfaces, required connections for hydraulics, pneumatics, and electrics, as well as models or implementations of baseline control, HMI, and communication building blocks. Description of combination possibilities or limitations with other resources in order to combine individual functionalities into one overall functionality. Fig. 7 shows the information flow for two of the abovementioned phases, which converges in an orderly fashion using mechatronic modules. 5.3. Engineering of a Material Flow System As for the description of the production line scenario, for the engineering of an intralogistics material flow system a general engineering process is described; see Table 5, before a model is presented that offers a possibility for the engineering of the decentralized material flow system. The phases refer to the partitioning of the processes as presented in Fig. 8. Phase Basic Engineering Tasks Example Results Plant Topology and Rough Layout Deduction of the rough layout based on the required material flow (requirement, particularly in view of transport functionalities, storage, handling, throughput of the factory ), rough simulation for the detection of bottlenecks Detailed Layout and Specifications Refinement and detailed specification of the requirements, establishment of detailed layout, adaptations, optimization of parts lists, concept for electrics, determination of the IT concept, strategies for control algorithms, definition of the interfaces between disciplines, refined simulation based on control algorithms Realization and In-House Test Procurement , partial installation, PLC, and IT side configuration and programming related individual tests/interface tests automation/IT Construction/ Commissioning Installation of the systems, commissioning of control system, test of IT interfaces with other processes Table 5. Phases and Tasks of Basic Process for Engineering of Material Flow System. 5.4. Engineering of a Decentralized Material Flow System As shown in Chapter 3.2, the request for flexible integration and reconfiguration of an intralogistics system could be realized by the creation and continuous use of mechatronic modules. For this purpose, previously centralized automation functionalities are distributed to individual modules, which leads to the decentralization of the intralogistics system. As explained there, this approach has implications on the architecture of the automation system and, therefore, on the handling of the modules. This is reflected by the introduction of an engineering process for decentralized systems that supports the engineering in the design, commissioning, and reconfiguration phases. This will be presented hereafter. Plant Topology and Rough Layout As common, a rough layout is created, based on the customer requirements and the specifications of the factory planners, that describes the general topology of the system and all source/target relations. From this layout, the system integrator identifies the factory parts to be installed and their technical interrelations as depicted in Fig. 9. These factory parts may consist of one or more mechatronic modules. One example for a factory part consisting of several modules is a buffer storage unit for intermediate storage of boxes, consisting of the material handling modules, a rack, and an automated storage and retrieval system (AS/RS). In this phase, not only the factory components but also the mechatronic modules are still generic. For example, it is determined where the buffer storage unit is located in the topology, how many spaces it must have, which throughput it performs, and which functions are generally required. But it is not yet defined which particular conveyor types and which AS/RS will be used. At this time, a rough simulation of the process is performed for the verification of the throughput. Detailed Layout and Specification Now, a successive refinement of the developed requirements and definitions is done in a top-down approach. Initially, the requirements for the mechatronic modules are further detailed. Then, it is determined which mechatronic modules will be used in reality, e.g., the conveyor of Company A, that can move a certain maximum load, and a rack feeder of Company B. At this time, the identification of components to be developed specifically for the project is also made, such as, for example, a special gripping device for the rack feeder for the nonstandard boxes of the customer, including the corresponding automation system. In this phase, the control and process concepts are specified. In opposite to central automation, in which the process logic can be explicitly specified, the procedures may only be defined through the rules of interrelations. As an example, the control of a transport process by driverless transport systems (Automated Guided Vehicles, AGV) can be considered. This control can be implemented by a framework of auctions. A bid for the box transport can be requested by the box while the AGVs will provide it based on availability of the corresponding AGV, its actual location, its transport capacity, and other parameters. The box transport than shall be assigned to the AGV with the most “beneficial” bid. That means that the engineering process is performed at a more abstract level; the possibilities of interactions of the modules must be very familiar to the developer. Then, a refined simulation of the processes is performed. This simulation exploits functionalities of the mechatronic modules used later on in the actual operation in suitable granularity introducing them into the simulation by Plug&Play. This simulation allows the rough testing of the effects of different control concepts (i.e., different system configurations). This also allows identifying components and rules to be developed specifically for the project. The interfaces between the modules are defined using standardized interface descriptions. The interfaces of the mechatronic material flow system to superimposed processes (e.g., ERP system or Warehouse Management System) and neighboring processes (e.g., the production control system) are defined. In addition, the connections of the mechatronic modules to the central infrastructure components are defined, such as, e.g., electrical power supply, compressed air supply, and connection to the IT network. Realization and In-House Test The individual mechatronic modules are configured and parameterized for their particular task in accordance with the requirements of the established specifications. For this purpose, the specialists of the different technical disciplines continue to work on their specific tasks. However, its work is based on consistent mechatronic modules that provide the corresponding views. The necessary project-specific designs are performed. Based on the control concept and the defined possibilities for communication and coordination between the modules, the concrete control mechanisms are configured and project-specifically extended if necessary. The functionality per se is generated at runtime by using defined rules. An in-house test of the system is performed during which a pretest of the facility is done to the possible extent. The vertically modularized structure and the “Plug&Play” functionality support virtual commissioning by subjecting readily configured or installed facility parts to the test and recreate others that are not completed by simulation or emulation. Construction/Commissioning During the commissioning phase, the “Plug&Play” functionality, i.e., the use of pre-integrated modules with the capability to identify each other and coordinate among each other, is applied. It allows a bottom-up installation of the factory according to the factory layout. The physical modules possess mechanisms in order to recognize at which position of the factory topology they are located and perform their configuration and parameterization based on their specifications. They connect themselves with their neighboring modules in terms of automation and communicate with each other as illustrated in Fig. 10. The use of pre-integrated mechatronic modules allows a functionally oriented installation of the factory and, therefore, an early testing of interconnected partial areas and, specifically, an early start of the commissioning of the automation. It is not necessary to integrate completely mechanics and electrics before commissioning the automation, but it is possible to combine and test small functional units such as, for instance, a material handling circuit that is able to move boxes while additional integration still occurs around it. Reconfiguration Even in existing plants, reconfiguration procedures occur. They generally require extensive engineering processes. If, for instance, additional diverts shall be included in the automatic transport system mentioned above in order to be able to move to different locations, an entire engineering process needs to be performed for such a change. Then, the mechanics of the transport system must be separated at the plant locations in the context of the commissioning, the diverts must be mechanically installed, and subsequently, the electrics and the automation system must be installed and newly commissioned. In the case of the decentralized mechatronic system, these activities are supported by the “Plug&Play” functionality of the modules. Modules can be removed from the overall system without causing far-reaching changes to the automation system (dynamic adaptation to changed topology) as shown in Fig. 11. In terms of automation, new modules, to a large extent, are autonomously integrated into an existing plant. The required extent of the engineering depends essentially, in this example, on the requirements for actuality and consistency in the plant documentation, such as, for example, the updating of the plant layout. Predevelopment of Mechatronic Modules In order to keep the project specific effort for the use of these modules as low as possible, they must be defined and specified as far as possible in advance, also for the intralogistics system as described in Chapter 5.2. This means the creation of mechatronic module building blocks that are defined independent of specific projects. These modules provide all involved disciplines with their particular views using a consistent model. The building block approach supports the top down proceeding during the design phase by the provisioning of module descriptions based on which the initially still rough plant layout can be refined successively. Therefore, standardized means of descriptions must be applied. They contain required module information related to the different disciplines or to the proposed (transport) services, for instance. There are functionalities in an intralogistics system that require comprehensive information, such as, the routing of a box to its target destination or the allocation of plant resources to tasks based on the current load of the system (e.g., selection of automated storage/retrieval system, AS/RS). They were previously performed through central systems. Such functionalities have to be replaced for decentralized plants by other mechanisms. This includes concepts for the substitution and distribution of such control logics, capabilities for communication, as well as for coordination of the modules, such as auctions. For instance, the decision finding for allocating a storage order to an AS/RS, is done rule-based in the decentralized case. Formerly, a central system maintained information about the load of the AS/RS and made decisions for a suitable device. Now, whether an AS/RS may offer its services or not has to be determined by rules. In addition, it must be determined according to which rules the devices coordinate among each other about the allocation of an order and, lastly, select one of them for the execution of the storage order.

6. Methodical Evaluation of Benefits and Risks Changes, such as the introduction of mechatronic modules, a mechatronic approach in engineering, distributed control logic, and function-oriented commissioning, are only supportable if their impact, in terms of benefits and risks, on the entire industrial life cycle, has first been worked out in detail (Löwen, et al., 2005). For the planning, realization, and commissioning phases, there is no well known procedure through which the added value of an automation concept can be determined. Regarding the introduction of new concepts, it is of high importance to evaluate benefits and risks before the actual practical deployment. Although an effort-and-cost based evaluation would be desirable, the lack of completed projects and reliable figures prevents the use of such an evaluation. In order to close this gap, an evaluation strategy was developed the PABADIS'PROMISE and “Internet of Things” research projects. The basic idea of the method is the creation of reference models for engineering processes and activities along the life cycle of an automation solution. These models refer to the corresponding automation concepts, for instance, the classically developed system and the decentralized automation system developed mechatronicaly, to compare both. The creation of such a model is done by dissecting the life cycle of the plant in its phases by the dissection of the processes (e.g., layout planning) within the individual phases into individual activities and by the identification of their relation with the automation system. For the creation of a neutral reference basis for the later comparison of different automation concepts, a meta-model was developed; see Fig. 12, which defines all required features of the corresponding reference models for engineering and commissioning in a uniform manner. As an auxiliary tool for building the reference models, corresponding templates were created to record activities/processes. The evaluation is done by a comparative assessment. As one of the basics depicted in Table 6, generally applicable evaluation criteria were defined, derived from central levers in factory engineering, such as modularization, re-use, integration, and seamlessness (Löwen et. al., 2005), as well as under the viewpoint of applicability. They serve as guiding issues for the identification of critical factors in engineering and address specifically the challenges concerning the phases mentioned in Chapter 4. In addition, the standard ISO/IEC 9126, which regards the assurance of software quality, was evaluated, and the quality characteristics included therein were transferred, adapted, and amended to meet the requirements of plant business. The criteria catalogue thusly generated serves as the basis for the evaluation; an excerpt of questions can be found in Table 6. Topic Criteria Question Details Suitabi lity Customer requirements Which customer requirements are relevant for the system integrator in order to design and realize the plant? Typical customer requirements today aims of system Control architecture specific requirements Appropriateness Are the requirements considered in a suitable way? e .g. , highly redundant (and costly) automation system in case of non-time-critical processes is not appropriate Interoperability Content- related dependencies between activities Which dependencies during the engineering process do exist between automation engineering and other disciplines? required information from mechanical engineering, electrical engineering and mechanical plant layout processes to be controlled/monitored, list of process signals sensors /variables to measure the process actuators /variables to influence the process View integration How is cooperation of technical disciplines supported? e .g. , integrated information models such as multi-discipline information objects Table 6. Excerpt of Criteria Catalogue. For the automation concepts to be compared, according to the evaluation proceeding as shown in Fig. 13, a reference model is initially established for the processes and activities along the life cycle. The informations in Chapter 5 serve as a basis for the creation of these models for the presented automation solutions. Subsequently, the different models are analyzed based on the evaluation criteria and compared to each other related to benefits and disadvantages. In the following, the results of the comparison of centralized to decentralized automation systems shall be presented.

7. Implications for the Engineering Processes The detailed gathering and analysis of the individual processes and activities for both decentralized production systems and, also, decentralized material flow systems showed very similar results as compared to previous engineering processes. To begin with, the following findings are related to the activities to be performed and the resulting (expected) efforts. Predevelopment: For the creation of mechatronic blocks, a correspondingly higher effort has to be undertaken for predevelopment. This includes: Adequate definition of standard modules with as few as possible technical and functional dependencies by systematic dissection of a plant Coordination across the involved disciplines for the generation of mechatronic modules Standardized interface descriptions (functional, technical, information technical) Standardized description of process functions or partial processes provided by a module Description of sequences of processes and the invocation of process functions Provision of configuration possibilities and interfaces for project specific adaptations Provision of module-specific automation control functionality and its implementation Provision of application guidelines for modules (e.g., application areas, limitations, dependency on configuration possibilities, and variants) The creation process for mechatronic module building blocks has to be done in cooperation and coordination with all participating stakeholders (system integrator, equipment/machine supplier, and component supplier). Layout, Detailed Design, and Realization: By means of the project-independent creation of mechatronic modules, a shifting of engineering processes to earlier phases results: Control engineering is not an individual task any more, but is derived from models of the production process and of mechatronic modules. Dependent on the reuse concept and the grade of standardization appropriate in this domain, the engineering process is essentially reduced to the selection and adaptation of the utilized modules through configuration. By means of the Plug&Play characteristics (predefined functionalities and coordinated interfaces) and the mechatronic building blocks, simulation or emulation can be used in a more realistic way for the mapping of the plant (use of the same software modules in both the automation system and the simulation). The mechatronic approach supports parallel work and coordination across the involved disciplines for project specific engineering tasks. Installation/Commissioning: Here, mainly the Plug&Play characteristics and the pre-integrated mechatronic modules are used: The effort for installation and commissioning can be reduced since essential functional and technical aspects in the modules have already been pre-integrated. This includes, particularly, the integration of the control system and MES functionalities. The existing mechatronic information and the detailed emulation possibilities facilitate virtual commissioning. Through standardized interface definitions and the use of proven modules, the integration risks can be reduced. By using mechatronic modules, a stronger focusing on rapid availability/completion of functionalities is possible during installation (installation according to functional areas and not according to diciplines). This also allows a faster completion of tests. In summary, regarding the engineering efforts in projects, efforts are shifted from design and commissioning to process planning and plant layout. This is valid for both engineering of production lines and material flow systems. I.e., efforts are moved towards earlier phases in the project; see Fig. 14. Additional efforts (project independent) will be required for the development and maintenance of module libraries. The benefits occur in plant realization, commissioning, and reconfiguration. Standardization and reuse in terms of generic utilizable resources will reduce total costs in the long term.

8. Comparison of the Engineering Approaches and Conclusions The collected information related to the activities along the life cycle of an automation solution serves as basis for the comparative evaluation between a classically developed system and a mechatronicly developed decentralized system. The following results have been worked out with the characteristics from decentralized automation use cases as introduced in Section 3 in combination with the described mechatronic engineering approaches. The general advantages of engineering with mechatronic modules, such as, for instance, cross-discipline- work and the improved reuse or standardization of partial solutions, were already discussed in other papers and shall not be described here any further (Thramboulidis 2008, Löwen & Wagner 2009, VDI 2206). Application Effort and Complexity: The applicability and manageability of a modular, decentralized automation approach – particularly regarding the modularization of automation and control functionalities – must still be ensured. For this purpose, one must differentiate between the creation of the mechatronic modules in a predevelopment project and their application in the particular engineering projects. Overall, it can be expected that the specification and implementation effort to be performed in advance and the complexity for the creation of mechatronic modules with integrated automation and control functions, which are autonomous and can be integrated independently of each other, will increase substantially. For this purpose, bases for modules have to be created that are usable for different projects and configurable for the specific applications. This requires detailed knowledge of the domain, extensive technological expertise, and an understanding of the core functionality of the modules. One example for a starting point for this approach is the INTEGRA standard specifying first consistent mechatronic viewpoints for automotive production lines. These pre-produced modules facilitate the engineering for project-specific applications. The more plug&play modules are available the less effort is required for the engineering. In addition, project risks can be reduced by early validation of fulfillment of customer requirements due to availability of module descriptions and models. This, however, only applies if module adaptations occur which can be done by configuration, selection of variants, or extensions, and in which do not require any changes to the predefined core functionalities of the modules. In that case, there is no knowledge of the inner structure of the modules required, but only an understanding of the configurable functionality, interfaces, and external interdependencies. The modules themselves can be regarded as black boxes. For required project-specific adaptations at the core functionalities of modules, a deep technical understanding is required, for instance, relating to the internal design and structure or the interaction between the modules. For this activity, an increased complexity must be considered in analogy to the creation of the modules. The objective here is to the find the optimum working point by properly cutting and sizing the both plant structure and control tasks. For the operating phase, it is important that the inner complexity of the system is hidden from the user. Previously existing interaction and visualization possibilities must continue to exist, which means that previously centralized information must now be collected in a decentralized manner. For this purpose, suitable mechanisms and utilities must be created. Task Distribution/Automation Pyramid: The hierarchical structure of the automation pyramid has the objective of being able to manage the complexity of the overall system. This is obtained with the described approach by stronger functionally and modularly oriented structuring. Now each module integrates the needed automation functionalities for several automation levels. Decisions by the previous control level are shifting toward the field level, which means that decisions are made closer to the process location of activities. However, there still needs to be a layering within the automation software. This is since the direct control of field devices, for instance, by a decentralized control system based on an agent framework, appears improbable because of insufficient real time characteristics; see Fig. 15. It became obvious that distribution is advantageous particularly in those cases where a plant can be structured in functionally separated areas and where information about the overall status is not frequently required for decisions. In such cases, a very high communication/coordination effort would be required and information would have to be available redundantly. Therefore, in plants, there will exist automation functions that still must be deployed centrally, like the plant visualization and archiving (SCADA system). Suitable methods are required for the easy adaptation of such systems to the application case in order to avoid additional separate engineering. Determinism: Still today and particularly in intralogistics, very complex automation systems cannot be currently designated as strictly deterministic. Within a baggage handling system, for example, the routing is dependent on so many input values that decisions are difficult to predict and to repeat. This development is even amplified by process control through distributed intelligence since the way in which such systems work is not determined by central algorithms but is rather based on more or less generic rules. For the engineering and configuration of the system, the utilized mechanisms and the interaction possibilities of the components among each other must be well known and manageable. This causes the simulation to become substantially more important in order to ensure the behavior pattern of the system. Adaptation/Change Ability, Dynamic Behavior: The flexible, adaptable behavior of distributed intelligence is particularly recognized as an advantage during operation. Rule-based coordination mechanisms allow the reaction to events that are not precisely planned and the flexible adaptation to changed processes. These advantages pay off during the failure or repair of individual components, as well as during different load situations or for changed processes. As above, in this case an increased use of simulation during engineering will be required for the verification of the desired behavior. Additionally, there is a discrepancy between the detailed project-specific requirements related to automation functionality and the necessary generalization, which is required for the provision of project-independent, decentralized components or modules. It is an open question, by which means an optimal flexibility of such modules can be predefined without increasing internal complexity, and how these predefined flexibility can be adapted to particular use cases without causing high complexity in engineering (also regarding the interaction between the modules). Traceability: Precondition for the timing related correct retracing of events in the plant is a corresponding synchronization mechanism that sorts the (partial) events that are stored in the individual decentralized modules by time and that is able to create an overall picture. This capability is mandatory for troubleshooting in the framework of engineering activities, particularly during commissioning and acceptance, and is indispensable for customer acceptance. The corresponding required mechanisms, for instance, tools to support the troubleshooting for decentralized systems, have to be still further developed. Robustness: By eliminating the central control computer and, consequently, a Single Point of Failure, the impact of a failure of decentralized automation components tends to be locally limited. Opposed to this are questions still to be analyzed, such as the consideration of data management and data security. Key words in this connection are: transaction security, data distribution/persistency, redundancies, backup/recovery concepts, etc. Adequate measures must be taken during engineering and lead to a corresponding higher engineering effort, as well as, possibly, to higher cost for more intelligent automation components and additional mechanical redundancies. Formalization, Overlapping Models, and Standards: High project-independent investments are required for the development of modular mechatronic units that are standardized and usable in multiple projects. This modularization is subject to the planning process and needs to incorporate all stakeholders in the manufacturing life cycle. The need to introduce common models, interface and descriptions standards, as well as business-spanning standardized processes, arises. In general, standardization entails a structured, repeatable proceeding that has a positive effect on the quality of the overall system. However, a strong formalization and consistent information model through the engineering phases and automation levels are required for this purpose. Furthermore, new technologies are required for the provision of modular, configurable automation functions. Additionally, it subject to further discussion who will be the driver and responsible for module library development. Machine suppliers and system integrators (as well as plant owners) could be drivers, but in all cases, common standards are required that do not exist today. In addition, know-how protection will become an important topic in this scenario. The creation of extensive module building blocks does not make economic sense in every case. It has to be individually verified which effort is appropriate for the module building blocks and how much effort is to be exerted for each specific project.

9. Migration Concepts The evaluation of the benefits and risks of the decentralized systems has shown that their advantages can be utilized in different phases of the plant life cycle. During layout, detailed design, and realization such systems offer the chance to break up the previous discipline-oriented procedure with a mechatronic approach. A joint mechatronic data model, offers the opportunity to achieve continuity of data and provide the participating disciplines with data tailored to their required view of that data. This reduces the danger of inconsistent data, particularly for later technical changes. The construction and the commissioning of a plant assembled of decentralized components can be supported by a Plug&Play concept that allows the integration of individual components in a more simple manner, as well as a semi-automatic configuration of the modules. The advantages of decentralized automation during operation are generated by a higher flexibility with respect to changes in the workload or of production steps, and with respect to failure, repair or extension of a component. This allows dynamic reaction on unforeseen events. Concerning the actual system architecture, the question arises regarding the Plug&Play concept as to whether it makes technical or economic sense to equip each module with its own control. This becomes even more difficult in functions that have previously been centrally available, for instance, a SCADA or a visualization system. It is not sufficient here to simply distribute these functions logically, as new concepts are required that lead to a principle change in the technical infrastructure of previous automation and control levels. Such decentralized systems, therefore, work at a different abstraction level; instead of concrete functionality, rules for coordination are established that then, for example, are worked off by an agent framework in the form of auctions or other mechanisms. Much further work has to be done before such systems are ready for the market. The actual implementation of agent platforms, for instance, are widely based on developments in the university environment and must be adapted to the industrial application, particularly in the automation environment, or may even need to be newly developed. The domain-specific requirements of the customers are an important aspect of the economic feasibility of decentralized systems. For instance, for production lines as well as for baggage handling systems, customers (automotive manufacturers or airport operators) have extensive, specific and very concrete requirements as to how the automation architecture of such facilities shall be designed. A system without a central control computer with multiple redundancies that would be controlled by a multitude of small, decentralized controllers is currently (still) hardly imaginable, e.g., for large airports. In order to consider these findings and still be able to use the advantages of a decentralized approach, the procedure described hereafter is proposed. A modularly, decentrally designed plant can, by all means, still be realized by a centralized automation system. If continuity of modularity can be ensured from design to realization, this approach offers itself as a practicable compromise. Such a procedure is also supported by (VDI 2206), which describes the development methods for mechatronic systems. It is distinguished between the functional and spatial view of mechatronic modules: “The functional integration of mechanical and electrical/ electronic components takes place by connecting them by means of material, energy and information flows. The components may in this case be spatially separate from one another. In the case of spatial integration, the mechanical and electrical/electronic components form a structural unit in the sense of a common entity.” Even if the focus of this guideline is more oriented toward the construction of mechatronic products, such as a breaking unit, and less toward plant engineering, the findings described in it can be well applied. A very promising approach in this direction consists of, on one hand, performing the engineering mechatronicly, i.e., by using building blocks of independent mechatronic components in a logically decentralized manner, and, on the other hand, designing the plant per se physically/technically in a central manner (e.g., with a centralized control system). By doing so, it is possible to build upon proven automation technologies and, at the same time, use the advantages of mechatronicaly-based engineering. New developed approaches supporting mechatronic based engineering processes can become an essential driver for this migration path (Drath et. al. 2008) On the other hand, a migration concept can be developed resulting in actually decentralized configured plants. For instance, modular control code for an PLC program can be handled as a logically integrated part of the mechatronic component during plant design. In the framework of plant commissioning, one then omits spatial (i.e., completely decentralized as in Fig. 16 upper half) integration, and completes, instead, a mapping to a centralized automation system; see Fig. 16 lower half. The abovementioned control code of a mechatronic component would not run on a decentralized controller that is spatially attached to the mechatronic component, but be attributed, rather, to an PLC on which it runs easily integrated since it is pretested and equipped with the corresponding mechanisms. The term PLC stands here representative for a classic PLC, a soft-PLC, a plug-in module, or other solutions, for instance, on a PC basis. The plant created in this manner has “from the outside,” essentially, the same appearance as the previous centralized plant but came into being in a different manner and is constructed differently on the inside. If desired, further reaching spatial decentralization may be done in subsequent steps.