Engineering of IoT Automation Systems

Full text

(1)DOC TOR A L T H E S I S. Department of Computer Science, Electrical and Space Engineering EISLAB. Luleå University of Technology 2017. Oscar Carlsson Engineering of IoT Automation Systems. ISSN 1402-1544 ISBN 978-91-7583-791-8(print) ISBN 978-91-7583-792-5 (pdf). Engineering of IoT Automation Systems. Oscar Carlsson. Industrial Electronics.

(2)

(3) Engineering of IoT Automation Systems. Oscar Carlsson. EISLAB Lule˚ a University of Technology Lule˚ a, Sweden. Supervisors: Jerker Delsing and Jens Eliasson.

(4) Printed by Luleå University of Technology, Graphic Production 2017 ISSN 1402-1544 ISBN 978-91-7583-791-8 (print) ISBN 978-91-7583-792-5 (pdf) Luleå 2017 www.ltu.se.

(5) To my family, who have always supported and inspired me.... iii.

(6) iv.

(7) Abstract Major societal challenges such as environmental sustainability, availability of energy and raw materials, and globalisation are creating new requirements for many actors in society. These new requirements relate to efficiency, flexibility, sustainability, and competitiveness. While these aspects have all been around for some time, and many systems have been locally optimised with regards to one or a few of these requirements, recent advances in communication and processing capabilities promise increased possibilities for connecting different parts of society, allowing optimal operation on a much larger scale. While industrial production systems have been controlled electronically for decades, the digitisation of market channels and consumer systems, together with the possibility to interconnect different production facilities, now allow for automated interaction along the whole supply chain from raw materials to end users. Simultaneously, increased demand for efficiency forces increased specialisation among actors, which with increased possibilities of interconnectivity, creates large enterprises of cooperating, specialised stakeholders. One of the major remaining obstacles for a widespread adaptation of more intelligent, more connected systems, able to deliver these envisioned results, is a coherent approach to the engineering and management of Systems-of-Systems involving very large numbers of devices and operating across several automation domains. For traditional automation systems there are established engineering procedures and numerous standards for engineering data, although most are focused on the static processes that have traditionally been the norm. For full integration with a digital society many of the existing automation systems will need significant modifications and as many automation systems are ageing and in need of replacement, a suitable solution to this may be a large scale migration to new automation solutions. The work presented in this thesis includes some new approaches and methodologies to utilise the existing engineering procedures and standards, while introducing some of the flexibility proposed by the emerging technologies. The major technical solutions presented consist of a structure way to organise connected systems and how they are related, regardless of engineering standards used to design their interactions, and an approach to allow configuration of heterogeneous systems through service interactions. Further contributions include an approach for migrating certain categories of existing industrial control systems to a service oriented architecture, as a basic outline for adaption of the next generation of automation systems in industry. Certain remaining challenges have been identified, which have to be addressed for a successful launch of widespread interconnected automation systems based on Internet of Things and associated technologies.. v.

(8) vi.

(9) Contents Part I. 1. Chapter 1 – Introduction 1.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3 5 5. Chapter 2 – Digitisation of Society 2.1 Systems-of-Systems . . . . . . . . 2.2 Automation and clouds . . . . . . 2.3 Internet of Things . . . . . . . . . 2.4 The Arrowhead project . . . . . .. . . . .. 7 7 8 10 11. Chapter 3 – Industrial Automation Systems 3.1 Automation systems by industrial sector . . . . . . . . . . . . . . . . . . 3.2 Industrial automation engineering . . . . . . . . . . . . . . . . . . . . . . 3.3 Standards for engineering data . . . . . . . . . . . . . . . . . . . . . . . .. 15 15 18 21. Chapter 4 – Engineering of IoT Systems-of-Systems 4.1 Engineering in the Arrowhead framework . . . . . . . . . . . . . . . . . . 4.2 Automation system engineering work-flow . . . . . . . . . . . . . . . . .. 23 24 26. Chapter 5 – Migration of Industrial Automation 5.1 Migration of industrial automation systems . . . . 5.2 Key differences between SCADA and DCS . . . . 5.3 Migrating SCADA to SOA . . . . . . . . . . . . . 5.4 Migrating DCS to SOA . . . . . . . . . . . . . . .. . . . .. 29 29 32 33 33. Chapter 6 – Contributions to appended papers 6.1 Additional publications . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35 39. Chapter 7 – Conclusions and Future Work 7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41 41 43. References. 45. and Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. vii. Opportunities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Systems . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . ..

(10) Part II Paper 1 2 3 4. 51. A Introduction . . . . . . . . . . . . Challenges in migrating industrial Migration procedure . . . . . . . Conclusion . . . . . . . . . . . . .. . . . . . . . . . . . . . . process control systems . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Paper B. 53 55 57 60 65 69. Paper 1 2 3 4 5 6 7. C Introduction . . . . . . . . . . . . . . . Migration . . . . . . . . . . . . . . . . Functional aspects . . . . . . . . . . . Migration procedure . . . . . . . . . . Migration of functionality . . . . . . . A first step - Migration of a lubrication Conclusion . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . system . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 77 . 79 . 81 . 85 . 88 . 95 . 106 . 118. Paper 1 2 3 4 5. D Introduction . . . . . . . . . . . . . . Existing standards and related work . Engineering tool interoperability . . . Plant description use cases . . . . . . Conclusion . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 125 127 129 131 134 137. Paper 1 2 3 4 5. E Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use case: Orchestration from Process & Instrumentation Diagram Conclusions and Future work . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 141 143 145 147 151 153. Paper 1 2 3 4 5 6 7. F Introduction . . . . . . . Related work . . . . . . Proposed Approach . . . Use cases and Evaluation Discussion . . . . . . . . Conclusion . . . . . . . . Future work . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 157 159 162 163 168 172 173 173. Paper 1 2 3. G 177 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 IoT automation architecture . . . . . . . . . . . . . . . . . . . . . . . . . 182. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. viii. . . . . . . .. . . . . .. . . . . . . .. . . . . . . .. . . . . .. . . . . . . .. . . . . .. . . . . . . .. . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . ..

(11) 4 5 6 7 8. IoT automation engineering . . . . . . . . . . . . . . . . Automation engineering: A process automation scenario Application of IoT Automation Engineering . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . Future work . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 184 188 191 197 197. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 201 203 204 211 213. Paper 1 2 3 4. H Architecture fundamentals . . . . . Important definitions . . . . . . . . Documentation structure . . . . . . Arrowhead Framework architecture. Paper 1 2 3. I. Paper 1 2 3 4 5. J Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . Engineering of an Arrowhead compatible multi-domain facility Component-based engineering methodology . . . . . . . . . . . Safety and security engineering of IoT automation systems . . Engineering scenarios . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 245 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Mandatory core systems and services . . . . . . . . . . . . . . . . . . . . 247 Automation support core systems . . . . . . . . . . . . . . . . . . . . . . 266. ix. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 295 297 297 299 304 321.

