9789144138930 by Smakprov Media AB

SYSTEM DESIGN AND IMPLEMENTATION PRINCIPLES FOR

DEVELOPMENT OF CYBER-PHYSICAL PRODUCTION SYSTEMS

LUIS RIBEIRO

Copying prohibited This book is protected by the Swedish Copyright Act. Apart from the restricted rights for teachers and students to copy material for educational purposes, as regulated by the Bonus Copyright Access agreement, any copying is prohibited. For information about this agreement, please contact your course coordinator or Bonus Copyright Access. Should this book be published as an e-book, the e-book is protected against copying. Anyone who violates the Copyright Act may be prosecuted by a public prosecutor and sentenced either to a fine or to imprisonment for up to 2 years and may be liable to pay compensation to the author or to the rightsholder. Studentlitteratur publishes digitally as well as in print formats. Studentlitteraturâ&#x20AC;&#x2122;s printed matter is sustainably produced, both as regards paper and the printing process.

Art. No 43019 ISBN 978-91-44-13893-0 First edition 1:1 ÂŠ The Author and Studentlitteratur 2020 studentlitteratur.se Studentlitteratur AB, Lund Cover design: Jens Martin/Signalera Printed by Dimograf, Poland 2020

CONTENTS

Preface 7 PART I

Design Principles

CHAPTER 1

Introduction 11

CHAPTER 2

The Fourth Industrial Revolution 15

Heading towards the Fourth Industrial Revolution 15 Emerging System Design Concepts 22 Cyber-physical Production Systems and Industrial Cyber-physical Systems 23 Digital Twins 27 Cyber-physical Productions Systems and\or Digital Twins and Design Requirements 28 CPPS’s Reach and Conceptual Challenges 36 To CPPS or not to CPPS 37 Conceptual Challenges 37 Integrated Discussion 50 47 Test Your Understanding 48 51 CHAPTER 3

Supporting Concepts 53

System 53 System Element 53 Structural Relationships between Elements 54 Operational Environment 54 System Boundary 55 System Attribute 55 System State 55 System of Systems 55 Interface 56

contents

Production System 56 Asset 56 Emergence 56 Self-organization 58 System Architecture 59 Modular Architecture 60 Integral Architecture 60 Top-down Design 60 Bottom-up Design 61 CHAPTER 4

Incorporating Ideas into Concrete System Design 63

One Possible Design Process 63 High-level Design Principles 64 Reference Architectures 65 Instantiated System Specific Architecture 65 System Behaviour and Control Design 66 Hardware in the Loop Implementation 66 CPPM Reference Architecture 66 The CPPM Structure in Detail 67 Architectures for CPPSs 69 First Design Stage Considerations 70 Second Design Stage Considerations 75 Third Design Stage Considerations 82 Fourth Design Stage Considerations 87 Fifth Design Stage Considerations 98 The Critical Thinking Check-list for CPPS Design and Implementation 103 Very Brief Notes on the Operation of CPPSs 104 Test Your Understanding 107 PART II

Implementation

CHAPTER 5

Preparing the Development Environment 111

Software Setup 112 Setting up the JAVA Virtual Machine 112 Setting up the Development Environment 115 Setting up the Agent Platform 117 JADE in a Nutshell 120 4

ÂŠ T H E A U T H O R A N D S T U D E N T L I T T E R AT U R

contents

Agent Interaction Protocols 131 Test Your Understanding 133 CHAPTER 6

Setting the Stage 135

Horizontal Integration Scenario 135 Reference Architecture for the Horizontal Integration Scenario 136 Implementation of the Horizontal Integration Scenario 143 PART III

Conclusion

CHAPTER 7

Final Thoughts and Outlook 183

Bibliography 185 Index 191

ÂŠ T H E A U T H O R A N D S T U D E N T L I T T E R AT U R

CHAPTER 3

Supporting Concepts

So far, several important definitions have been introduced and discussed. Among these are the ones of CPPS (Definition 2.2), CPPM (Definition 2.3), Module (Definition 2.5) and the ones related to requirements (Adaptability, Convertibility, Integrability, etc. in Tables 2.2 to 2.9). There are other concepts that have been recurrently used, for example when referring to CPPMs one has often referred to its cyber and physical parts without providing any further details. System, Production System and CPPS have also been interchangeably and informally used. The concept of interface, which is quite central to the discussion, also requires a more formal description. Finally, there are a few concepts that we have not mentioned yet. All of these need a more accurate definition now, before things get more technical. They are essential before moving to the next chapters. However, many others will be discussed therein when required.

