to new, highly complex systems that increase configuration costs. In particular ... other than industrial automation or applies simple and, for real-life problems, not ...
Using Design Space Exploration to Calculate Deployment Configurations of IEC 61499-based Systems Tarik Terzimehic1 , Sebastian Voss1 and Monika Wenger1 Abstract— Continuous digitalization in the industry leads to new, highly complex systems that increase configuration costs. In particular, software and hardware changes cause major downtime. To dynamically reconfigure control system and avoid downtime, it is necessary to calculate valid or optimal deployment configurations. Previous research applies Design Space Exploration (DSE) techniques embedded into model-based design methodologies to calculate deployment configurations. However, current research either aims domains other than industrial automation or applies simple and, for real-life problems, not applicable constraints and objectives. Thus, the deployment of software components to hardware components is still an exhausting and manual task. In this work, we take first steps towards an automatically optimized deployment of the industrial automation systems. In particular, we propose applying DSE to calculate deployment configurations of IEC 61499-based control applications. In order to reduce the exploration space, we identify domain-specific constraints and objectives. Furthermore, we extend the IEC 61499 System and Application models’ descriptions by proposing relevant hardware and software annotations. We exhibit the applicability of the identified annotations, constraints and objectives on the example of an Industry 4.0 relevant case study.
I. INTRODUCTION Key aspects of the fourth industrial revolution (Industry 4.0) are the flexibilization of production process and the significant reduction of configuration cost [1]. Flexible and reconfigurable manufacturing systems can be converted to accommodate completely new products at very low costs, even if these were not taken into account when planning the system. Additionally, control software must be exchanged dynamically to ensure rapid conversion of the system. One way to achieve this flexibility is to design manufacturing systems that allow dynamic redeployment of the software components (SWCs), i.e. deployable software units, to hardware components (HWCs), e.g. Programmable Logic Controllers (PLCs), further referred to as solely deployment. For that purpose, we need to calculate valid deployment configurations, that is deployments that satisfy certain constraints, such as maximal hardware cost, energy consumption etc. Since Industry 4.0 requires an optimal manufacturing process [1], we may strive to generate a deployment that is optimal with respect to the given objectives (e.g. calculate a deployment configuration that leads to the minimal energy consumption). Due to the increased complexity of current manufacturing systems, i.e. the growing number of SWCs, HWCs and their properties, it is difficult to manually find a valid or an optimal 1 fortiss ickestrae
GmbH, Model-based systems engineering, Guer25, Munich, Germany, {terzimehic, voss,
wenger}@fortiss.org
deployment [2]. Design space exploration (DSE) techniques are applied when manual design decision are difficult due to a large exploration space. DSE defines the process of finding a solution within a constrained solution space [3]. DSE can be used in conjunction with model-based development (MbD). MbD provides a system abstraction with suitable models, with different models describing the system from different perspectives. For example, the logical or software model describes the functionality of the system, whereas the technical or hardware model describes the platform/hardware specific aspects of the system. Thereby the system’s functionality can be developed independently from the hardware specification, which is particularly important for complex systems [4]. Numerous research studies apply DSE techniques embedded into MbD to find appropriate configurations [2], [5], [6], [7], [8]. However, these studies are inapplicable for industrial control software, as they either (1) aim domains other than industrial automation or (2) apply simple and, for real-life problems, not applicable constraints and objectives. Within this work, we take first steps towards an automatically optimized deployment of industrial automation systems. We explore the specifics and needs of the industrial automation domain while focusing on IEC 614991 based systems, as they provide, among others, means for dynamic redeployment. In particular, we propose applying DSE to solve the deployment problems of IEC 61499based control software applications. We identify domainspecific constraints and objectives in order to reduce the exploration space. Furthermore, we propose an extension of the IEC 61499 standard by deployment-relevant hardware and software annotations. The presented concept could be used in conjunction with different optimization and satisfiability solving algorithms, such as Satisfiability Modulo Theories (SMT) or linear programming. Finally, we exhibit the applicability of the identified annotations, constraints and objectives in an Industry 4.0 relevant case study. II. R ELATED W ORK Several research studies address the deployment problem by applying DSE techniques in conjunction with MbD methodologies [2], [5], [6]. The listed works use different optimization and satisfiability solving algorithms, such as SMT solver or linear programming, to explore the design space. However, these works do not fit industrial control software, as (1) they apply automotive-specific constraints, 1 The IEC 61499 is an industrial standard that defines an open architecture for the design of distributed control applications.
objectives and annotations and (2) the software applications are based on semantics that is uncommon in industrial automation domain and therefore probably unfamiliar for process engineers and technicians. The majority of current industrial control software applications are based on the IEC 61131-3 standard for PLCs, which unifies the way of programming PLCs. The IEC 61499 standard represents an extension of the IEC 61131-3 standard. Both standards use a function block (FB) as the main element of function encapsulation. However, the IEC 61499 standard completely forbids the usage of global data. Thus, FBs get decoupled from their environment, greatly increasing the reusability and reconfigurability of IEC 61499-based control applications. Furthermore, the IEC 61499 defines basic reconfiguration services, which provide the possibility to reconfigure the application during runtime [9]. In [7], a SMT solver is applied to generate valid reconfigurations of IEC 61499-based control systems. This work describes control software architectures and high-level requirements with logical formulae, which are used as input for the SMT solver. The SMT solver calculates deployment configuration that satisfies the high-level requirement for a multiple deployment of FBs. Nevertheless, the definition of complex deployment problems would require applying several constraints and also objectives to optimize a limited set of solutions. Additionally, the specifics of IEC 61499based systems should be considered more thoroughly, such as relations between devices and resources, inter-device communication and configurations overheads etc. Similarly, [8] used linear programming algorithm to calculate valid and optimal deployment configurations of IEC 61499-based control systems. The authors identified several constraints, objectives and annotations as an extension of the IEC 61499 standard. Although we recognise some of those annotations as relevant for the definition of deployment problem, the relation and applicability of others are vague. For example, it is unclear how the hardware annotation “processing power” relates to the software annotation “worst case execution time (WCET) of the FBs”. In this paper, we identify and formalize software and hardware annotations, as well as constraints and objectives to specify desired deployment configuration of IEC 61499based sytems. We provide a domain-specific case study, which exhibits the applicability of the identified annotations, constraints and objectives. III. M ODEL - BASED D EVELOPMENT WITH IEC 61499 MbD approaches have also been applied in the industrial automation domain to handle the rising software’s complexity. The IEC 61499 standard for distributed industrial control systems proposes the usage of different models to achieve software and hardware abstractions. IEC 61499 applies an application centric design, where the functionality of the whole system is defined within a platform-independent Application model. The Application model is created by FBs, which represent SWCs that encapsulate functionality and interact with the other components
via data and event interfaces [10]. The IEC 61499 FBs are event driven, which is one of the major differences to other languages in the domain of industrial automation. Thus, FBs require input events to process input data [11]. The System model specifies the hardware configuration, like control devices and communication systems. A device (e.g. a PLC) can contain several resources that represent an independent execution environment for function block networks (FBNs). They may be used for the logical separation of the device onto smaller independent entities [10]. The functionality from the Application model is mapped to the System model, resulting in the Distribution model. The Distribution model maps the applications FBs to the resources of the control devices, where they get executed. The standard defines management commands to configure IEC 61499 compliant devices. These commands support creating, deleting, starting or stopping IEC 61499 elements, as well as querying information form IEC 61499 compliant runtime environments (RTEs) [12]. In this way the IEC 61499 facilitates the mechanism for deployment and dynamic redeployment of control software applications. IV. D EFINING THE D EPLOYMENT P ROBLEM FOR IEC 61499 - BASED S YSTEMS To dynamically reconfigure control system and avoid downtimes, we have to calculate valid or optimal deployment configurations. Thus, an automation engineer should be able to specify the deployment problem, i.e. to define constraints, objectives and different hardware and software annotations. In this section we identify the relevant hardware and software annotations within IEC 61499 System and Application models’ descriptions, and the domain specific constraints and objectives (see Table I). We formalize some constraints and objectives to demonstrate their applicability in defining the deployment problem. Finite sets Application and System represent the software and hardware architectures, i.e. sets of all available SWCs (i.e. FBNs in IEC 61499-based systems, denoted as fbn) and HWCs (i.e. IEC 61499 devices, denoted as device), respectively. We define the function used(device) that returns value true if the device contains at least one fbn. Similarly, the function deploy(fbn, device) returns value true if the fbn is deployed onto the device. The components fbn and device are used as data structures. We access different hardware and software annotations by using member access operator (.), e.g. device.cost to access annotation cost of the device. Cost constraint and objective: While modeling software and hardware architectures, we can strive to limit or even minimize hardware costs, which is also often applied in the automotive domain [5]. For example, an automation engineer can specify the cost of PLCs (device.cost in Equations 1 and 2) while modeling the hardware architecture (System in Equations 1 and 2) within the System model of IEC 61499 Architecture. Subsequently an engineer could specify the constraint, so that the total cost of the applied hardware infrastructure does not exceed a certain maximal value (max cost in Equation 1). We can also strive to minimize
TABLE I: Constraints, objectives and annotations for IEC 61499-based systems Constraint
Objective
SW Annotation
HW Annotation
Cost: limit costs of devices
Minimize costs
-
Device’s cost
Energy: limit energy consumption
Minimize energy consumption
-
Energy consumption
Number of devices: limit number of used devices
Minimize number of used devices
-
-
HW skills: allocate FBNs to the required devices
-
Required HW skills
Available HW skills
RTE skills: allocate FBNs to the compatible RTE
-
Required FB types
Available FB library
Parallel execution: execute FBNs parallel
-
Parallel FBNs
Max. number of resources
Functional coupling: group coupled FBNs
Max. cohesion / min. coupling
Coupled FBNs
-
E2E deadline: guarantee specified latency
Minimize E2E latency
WCET
Communication overhead
Memory: prevent memory exceeding
Minimize memory usage per device
FBN’s memory size
Device’s memory
SIL: allocate FBNs to reliable devices
Minimize total SIL
FBN’s safety level
Device’s safety level
Redundancy: allocate FBNs to several devices
-
Number of FBN’s copies
-
Security: forbid access from outside
-
Security-critical FBN
Accessible device
HW stress: limit device’s load
Minimize device’s stress / load
-
Max. stress / load value
the whole cost, in which case we define an optimization objective (Equation 2). device.cost ∗ used(device) < max cost
∑
(1)
device∈System
min
By applying the constraint formalized with Equation 3, we can ensure deployment of the FBNs to the devices with required hardware skills. ∀ f bn ∈ Application, ∀device ∈ System : deploy( f bn, device) ⇒ f bn.rq hw ⊆ device.skills
∑
device.cost ∗ used(device)
(2)
device∈System
Energy constraint and objective: We can apply an energy constraint and objective to limit or minimize energy consumption of the used hardware infrastructure, respectively. In the simplest case, we could specify the approximate energy consumption of the available hardware infrastructure and launch energy constraint and/or objective. If we strive for more precise results, we have to relate the energy consumption to other factors, such as CPU load. Energy constraint and objective are applicable both in automotive [2] and industrial automation domains. Number of devices constraint and objective: To reduce the complexity of the hardware architecture and achieve an easier hardware maintenance, we can limit or minimize the number of used devices, while calculating valid or optimal deployment configurations, respectively. HW skills constraint: Some FBNs or applications require certain hardware skills, such as special computation hardware, access to sensors and actuators, communication interfaces etc. Thus, an engineer should be able to either (1) manually allocate particular FBNs to particular devices and calculate the deployment configurations of remaining components according to other specified constraints and/or objectives (as it is done in [2]), or (2) specify the required (fbn.rq hw in Equation 3) and available skills (device.skills in Equation 3) within the Application and System model, respectively. For example, a FBN requires and device provides access to the light barrier sensor within conveyor PE005: • fbn.req hw = {PE005.light barrier} • device.skills = {PE005.light barrier, PE005.motor etc.}
(3)
RTE skills constraint: To dynamically (re)deploy FBNs, we need to consider the capabilities of the RTE running on the device, as a special form of HW skill. We have to consider which FB types are supported by the RTE, since only available FB types can be instantiated. Thus, we have to describe the skills of the RTE, like the supported FB type library. The required FB types are already specified within the Application model. To dynamically redeploy FBNs to another device, a constraint formalized by Equation 4 could be applied. Hence, only device candidates whose RTEs contain all necessary FB types (e.g. fbn.fbtypes = {F ADD, E SR, etc.}) can be considered. ∀ f bn ∈ Application, ∀device ∈ System : deploy( f bn, device) ⇒ f bn. f btypes ⊆ device.rte lib
(4)
Parallel execution constraint: A device in a System model can contain resources, which can be regarded as independent execution containers for FBNs. Resources provide a logical separation of the device onto smaller independent entities. By deploying applications onto multiple resources, we can achieve a quasi parallel execution2 . However, a device cannot contain an arbitrary number of resources without jeopardizing its computational and memory performances. Thus, the annotation of the maximal number of resources within one device should be possible. On the other hand, the Application model should provide mechanisms to denote parallel FB networks, i.e. the parts of the applications that are supposed to run concurrently. In this way, we satisfy timing 2 quasi parallel since resources can only be processed in parallel if they run on different cores of the central processing unit (CPU)
performance demands by executing FBNs across several resources and/or devices in parallel. Functional coupling constraint and objective: Similarly, we may want to couple some FBNs, so that they are executing within the same device, or within the same resource. This way, we might achieve lower latency between FBNs, i.e. an increase of the intra-device and a decrease of the interdevice communication. The communication between devices is realized through manually configured service interface FBs. Thus, we can define the functional coupling constraint by selecting the FBNs that are supposed to be executed within the same device and thereby avoid communication and configuration overheads of inter-device communications. Additionally, we can specify the objective to maximize cohesion (i.e. intra-device communications) and minimize coupling (i.e. inter-device communications). E2E deadline constraint and objective: Moreover, to guarantee latency of the time-critical FBNs, we specify the end-to-end (E2E) deadline, as proposed in [8]. For that purpose, we need to specify WCETs of the FBs within time-critical FBNs while modeling the software architecture. Required hardware annotations are the maximal number of resources per device and inter-resource and inter-device communication overheads. A solver could then “decide” if the time-critical FBN has to be split and executed across several resources or devices, respecting the FBs’ WCETs and communication overheads. Memory constraint and objective: The automotive domain is aware of the annotation of hardware’s memory capacity, software’s memory size and the constraint that prohibits exceeding the hardware memory limits [5]. Such memory constraint could be useful in IEC 61499 systems (Equation 5). The FBN’s size (fbn.size in Equation 5) could be calculated automatically, according to the used FB instances. Moreover, we can optimize memory usage by applying the memory objective (Equation 6). Here we want to balance the memory usage across devices. Thus, we minimize the variance of the normalized memory usage across all devices (Equation 6). ∀ f bn ∈ Application, ∀device ∈ System :
∑
f bn.size < device.max memory
(5)
f bn7→device
min
Var device∈System
device.used memory device.max memory
the redundancy constraint to deploy particular FBNs to the several devices. Security constraint: Since the appearance of Stuxnet malware3 , the security aspect within industrial automation domain gained increased interests [16]. In order to avoid outside attacks or undesired access to critical data, different hardware and software security solutions are integrated into PLCs. Further actions can be taken while generating deployment configurations. We can specify the FBNs that should not be accessible from outside. The security constraint forbids the deployment of those FBNs to externally accessible devices (e.g. PLCs connected to the Ethernet). Likewise, we could use the hardware skill constraint and request certain security measures, such as hardware authentications or encryption, as requested hardware skill. Thus, the security-vulnerable FBNs would be deployed only onto devices that provide the requested skills. HW stress constraint and objective: Deployment can also play a role in extending the lifetime of the hardware. Depending of the underlying hardware, stress factors should be identified and considered while calculating deployment configurations. For example, the temperature of a device, i.e. overheating, can significantly shorten the lifetime of device [17]. Thus, we estimate the possible overheating of the device while executing certain FBNs. Vogel-Heuser et al. [17] propose simulation-based evaluation for the estimation of temperature. Alternatively, the CPU load, which can be roughly estimated by the number of running resources, can be used as a stress factor. Hence, the maximal value of the stress factor (e.g. temperature or CPU load) can be specified within the hardware architecture and then, by applying a constraint or an objective, we can limit or minimize hardware stress, respectively. Summary: The identified constraints, objectives and annotations can define complex deployment problem. In some cases, we can achieve similar or same goals by applying different annotations, constraints and objectives. For example, functional coupling and E2E deadline constraints could both lead to better timing performance of the systems. However, sometimes we may lack some necessary information to apply certain constraint, such as WCET values for E2E deadline constraint. If certain FBNs are interacting intensively, we can couple those FBNs by applying functional coupling constraint. Thus, we achieve better system’s performance.
(6)
SIL constraint and objective: Safety is the most important process plant characteristic [13]. One way to increase the safety is to deploy FBNs annotated with certain Safety Integrity Level (SIL) only to devices of the same or higher SIL [14], i.e. to devices that are reliable enough. Thereby, the safety-critical components are equipped with reliable software and hardware. Redundancy constraint: In order to improve the reliability, particular SWCs sometimes have to be deployed multiple times across devices [7]. Therefore, we introduce the redundancy annotation for IEC 61499 FBNs and define
V. E VALUATION This section provides a domain-specific case study to illustrate the applicability of identified constraints, objectives and annotations for the deployment problem definition. A. Cold Rolling Mill Demonstrator With the aim to demonstrate the DSE application for calculation of deployment configurations, we consider the aluminum cold rolling mill demonstrator from the SMS group GmbH as an example. The aluminium cold rolling 3a
malicious computer worm that attacks PLCs [15]
Fig. 1: 3D structure of the aluminium rolling mill from SMS group, with transportation system (1), pallet and coil (2), roller conveyor (3), turn table (4), slider conveyor (5) and rolling process area (6) [18].
mill (Figure 1) consists of two main parts, the rolling process and the pallet transportation system (PTS). For the sake of simplicity, this case study focuses solely on the PTS. The PTS transports pallets with coils to different working steps of the plant. The PTS is composed of several roller conveyors, slider conveyors and turn tables. The roller conveyors perform the transportation task. Each roller conveyor has four light barriers to detect the pallet position. The pallet position is used to adapt the transportation speed and detect the movement direction. The slider conveyors move pallets between different rows of roller conveyors. The turn tables rotate the coil to change the winding orientation of the aluminium band on the coil [18]. B. Case Study: Failure Recovery Without Downtimes Wagner et al. [13] named availability, i.e. the continuous operation of the plant without downtime, as one of the most important aspects of rolling mills. Hence, we examined the applicability of the identified constraints, objectives and annotations while striving for high availability of such plants. First, we model the logical architecture (i.e. Application model), depicted in the upper part of Figure 2. The Application model consists solely of conveyor FBNs (i.e. SWCs, represented as blue blocks in Figure 2) that are interconnected according to the layout. Moreover, we specify software annotations for each FBN, such as required hardware skills (e.g. access to PE005 conveyor’s IOs) and safety levels to require a higher safety measures for the safetycritical components. Second, we model the hardware architecture, i.e. System model, presented in middle part of Figure 2. To save costs, we use one device (i.e. PLC, represented as grey block in Figure 2) to control several PTS’s components, as the components require less then ten IOs. One device can have several resources to independently run several FBNs. However, we annotate the maximal number of resources within a device to avoid jeopardizing its computational and
Fig. 2: Concept for IEC 61499 Distribution model generation and redeployment
Fig. 3: Configuration selection for redeployment of FBNs
memory performances. Moreover, we consider redundancy in case one of the devices loses its functionality. Thus, every device will have access to several PTS’s components, which are annotated as available hardware skills. In the example from Figure 2, each device can have up to four resources running. Two are used to independently control two different components (depicted with red and blue solid lines in Figure 2). For redundancy reasons, each device has access to four other components (depicted with red and blue dashed lines in Figure 2), controlled by another devices. Thus, we redeploy FBNs without changing the connections between HWCs. Next, we define the constraints for calculating valid deployment configurations. We apply: • • •
safety constraint to deploy safety-critical FBNs to the reliable devices. hardware skills constraint to deploy FBNs to the devices with the required IOs access. RTE skills constraint to deploy FBNs to the devices with compatible RTE.
When the desired constraints are specified, a solver (e.g. SMT solver) is launched to generate a set of valid deployment configurations. To increase the quality of the solution,
we define a quality attribute such as CPU load (i.e. number of running resources within a device). Thus, we select a valid configuration for which devices are least stressed and then perform deployment according to the selected configuration. The calculated set of valid deployment configurations can be saved in PTS’ Asset Administration Shell (AAS), which is a virtual representation of a real component [19]. The device’s AAS contains different information about the device (e.g. specified annotations, deployed source code, status variables etc.). During runtime we monitor the state of the components. In case a certain device loses its functionality or becomes overloaded (e.g. PLC2), we select another valid configuration from the set of the calculated configurations (available within PTS’ AAS). Here we apply the second best configuration according to the quality attribute (i.e. CPU load), as the first one is invalidated due to the PLC2 failure. The second best configuration would be the configuration C3 from Figure 3, as devices PLC1 and PLC3 will be less loaded, in contrast to configuration C2. Alternatively, we can strive for a configuration that leads to less device changes (denoted as weights in Figure 3). For example, if we apply the configuration C2 from Figure 3, we solely need to redeploy FBNs to one device, namely PLC1. After selecting the configuration, we redeploy necessary FBNs using IEC 61499 reconfiguration services. For that purpose, we obtain the source code from the AAS of defective PLC2 and deploy it to the other device. The redeployed FBNs are synchronised by reading the status variables from the AAS of defective PLC2. This way, we achieve a failure recovery without downtimes, as we apply another valid configuration without a time exhaustive recalculation. Recalculating configurations that consider actual system status can be performed afterwards, during the system runtime. The SMT-based approaches usually require exponential runtime to find a solution. If we strive to calculate an optimal deployment during runtime, approximate algorithms (e.g. metaheuristics) can be applied. For example, evolutionary algorithms are often used in architecture optimization [20]. VI. C ONCLUSION & F UTURE W ORK In this work, we analyzed the specifics and needs of the industrial automation domain, more precisely IEC 61499based systems, and identified constraints, objectives and annotations applicable for the deployment problem definition. Thereby, we took first steps towards an automatically optimized deployment of industrial automation systems. The domain-specific case study exhibits the applicability of the DSE approach in conjunction with IEC 61499 models in an Industry 4.0 relevant scenario, namely failure recovery without downtimes. We intend to implement and validate the proposed concept for future work. We plan to use Eclipse 4diac, an open source, IEC 61499 compliant, engineering framework [21] and extend it by the identified annotations, constraints and objectives, as well as the deployment synthesis model. Moreover, we will continue to identify the relevant constraints,
objectives and annotations. ACKNOWLEDGMENT This work is partially funded by the German Federal Ministry of Education and Research (BMBF) under grant no. 01IS16022N through the project BaSys 4.0 (Basic System Industry 4.0) (http://www.basys40.de/). R EFERENCES [1] Bundesministerium f¨ur Wirtschaft und Energie (BMWi), “Beziehungen zwischen I4.0-Komponenten Verbundkomponenten und intelligente Produktion,” Tech. Rep., 2017. [2] J. Eder, S. Zverlov, S. Voss, M. Khalil, and A. Ipatiov, “Bringing DSE to life: exploring the design space of an industrial automotive use case,” in 20th Int. Conf. on MdE Lang. and Syst., 2017. [3] B. Sch¨atz, B. Sch¨atz, F. H¨olzl, and T. Lundkvist, “Design-Space Exploration through Constraint-Based Model-Transformation,” in 17th IEEE Int. Conf. and Workshops on Eng. of Comp. Based Syst., 2010. [4] V. Aravantinos, S. Voss, S. Teufl, F. H¨olzl, and B. Sch¨atz, “AutoFOCUS 3: Tooling concepts for seamless, model-based development of embedded systems,” in CEUR Workshop Proceedings, 2015. [5] S. Zverlov, M. Khalil, and M. Chaudhary, “Pareto-efficient deployment synthesis for safety-critical applications in seamless modelbased development,” in Proceedings of the 8th European Congress on Embedded Real Time Software and Systems (ERTS 2016), 2016. [6] Alexander Diewald, Sebastian Voss and S. Barner, “A Lightweight Design Space Exploration And Optimization Language,” in CEUR Workshop Proceedings, 2017. [7] R. Sinha, K. Johnson, and R. Calinescu, “A scalable approach for re-configuring evolving industrial control systems,” in 19th IEEE Int. Conf. on Emerging Technologies and Factory Automation, 2014. [8] J. Frieben and M. Tichy, “Automatic deployment of IEC 61499 function blocks,” CAN newsletter, 2012. [9] W. Lepuschitz, A. Zoitl, M. Vall´ee, and M. Merdan, “Toward selfreconfiguration of manufacturing systems using automation agents,” IEEE Trans. on Sys., Man and Cybernetics, 2011. [10] A. Zoitl and V. Vyatkin, “IEC 61499 architecture for distributed automation: The ”glass half full” view,” IEEE Ind. Electr. Mag., 2009. [11] M. Wenger, A. Zoitl, J. O. Blech, I. Peake, and L. Fernando, “Cloud based monitoring of timed events for industrial automation,” in Proceedings of the Int. Conf. on Parallel and Distributed Systems, 2016. [12] I. SC65B, “IEC 61499-1 Function Blocks for Industrial Process Measurement and Control Systems. Part 4,” 2005. [13] C. Wagner, U. Epple, A. Metzul, K. Debus, V. Treivous, M. Tarnow, and C. Helle, “Requirements for the Next Generation Automation Solution of Rolling Mills,” in 43rd Annual Conf. of the IEEE Ind. Elec. Society, 2017. [14] S. Voss and B. Schatz, “Deployment and scheduling synthesis for mixed-critical shared-memory applications,” in Proc. of the Int. Symp. and Workshop on Eng. of Comp. Based Syst., 2013. [15] A. Nourian and S. Madnick, “A Systems Theoretic Approach to the Security Threats in Cyber Physical Systems Applied to Stuxnet,” IEEE Transactions on Dependable and Secure Computing, 2018. [16] T. Cruz, J. Barrigas, J. Proenca, A. Graziano, S. Panzieri, L. Lev, and P. Simoes, “Improving network security monitoring for industrial control systems,” in IEEE International Symposium on Integrated Network Management, 2015. [17] B. Vogel-Heuser, S. Wildermann, and J. Teich, “Towards the coevolution of industrial products and its production systems by combining models from development and hardware/software deployment in cyber-physical systems,” Production Engineering, 2017. [18] T. Terzimehic, M. Wenger, A. Zoitl, A. Bayha, K. Becker, and M. Thorsten, “Towards an Industry 4 . 0 Compliant Control Software Architecture Using IEC 61499 & OPC UA,” in 22nd IEEE Int. Conf. on Emerging Technologies and Factory Automation (ETFA), 2017. [19] “Structure of the Administration Shell.” Federal Ministry for Economic Affairs and Energy (BMWi), 2016. [20] A. Aleti, B. Buhnova, L. Grunske, A. Koziolek, and I. Meedeniya, “Software architecture optimization methods: A systematic literature review,” IEEE Transactions on Software Engineering, 2013. [21] T. Strasser, A. Zoitl, and A. Valentini, “Framework for Distributed Industrial Automation and Control (4DIAC),” in 6th IEEE Int. Conf. on Industrial Informatics, 2008.