(12) x.

(13) Acknowledgments First and foremost I would like to thank my supervisors Professor Jerker Delsing and Associate Professor Jens Eliasson for the support, good advice and the unwavering confidence they have shown me, even though our offices are separated by more than seven hundred kilometers. My colleagues at the Stockholm office of Midroc Automation, both past and present, deserve my most heartfelt appreciation for their support, their practical and technical insights and, not least, keeping it fun to go to the office. To all of Midroc, at all locations and working positions, I would like to extend my gratitude for all the inspiration, discussions and support I have received, even though I may not always have been able to explain what I am trying to achieve with this work. Also, a special mention must be made of my mentor, Doctor Fredrik Arrigucci, who is always so full of new ideas and was the one to give me the opportunity to pursue a PhD while still employed at Midroc Automation. I would also like to extend my gratitude to my other colleagues, working at companies, research institutes and universities all around Europe, that I have had the good fortune to work with through the research projects IMC-AESOP and Arrowhead. In addition I would like to thank the European Commission, Artemis-JU, ECSEL-JU and Vinnova who have funded much of my work through the Arrowhead and IMC-AESOP projects, thereby making my PhD studies possible. Last but not least I would like to thank my parents, my sister, and the rest of my family and friends for support, relief and the help to occasionally take my mind off my research.. Stockholm, January 2017 Oscar Carlsson. xi.

(14) xii.

(15) Part I. 1.

(16) 2.

(17) Chapter 1 Introduction “Why bother with a cunning plan when a simple one will do?” Terry Pratchett, Thud!, 2005 The whole world is developing ever more quickly and societies all around the globe are facing challenges of sustainability, efficiency, competitiveness, and flexibility. At a more concrete level, this takes the form of a need to develop environmentally, economically and socially sustainable societies and businesses. Competitiveness requires all producers to ensure the availability of energy and raw materials, and to use them efficiently. Additionally, global competition and communication is driving rapidly changing market trends, putting pressure on producers to adapt and giving benefits to consumers that are quick to seize new opportunities. A most promising component in adapting to these changes is the digitisation of production, products and society a a whole. A successful large scale digitisation can enable dynamic information exchange between all actors involved. Thus allowing planning and forecasting, optimisation and adaptation on a larger scale, applicable to all parts of society, thereby building a better world for all. One branch of utilising the benefits of digitisation is the automation of new processes and improvements to already automated operations. For Europe and more specifically for the European productive industries, further detailing of these challenges have been performed in different road maps and initiatives, such as Industry 4.0 [1], the Factory of the Future road map [2] and the ProcessIT.EU road map on process automation [3]. Three emerging trends in production industry that address these topics are: 1) Multi-stakeholder corporations, replacing large monolithic organisations 2) Learning from previous products and other parts of the value chains 3) Integrating information from the whole product and production process life-cycles In particular, the Factory of the Future road map [2] and the ProcessIT.EU road map on process automation [3] both identify the need for a more integrated product and 3.

(18) 4. Introduction. process engineering, in addition to the already mentioned integration of the products and processes themselves. The challenge of the automation engineering process and its associated tools can be seen as to capture a desired function, and turn it into a physical system that can be built to fulfill the intention of the designer. This is a complex task with many aspects and the most suitable engineering tools and methodology depend a lot on which part of task is perceived as the most challenging. Most engineering disciplines and most application domains have established structured and standardised engineering tools and methods. However, because the interaction between different disciplines and domains have historically been limited and not a critical factor, the standards vary greatly and only more recently have there been major incentives in harmonising the different standards. With the proposal of various approaches to promote integrability between automation systems from different application domains, as well as the incentives to maintain engineering data and system information along the whole life-cycle of a production process, this situation gave rise to the first two research questions. Q1 How can run-time and design-time knowledge efficiently be integrated to manage an automation system of systems? Q2 How can standardised engineering methodologies for capturing process and technical knowledge be utilised to manage a cross-domain IoT automation system of systems? Furthermore, for the establishment of new technology in the European production industry, Pereira et al. highlight in their study of the European Monitoring and Control market from 2007 [4], that the three main market barriers for Monitoring and Control in the process industry are: • Complexity of systems • High installation costs • Many old installations with legacy equipment The two first observations are likely to become even more valid when the emerging trends in production and the intention to make systems from different application domains interoperable, are considered. Thus, production automation engineering and installation simplicity and efficiency becomes very important. The last market barrier listed hints at a suitable entry point to overcome these challenges. A strong migration strategy that targets old installations would appear to have a credible chance for market success. A higher degree of digitisation should provide the possibility for increased flexibility and visibility for activities such as maintenance. At the same time, a migration strategy must look at legacy systems to see how those systems solve the challenges of complex systems with high availability and reliability. If performed well, a migration may also reduce both the complexity of the system and the.

(19) 1.1. Methodology. 5. installation costs by utilizing existing structures and hardware where appropriate, thus addressing all of the three main market barriers. These trends and observations initiated a third research question to be studied: Q3 What are the functional, performance and operational critical aspects of a successful migration of an industrial automation system to an IoT-based cloud solution?. 1.1. Methodology. The research work presented in this thesis has been conducted in joint research projects including universities, research institutes, and industrial partners. This has brought the possibility of bringing together experience from the methods used in different parts of society. The research methodology used has its roots in experimental computer science and engineering research, defined as “the building of, or the experimentation with or on, nontrivial hardware or software systems” [5]. For the proposal of new methods, current state-of-the-art approaches have been studied through discussions with experience engineers and researchers, through reading papers in the area, and by taking relevant courses. This has identified situations where new technology and societal developments have opened opportunities for improvement over the current state-of-the-art. An iterative process has been used throughout this work: 1. The problem stated is analysed theoretically and a number of performance indicators for a solution are stated 2. A hypothetical solution is designed 3. The proposed design is implemented 4. The implementation is tested for the stated performance indicators 5. Return to 1 for a refined analysis. 1.2. Thesis outline. This is a compilation thesis consisting of two parts. The first part describes the wider societal background, the technical context and the challenges that formed the basis for the research questions Part II consists of five peer-reviewed papers that have been published in the proceedings of various conferences, two submitted journal papers and three book chapters. All are part of the research performed as part of this thesis work, they have been edited to follow the format of the thesis layout, but without any modifications to their contents..

(20) 6. Introduction. The remainder of Part I is structured as follows. Chapter 2 describes digitisation, the technical concepts of Systems-of-Systems and Internet of Things (IoT), and the Arrowhead project, presenting the justification leading to the research presented in the thesis. Chapters 3 and 4 presents the specifics of engineering in the domain of industrial automation and for IoT Systems-of-Systems. Chapter 5 summarises the challenges of migration of industrial automation systems, and a proposed approach. Chapter 6 describes the research contributions of this thesis. Chapter 7 offers some conclusions drawn from the results, presents answers to the research questions, and describe directions for future studies..