System The notion of system is central for the entire discussion in this text. There are many definitions of system and in the present context one shall consider that a system is [25]: Definition 3.1 System â&#x20AC;&#x201D; combination of interacting elements organized to achieve one or more stated purposes.

System Element From the previous definition a system has elements and elements can be [59]: Definition 3.2 System Element â&#x20AC;&#x201D; (an) atomic (i.e. not further decomposed) (component of a system) , or (it) can be (a) system in its own

ÂŠ T H E A U T H O R A N D S T U D E N T L I T T E R AT U R

part i design principles

merit (i.e. decomposed into further subordinated system elements). Furthermore, the integration of the system elements must establish the relationship between the effects that organizing the elements has on their interactions and how these effects enable the system to achieve its purpose.

Structural Relationships between Elements Elements in a system can be structurally related in different ways. Some are stronger than others. The definition of these relationships is quite common in software and three main types of structural relations are considered: Definition 3.3 Association — is a weak form of relation. It simply states that one element is related to another in some way. Definition 3.4 Aggregation — an aggregation reflects a “has a” relation. Here there it is much more obvious that a part and whole relationship exists. The part, however, is relatively independent from the whole. Even if it works together with it and the whole cannot operate without the part, if the whole is disaggregated the part continues to exist. Definition 3.5 Composition — denotes a very strong “has a” relation whereby parts do not have an existence outside the control of the whole. Therefore, the destruction of the whole implies the destruction of the part.

Operational Environment An engineered system normally operates in a given environment. The operational environment of a system can be defined as : Definition 3.6 Operational Environment — the environment in which systems are deployed. The problem or opportunity in response to which the system has been developed, exists in this environment ¹. 1 Operational Environment (glossary). (2018, October 16). SEBoK, . Retrieved 11:45, May 27, 2019 from https://www.sebokwiki.org/w/index.php?title=Operational_Environment_ (glossary)&oldid=54715.

3 supporting concepts

All elements that do not belong to the system but interact with it are part of the operational environment. From them it is only important to understand how they interact with the system and nothing else.

System Boundary The fact that there is a System and its Operational environment means that there is a system boundary. Definition 3.7 A System Boundary — is a “line of demarcation” between the system itself and its greater context. (...) It defines what belongs to the system and what does not. The system boundary is not be confused with the subset of elements that interact with the environment. (...) The positioning of the system boundary is one that serves uniquely design and analysis purposes and may vary for the same universe [59].

System Attribute Definition 3.8 System Attribute — an observable characteristic or property of the system. (...) Attributes are represented symbolically by variables. (...) Every variable has a domain which could be but is not necessarily measurable [59].

System State Definition 3.9 System State — a system is in a state when all the values assigned to its attributes remain constant or steady for a meaningful period of time [27].

System of Systems Definition 3.10 System of Systems — is a system whose elements are managerially and/or operationally independent systems. These interoperating and/or integrated collections of constituent system usually produce results unachievable by the individual systems alone. Because a system of systems is itself a system, the system engineer may choose to whether address it as either a system or a system of systems, depending on which perspective is better suited to a particular problem [59]. Here it is important to consider the structural relationships defined before. A system that has stronger composition relation to its elements

part i design principles

would probably classify less as a system of systems. The degree of independence conveyed by the system of systems definition suggests that elements in a system of systems either associate or aggregate.

Interface Definition 3.11 Interface — is a shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics [10]. Definition 3.12 Interface — a hardware or software component that connects two or more other components for the purpose of passing information from one to the other. [10].

Production System Definition 3.13 Production System — a system that incorporates a factory and its physical and logical components (including equipment and tools but also other system elements such as IT systems and computing devices that exert a direct control over the processes within that factory) as well as local human actors. All processes and equipment that are not within the factory or exert direct control over it belong to the operational environment of the factory.

Asset Definition 3.14 Asset — is an entity which is owned by or under the custodial duties of an organization, having either a perceived or actual value to the organization [40].