(21) Chapter 2 Digitisation of Society and Automation Opportunities. Large scale digitisation of society holds vast potential for improvements in many areas, including environmental, economical, and social sustainability. Some areas of society have already become increasingly digital and some of the early benefits have been reaped through automation of various functions in society. The increasing spread of digitisation promises even greater benefits through interconnection and collaboration between ever growing, ever more numerous automated systems. One popular term for these interconnected collaborating systems is that they together constitute a System-of-Systems.. 2.1. Systems-of-Systems. Systems-of-Systems is one of the design concepts suggested for integration of the very large automation systems proposed in road maps and initiatives such as Industry 4.0 [1], the Factory of the Future road map [2] and the ProcessIT.EU road map on process automation [3]. In particular the envisioned trend of multi-stakeholder corporations match the two defining characteristics of Systems-of-Systems, proposed by Maier [6]: • Operational Independence of the Elements: If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. That is, the components fulfill customer-operator purposes on their own. • Managerial Independence of the Elements: The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems. 7.

(22) 8. Digitisation of Society. In a multi-stakeholder corporation, large monolithic organisations are becoming more modular, with independent entities where responsibilities and decision making can be distributed. As such, multi-stakeholder corporations does not necessarily have to refer to cooperating legal entities but that responsibility and decision making is distributed enough that it could as well be different legal entities, i.e. they are distinctly different stakeholders. Through efficient integration of the modular stakeholders, each stakeholder is enticed to become more specialised and more competitive, as the modular structure with dynamic integration allows replacement of single stakeholders to bring about a more competitive corporation. In order to enable Systems-of-Systems that fully implement these characteristics, Maier [6] also describe four architectural design principles: • Stable Intermediate Forms: A System-of-Systems designer must pay closer attention to the intermediate steps in a planned evolution. The collaborative system will take on intermediate forms dynamically and without direction, as part of its nature. Thus, careful attention must be paid to the existence and stability (in all suitable dimensions) of partial assemblages of components. • Policy Triage: The System-of-Systems designer will not have coercive control over the systems configuration and evolution. This makes choosing the points at which to influence the design more important. In communication-centric systems, this means that design leverage will frequently be found in relatively abstract components (like data standards and network protocols). • Leverage at the Interfaces: A System-of-Systems is defined by its interfaces. The interfaces, whether thought of as the actual physical interconnections or as higher level service abstractions, are the primary points at which the designer can exert control. • Ensuring Cooperation: A System-of-Systems exists because the partially independent elements decide to collaborate. The designer must consider why they will choose to collaborate and foster those reasons in the design. This is not a consideration in the design of monolithic systems where the components can operate only as part of the whole. Given the challenges and opportunities presented by the digitisation of society, as illustrated in the mentioned road maps and initiatives, the System-of-Systems characteristics given by Maier appears to identify and categorise some important aspects, in a generalised way.. 2.2. Automation and clouds. The implementation of digital Systems-of-Systems is not generally obvious, and given the traditional methods for digital systems, the sheer scale of the Systems-of-Systems envisioned may present a significant challenge..

(23) 2.2. Automation and clouds. 9. As a method of managing large scale digital systems, Cloud Computing has become a popular term in Information Technology (IT) for the last decade, based in a much older idea of sharing computation resources dating back to 1957 [7, 8]. The phrase Cloud Computing gained popularity in 2007 after announcements from Google [9] and Amazon [10] in the previous autumn. As do many buzzwords, Cloud Computing has a broad meaning. In a clarifying effort the National Institute of Standards and Technology of the U.S. Department of Commerce (NIST) [11] has defined five Essential Characteristics of Cloud Computing: • On-demand self-service • Broad network access • Resource pooling • Rapid elasticity • Measured service An example of how cloud computing might appear in the field of automation systems can be taken from an Agent-based manufacturing execution system [12]. Agent-based manufacturing execution systems can utilise flexibility in a production line to allow for efficient dynamic scheduling of short production series. This is achieved through identification of units at an early stage, e.g. through an electronic tag or a small system with communication capabilities on each unit. Each identified unit can then be assigned a specialised production sequence with individual modifications. The sequence of operations and production flow is then ensured by software agents representing the units From a functional perspective, the location of the production recipe (i.e. the data) and the execution of algorithms for production scheduling (i.e. the computation) is irrelevant. The production flow will be the same regardless of if the data and computation is centralised, with a passive tag on each unit and each operation performed on request from the centralised system, or if the units are equipped with the capabilities to communicate with each other and individually request operations at each production step through direct communication to the production systems, where the organisation is handled through a distributed algorithm. In such a scenario the location of the data and computation can be seen as obscured, as if known to exist but hidden within a cloud. Obscurity is a question of perspective though, and only one aspect of Cloud Computing. However, as long as each unit is represented as a software agent on the networked systems, and the execution location can be changed, allowing for the essential elasticity, and it is operated through a networked, measured service-oriented approach, either implementation could be considered an implementation of Cloud Computing. Among the Essential characteristics proposed by NIST, this aspect is represented by Resource pooling, in that the resources are not assigned specifically by design but rather available in a pool..

(24) 10. Digitisation of Society. Even though the general definitions of cloud computing, like the one proposed by NIST, allow for a rather wide set of implementations, the general perception of a Cloud has become more associated with globally accessible platforms for software execution and data storage. This is likely stemming from the implementations presented by e.g. Amazon and Google, as these coincided with the popularisation of the term. For applications that are inherently local, in that they operate to a large degree with physical objects and measurements as points of input and output, the benefits of global accessibility are not as apparent as with more traditional IT systems. This, combined with the narrowed perception of the concept, appears to be one of the reasons for a couple of other concepts, such as Edge [13, 14] or Fog [15] computing. For automation networks there are also several reasons to restrict the span of the resource pooling and the elasticity, e.g. to be able to predict or guarantee Quality of Service (QoS) [16], and to restrict the broad, on-demand access, e.g. to meet a certain level of safety and security according to required safety and security assessments, as discussed in the appended Paper J. These reasons have motivated the more specific concept of a Local Automation Cloud, as described by Delsing et al. [17]. A Local Automation Cloud, as implemented on a series of local devices running software in a distributed manner and interacting with the physical world through a number of things can be seen as an implementation of an other popular concept, envisioned to provide countless opportunities for the improvement of efficiency, control, and comfort in society, the Internet of Things.. 2.3. Internet of Things. The Internet of Things is envisioned to be a cornerstone in the connected, comfortable, efficient, and productive society of tomorrow. The idea behind the Internet of Things is to allow things to communicate directly with each other, e.g., to share related information from different systems and to present the information to users in a more useful manner, allowing humans to focus on decisions and actions rather than filtering and combining information from different sources. Cisco presents a good example in an infographic [18], in which information from traffic systems, train systems and meeting schedules is aggregated and communicated to the alarm clock and car systems of an end user. These interactions exemplify the characteristics of a System-of Systems very clearly, in that all of these things are already independent, functioning systems, before they receive any connectivity. Through an example, such as the one by Cisco, it is possible to visualise how an SoS is formed from the independent systems, using the four architectural principles. In the Cisco example, the alarm clock has its alarm time modified by information from a meeting schedule, a car, a traffic information system, and a train information system, resulting in the alarm clock additionally signaling the car and a coffee maker in turn. All of these systems are independent from both an operational and managerial point of view, satisfying the two defining characteristics proposed by Maier. Furthermore, although the example is presented by Cisco as complete, it is possible to.

(25) 2.4. The Arrowhead project. 11. see that any one of the connections would be a useful integration on its own, and any set of the connected systems will be a stable intermediate form. Similarly, it is obvious that the System-of-Systems designer is not likely have coercive control of such diverse systems a train information systems, a car and a coffee maker, thus satisfying the policy triage. The same applies to the characteristic referred to as “Leverage at the Interfaces”, as the capabilities in this example are fundamentally limited by the interaction capabilities of the alarm clock and of the other systems. The characteristic of “Ensuring Cooperation” does not appear clearly in the example, but it is reasonable that the described System-ofSystems exists primarily for the benefit of the user of the alarm clock, and the connections to all other systems are likely driven by commercial interest from the system providers, seeing that an owner of a connected alarm clock might be willing to pay a small premium for a connected coffee maker, and so on. This example illustrates the benefit of interoperability between rather diverse systems, and that it is something of a requirement for widespread establishment of the IoT vision. A survey of commercial IoT frameworks and platforms, with various solutions to interoperability, was performed by Derhamy et al. [19]. Part of this vision is the Industrial Internet of Things (IIoT) whereby connected devices in industrial installations, in addition to performing the duties of the automation systems of today, provide countless opportunities for improvement thanks to dynamic access, for human and electronic decision makers alike, to systems and information that were previously obscured [20]. Cisco predicts 3.4 IP-connected devices per person on earth by 2020 [21] and that M2M connections will grow from 4.9 billion in 2015 to 12.2 billion by 2020 [22]. Only a minority of these are industry related but the Compound Annual Growth Rate (CAGR) is predicted to be over 10% for Manufacturing and Supply Chain and nearly 30% for the Energy sector. The technology behind the Internet of Things is based on Internet Protocols (IP) and Service-Oriented Architectures (SOA) as an open platform with tested technology. Pereira et al. highlight in their study of the European Monitoring and Control market from 2007 [4], that one of the main challenges of Monitoring and Control in the fields of both manufacturing and process industries for the European market appears to be related to the establishment of IP and service-oriented architectures.. 2.4. The Arrowhead project. Based on the high-level visions and road maps for societal improvements, the Arrowhead project was formed around the grand vision to “Enable collaborative automation by networked embedded devices”. Two grand challenges were identified in the proposal of the project, in the spirit of the System-of-Systems approach, focusing on the communication and interface aspects especially. The two Arrowhead Grand Challenges are: • Enabling the interoperability of services provided by almost any device • Enabling the integrability of services provided by almost any device.

(26) 12. Digitisation of Society. Figure 2.1: Key concepts of the Arrowhead Framework.. As previously illustrated, and further highlighted in the first of these two Grand Challenges, interoperability is of vital importance to bring the societal benefits that are envisioned for digitisation. However, interoperability is a wide concept and can come in different varieties, both in terms of the technical level that can be agreed upon but also what span of functionality that is included. E.g., as Derhamy et al. [23] illustrate in their proposal for handling error-messages during translation between communication protocols, a more complete approach to interoperability must handle much more than simply handing over a data package between two devices. Ultimately, interoperability will have to depend on the application and the situational requirements, but it is likely that for the scope targeted by Arrowhead, the challenge will include the following interoperability aspects: • Protocol interoperability • Security interoperability • Semantics interoperability All of these aspects have been investigated during the project, with the first one showing the most promising results, summarised by Derhamy [23, 24, 25]. Security interoperability has been addressed within the project, but significant challenges remain [25, 26]. Simultaneously, significant progress has been made by other research groups on the challenge of Semantic interoperability, although much work remains to be done [27, 28, 29]. The second Grand Challenge of integrability of services illustrate that through integration by service interactions, a greater function can be fulfilled, much in the same sense that Systems-of-Systems may be able to address the greater societal challenges in a way that the independent systems have yet been unable to..

(27) 2.4. The Arrowhead project. 13. The cornerstones for enabling integration of systems will be to understand 1) what things there are that could possibly be integrated, and 2) how these things should be connected so that the integration leads to added functionality or value. From the Arrowhead project has emerged the Arrowhead Framework for integration of interoperable systems, through the use of service interactions [26, 30]. Within this framework, the method for finding other systems is through a Service registry and discovery system, and the method for finding how systems should be connected for greater benefit is through an Orchestration system. Given the openness of a framework based on the principles of a service-oriented architecture, it is additionally deemed necessary to have a trusted actor to certify the authenticity of connected systems and authorise service interactions in the System-ofSystems, a function that in the Arrowhead framework is provided by a Authentication and Authorisation system. These three core systems for the basis of the Arrowhead framework, by enabling the interoperability and integrability between compatible connected systems, as illustrated in Figure 2.1. Some of the key scientific contributions presented in this thesis represents the approach by which a System-of-Systems based on the Arrowhead framework can be designed to fulfill a desired function, through populating the Orchestration system..

(28) 14. Digitisation of Society.

(29) Chapter 3 Industrial Automation Systems. The previous chapters discussed the most modern technologies that society is currently discussing and developing. To better understand the environments such systems have to operate in, it can be helpful to first study the history of what we today consider legacy automation systems. Industrial control systems can be traced back to the very first industrial machines in the 18th century, through famous scientists and inventors such as James Watt, William Siemens and James Clerk Maxwell, from purely mechanical systems to electrical relay systems and further on to microprocessor based systems in the early 1970’s [31]. Today virtually all industrial control systems are based on microprocessor systems, small electronic devices distributed across all areas of industrial systems. Although the electronic hardware today is not so different in the different areas of industrial automation, there are significant differences in the structure and their organisation. Through these technical differences and through some historical differences between industrial sectors, many different approaches have been established for engineering of the different industrial automation systems.. 3.1. Automation systems by industrial sector. Throughout the evolution of industries and industrial control systems, the focus and challenges have differed between industrial sectors. Generally speaking, there can be said to be three main categories of industries affecting the automation systems that have evolved in these sectors, these are: 1. Manufacturing industries where products are made piecewise, often through the assembly of components into a complex product ready for delivery to a consumer market. The production flow is characterised by a series of machines along a transport system, where products arrive one at a time to each machine which performs a series of operations on each product before the product is transported to the next machine. 15.