Emergence The definition of system of systems considered before explicitly mentions that integrated collections of constituent system usually produce results unachievable by the individual systems alone. This effect is commonly referred to as emergent behaviour. The notions of emergence and selforganization, defined next, are central to the design of CPPS and for that reason they will have a bit of a disproportionally larger treatment in comparison to the other concepts in this chapter. The term emergence is attributed to G. H Lewes when studying chemical reactions. Lewes 56

3 supporting concepts

observed that some components could be hardly traced back to the expected chemical interactions and devised the concepts of resultant and emergent. Lewes observed [21] the “although each effect is the resultant of its components, we cannot always trace the steps of the process, so as to see in the product the mode of operation of each factor. In the latter case, I propose to call the effect an emergent. It arises out of the combined agencies, but in a form which does not display the agents in action (...) Every resultant is either a sum or a difference of the co-operant forces (...) is clearly traceable in its components (...) the emergent (...) cannot be reduced either to their sum or their difference”. Emergence as a concept seems therefore very closely linked to the observer and the nature of the observations. The discussion around the concept can get quite philosophical as on the one hand, assuming that the whole is bigger than the sum of the parts, if literally interpreted, leads to the conclusion that it may be possible to get “something out of nothing” which is, to date, a physical impossibility; on the other hand people have natural cognitive limitations that prevent them from understanding extremely complex causality flows. That is the reason why one creates models, simulators and even the concept of system (Definition 3.1). Ignorance is not an excuse for emergence but, having considered that, emergent phenomena often have the following characteristics [2]: • Radical novelty: emergents have features that are not previously observed in the complex system under observation. This novelty is the source of the claim that features of emergents are neither predictable nor deducible from lower or micro level components. In other words, radically novel emergents are not able to be anticipated in their full richness before they actually show themselves. • Coherence or correlation: emergents appear as integrated wholes that tend to maintain some sense of identity over time. This coherence spans and correlates the separate lower-level components into a higher-level unity. • Global or macro level: since coherence represents a correlation that spans separate components, the locus of emergent phenomena occurs at a global or macro level, in contrast to the micro level locus of their components. Observation of emergents, therefore, is of their behaviour on this macro level. • Dynamical: emergent phenomena are not pre-given wholes but arise as a complex system evolves over time. As a dynamical construct, emergence is associated with the arising of new attractors in dynamical systems (i.e. bifurcation).

part i design principles

• Ostensive: emergents are recognized by showing themselves, i.e., they are ostensively recognized. (...) Because of the nature of complex systems, each ostensive showing of emergent phenomena will be different to some degree from previous ones. From the previous enumeration it is important to highlight the macro level effect. Emergence can only be considered as such if the emergent attributes depend somehow on a certain mix of elements and their behaviours. The behaviour of the system cannot be predicted from the laws satisfied by these elements individually. That means that the scale of observation matters for the identification of micro-macro correlations [7].

Self-organization The notion of self-organization is closely related to the notion of emergence. There are multiple ways of defining self-organization and, as in the case of emergence, one is not looking here for the ultimate definition but rather for the intuitive notion that is useful to the understand the design of CPPSs. A few definitions include [14]: • Self-organizing systems usually exhibit what appears to be spontaneous order. • Self-organization can be viewed as a system’s incessant attempts to organize itself into ever more complex structures, even in the face of the incessant forces of dissolution described by the second law of thermodynamics. • The overall system state of a self-organizing system is an emergent property of the system. • Interconnected system components become organized in a productive and meaningful way based on local information. • Complex systems can self-organize. • The self-organization process works near the edge of chaos. Self-organization is an interesting feature in engineered systems since it can make them more resilient and robust to faults and failures. Unlike emergence, self-organization normally requires a more explicit interaction between the system components through some interface. There are generally many different ways of attaining so including but not limited to [55]: 58

3 supporting concepts