(30) 16. Industrial Automation Systems 2. Process industries in which a raw material is processed into a more refined material, often for delivery to manufacturing industries. The production flow is usually continuous, going through highly specialised machines that process the material as is flows through or captures in large vats for processing before it is released in a continuous flow to the next machine. For automation purposes, large energy production facilities such as power stations are often grouped with process industries, as a facility where a raw material such as coal, oil or waste material is processed into heat and electric energy. 3. Utilities and infrastructure: Although technically not production facilities, utility systems such as water and sewage networks, power grid systems, rail networks and tunnel systems are often considered industrial systems. These networks are all geographically distributed, with some powered systems spread out over great distances, with some need to monitor the systems and with a need to perform some local control actions at the widespread locations.. Through the practical differences in operation, different markets and different technical evolutions, these three industrial sectors have developed different automation traditions and approaches to the engineering of these systems.. 3.1.1. Manufacturing industry automation systems. Mehrabi et al. [32] identify four historical manufacturing paradigms (Mass production, Lean manufacturing, Flexible manufacturing systems, and Reconfigurable manufacturing systems), up until the year 2000. Each of these paradigms being focused on addressing a very specific competitive advantage, and each new paradigm depending on or including the previous ones. In a similar manner Jovane et al. [33] identify Craft Production starting in the middle of the 19th century, Mass Production starting with the invention of the assembly line in 1913, Flexible Production introduced in the 1970’s, and Mass Customisation and Personalisation starting around the year 2000, and predict a fifth paradigm in Sustainable Production for the 2020’s. Figure 3.1 illustrate the historic progression in terms of variety and volume. The manufacturing industry has traditionally used a lot of manual labour, since the start of the era of mass production, organised at stations along the assembly line, and the automation of manufacturing has until all but recently been intended to improve the efficiency and quality of the traditional assembly line. As such, the general approach has been to automate the operation at each station individually, resulting in relatively independent automation at each station, with only limited monitoring and coordination between stations through a supervisory system. This set-up is called a PLC-SCADA approach, using a Programmable Logic Controller (PLC) at each station and a Supervisory Control And Data Acquisition (SCADA) system for supervision and coordination. This separation between local and distributed control means that each station or production cell can be engineered more independently, allowing suppliers of manufacturing equipment to deliver fully automated production cells, only providing a limited communication interface to the SCADA. This lowers the cost of acquiring each production.

(31) 3.1. Automation systems by industrial sector. 17. Figure 3.1: Illustration of the historic progression of manufacturing. Adapted from [33].. cell but can lead to complications during operation and maintenance of the systems, if production cells have been acquired from different suppliers not following the same engineering practices.. 3.1.2. Process industry automation systems. Compared to the manufacturing paradigms, process industries was for a long time focused exclusively on product cost and product quality; the significant competitive advantages identified by Mehrabi et al. [32] as significant for Mass production and Lean production, respectively. This has most likely contributed to the affinity for highly specialised equipment with very high reliability and throughput within the sector. Only more recently has there been an interest in more customised products from the process industry, possibly as a result of globalisation where the largest and most efficient plants are able to serve the entire global market of bulk products forcing smaller plants, with higher relative operating costs, to go out of business or focus on specialised markets where the revenue per volume is higher. Partially due to this focus on efficiency and quality in the production, and partially due to the high investments made in the process machinery, the automation in process.

(32) 18. Industrial Automation Systems. industries has developed in a different direction than that of the manufacturing industries. In process industries there is a strong focus on the process flow, throughout the whole production facility, and as such the automation is organised as one tightly connected system, with control execution hardware distributed throughout the facility. This is referred to as a Distributed Control System (DCS). While the electronic hardware in each of the controllers in a DCS can be very similar to a PLC, a major difference is that the engineering of the whole DCS is done centrally, ensuring that the same engineering approach is used across the whole facility but often at a higher cost as it is more difficult for suppliers to streamline their engineering procedures.. 3.1.3. Utilities and infrastructure automation systems. In the field of utility services, such as water and sewage transport, and infrastructure, such as railroad networks, power grids, motor highways and tunnels, the automation challenges have long been focused on immediate local control and long-distance supervision. The commercial situation is usually very different compared to the two other categories, with utilities and infrastructure systems often serving a specific geographic area with very little competition within that area. As the services are often funded, owned or heavily regulated by governmental or municipal bodies, the focus is often a required level of service at minimal cost. Therefore, there has been an even stronger focus on cost than for process industries, and only very limited concern for quality. In this environment the automation systems have taken on a third type of structure, called SCADA systems as is common in manufacturing industries but traditionally with Remote Terminal Units (RTU) executing the local control. An RTU is similar to a PLC but the structure is much more focused on the communication issues that may occur in such geographically distributed systems. Given that continuous, reliable operation is critical in this area, an RTU is expected to be able to continue its operation even if the connection to the supervisory system is disabled for some time, and usually configured to store all data locally until the communication can be resumed. Compared to the operation of a PLC in a manufacturing scenario, the control scenario for an RTU is usually much simpler with only one mode of operation controlling a few devices.. 3.2. Industrial automation engineering. Much of the industrial automation engineering is performed as projects and can be structured using a traditional project management approach using the five phases of a project that are illustrated in Figure 3.2. In Paper [G? - fix!], a more specific work-flow for automation engineering is described, following the five steps: 1. Conceptual application design: This step is comparatively informal and and usually not technically specific but should outline the purpose and motivation for the application. Typically it should answer the question “Why?” and provide basic requirements to the design, given available resources and other constraints..

(33) 3.2. Industrial automation engineering. 19. Figure 3.2: Project Management main phases. Illustration from Wikimedia commons, licenced under GNU Free Documentation License.. 2. Functional design: This step will produce most of the overarching design documents. The results of this should be a detailed design of the mission critical functionality and functional requirements for the support systems. 3. Procurement and Engineering: These two activities are often performed in parallel, and will affect each other. Certain requirements and design decisions may limit procurement to a single option, that will affect engineering. Subsequently, engineering decisions may pose additional requirements on procurement of other parts or subsystems. 4. Deployment and Commissioning: As all equipment is purchased, configured for the application, and delivered to the site of operation, a process of deployment and integration of all systems begin. When systems have been connected a series of integration tests and commissioning starts, after which the full, interconnected system-of-systems is ready for operation by the end user. 5. Operation: When the operational phase starts, the full system-of-systems should perform at the requested level without any need for further engineering. However, in most scenarios there are minor details that were not foreseen during the design phases and must be adjusted. Similarly, external factors, such as markets or regulation, are likely to change during the operation of a large system. All of these may require updates to design and engineering, including documentation and data. The work-flow serves as a basis for the engineering of automation systems based on Internet of Things, but it is based on an amalgamation of the work-flow used for traditional engineering of automation systems in various domains.. 3.2.1. Engineering similarities and differences. Due to the aforementioned differences, the automation engineering within these three categories has developed in slightly different directions. In the Manufacturing industry, there is a high acceptance for specialised controllers for tasks such as robot control and Computerised Numerical Control (CNC) for, e.g.,.

(34) 20. Industrial Automation Systems. automated cutting, welding, and grinding. With time, some of these controllers have expanded their functionality to encompass the full control of a manufacturing cell, including presenting an interface that can be directly integrated to e.g. a SCADA system for organisation at a higher level. In some applications, there is still common practice of instead having a PLC in control of each manufacturing cell, interacting with and coordinating the specialised controllers within the cell, and communicating with supervisory systems. In both cases, the engineering of the control at the level of the specialised controllers is usually based on 2D or 3D geometric models or drawings that are interpreted by the specialised controllers into movement patterns, with the interpretation specific to the machine builder. The coordination between different machines is usually based on sequential coordination, for which programming in Sequential Function Charts (SFC) is well suited, SFC being one of the traditional PLC programing languages described by IEC 61131-3 [34]. Comparatively, Process industries typically prefer to have as much of the control integrated directly in the Distributed Control System (DCS). This brings with it a number of advantages, to which the owners, operators and engineers in the industry have now become accustomed. From an engineering perspective, a significant advantage is that much more of the systems are accessible from a single engineering station using a single engineering environment. On the other hand, the investment in automation is typically more costly, as it is more difficult to re-use engineering effort from other production plants as the production segments are not as clearly separated into single units as is customary with manufacturing cells. As the process industries are typically not concerned with the geometrical properties of their products but rather have different quality aspects, the engineering has not been as focused on the usage of product models in the engineering. To the extent that models are used, they are usually more of simulations of various thermal and chemical processes, visualised in graphs or symbols. As most process operations are not shifting between different states according to a sequence, but rather operate continuously with some variance around the preferred optimum, the programming is preferably done in Continuous Function Charts (CFC), an extension of the traditional PLC programming languages described by IEC 61131-3 [35, 36]. For utility networks, the previously mentioned structure of the automation systems, the commercial focus on cost reduction and the situation where many control points along a network are practically identical, has led to an engineering strategy where each control point is engineered, programmed and built exactly identical. As this means that the design can be reused many times using the exact same combination of components, the engineering effort is spread on a very large number of systems. This subsequently means that the engineering cost per system is relatively low, compared to both manufacturing and process industries. On the other hand, the relatively simple control points and geographic distances has pushed more functionality to the SCADA level, especially in the areas of remote monitoring..

(35) 3.3. Standards for engineering data. 21. Figure 3.3: Functional hierarchy as defined according to ISA-95 / IEC 62264. [37]. 3.3. Standards for engineering data. In spite of the differences, virtually all traditional automation systems within both manufacturing and process industries are organised on a higher level according to the standard IEC 62264, based on ANSI/ISA-95. This standard describes the hierarchy between systems, as illustrated in Figure 3.3, and prescribes limited interaction between systems at different levels of the hierarchy. In terms of the preciously described DCS and PLCSCADA solutions, they all reside within level 1 and 2 of this hierarchy. Similarly, at the other end of the scale, most automation programming today is implemented in one of the five languages defined by the standard IEC 61131-3 [38], or an extension thereof, such as Continuous Function Charts. At the same time, at various levels from the general view of the ISA-95 hierarchy to the implementation details of IEC-61131, there is a variety of competing and complementary standards for system management at various stages of the industrial automation lifecycle, including e.g. design, engineering, operation and maintenance. Fernández and Márquez [39] illustrate some of the differences between the standards R promoted by the IEEE Utility Communications Architecture (UCA ) International Users.

(36) 22. Industrial Automation Systems. Group, which works closely with the IEC Technical Committee (TC) 57 IEC 61850, IEC 61970 and IEC 61968, primarily associated with power systems management. And on the other hand, ISO TC 184, collaborating with “Machinery Information Management Open Systems Alliance” (MIMOSA), promotes standards primarily associated with the category above described as process industry. These standards include, e.g., OPC (“OLE for Process Control”), ISO 15926 - Industrial automation systems and integration, and ISO 18435 - Industrial automation systems and integration – Diagnostics, capability assessment and maintenance applications integration. For the manufacturing industry, the German initiative Industrie 4.0 promotes the following standards in the Reference Architectural Model Industrie 4.0 (RAMI4.0) [40]: For life-cycle and hierarchical structure: • IEC 62890 “Life-cycle management for systems and products used in industrialprocess measurement, control and automation” • IEC 62264 (ISA-95) / IEC 61512 (ISA-88) For end-to-end engineering: • AutomationML • ProSTEP iViP • eCl@ss Additionally, the standard IEC 81346 “Industrial systems structuring principles” [41] is commonly used in both manufacturing and process industries. There are several standards used in more than one industrial domain, and there are already some initiatives on synchronization between pairs of complementing standards such as collaboration between AutomationML (IEC 62714) and OPC-UA (IEC 62541) [42] as one example and collaboration between ISO 15926 and Mimosa [43] as another. Also, Göring and Fay [44] illustrate how IEC 81346 can complement AutomationML, but across the different automation domains there are still many different standards available, most with some significant advantage within their most prominent domain..

(37) Chapter 4 Engineering of IoT Systems-of-Systems. To form a functioning System-of-Systems out of element systems based on Internet of Things as discussed in Chapter 2, a coherent approach, such as an IoT Framework, is required. Within the scope of using Internet of Things (IoT) devices in a Service-Oriented Architecture (SOA) to create inter-domain Systems-of-Systems (SoS) for automation, there are some limiting factors to the methods available for constructing the full Systemof-Systems. Looking at the principles for IoT, SOA, and SoS, it is clear that the SoS coordination should have as little impact as possible on the design of the individual systems. Given the architecture, it can also be assumed that that the interaction should be through services. Furthermore, relating to the envisioned scenarios with multiple cooperating stakeholders within one automation application, it is likely that some stakeholders will have the possibility to change how an individual system operates while some others will have the authority to decide how systems should interconnect to fulfill the automation application. This may be the case both during design-time, including the engineering work, and during run-time. The effects of multiple cooperating stakeholders has not yet been investigated, but remain an area of potential future work, as discussed in Section 7.2. Given the envisioned number of units that are to be engineered in this fashion, it is also important that the engineering is very efficient, which has been an important factor in this thesis. To limit the scope and refine the solutions, the concept of engineering in this area can be detailed further. In essence, the engineering tasks addressed in this work can be sorted into addressing one of the two questions: 1. How should each system be set to act as the controlling stakeholder desires? 2. How should cooperating systems be made to do what a System-of-Systems application designer intends? 23.