• Direct interactions: are mainly considered with peer to peer interactions and associated information broadcast that is believed to be sufficient so that local computations at element level lead to a global coherent state. This sort of self-organization tends to privilege the system’s structural organization. • Stigmergy: is based in indirect interaction. The main actions occur as a response to environmental change. It is the form of organization normally attributed to social insects. The overall effect is in principle less predictable than in the former case. • Reinforcement: mainly relates to the element’s ability of learning from previous actions. It is normally associated with a scoring system where distinct elements may tend to specialize in order to increase their score. • Cooperation: privileges self-organization through the implementation of explicit cooperation mechanisms regardless the altruistic or selfish nature of the system elements involved. While emergence closely relates to “surprise” attributes of a system, self-organization can actually be perceived as a potential design construct. The system is designed such that its components, using a known mechanism, steer the whole to a state or through a set of states.

System Architecture In order to systematically create systems, one needs a set of guidelines. Such set is called the System Architecture. Definition 3.15 System Architecture — an abstract description of the entities of a system and the relationships between those entities [11]. A system architecture provides guidelines for designing a system in a way that is both systematic and leads to a result whereby the system fulfils its intended goals. The system architecture captures the system’s primary functions that have immediate value and other lifelong properties that have life cycle value: durability, maintainability, flexibility, robustness, adaptability, safety, security, scalability, extensibility, etc. Therefore, it fulfills many different functions [11]: • It is a way to understand complex systems – by defining the system creation rules and influencing the operating and failure modes.

part i design principles

• It is a way to design complex systems - by defining the elements of a system, their interactions and assessing conflicts and the element’s coupling degree. • It is a way to design standards and protocols to guide the evolution of long-lived systems – by stabilizing the system’s way of working. • It is a way to manage complex systems – by making sure that the different stakeholders have the adequate view over a system. The system architecture is therefore a crucial document throughout the life cycle of any given system. As a mean do describe the elements within a system and their relationships, the architecture can model a more, or less, modular solution [11].

Modular Architecture Definition 3.16 Modular Architecture — (...) consists of modules, each with one or few distinct functions, connected to each other with a few simple, well-defined interfaces. In the ideal limiting case, all the interactions between the modules occur over these predefined interfaces, and all system behaviour is encompassed by module behaviour and interactions across the defined interfaces [11].

Integral Architecture Definition 3.17 Integral Architecture — (...) contains modules that perform multiple functions and interact over many interfaces (...) in some limiting cases, there are no discernable modules [11]. Even if modules can potentially be considered in both modular and integral solutions, in integral solutions, the modules are heavily composed into the system to the point where they are not discernible any more as modules. This is in striking opposition to the more aggregation-oriented view of modular architectures.

Top-down Design Architectures can generally be designed in a top-down fashion following a reductionist approach by starting from the higher level and fully specified requirements and progressively decomposing them into basic requirements that can be directly address by a specific function, entity or device [11]. 60

3 supporting concepts

Bottom-up Design Architectures can alternatively be designed in a bottom-up way when the requirements emerge over time. This is a typical design for experimental projects and normally implies a considerable amount of trial and error [11].

ÂŠ T H E A U T H O R A N D S T U D E N T L I T T E R AT U R

Luis Ribeiro, Docent, PhD, is an Associate Professor in Manufacturing Engineering with Specialization in Industrial Cyber-Physical Systems at LinkĂśping University. Luis has been in many national and international research efforts which, among others, have laid the foundation for what is now understood as the Fourth Industrial Revolution.

SYSTEM DESIGN AND IMPLEMENTATION PRINCIPLES FOR INDUSTRY 4.0 DEVELOPMENT OF CYBER-PHYSICAL PRODUCTION SYSTEMS

This book narrows down the ever expanding domain of the Fourth Industrial Revolution and concentrates in Production Systems. It focuses in control and execution aspects. The reader will learn about design and implementation of production systems that are cyber-physically formulated. These are modular and each component is autonomous within its design purposes. The overall result is an highly resilient and scalable system where constant change is part of the systemâ&#x20AC;&#x2122;s operations. The book is divided in two parts. The first contains the theoretical basics of Cyber-Physical Productions Systems. The second provides a simple but illustrative programming exercise that will lead the reader in creating a prototype implementation of the cyber part of Cyber-Physical Production System. The book is accessible to everyone with a genuine interest in this emerging area. Readers with an engineering background will find it easier to understand as the book targets mainly Mechanical, Production and Automation Engineers but also Computer Scientists with an interest in developing industrial software solutions.

Art. No 43019

studentlitteratur.se