(38) 24. Engineering of IoT SoS. In general, the phrasing used here is that the first question is handled through Configuration while the second one is handled by Orchestration. These names are the ones primarily used in the Arrowhead framework [26, 30], but similar concepts should be available for other IoT frameworks and platforms as well. The rest of this chapter will present some methods and approaches to address these challenges in an efficient manner that can be used for virtually all systems, across all of the automation application domains targeted by Arrowhead and hopefully others as well.. 4.1. Engineering in the Arrowhead framework. Three Arrowhead core systems were presented in Section 2.4; Authorisation and Authentication, Service registry and Orchestration systems. These three systems are considered mandatory core systems of the Arrowhead framework [26, 30]. The design also contains nine automation support core systems, as detailed in the appended Papers H and I. For the engineering methods presented in this thesis, five of the Arrowhead core systems are of particular interest: • The PlantDescription system is intended to provide a basic common understanding of the layout of a System-of-Systems, and to act as an intermediate abstraction layer, based on existing standards for design and engineering data, isolating only the objects and their relations. One key usage of the Plant Description is as a source of design data for the orchestrator [45, 46]. • The Configuration system is designed to provide a generic approach to management of configurable devices and systems, the Configuration system provides a service acting as an organised storage for configuration files [47]. • The Orchestration system is responsible to assign service providers to consuming systems. Several implementations have been made, as described by Heged˝ us et al. [48], but with regards to the engineering work-flow these are interchangeable. • The System registry is designed to provide a local cloud storage, holding the information on which Systems are registered with a local cloud, meta data of these registered System and the services these systems are designed to consume [26]. • The Device registry shall provide a local cloud storage, holding the information of which Devices are registered with a local cloud [26]. Considering that the work presented in this thesis was intended to support the Arrowhead project, which spans not only the three mentioned industrial domains (manufacturing, process, and utilities) but also building automation which uses several other standards, the structuring and identification of systems was considered a significant challenge to the objective of developing a coherent engineering and operation methodology, usable by most of the targeted domains. The following list was composed as a collection of important standards, each relevant to one or more of the targeted domains:.

(39) 4.2. Automation system engineering work-flow. 25. • CAEX (IEC 62424) [49] • AutomationML [50] (IEC 62714) • MIMOSA [51] • OPC UA [52] (IEC 62541) • IEC 61499 Function blocks [53] • IEC 81346 Industrial systems structuring principles [41] • fastAPI Swedish building automation [54] • IEC 61850 Power utility automation [55] • ISO 16484 Building automation and control systems (BACS) [56] It is well recognised that this is not a complete or exhaustive list, but it is hoped that the list is large and diverse enough to expose the most critical issues that may appear in creating a coherent approach for so many different application domains. The integration of data from several standards is not a novel challenge, in fact there is already an available standard for integration of data from two or more standards, the standard ISO/TS 18876 “Industrial automation systems and integration – Integration of industrial data for exchange, access and sharing” [57]. This standard provides a methodology intended to capture all of the data of two or more sources that are using different standards, and create a new data-set including all of the captured data. This is a useful approach on an application basis, where each data source does most likely not use all of the possibilities of each standard, or when it is absolutely necessary to merge two sets of data. However, as a general approach for engineering and management of multi-domain automation systems, it is likely to become cumbersome, as each added standard is almost certain to grow the data-set. In an attempt to enable cooperation in engineering between users of these different standards, the Plant Description is proposed as a unifying concept. Using the idea that all domains identify objects or systems as units that are related to each other, it is possible to record the identities of them and their respective relations. The details of the concept is presented in the Papers D, E, H and I, with further examples of its usage in Papers G and J. For the configuration of automation devices, there are not as many standards in common use, but more providers use proprietary formats. In order to present an approach to configuration that could incorporate the variety of open, standardised and proprietary solutions, the Arrowhead Configuration system was designed to keep track of and transfer configurations. The approach is presented in Papers F, H and I, with some examples of its usage in Papers G and J..

(40) 26. Engineering of IoT SoS. Figure 4.1: Five steps of an automation system engineering work-flow.. 4.2. Automation system engineering work-flow. In Paper G, an engineering work-flow is presented, encompassing five steps from Conceptual application design to Operation, as illustrated in Figure 4.1. The work presented in this chapter is primarily focused on the third and fourth of these five steps, “Procurement and Engineering” and “Deployment and Commissioning”. Starting from Conceptual application design, there are no proposed additions or changes for this phase. While there is great potential for new applications using the new technology, it is assumed that the design process at this level will remain essentially unchanged, as there is very little specification at technology level involved at this stage. Regarding Functional design, step two of the work-flow, it is likely that there would be additions to the process due to new possibilities, e.g., the late binding between systems that is offered in a Service-Oriented Architecture. However, the work presented here is more focused on the engineering, as in turning a design into a working system, rather than on how to best capture the design in the first place. For the two connected tasks of Procurement and Engineering, there are some significant differences proposed, compared to current practice. Given the increased independence of IoT devices in a system-of-systems approach, there should be better options for Procurement to focus on performance and commercial concerns, with less effort spent on assuring interoperability. For the task of Engineering in this step, the work-flow proposes that an engineer can decide which types of automation devices to use based on documentation such as the System Descriptions (SysD) and Service Descriptions (SD) used in the Arrowhead framework [26, 58]. For devices that need to be configured for the intended application, configuration files can be constructed offline and organised using the Configuration system, without direct access to the device. This is further described and discussed in Paper F. A second significant proposal for the engineering task is usage of the Plant Description concept, described briefly in the previous section. As part of the work-flow, the Plant Description is used both as an abstraction of the system-of-systems, to be used by other engineering systems and user interfaces, and as input data to create orchestrations in the system-of-systems. The concept of the Plant description and its potential usage in engineering is further described and discussed in Papers D, E and G. The fourth step of the work-flow, Deployment and Commissioning, is intended to use.

(41) 4.2. Automation system engineering work-flow. 27. the information stored in core systems, such as the PlantDescription system, the Configuration system and the Orchestration system, to streamline primarily the deployment, as described in Papers F, G and J. During deployment, the PlantDescription system is intended to help in the identification of devices and the Configuration system reduces the number of manual operations. During commissioning, the Plant Description should prove useful as a tool for System-of-Systems overview, similarly to the usage scenario proposed for automotive industries in Paper D, where the Plant Description serves as a point of reference when different viewpoints or data sources need to be related to each other. Operation is the final step of this work-flow, though the life-cycle of most of the systems and data continues. There are several aspects of the methods included in the work-flow that can benefit operation and later phases of the life-cycle. Some of these are described in Paper J, but they are not included in the work-flow and thus not discussed in detail in Paper G..

(42) 28. Engineering of IoT SoS.

(43) Chapter 5 Migration of Industrial Automation Systems A very specific type of engineering projects concern the situation where an existing system is already providing much of the desired functionality, and the intention is that the new system should replace and extend the functionality provided by the existing system. This group of engineering projects is called migration projects and the key trigger for such a project is usually a desire to replace the existing technology with a whole new generation of technology, or a new paradigm.. 5.1. Migration of industrial automation systems. There is a long tradition of migration of Information Systems (IS) within the field of Information Technology (IT) and computer science [59, 60]. Compared to a generic ITsystem migration, the procedure for migrating an automation system does have some similarities that can be used to draw conclusions or at least form a hypothesis. One similarity between the two is that they both have a core of raw data and usually several different user interfaces, and in between these, there are one or more layers of subsystems that combine and process the raw data into more accessible information before it is presented for the user to act upon. However, there are also significant differences between IT systems and industrial automation systems, most significant are the direct connections from an automation system to the mechanical components, sensors and actuators that are part of the physical process. This means that there is an added level of complexity in migrating the sensors and actuators, compared to the databases or similar systems of the IT world, and this complexity can carry over to the layer of systems and applications that access those components. To facilitate a general migration strategy using migration paths as described by Delsing et al. [61] the IMC-AESOP project [62, 63, 64] provided a set of key issues that should be addressed in any migration plan for an industrial process control systems. 29.

(44) 30. Migration of Industrial Automation Systems 1. Current situation (a) Analysis of the legacy systems including state of documentation, interfaces and tools. (b) Identification of systems characteristics and parts that should/could be migrated. This is driven by internal strategies, available solutions and current KPIs 2. Desired situation (a) Identification of business needs, requirements and goals 3. Transition/Implementation phase (a) Evaluation of possible migration paths and choice of the most suitable ones (b) Identification and evaluation of cross-relations between migration paths for different KPIs (c) Identification of needed migration tools (d) Process migration steps and check-tests (e) Execution of the migration and stepwise evaluation 4. Risk analysis and Risk mitigation strategies (a) Risk analysis and impact (b) Risk mitigation strategies 5. Measures and trends (a) Evaluation and verification of the overall result (both at the system and process level) (b) Further optimization towards KPIs, e.g., reliability, performance, etc.. Compared to the five phases suggested by Bisbal et al. [59] (1. Justification, 2. Legacy System Understanding, 3. Target System Development, 4. Testing, 5. Migration), and the project management phases illustrated in Figure 3.2, there are some links to be found. The first is from the Desired situation to Justification, which is part of the Initiation and provides part of the input to Planning and Design. From the Current situation there is a link to Legacy System Understanding, which is another requirement for Planning and Design. The Transition/Implementation phase is focused on the plan for Migration, i.e., the result of Planning and Design that is used for Executing. In the end, Risk analysis and Risk mitigation strategies together with Measures and trends provide the basis for Testing or a plan for Monitoring and Controlling. All of these strategies and approaches have a common thread; however, there are some differences, as for example, that these last key issues listed here are not strictly different phases but aspects that should be considered for the migration process..

(45) 5.1. Migration of industrial automation systems. 31. A general migration procedure for industrial automation systems could look something like this: 1. Justification Including the desired improvements, new and existing requirements, conditions and extent of the migration. 2. Select target solution This process must take all technical, organizational, and business considerations into account, such as maintainability, future availability of know-how, hardware and software support, and all requirements that were identified in the justification process. 3. Find step-size for step-wise migration This will define much of the migration strategy. As O’Brien and Woll [65] mentions there are cases where an all-at-once strategy is advisable but this is likely to be more rare the more modular both the existing and the target systems are. 4. Identify system modules for migration This process should be based on knowledge of the existing system and may be based on hierarchy, subsystems, hardware or software objects, functionality or other concepts but it should always take the outcome of justification, target solution and migration step-size into account. 5. Organize system modules into migration steps At this stage it is vital to verify that all required functionality is available throughout the migration process, meaning that special consideration must be taken to verify that all required interconnections between system modules are available before and after each migration step. 6. Plan, execute and validate each migration step Each individual step will require some more detailed analysis of the legacy system, target system development, testing, commissioning and validation. 7. Monitor and validate Before closing the migration project the situation as a whole should be documented and validated with regards to the justification and requirements that were set at the beginning. 8. Close the project Evaluate the migration as a whole and try to find points for improvement of the process that can be used in the future and shared with others. The above process describes the considerations made when the strategy for migration of ISA-95 structured Distributed Control Systems to a Service-Oriented Architecture presented in paper C was developed. However, as the justification was somewhat forced and the target solution was already defined in that scenario it was necessary to make.

(46) 32. Migration of Industrial Automation Systems. some assumptions. When the process was used in the demonstration presented in paper B it was halted in the middle of Plan, execute and validate each migration step with the first step executed and validated but the following migration steps only planned at a higher level. As discussed in Chapter 3, there are a few different structures by which traditional industrial automation systems are built and organised. The one typically used in process industries, the Distributed Control System (DCS), is often built, configured, and operated as one strongly interconnected system. Therefore, this type of industrial automation systems can be seen as a very interesting example for the proposal of a migration procedure, intended to facilitate the migration from a traditional automation system to a System-of-Systems based on a Service-Oriented Architecture (SOA). When discussing the migration of industrial process control systems structured according to the ISA-95 as in figure 3.3 it is worth noting that Supervisory Control And Data Acquisition (SCADA) systems are usually considered to represent level 2 in the ISA-95 structure with Remote Terminal Units (RTU) or Programmable Logic Controllers (PLC) acting as local controllers in level 1. Distributed Control Systems (DCS) on the other hand are usually considered to span both level 1 and 2, sometimes including functionality otherwise provided by level 3 systems. Higher level systems are usually not considered part of the control system but rather connected to and interacting with it. Although the difference in technical capabilities between SCADA/PLC solutions and DCS have diminished over the years, there are still certain operational and architectural differences that makes the process for migrating a DCS very different from migrating SCADA/PLC-based systems.. 5.2. Key differences between SCADA and DCS. Most of the differences between SCADA and DCS can be traced to the differences in design goals and for most systems today it is possible to do everything with both types of systems, but one is often simpler, cheaper or better suited for each case. In essence, it can be said that a SCADA is data-gathering oriented, while a DCS is process oriented. The controllers or PLCs in a DCS are characterized more by distributed execution platforms rather than independent systems, and for that purpose, the communication networks within a DCS are often built redundantly so that communication is always available. In contrast, the local controllers in a SCADA configuration are designed with possible interruptions in communication in mind, meaning that they are much more independent and usually designed to continue their operation for some time without a connection to the SCADA. In some cases, the system uses a Remote Terminal Unit (RTU) that manages the communication to the central supervisory system, while in other setups, this may be performed by components integrated in the PLC responsible for local control. A SCADA solution is more often used in scenarios in which all information required for normal operation is available locally, such as long distance utility networks or factory automation in which each station can perform its task independently of other stations..

No results found