AutomationML: A Practical Guide (de Gruyter Textbook) 3110746220, 9783110746228

Citation preview

AutomationML

De Gruyter Textbook

AutomationML A Practical Guide Edited by Rainer Drath

ISBN 9783110746228 e-ISBN (PDF) 9783110746235 e-ISBN (EPUB) 9783110746594 Bibliographic information published by the Deutsche Nationalbibliothek The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available on the Internet at http://dnb.dnb.de. © 2021 Walter de Gruyter GmbH, Berlin/Boston

Contents Foreword by Prof. Dr. Alexander Fay Foreword by Andreas Graf Gatterburg Acknowledgement by Prof. Dr. Rainer Drath

Rainer Drath, Pascal Habiger Chapter 1 What is AutomationML? 1 What is AutomationML? 1.1 Introduction and Motivation 1.2 Why AutomationML was developed 1.3 Challenges for a neutral data format 1.4 What is AutomationML? 1.5 Encoding information with AML – four layers of abstraction 1.6 Exclusions 1.7 AutomationML Specifications 1.8 The AutomationML association 1.9 References for Chapter 1

Rainer Drath Chapter 2 CAEX and AutomationML Guide 2 The CAEX and AutomationML guide 2.1 AutomationML architecture and modelling philosophy 2.2 The CAEX 3.0 guide 2.3 AutomationML Edition 2 versus CAEX 3.0

2.4 AutomationML base libraries 2.5 Referencing external documents 2.6 Extended AutomationML Concepts 2.7 Best practice recommendations for AML modelling 2.8 Conclusion and summary 2.9 References for Chapter 2

Rainer Drath, Steffen Lips Chapter 3 Modelling of Geometry and Kinematics 3 Modelling of Geometry and Kinematics 3.1 Introduction 3.2 Modelling of geometry and kinematics with COLLADA 3.3 Examples 3.4 Interlinking COLLADA and CAEX 3.5 Summary 3.6 References for Chapter 3

Arndt Lüder, Nicole Schmidt, Rainer Drath Chapter 4 Modelling of Behaviour 4 Modelling of Behaviour 4.1 Introduction and Motivation 4.2 AutomationML approach for representing behaviour models 4.3 How to reference external behaviour models 4.4 How to model behaviour with IEC 61131-10 4.5 Example 4.6 Modelling of complex behaviour or protected models via FMU

4.7 Discussion and Conclusion 4.8 References for Chapter 4

Lorenz Hundt, Josef Prinz, Rainer Drath Chapter 5 The AutomationML Editor 5 The AutomationML Editor 5.1 Introduction 5.2 Purpose of Usage 5.3 User Interface 5.4 Editing Functions 5.5 Extended Functionality 5.6 Customization of the AutomationML Editor 5.7 How to send Feedback 5.8 Summary 5.9 References for Chapter 5 Abbreviations Biographies About the Editor About the Co-Authors Trademarks Index

Rainer Drath (Ed.) AutomationML

Also of interest

AutomationML The Industrial Cookbook Edited by Rainer Drath, 2021 ISBN 978-3-11-074592-4, e-ISBN (PDF) 978-3-11-074597-9, e-ISBN (EPUB) 978-3-11-074619-8

Robotic Process Automation

Management, Technology, Applications Edited by Christian Czarnecki, Peter Fettke, 2021 ISBN 978-3-11-067668-6, e-ISBN (PDF) 978-3-11-067669-3, e-ISBN (EPUB) 978-3-11-067677-8

Algorithms Design and Analysis Sushil C. Dimri , Preeti Malik,Mangey Ram, 2021 ISBN 978-3-11-069341-6, e-ISBN (PDF) 978-3-11-067669-3, e-ISBN (EPUB) 978-3-11-067677-8

De Gruyter Series on the Applications of Mathematics in Engineering and Information Sciences Edited by Mangey Ram ISSN 2626-5427, e-ISSN 2626-5435

Editor Prof. Dr. Rainer Drath Pforzheim University of Applied Sciences Institute of Smart Systems and Services Faculty of Technology Tiefenbronner Str. 65 75175 Pforzheim Germany [email protected] ISBN 978-3-11-074622-8 e-ISBN (PDF) 978-3-11-074623-5 e-ISBN (EPUB) 978-3-11-074659-4 Library of Congress Control Number: 2021936234 Bibliographic information published by the Deutsche Nationalbibliothek The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available on the Internet at →http://dnb.dnb.de. © 2021 Walter de Gruyter GmbH, Berlin/Boston Cover image: Rainer Drath, AutomationML e. V.

→www.degruyter.com

Foreword by Prof. Dr. Alexander Fay Almost twenty years ago, the idea of an object-oriented, manufacturer-neutral, computer-readable description of industrial plants was first presented: CAEX, short for Computer Aided Engineering eXchange1. In a world of document-oriented engineering tools, this opened up the possibility of loss-free information exchange. Soon afterwards, when internationally standardized in IEC 62424, the concept of a system model structured hierarchically with objects found more and more supporters. CAEX enables both requirements and solutions for engineering tasks to be linked to the plant objects. CAEX is more than just an XML-based exchange format for engineering data: CAEX can support the engineering workflow consistently and connect previously separate software tools and engineering tasks during the planning, implementation and operation of industrial plants. Because of these strengths, CAEX was chosen to be the backbone of AutomationML. By integrating further description means, such as COLLADA for geometries and PLCopen XML for process descriptions and control programs, AutomationML enables the linking of all planning and operational information to the assets of a system. AutomationML, thus, provides what is necessary to build a digital twin of an industrial plant. Thereby, AutomationML offers a multitude of application areas: in addition to modelling of industrial plants, it has been applied to model different technical systems such as communication systems, building automation systems, energy supply and

distribution networks, but also various kinds of diagrams. In fact, everything which can be structured into objects and links (of whatever type) between them can be modelled with AutomationML and, thus, be transferred to other software tools for further information processing. To this day, more than 2,000 publications from industry and academia report the capabilities and advantages of AutomationML. A lot of considerations and experiences from practical applications have contributed to the development of AutomationML, which now is available in Edition 2 and further improves the modelling capabilities and reduces the modelling effort. Therefore, it is the right time now for this book, to introduce these advantages to a wider audience. Though the basic principles of AutomationML are easy to grasp, a more detailed study of the topic is necessary to fully benefit from the advantages of AutomationML. This book is ideal reading both for the AutomationML beginner, who will be introduced gently to the main concepts, as well as the AutomationML expert, who will find valuable modelling techniques. AutomationML can significantly simplify information exchange between software tools throughout the entire life cycle of a plant, for the benefit of engineering service providers, plant constructors, plant operators and manufacturers. This book is highly recommended to all who want to know how they can participate in this development. Prof. Dr.-Ing. Alexander Fay , Hamburg, November 2020 Helmut Schmidt University, Hamburg

Foreword by Andreas Graf Gatterburg The AutomationML Initiative was founded in 2006, initiated by Daimler AG. It was intended to generate a neutral data format for engineering data exchange, but a group of pioneers from different companies and universities foresaw the opportunities of data digitalization in the manufacturing industry and developed a data format that is a full-fledged modelling language. Today, 14 years later, AutomationML is a well-known and accepted technology and already established in industry. The basic motive of AutomationML is cost savings. Cost-saving is always on the mind of the customer of industrial automation. In our highly developed economies, the cost of skilled labour is most of the time far more significant than material or equipment cost. Nevertheless, all too often engineers are confronted with a situation where they have no possibility to reuse the results of their fellows. A lack of open interconnection between engineers in an automation project leads to exploding costs. Caused by a fragmented documentation and tool landscape, this complex is the cause of many a failed project and hampers the growth of future markets in automation significantly. The story we tell in this book is a different one. It is the story of how openness can make your work better. When the first book on AutomationML was published a decade ago, AutomationML was considered, even by its inventors, to be nothing but a file format for data exchange in engineering tool chains. It is this still, and an increasingly successful one at that. But, over the years, AutomationML has become more. It has

become an information modelling language for automation engineering. AutomationML has, through the tireless work of a committed community, become a host to one of the most extensive pools of engineering models in the industry today. For industrial companies, the usage of AutomationML has proven to be doubly beneficial. Not only can the application of AutomationML help diminish data loss and resulting incompatibilities in engineering tool chains, but it was also proven that modelling information in AutomationML is a futureproof approach to support the digitalization of plants, products and portfolios. If, as a reader, you now wonder if the claims laid down in this preface can possibly be true, I cordially invite you to make your own assessment. In this book, you find the current state of the art for AutomationML to the best of the knowledge of global experts for the technology. The AutomationML e.V. as the caretaker for the AutomationML technology would also like to invite you to engage with us and give us feedback on your thoughts about what you will read in this book. And, maybe, to join us in the future journey of the AutomationML technology. Dr.-Ing. Andreas Graf Gatterburg, Hattersheim, November 2020 First Chairman of the Board of AutomationML e.V.

Acknowledgement by Prof. Dr. Rainer Drath This book was written in the second half of 2020. Ten years ago, AutomationML was a promising technology. Today AutomationML is a solution and offers more functionality and more solutions than is generally known. The time is ripe for a textbook that explains the features and possibilities offered by AutomationML's Edition 2 and its hidden capabilities. While structuring this book project, the amount of material on Automation fundamentals and industry applications resulted in two books: first the present introduction into AutomationML principles and second a book for advanced users AutomationML – The Industrial Cookbook published by the same publisher. This book provides researchers and industry partners a comprehensive in-depth look into the basics of AutomationML. It is remarkable that CAEX and AutomationML, even without any textbook so far, has surprisingly quickly found its way into the academic and industrial world. This book is intended to support this in greater depth. This book was supported by valuable discussions with many AML experts and their contributions. I would like to take this opportunity to thank sincerely to Steffen Lips for his feedback in the geometry/kinematics modelling, to Nicole Schmidt and Arndt Lüder for the continuous tuning of the behaviour chapter, to Josef Prinz and Lorenz Hundt for the development, support and documentation of the AutomationML Editor, and to Pascal

Habiger for manifold contributions to this book. And I want to thank Ronald Rosendahl for fruitful discussions about various perspectives of explaining AutomationML. It was a pleasure for me to formulate, collect, illustrate and compile all the topics and aspects of CAEX and AutomationML into a comprehensive book for the international scientific and industrial audience. A special thanks goes to the mental and scientific roots of CAEX, Prof. Fay and Prof. Epple, who recognized the urgent topic of data exchange between engineering phases 20 years ago and initialized the CAEX development. It was my pleasure to drive the CAEX development starting 2001 together with Prof. Epple until its international standardization in 2006. In 2009, CAEX was adopted by the AutomationML association. I would also like to thank the head of the AutomationML office, Sven Schwirblat, for his support, and Carl Schumaker from Rockwell Automation in particular for his engaged support in smoothing the English language of this book. Last but not least, I want to express my personal thanks to my wife Nicole Freitag, who, as an external reviewer, has also enriched the book with many valuable suggestions, and to my little son Jonathan, who is always a great source of inspiration. Prof. Dr.-Ing. Rainer Drath, Kuppenheim, March 2021 Pforzheim University of Applied Sciences

Chapter 1  What is AutomationML? Motivation, goals, innovations, and values of AutomationML Rainer Drath Pascal Habiger Content 1 What is AutomationML? — 3 1.1 Introduction and Motivation — 3 1.1.1 About this book — 3 1.1.2 Reading guidance — 4 1.2 Why AutomationML was developed — 5 1.3 Challenges for a neutral data format — 8 1.3.1 Approaches for engineering data exchange — 8 1.3.2 Iteration support: hidden but important and difficult — 13 1.3.3 Management of heterogeneous semantics — 15 1.3.4 Standardization deadlocks — 17 1.4 What is AutomationML? — 19 1.4.1 Overview — 19 1.4.2 Goals of AutomationML — 20 1.4.3 Key innovations in AutomationML — 22 1.4.4 Values of AutomationML — 24 1.5 Encoding information with AML – four layers of abstraction — 27 1.5.1 Data model versus information model — 27

1.5.2 The four-layer model of information encoding — 28 1.5.3 AutomationML in the four-layers model — 31 1.6 Exclusions — 31 1.7 AutomationML Specifications — 32 1.7.1 AutomationML IEC 62714 Series — 32 1.7.2 Whitepapers — 35 1.7.3 Application Recommendations — 35 1.7.4 Best practice recommendations — 36 1.7.5 Availability — 36 1.8 The AutomationML association — 37 1.8.1 Initiators and members — 37 1.8.2 Possibilities of participation — 38 1.9 References for Chapter 1 — 39

1  What is AutomationML? 1.1  Introduction and Motivation 1.1.1  About this book In 2018, AutomationML2 took a new step in its life cycle: the second edition of the AML architecture was released and published as international IEC standard. In parallel, a series of industrial technology trends gained momentum in industry: cloud technology, digitalization, the introduction of internet technologies into production, and a growing software mindset have been established in almost all industrial sectors. This is a fruitful ground for software innovations. AutomationML stands for digitization of engineering data and engineering work-flows. It combines the power of XML, object-orientation and semantics and achieves both human readability and machine-readability. It pursues the exchange of comprehensive electronic data models instead of printed diagrams. It enables seamless data flow in complex engineering tool chains across industrial domains. It is a method for transforming data into valuable information and it in timeless ASCII files or data streams for data exchange, and it supports the special needs of iterative data exchange. During the last decade, AutomationML has transformed its perception from a file format into an object-oriented data modelling language; it allows for modelling domain models as libraries and for the digitalization of industrial standards as electronic information models. This book is a practical guide to AutomationML and the official CAEX and AutomationML textbook from the

AutomationML society. It is the successor of the first AutomationML book [DRA10] and introduces the latest AutomationML Edition 2 an XML based data format that was published as an international standard in 2018 as IEC 62714. The new Edition 2 supports the latest CAEX 3.0 that incorporated a variety of industrial feedback and significantly simplifies modelling of machine-readable content. Machine readable information models are a valuable source of innovation. Having machine readable domain models and concrete engineering data makes the data accessible and interpretable for software. This enables a plethora of opportunities: apps can run through the data models and can generate value: for instance, by checking consistency and quality, generating control code or human machine interfaces, searching for correct information or energy flow in the cabling, searching for correct material flow in the piping etc. It is all available with AutomationML topology models. From the beginning, AutomationML was a technology that combines industrial automation and IT. Automation devices become increasingly intelligent, but automation components alone are mostly useless: in order to gain their value, they must be engineered and configured to work properly. This requires programming, configuration and planning. It is engineering that transforms automation devices into valuable and intelligent assets; but engineering is expensive, error prone and usually requires the involvement of many professions and sub suppliers, an immense source of productivity and errors at the same time. The competitiveness of vendors of automation components or automation systems will increasingly depend on the ability to simplify their engineering. This is a software and systems engineering methods topic which is and will be an increasingly important key differentiator.

AutomationML is a powerful vehicle for achieving seamless engineering tool chains or networks and a connection point for many hotspot technologies; for example, eClass, the Asset Administration Shell, cloud computing and artificial intelligence. The focus of the AutomationML society has been extended from the AutomationML technology itself towards methods for integrating more and more aspects of engineering by integrating standards such as eClass or FDI into AutomationML; for being a valuable source, transport medium or target of engineering value chains; for the methodology of its application; and for the development of comprehensive and industry proven best practice and application recommendations. But these advanced topics are part of the second book AutomationML – an industrial cookbook published by the same publisher. 1.1.2  Reading guidance This book is a guide through the universe of AutomationML. It spotlights AutomationML from different perspectives and is written for beginners and experts, for software developers, managers, students, teachers, professors and end users. It starts with an introduction into the philosophy behind AutomationML, its core innovations, goals and values. It contains a AutomationML textbook for teachers and students and explains all the details of the object modelling language. AutomationML comprises some widely unknown innovations and it is time to give a spotlight to them. To be more precise: – This book is written for students, teachers and professors in colleges and universities. – This book is written for researchers and PhD students: AutomationML encourages the application and development of new methods and approaches that cannot

(yet) be realized with today's tools. AutomationML offers material for diploma, bachelor, master and doctoral theses and can contribute to the transfer of new technologies such as “Semantic Web”, “Automation of Automation”, “cloud-based data hubs”, “semantic integration” and “data integration” to industry. Already in early stages of AutomationML, the literature shows promising approaches; see for example [RGF09], [GKF+09], [GWF08], [MND+09], [REDR09], [KRST09] and [WBR+09] and many more. – This book is written for engineers and decision-makers in the process and manufacturing industry who want to address the topic of data exchange between engineering tools or the digitalization of engineering tool chains. – This book is also addressed to computer scientists, who will find many helpful details and examples for the modelling of AutomationML. Chapter 1 is dedicated to the motivation, goals, initiators, innovations, and values of AutomationML. Chapter 2 explains the architecture of AutomationML and provides a detailed guide through the object-oriented modelling principles. Chapter 3 is dedicated to geometry and kinematics. Chapter 4 describes various aspects of modelling behaviour with AutomationML. Chapter 5 introduces the AutomationML Editor as an ideal starting point to learn AutomationML. At the website [BookLink@], most discussed AML example models, software and additional documents can be downloaded in their latest version.

1.2  Why AutomationML was developed

In the office environment, electronic data exchange is an everyday matter of course. When we are asked for a photo, we don’t care about tools, we just send it from our smartphone to friends and family. No matter whether images, texts, web pages, vector graphics or documentations are involved, for a multitude of indispensable cross-platform information, standard data formats have been established. Examples of this are data formats known under the name extensions “jpg”, “pdf”, “mp3”, “rtf”, “tiff”, “bmp”, “html” or “xml”. The reason for this development is obvious: standardized data formats have unbeatable advantages if data exchange represents a significant value of the information. In engineering projects, industry acts vice versa: here we agree on tools and not on data formats. The original value creation was mainly created within the tools, not between the tools. →Fig. 1-1 illustrates a subset of the variety of engineering tools. Why do we have no established data exchange format for engineering data? While a camera app on a smartphone defines its value directly from the exchange of photos, this is different with engineering tools. Whether CAD, simulation or functional engineering, the efficiency of the related engineering activities with software tools is way better than without the tools. For collaboration between engineering partners, the harmonization of the tools promised an elegant way for seamless engineering. But this is changing. As →Fig. 1-1 illustrates, the variety of engineering tools is immense. When a small engineering company is requested to use a predefined set of engineering tools, and the engineering company is working for multiple customers, there is an explosion in license costs for the engineering tools together with reduced engineering efficiency and quality.

Fig. 1-1 High complexity due to numerous software tools Consequently, there is a need for providing experts and teams specialized for these tools, leading to a gap in re-usability of solutions between those tools. Who is paying the bill?

Today, the functionality of engineering tools is matured and converging. Under growing cost [FAY06] and time pressure in engineering, the value of data exchange is now rising into focus [RHA02]. Key drivers are: – The engineering of manufacturing and process plants is a cost-intensive and complex process. The increased availability of low-cost sensors, internet-based communication technology, cloud platforms and knowhow will significantly increase the density of information in plants and thus the need for the meaningful engineering of this information. Efficient data exchange is a key ingredient for future competitiveness. – Engineering requires the cooperation of a variety of professional groups which use specialized software tools. – Engineering is characterized by a historically grown strong division of labour and is divided into separate phases or trades in the past. In each of these phases, engineers continue to change engineering data. While doing so, the data across all different tools diverge, engineering data is subject to continuous and iterative enrichment and change in the course of engineering. This is not a mistake in the workflow or engineering methodology, it is the nature of engineering. A significant effort is required in order to keep the data synchronized and consistent across the engineering tools. – Engineering efficiency benefits from reuse. Often plants are not completely redesigned. Instead, prepared standard plants or sub-systems are used as blueprints to plan a plant to produce a specific product, for example the body shell of a vehicle model. The reuse of plant data in different versions and configurations is therefore a very

important requirement and an essential prerequisite for efficient engineering. Summary Data exchange between the phases of plant engineering is key for reuse, quality and consistency of engineering data. It reduces development cost and time, eases maintenance and comparability.

1.3  Challenges for a neutral data format 1.3.1  Approaches for engineering data exchange The key challenge of engineering tool chains is the synchronization of continuously changing, multimodal, interdisciplinary, cross-company and process spanning engineering information immanent to state-of-the-art engineering processes. The flow of information is a result of these processes and manifested in complex workflows. These workflows require a comprehensive tool landscape that usually is of heterogeneous nature (from different vendors). Unfortunately, engineering tools are specialized for their own functionality and are not designed to synchronize their data among each other. Even though we all share our documents via Microsoft Office or PDF documents in the office world, automation engineering does not have a file format for exchanging information. There are different options to solve this issue [DGE05], [DRBA11], [DRBA12]. 1.3.1.1  Option 1: Harmonization of engineering tools

In this option, engineering suppliers are not free to choose their best-of-class tools but are contractually obliged to use certain engineering tools defined by the system integrator or plant owner (see →Fig. 1-2).

Fig. 1-2 Tool centric engineering This approach has many advantages: it elegantly solves the issue of tool incompatibility and lossless handover of engineering results to customers and is therefore widely established in manufacturing industry. The drawback of this approach is that such agreement on tools makes it difficult for sub-suppliers to be efficient. This is due to the fact that the reuse of proven solutions or libraries between projects as well of reusing toolexperts across different projects gets almost impossible in a multi-project and multi-customer environment. Finally, engineering companies have to pay for costly software tool licenses, experts and libraries. A second drawback is that this approach still does not solve the data synchronization between the different tools, for instance the comparison of signal lists between PLC and robot programming.

1.3.1.2  Option 2: Simple file-based data exchange In this option, each engineering supplier uses its preferred bestin-class engineering tools, and the data exchange between tools is file-based (→Fig. 1-3). This option overcomes the drawbacks of option 1. It is easy applicable because the development of some EXCEL templates, CSV files or XML schemas is a quick solution for data exchange. Therefore, this option is widely established in industry because of its simplicity to interconnect the typical heterogeneous tool landscape.

Fig. 1-3 File-based data exchange The drawbacks of this option are missing iteration support (see →section 1.3.2), the high number of required software exporters and importers and a large variety of proprietary file formats that are typically changing from project to project or even within a project. For each additional engineering tool, the number of

required data exchange interfaces and data formats grows considerably through combinatoric effects. This finally leads to version complexity for software interfaces, data formats and versions of the same data format, and high development and maintenance cost. This approach is widely used for small and mid-size projects, but not recommendable for large scale projects. 1.3.1.3  Option 3: Common tool suite In this approach (→Fig. 1-4), an engineering tool vendor provides a one-stop-shop for engineering: all needed engineering tools are provided as a common tool suite from a single vendor working on the same database. This elegantly solves the problem of data synchronization between all participating tools, including iteration support. The number of software interfaces is limited, and engineering suppliers can seamlessly integrate their data in collaboration with others.

Fig. 1-4 One common tool suite

The key drawback of this option is that users of this tool suite are immediately bound to the tool vendor including its innovation speed and license conditions. There is usually no option to select and integrated other best-in-class tools. In a multi-project and multi-customer environment, reuse of proven solutions or libraries between projects as well of reusing tool-experts across different projects becomes almost impossible. The engineering suppliers have to pay multiple times for costly requested software tool licenses, specialized experts and tool dependent libraries. This option is suited for large projects such as power plants or oil-platforms, but rarely suited for small or mid-size projects in industry. 1.3.1.4  Option 4: Data exchange with harmonized data models In this option (see →Fig. 1-5), all participants of a toolchain (for example the engineering suppliers and the system integrator) keep their individual best-in-class engineering tools with individual proprietary databases. But beside this, the participants develop a common homogeneous data model which serves as an intermediate data model for the data to be exchanged. A common data hub implements the agreed common data model, for example developed by a third-party software vendor. The exchange is realized using a service bus or file-exchange. This option is recommended for centralized data infrastructures and requires significant harmonization efforts for creating a common data model. How to achieve this is explained in [DRA21] (Chapter 20 Industrialization and Toolchain and Chapter 21 AutomationML governance at Daimler AG). With rising number of peers to be integrated in an exchange process, the complexity of the semantic harmonization, versioning and the

model itself requires appropriate governance. This problem is well known under the term “building a world model”. Powerful version management for the data model versions is required and the innovation speed of each single software vendor is bound to the speed of the semantic harmonization. In this option, AutomationML’s usage as an intermediate data exchange format can be extended to contain the common, intermediate data model.

Fig. 1-5 Semi-centralistic approach with harmonized data model 1.3.1.5  Option 5: Data exchange via alignment of heterogeneous data models In this option, as in the previous one, the participants (for example engineering suppliers and the system integrator) keep their individual preferred best-in-class engineering tools with individual proprietary databases. The difference with the previous option is that each participant shares the data that is of

interest for exchange but without first performing a semantic harmonization by creating a common data model (→Fig. 1-6). The challenge in this option is: how to achieve semantic alignment between these unharmonized heterogeneous data models without the effort of generating a common harmonized data model? A solution methodology including pragmatic interoperability or usage alignments is described by ABB in the Industrial Cookbook [DRA21] Chapter 23 Semantic and Pragmatic Interoperability Mappings. It requires firstly a machine-readable data model that can hold the different semantics in a syntactically standardized way. This makes the individual data models in the data hub machine readable even without semantics. For machine interpretability, a powerful mapping functionality is required. This mapping is a separate step that can evolve over time while individual tool data models and software interfaces remain unchanged. A data hub additionally provides authentication, up- and downloads, subscriptions, version management and synchronization features. The harmonization of an engineering world model is not needed. This option overcomes most of the previously mentioned difficulties. It is conceptually a highly promising approach for distributed data infrastructures with many participants and a prediction of upcoming Industry 4.0 engineering infrastructures based on asset administration shells. Here, AML’s usage can be extended to its usage as an information (and knowledge) exchange format based on semantic (and pragmatic) interoperability alignments.

Fig. 1-6 Semi-centralistic heterogeneous approach Summary Data exchange between engineering tools is achieved with different options, although these have limitations in terms of applicability, iteration support and versioning management. Except the tool suite, all other options require comprehensive data models and file-based dataexchange. 1.3.2  Iteration support: hidden but important and difficult Developing a new file format for the simple file-based data exchange (see option 2 in →section 1.3.1.2) in engineering seems to be easy: just model what is needed and go for it. While

using EXCEL or XML, comprehensive tool support and established expertise promises quick results. This is why a lot of file formats are developed in industry, but by nature, those file formats are mostly of proprietary nature and may change from company to company, from project to project, and may even evolve within a project’s lifecycle. There is a series of strong arguments that support that file-based data exchange is more difficult than expected, and mostly remain in provisional solution status. Industrial practice teaches us that the key problem in the data exchange process is not the one-shot-exchange, but the change management during iterative data exchange. This requires the support of iteration loops on two levels. 1.3.2.1  Iteration loop level 1: Exchange of engineering data Engineering is an iterative process: data exchange between engineering tools does not happen one time only but multiple times. Iterative data exchange typically requires a procedure as illustrated in →Fig. 1-7.

Fig. 1-7 Iterative data exchange in engineering Simple file-based data exchange by using spreadsheets (for example Excel) or hierarchical structures like XML indeed provide powerful and quick means to solve the green elements a), b) and partly c). But they are weak in the red elements: version management, difference calculation and mapping/ import, and blind for the white elements f) and e). The white elements represent further tasks of iterative engineering which are widely not supported by simple file-based data exchange: impact analysis and validity checks. Both tasks require semantic interpretability of the data and knowledge about the relations between incoming and already existing data.

In order to provide solutions for the red elements, further concepts are needed: for the red elements: – In d) the exchange software needs knowledge about the syntax (not semantics) of the data, and it needs access to a historian repository. – In g) it needs comprehensive mapping, version and identification information for each data item in the exchange file and historical versions of the exchanged data. – For g) the software additionally needs knowledge about the meaning (semantics) of the data and of the target tools database. To pre-process the data for the red elements further approaches for the green elements are necessary: – In a) the data exporter should provide guidance to select the data that is relevant for data exchange. – In b) the data exporter should provide a new version of the data with access to a version tracking system. – In c) the exchange software needs knowledge about the structure of the data in order to visualize the data in an appropriate way. – For the white elements e) and f) it needs additional knowledge about how those data are utilized in the target tool. 1.3.2.2  Iteration loop level 2: Data format evolution Beside the iterative exchange of engineering data itself, the data format itself and the underlying domain models are subject of iterative changes (see →Fig. 1-8). While proprietary Excel and

XML solutions are strong in the green steps a-b), they usually fail in the red steps (c-e). To provide solutions for the red elements, further concepts are needed: – In c) the data format needs version information about its own language elements, – In d) the data format should provide version information about each element in the data model, – In e) the data format and data models need a community that maintains the format and models and provides the knowledge and application support to a wide range of experts. For global and standardized engineering world models, the step e) is critical. For companies, this is solvable by a governance organization and harmonization process as reported by the AutomationML society in the Industrial Cookbook [DRA21] (Chapter 20 Industrialization and Toolchain from BMW and in Chapter 21 AutomationML Governance at Daimler AG).

Fig. 1-8 Iterative evolution of the data format and the data model With respect to AutomationML, it fulfils the technical requirements for a professional data exchange which are a standardized syntax, an extensible architecture, a comprehensive support of version and meta information “about the data”, support for modelling the meaning of the data (semantics), and guidance by documentation and reference implementations. Summary

Engineering data exchange formats should provide comprehensive iteration support. This is a key concept in AutomationML. 1.3.3  Management of heterogeneous semantics Unfortunately, the standardization of engineering data exchange formats is complicated by the fact that companies have already developed manifold proprietary data models and data formats. Additionally, they developed proprietary semantics and ways of thinking which are of course directly reflected in their tools. Therefore, the standardization of engineering related data exchange formats is fragmented in many pieces, and even within one domain, many sub data formats have been developed. The multitude of data models is by no means harmonized; the same terms or concepts can have different meanings between different partners. Summary Beside iteration support, the main difficulty of developing an engineering data format or an object modelling language is the management of semantics. The origin idea of a neutral file format - not only XML - is storing data in a lossless and vendor independent way. Wherever such a neutral file comes from, it can be imported (with the use of existing software applications) into almost every engineering tool. This idea is in fact the driving force for all semantic standardization activities regarding a common data model.

The major idea is the definition of a common data model combining the “common concepts” of all participating domains as well as their respective tools. This is why the standardization community widely aims for developing a common semantic engineering world model. The result of semantic standardization would be a library of neutral domain models and a comprehensive dictionary of terms with an agreed meaning. The idea behind this is: when we speak the same language with agreed terms, we can understand each other. If an exporter exports its data in a common data format with agreed semantics, every importer would be able to read and to process it [DRBA12]. Regarding semantics, many activities are directed towards semantic standards, for example [ISO 15926], STEP [ISO 10303], [NE 100], PlantXML [ART04], the Engineering Service Bus [WMZ+10], [DEX12@], [NE 150] or knowledge-based methods as described in [WMM11]. However, no comprehensive engineering standard with a common syntax/ semantic has been achieved yet. A standardization procedure for developing a comprehensive engineering data model would need a series of activities: a. A group of experts for each participating engineering tool or domain must contribute their “own concepts”. b. All participants must agree on “common concepts”. c. A neutral semantic data model must be defined, covering the common concepts, for example in an object model by using UML. d. A neutral syntax of the common data model must be agreed, for example with XML. e. A document must be written which describes the agreed upon common concepts, the semantic data model, the

syntactical implementation, for example, in a standard text or a white paper. f. In industry, sufficient experts must be available who understand the standard to implement it into their respective engineering tools by means of data ex- and importers. g. The industry must provide enough ex- and importer software supporting this standard. h. Experiences from the application feed back into (a). The major problem of this standardization sequence is a weak feedback loop between usage (h) and standardization (a). As history shows, engineering tool vendors wait until the standard reaches a certain level of maturity before they start addressing their software to this standard, for instance by the implementation of corresponding exporters and importers (g). On the other hand, the standardization requires profound industrial experiences (and implementations) to reach a profound level of maturity (h). This is an existing paradox which leads to deadlocks initially described in [DRBA12]. 1.3.4  Standardization deadlocks 1.3.4.1  Standardization deadlock #1 →Fig. 1-9 illustrates a first standardization deadlock. Standardization needs feedback from the users (a). Users themselves need software tools to apply the current version of the standard in order to generate feedback (b). Software vendors cannot effort the costly programming of intermediate versions of standards, they wait for the final version (c). This

results in a deadlock: each party is waiting. This is the reason why semantic standardization is a time-consuming process.

Fig. 1-9 Standardization deadlock #1 1.3.4.2  Standardization deadlock #2 →Fig. 1-10 illustrates a second standardization deadlock: as soon a small semantic standard succeeds and is applied in an ecosystem of engineering tools and is successfully used in industrial practice (a), it immediately loses its innovation power and the standard freezes (b). In case of change requests, the standardization is locked since a change of the standard would immediately break the compatibility to the existing tool ecosystems, would compromise investments, and would destroy the core of a standard: its stability.

Fig. 1-10 Standardization deadlock #2 1.3.4.3  Standardization deadlock #3 A third standardization deadlock which is shown in →Fig. 1-11 appears when we look at the large amount of engineering data that would need to be standardized. Standardization is an activity of years while at the same time the project requirements may change within weeks. There is an obvious incompatibility of the high frequency of short-term needs of industrial projects compared to the low frequency of long term standardization. The deadlock #3 appears when an emerging standard can only be used once it is finalized.

Fig. 1-11 Standardization deadlock #3 Summary Up to now, no data model standardization activity has successfully achieved and established a neutral semantic model for all domains in automation engineering.

1.4  What is AutomationML? 1.4.1  Overview AutomationML was originally developed and explained as a neutral data exchange format for engineering. In the meantime, this explanation has been developed further. AutomationML is a comprehensive XML based object-oriented data modelling language. It addresses the challenges explained in section 0 and allows for modelling, storage and exchange of engineering models covering a multitude of relevant aspects of engineering. AutomationML provides a comprehensive set of flexible mechanisms and innovations to model todays engineering aspects as well as future engineering aspects to come. Its language characteristics allows modelling of existing or new

domain models. →Fig. 1-12 gives an overview of the goals, related innovations and created values of AutomationML. These are discussed in more details in the following sections.

Fig. 1-12 Goals, innovations and values of AutomationML 1.4.2  Goals of AutomationML The main goal of developing AutomationML was to provide a data modelling language for modelling and exchanging heterogeneous semantic engineering data models across heterogeneous engineering tools, that enables lossless data exchange in a software tool chain across all engineering steps. AutomationML enables the electronic modelling of the most

complete description possible of entire plants, including the components contained therein, across all engineering disciplines and phases. This covers complex object hierarchies, for example plant topologies, and creates space for new apps that provide completeness checks, rule-based quality checks, pattern search, error search, generation of control code/user interfaces/interlockings/simulation models and much more. →Fig. 1-13 illustrates the general coverage of AutomationML: the modelling of plant hierarchies, geometry, kinematics, motion planning and behaviour modelling.

Fig. 1-13 Coverage of AutomationML AutomationML needs to pursue a number of further sub-goals in order to achieve its main goal while satisfying these demanding requirements.

G1 – File based data exchange: AutomationML should allow file-based data exchange and provide persistency as prerequisite for data exchange and change management that calculates and visualizes the differences between old and new data. G2 – Evaluable data: In the course of the product life cycle, data and information are usually exchanged in such a way that they can be read by humans, but not by machines or vice versa. AutomationML should provide data and information so that they can be evaluated by both humans and machines as preconditions for algorithmic accessibility. G3 – Overcome standardization deadlocks: AutomationML should overcome the described standardization deadlocks of →section 1.3.3 to ensure closing the recurring gap between standardization and practical use. G4 – Reuse of proven solutions: AutomationML should reuse established solutions wherever possible in order to gain wide acceptance throughout the community of automation engineering without reinventing the wheel. G5 – Reuse of external semantics: AutomationML should be able to reference existing semantic standards to not agreeing on property names and allowing the continued use of company standards. G6 – Integration of existing semantics: AutomationML should be able to integrate existing semantic models that not entirely new un-established semantics have to be developed. The aim should be to instantiate, parameterize or interconnect the data among each other or with other data without changing the standards. G7 – Management of heterogeneous semantics: AutomationML should be able to manage heterogeneous semantics, defined in proprietary and public standards as well as heterogeneous data models to cope with the heterogeneous landscape of engineering data and tools.

G8 – Management of unknown data: A critical point of data exchange is the import of data. During import, the importer needs to identify the relevant items and to import them into the correct place in the target database. To do this, the importer needs to recognize the meaning of objects and attributes. If the meaning of some data is unknown AutomationML should explicitly manage this. G9 – Market acceptance: AutomationML should be accepted in the market and used throughout the community of automation engineering. G10 – Supporting iterative engineering: The reality of engineering requires continuous and iterative enrichment and changes to the subject of engineering as well as its methods. Consequently, not only the instance data but also the underlying engineering model changes. AutomationML should support these iterative engineering adaptions. G11 – Varying specificity: A serious challenge in the specification of an exchange format is the structure and the freedom of variability of the data encoding. AutomationML should offer a solution to cope with varying specificity. 1.4.3  Key innovations in AutomationML

Fig. 1-14 Key innovations of AutomationML at a glance To achieve the described sub-goals, AutomationML provides a series of innovations illustrated in →Fig. 1-14. I1 – Meta format instead of data format: AutomationML is a language for modelling syntactical and semantical information within a meta model and not a static data model as described in →section 2.2.1 About CAEX as meta data model. The ability to model a data model makes AutomationML a markup language on top of its ability to store and exchange the data in a file. AutomationML is therefore more than a pure file-based data exchange format (G1). I2 – Object-oriented modelling with relations: AutomationML bases on XML and provides object modelling techniques with explicit modelling of relations and semantic references in an electronic object model which is readable and evaluable for humans as well as machines (G2).

I3 – Separation of syntax and semantics: The objectoriented modelling of data is library based. The AutomationML standard (by intention) does not provide ready-to-go domain models (for example for process industry) but provides means to model them in libraries. The modelling of libraries is described in →section 2.2.6. AutomationML defines rules and mechanisms for library development, providing a well-defined syntax to model domain specific libraries and classes. But the meaning of attributes or classes remains in the ownership of the user or a standardization body. This strictly separates semantics and syntax and significantly simplifies the work of standardization bodies. This feature is essential because AutomationML allows modelling of objects or attributes with the same syntax but with different semantics. This significantly simplifies software development and evolution of the object models without modification of the AutomationML standard. In summary AutomationML works in semantically harmonized environments, but also when there is no harmonization of semantics at all. It also works when there is some standardization available. This allows the immediate application of AutomationML without waiting for a global semantic standard. With this innovation the standardization deadlocks are obsolete (G3). I4 – Utilization of existing standards: AutomationML has a lean architecture by integrating established, open and free XMLbased standards for individual disciplines. AML reuses established existing data formats for different domains (G4) and defines their interconnection only. The architecture and selected formats are described in →section 2.1. I5 – Referencing existing semantics: Semantic standardization usually pursues the development of agreed terminologies. AutomationML goes one step further: it allows to name attribute types “as you want” and to add a reference to these attributes towards existing external semantic standards.

The referencing of external semantic standards (G5) decouples the semantic of attributes from their naming since the name and the meaning are separate items. This help keep mature, established and proprietary company standards alive, which increases acceptance and simplifies the modelling of semantic standards. I6 – Modelling of mixed semantics: AutomationML allows re-modelling existing standardized data models (G6) such as eCl@ss or IOLink in the shape of AutomationML libraries. The only precondition is that the original data are modelled in an object-oriented manner. This enables the modelling of electronic product libraries, i.e., digital versions of product catalogues or the digital twin as described in [DRA21] (Chapter 14 The AutomationML Component and Chapter 15 AML domain model for Electric Interfaces). Since AutomationML can hold multiple libraries, those libraries can be from different sources: from a proprietary database or from a standardization body. This means that AutomationML can hold data following different semantics at the same time. As example, a product catalogue for robots of the one company can be stored in AutomationML in parallel to a product catalogue of conveyors of another vendor, each following its own semantics. I7 – Identification of semantics: Not to get lost in semantics diversity, AutomationML has comprehensive identification mechanisms (G7) that identify the semantics to be used on different levels. An AutomationML document can be labelled as a whole, meaning that the AML exporter can explicitly specify which tool has generated this file. This allows for differentiation of files from different proprietary industrial partners. The same applies for classes, instances or even attributes; each data item can be associated to its origin helping to navigate to the data source tool, source project and the

original object in the source database. This is described in →section 2.2.14.3 Meta information about the AML source tool(s). I8 – Explicit knowledge about unknowns: If the meaning of some data is unknown, such unknown data types can be recognized systematically (G8) and can be copied into an AutomationML library of unknown data. This concept is described in the Industrial Cookbook [DRA21] (section 10.6.6 Strategy for handling unknown data). I9 – Free international standard (IEC 62614): AutomationML is accepted in the market (G9) being an IEC standard and no license fee is required. I10 – Model sustainability: AutomationML supports the encoding of the evolution of information in the engineering process (G10) on each level of abstraction. The prototypic nature of AutomationML models provide the agility necessary to reflect the changes in the lifecycle of a system under design. I11 – Different levels of abstraction: AutomationML combines the variability of the semi-structured nature of XML with an optional degree of precision in strong typed models (G11). The specification of object semantics like composition structure, interfaces or properties on different levels of abstraction enables a suitable representation of information in engineering processes. In the result, these innovations enable the exchange of engineering data in a heterogeneous tool landscape. In a heterogeneous semantics landscape, it considers existing standards, resolves the described standardization deadlocks and covers the needs of iterative engineering. 1.4.4  Values of AutomationML

Fig. 1-15 Values of AutomationML AML finally provides a series of key values illustrated in →Fig. 115 for data exchange not achievable with traditional simple filebased data exchange, for instance, with spreadsheets. V1 – Extensible and flexible by design: Domain models can be defined, modified and extended. Changes in the resulting domain models do not require a change of the AML standard, because AML is a language and not a static data model (I1). Persistency is a precondition to archive data but is just one form of the AML model. V2 – Human and machine readable: AutomationML is human readable as well as machine readable through its XML heritage and comprehensive semantic references. Looking at traditional graphic representations of engineering knowledge (for example P&I diagrams), they are invented for human eyes, requiring a human interpretation based on education and experience. A process engineer easily recognizes a square on a

P&ID as a tank. This is a human interpretation, a performance of a human brain, which combines background knowledge with experiences. Without background knowledge, the square consists only of four lines. When the engineers leave the room, the P&ID on the wall remains as a meaningless drawing with lines and circles. AutomationML, on the other hand, allows the embedding of hidden knowledge, requirements, assumptions, structural relationships, interconnections, references or semantics about objects and attributes, version and mapping information directly into the model. When the engineers leave the room, the engineering information in AML keep its meaning because of explicit modelling. This allows data exchange on a computational level, simplifies quality checks, enables data validation, smart export and import software, and is reusable for a variety of data exchange use-cases. AutomationML also serves the habits of engineers: AutomationML’s capabilities to model data in an object-oriented way allow engineers to model requirements, object topologies, properties and relations, and to store them in an electronic object model without the need of engineering tools (I2). The resulting object models may later be imported into commercial engineering tools. The object-oriented design is a generic method to exchange ideas among engineers. V3 – No standardization deadlocks: AutomationML overcomes the standardization deadlocks because it can model different semantic models with the same syntax (I3). There is no need to wait on a harmonized common semantic model. Even 100% proprietary domain models are supported. V4 – Acceptance by reusing established standards: The AML architecture specifications aim at high acceptance and fast development, since AML participates in the high degree of penetration of the globally recognized XML standard (I4). With the use of the W3C recommendations, such as time stamps according to UTC, many syntax questions regarding date

formats are solved from the outset and do not require further specification. The various document types can now be checked for conformity automatically to a considerable extent using freely available tools. However, this check only covers syntax; semantic and conceptual engineering errors cannot be automatically detected on the basis of a schema definition. For example, it is possible to create grammatically correct but completely meaningless plant descriptions. Incomplete or even contradictory descriptions are deliberately allowed, since AutomationML is intended to cover early planning phases in which the consistency of the data is still insufficient. V5 – Continued use of company standards: AML allows referencing existing semantic standards (I5) by means of semantic links. This eliminates the need to agree on property names and allows the continued use of company standards. V6 – Compatibility to other semantic standards: AML provides compatibility to other semantic standards (I6), for example IOLink, eCl@ss or NE150 because it can re-model the existing semantic models with the syntax of AML. Then, the features of AML can be added to the existing standards, but the semantics of the existing standards remain unchanged. Its generic and flexible modelling mechanisms allow modelling even upcoming semantic standards. At the same time, AML can model proprietary data structures of proprietary companies. Thus, it is possible to export object structures from industrial tools as for example EPLAN, COMOS, Engineering Base “as they are” directly into AML without any mapping to any standard. V7 – Identification and exploration of semantics: AutomationML allows identifying the semantics of the contained data elements in high granularity (I7). This allows receivers to explore the semantic dialect used in the document or used in classes, instances or attributes.

V8 – Identification and management of unknown data: Unknown data can be explicitly identified and managed (I8) into foreseen libraries. This database of unknown knowledge is a great help for the further development of import software. V9 – Standard: AML is an established and considered IEC standard (I9). V10 – Suitable for changing lifecycle data: Iterative changes in the engineering process result from varying requirements, technological implementations, manufacturing methods and many others. By means of AutomationML this information can be captured over the entire life cycle and reacted according to these changes. Versioning is only a fraction of what AutomationML offers for this purpose. Therefore, AutomationML is suitable for changing lifecycle data due to model sustainability (I10). V11 – Variability in abstraction: To handle varying specifications, AutomationML accomplishes this variability by abstraction (I11). With a varying degree of granularity through optional abstractions and precisions, AutomationML creates a certain degree of freedom in modelling with a simultaneous specification of the structure to be modelled. Beside these technical aspects, the AutomationML society provides a wide range of documents, white papers, implementation proposals and an AML editor in order to gain acceptance and to support its application. Working groups allow for development of new domain models or data exchange business cases, for example the usage of AML for modelling electronic product catalogues. Summary

AutomationML supports unique features required for data exchange in heterogeneous tool and semantic landscapes.

1.5  Encoding information with AML – four layers of abstraction The previous sections have underlined that plant design involves many experts with their different professions in a communication process which is more than data exchange, it is information exchange. The technology of being a persistent file is only one aspect among many. Due to high specialization of the information generated by a heterogeneous world of tools and methods (for example diagrams or mathematical models), the required communication exchange of information is of significant complexity. While AutomationML offers powerful concepts to encode such information into data models and to manage the difficult task of information exchange in engineering, it serves not only the communication of experts in production systems engineering but also experts in the development and application of software for this purpose. It therefore regards special requirements of the different aspects of software engineering which will be discussed in the Industrial Cookbook [DRA21] (Chapter 3 Software development with AML). 1.5.1  Data model versus information model In daily use there is hardly any difference between the terms data and information as well as data model and information model. In most cases they are treated as synonyms. But in the case of AutomationML the differences should be considered explicitly.

Data in its basic form are untreated, unanalysed, unorganized, unconnected and uninterrupted objects. For this purpose, their content is encoded in characters or character sequences whose structure follows strict rules, the so-called syntax. However, the meaning is not always unique – it mostly lacks at the semantics. In order to derive information from data, it must be interpreted in a context of meaning, implying that the data is assigned a semantic purpose. An essential characteristic of information is the separation of syntax and semantics. Furthermore, there is an additional view on information: The pragmatics (effect): the concrete application in concrete situations. In engineering, this means the modelling and exchange concrete instance information. The usefulness of an information is only given, if the information has an effect, thus triggering something particular [ENGR09]. The terms data model and information model are more difficult to distinguish. In a data model data are set in relation to one another, meaning they represent an information in total. However thereby a data model represents only the relations between data. The information model extends additionally the data model by context information, which allows to interpret and use data consistently. Information, which already represents objects abstractly with their properties, semantics and pragmatics, is set into relation [PRSC03]. In order to provide a path from data to information models, the following section explains four different layers of data modelling and their relation to AutomationML. 1.5.2  The four-layer model of information encoding During the development and application of AutomationML, the distinction between data and information has become increasingly important. We can discuss AutomationML with

users or software developers on four layers of abstraction: XML level, object level, semantic domain model level or project payload level. This helps to talk about the models with a narrowed scope. These layers are shown in →Fig. 1-16 and are built upon each other.

Fig. 1-16 The four-layer model, abstractions of AutomationML data exchange Each layer is completely represented by the concepts of the underlying layer. Once the representation of a layer is understood, it is not necessary to refer to the representation in an underlying layer. It is possible to discuss high-level concepts without the need to mention XML tags, for instance. Layer by

layer, the density of information increases. Besides, whether data or information is modelled, whether AutomationML represents a data model or an information model, is clarified in the following sections with detailed information of the four layers. Layer 0 - Syntax: This layer is about XML syntax; data is structured according to XML rules. This is base technology; no matter if there is a need to store engineering data to a persistent memory or to send it to a receiver within a computer network, the information has to be encoded into a sequence of data. That is how computers work. For instance, imagine we want to store or transmit the entire content or parts of a printed version of this book by computer. We would scan and process it page by page. The pages keep the content together and the page numbers will help us to consistently reassemble the book and check its completeness. Further, the table of contents helps to understand the structure of sections and sections especially if we utilize only parts of the book. This is what XML is used for in AutomationML on the basic layer 0. It ensures the consistent encoding of model data to a sequential form - it is called serialization. An important benefit of XML is that it represents structural data as well. Compared to a book, the surrounding tags keep content together in a self-contained way. Hierarchies are built by the nesting of tags. XML-references allow for pointing to granular parts of the code. Additionally, XML constitutes a well-accepted pool of platform independent basic data types as fundamental language concepts. All the mentioned features help to automatically ensure and evaluate the complete and consistent processing of an AutomationML document on a basic level - especially important if a document needs to persist or to be transmitted.

Summary Layer 0 is about the pure XML syntax; this is the serialization layer, a series of ASCII strings compliant to the XML grammar. Here is data but no information. This layer ensures the automated processing of the data and ensures general correctness and consistency in compliance with XML, but it does not cover semantics. Layer 1 - Object Model Language: Based on the structural model of XML, layer 1 serves an object-oriented model optimized for system design. It provides ordering principles for the structuring of data. Let’s utilize the book example again. Here meaning is given to the structural concept of sections. A section may be the preface, an introduction or a summary. Also writing techniques like cross references, figure of speech or the arc of tension are conceptualized at this layer. In case of AutomationML concepts like instance objects, template classes or relations between them are defined. It is similar to how data models in computer programming are built. Consequently, defined concepts associated to this level of abstraction serve as an abstract interface to the data back-ends that realize the functions of layer 0. This layer helps to comfortably negotiate implementation details with software engineers without detailed knowledge about the implementation. Layer 1 is the most important concept, as it enables object-oriented modelling, which is discussed in Chapter 2 and Chapter 5. For implementation recommendations refer to the Industrial Cookbook [DRA21], especially Chapters 3 and 4, which provide guidance in the software development support for exporter and importer. However, layer 1 is still not sufficient for engineering information exchange, since it only defines the language for

object modelling, it is a meta model that allows the definition of models. It does not cover domain models. Summary Layer 1 is about the pure object modelling language on top of layer 0. CAEX, the object modelling format of AutomationML, is the data format for modelling object hierarchies. It defines the object language elements as classes, attributes, instances, interfaces and links. It covers structural semantics on a standardized syntax, but most parts of the data model are still data, not information. Layer 2 – Semantics, Domain Models: In layer 2, all modelling concepts are aggregated to represent domain models within AutomationML. A domain model is a semantic data model that describes important elements of a domain on type level. A domain model is the next step of the conversion of data to information; all elements of a domain model are semantically defined. Specific concepts of engineering models become part of AutomationML projects as generalized models of system parts or as object instances organized in libraries. This enables an automated reliable exchange of the engineering models used within a project. For example, imagine documents of the electrical design. A model of the concepts which the electrical engineer is familiar with, is built in the AutomationML project. The created model elements are associated with the AR-APC (Application Recommendation - Automation Project Configuration). For more details about AR-APC refer to the Industrial Cookbook [DRA21], especially Chapter 11 Data Exchange between ECAD and PLC Tools – AR APC. While the library contains the specific domain model of the electrical engineer,

the AR-APC model represents the common semantics of the domain. Domain models are the prerequisite for time and cost savings by seamless engineering information exchange. They enable data exchange on the semantic level. Chapter 5 The AutomationML Editor allows concrete modelling of use cases for layer 2 and layer 3. Summary Layer 2 is about semantics baked into domain models, created with the language elements of layer 1. Domain models exist independent from AutomationML, can be sketched on a sheet of paper and can be electronically modelled with AutomationML. Domain models may be of proprietary nature in the form of company standards, or they may be public standards. Domain models represent type information but do not cover instance information (pragmatics). Layer 3 – Payload exchange: In this top layer 3, AutomationML provides access schemes to instance data that is semistructured, free of redundancy and optimized for transmission. Additionally, the AutomationML instance models allow one to easily fit the data to the reality it shall represent. Pragmatics are added to the semantic data. For example, individual customization of a machine is hard to apply to generalized models. In AutomationML you may just customize an instance or groups instead of changing the entire model. Summary

Layer 3 is about the final information exchange between engineering tools, utilizing layer 2 domain models. Here, value is created because the payload of specific engineering data can be exported, exchanged, imported and managed. This is information, no data. 1.5.3  AutomationML in the four-layers model AutomationML supports the entire range of all described layers. It covers the XML serialization, the modelling language for object models, the development of proprietary or standardized domain models and provides the means for efficient data exchange in iterative engineering workflows. However, in literature and in this book, the terms data model and information model are often used synonymously. This occurs regardless of the fact that information models are in the true sense of the word of higher value than data models.

1.6  Exclusions However, the discussion about the value and goals of AutomationML also includes the deliberate exclusions (E) of AutomationML. These exclusions are intentional by the AutomationML community and are justified in detail. E1 – Only encoding of information models: AutomationML specifies a meta model to be stored in an XML file format. Even though distinct abstraction layers of its model are used for object-relational mapping to databases, as the foundation of API specifications or the projection of information to transmission protocols, it just specifies the encoding of information models to the data model and data types of XML. Hence, AutomationML does not provide any means of automated consistency preservation, change management or dependency resolution,

though it enables the encoding of such. It is in the responsibility of tool manufacturers and process engineers to specify and realize tools that take over software-relevant functions. E2 – Only simple consistency checks: Beyond simple consistency rules, AutomationML cannot, for example, check whether the combination of components in a document makes sense. The use of AutomationML is no substitute for checking whether component versions are used sensibly, whether data occurs twice, does not match, or whether it is outdated for whatever reason. The consistency of data is in the responsibility of the related tool; AutomationML can only model the data coming from tools. Thus, errors in AutomationML data occur in the source tool or during the transformation to AutomationML. E3 – No definition of an engineering process: AutomationML does not define an engineering process. The central goal is to close essential gaps in existing tool chains with their existing workflows. There is no requirement to use certain tools in a certain way, nor is there a definition of which steps have to be performed with which prerequisites in order to achieve certain engineering results. AutomationML is intended to provide better technical support for established processes or to enable new processes. E4 – No world model of engineering: AutomationML does not provide a world model of engineering or an all-embracing ontology or database structure for all engineering disciplines. The existing company's own national or international standards are too diverse; the semantics of device properties, for example, are too different. AutomationML can map existing and future standards. However, defining, knowing, interpreting and exchanging these standards is the responsibility of the tools and project partners participating in the exchange of data. Tool manufacturers can use AutomationML to exchange common data with other tools, to partially refine it and then to merge it

again consistently. However, the functions required for this are tool-related and should not be confused with AutomationML. E5 – No database: AutomationML is not intended to be a database. The idea of having multiple tools that read and write data into an AutomationML file is misleading. AutomationML is a data format only; it does not provide any functionality of databases, for example user management, authorization management or locking of data. Instead, AutomationML is a transport medium. It can hold engineering data previously generated by a software tool on “as-is” basis. It does not check the validity or completeness of the data. It is explicitly allowed that AutomationML can model incorrect and incomplete data because intermediate states frequently have to be exchanged iteratively in engineering. Engineering data is a matter of changes and is complete and correct only after final completion.

1.7  AutomationML Specifications 1.7.1  AutomationML IEC 62714 Series One of the goals of AutomationML is to be further established as an open, free standard. Openness means first of all that everyone interested has unhindered access to the standard. The free-of-charge aspect serves the faster spreading of the standard especially at universities and innovative companies. The use of AutomationML for the development of new methods should be possible without obstacles, in order to spread their know-how consciously. If plant engineering data is already available in AutomationML as completely as possible, it can be used in smaller efficient tools and algorithms for further engineering steps, for example for better path planning, more powerful simulations, automatic plausibility checks or automatic generation of robot or PLC program code as well as user

interfaces. The cost-free nature of AutomationML thus also serves to promote the development of more effective tools to reduce engineering costs in the long term. An open standard means not only unhindered use but also free cooperation in standardization. Every company can engage itself for its interests through membership and participation in the standardization working groups as long as these do not contradict the goals of the standard. For example, in the early days a lot of emphasis was placed on topology, geometry, kinematics and logic. Other topics were initially given lower priority and can be taken up at any time. The members of the AutomationML society make use of the principle of open standards themselves by participating in other standardization bodies, namely the Khronos Group and PLCopen, in order to make suggestions for further development. With the versions of COLLADA 1.5 and PLCopen XML 2.0 published in 2008, the cooperation of the AutomationML consortium with the respective committees has already been successfully implemented. The type of standard, either a company standard, a consortium standard or a norm, is independent of origin and licensing. A corporate standard can gain considerable market significance even if it has been defined by only one company. For example, the Integra standard of Daimler AG has a significant impact on all suppliers, and for manufacturing plants, this includes many well-known automation companies, large and small. A consortium standard is created as a joint result of a freely formed group of companies. It is very well suited to quickly make first specifications usable and to flexibly integrate further requirements in small iteration steps. Investments in the industrial environment are usually of a long-term nature, so the balancing act between current developments and proven technologies is always critical. What is

the use of a beautiful software when it becomes obsolete in three years and the manufacturer is no longer on the market in five years, but the system to be controlled is designed for a life of 15 years? In the opinion of the AutomationML society, IEC standardization is therefore the best basis for long-term stability and planning. The working group AK 941.0.2 “AutomationML” was established in the DKE for standardization as an IEC standard. Since AutomationML is basically designed to be expandable, a series of standards is developed; it is illustrated in →Fig. 1-17. – IEC 62714 Part I [IEC 62714-1:Ed2] describes definitions, general concepts and the architecture of AutomationML which are valid for all parts of AutomationML, especially for future standard parts, which were not specified at the time of standardization of the first part and will be added later. It defines layer 1 of the layer concept and fundamental libraries in layer 2. It was published as an international standard in Edition 1 in 2012. The latest Edition 2 of this standard was released in 2018. – IEC 62714 Part II [IEC 62714-2:Ed1] was published 2015 and addresses fundamental industry-specific basic libraries on layer 2, especially role libraries. These libraries have a high added value, since they allow plant engineering to be specified at a very early stage without having to commit to specific products and versions. Standardization means that submitted basic libraries can no longer simply be changed. Therefore, they were separated from the first part, which could be stabilized very early on. However, the creation and further development of user-defined libraries is explicitly intended; it is mandatory that new classes are derived directly or indirectly from the base classes. This ensures

the automated detectability of new and unknown roles. The latest Edition 2 of this part is currently in the CDV status in the IEC standardization cycle and expected to be published 2020/2021. – IEC 62714 Part III [IEC 62714-3:Ed1] was published in 2017 and describes the modelling of geometry and kinematics with COLLADA. It was published as an international standard in Edition 1 in 2017. – IEC 62714 Part IV [IEC 62714-4:Ed1] was published in 2020 and covers the modelling of behaviour based on IEC 61131-10 for the modelling of sequences, interlockings, controlled and uncontrolled, discrete and continuous behaviour and its integration into the topology description with CAEX by suitable referencing mechanisms. It was published as an international standard in Edition 1 in 2020. – IEC 62614 Part V standardizes the modelling of communication systems with AutomationML. Its Edition 1 is published in 2021 as CD.

Fig. 1-17 IEC-Standard series for AutomationML

1.7.2  Whitepapers In preparation and as documentation of the state of the art, the AutomationML society frequently creates and publishes whitepapers at [AML.org@]. Whitepapers provide generic specifications for the AutomationML modelling, dedicated to a certain topic, containing modelling rules and examples. Basic AutomationML topics are covered by the present book, advanced topics are covered by [DRA21]. Table 1-1: AutomationML Whitepapers White Paper (WP)

Reference

Chapter

Part 1 – Architecture and general requirements

[WP Part1@] [WP Part2@] [WP Part3@] [WP Part4@] [WP Part5@] [WP Part6@] [WP eCl@ss@] [WP OPC@]

2

Part 2 – Role class libraries Part 3 – Geometry and Kinematics Part 4 – Logic Part 5 – AutomationML Communication Part 6 – AutomationML Component AutomationML and eCl@ss integration OPC Unified Architecture Information Model for AutomationML

1.7.3  Application Recommendations

2 3 4 [DRA21] 17 [DRA21] 14 [DRA21] 22 [DRA21] 18

Beside Whitepapers, the AutomationML society publishes Application Recommendations (AR). They specify concrete domain models for certain industrial domains and provide concrete AutomationML libraries for reuse. Table 1-2: AutomationML Application Recommendations Application Recommendations (AR)

Reference

Chapter

Automation Project Configuration

[AR APC@]

Drive Configurations (M_CAD aspects)

[AR DRIVE CAD@] [AR MH@]

[DRA21] 11 [DRA21] 12

Modelling of Material Handling in AutomationML Provisioning for MES and ERP – Support for IEC 62264 and B2MML Asset Administration Shell Representation

[AR MES ERP@] [AR AAS@]

[DRA21] 13 [DRA21] 25 [DRA21] 19

1.7.4  Best practice recommendations Best practice recommendations (BPR) document recommendations of the AutomationML society how to model certain aspects which are usually domain independent and of general interest, for example how to model multilingual attributes, how to reference external documents, how to model regular expressions. Several of the published BPRs have been developed before AutomationML Edition 2 has been released, they are relevant for AutomationML Edition 1 only. BPRs for AutomationML Edition 1 have been natively introduced into the AutomationML Edition 2 standard, hence they don’t need an updated BPR. In case a BPR

is relevant for AML Edition 1 only, the current implementation in AutomationML 2 is presented in this book. Table 1-3: AutomationML Best Practice Recommendations Best Practice Recommendations (BPR)

Relevance

Reference

Chapter

Constraints with regular expressions in AML

AML Ed. 1+2

2.7.1

ExternalDataReference

AML Ed. 1

Modelling of List Attributes in AutomationML Multilingual Expressions in AutomationML Naming of related Documents and their versions

AML Ed. 1

[BPR RegExp@] [BPR EDRef@] [BPR MLA@]

AML Ed. 1

[BPR ME@]

2.6.7

AML Ed. 1

2.2.14.3

DataVariable

AML Ed. 1+2

AutomationML Container

AML Ed. 1+2

Reference Designation

AML Ed. 1

Units in AutomationML

AML Ed. 1+2 AML Ed. 2

[BPR RefVersion@] [BPR DatVar@] [BPR Container@] [BPR RefDes@] [BPR Units@] [BPR EI@]

[DRA21] 15

Modelling of electric Interfaces (Draft, Request for Comments)

2.5.4 2.6.8

[DRA21] 18 2.6.9 2.7.2

1.7.5  Availability All mentioned Whitepapers, Application Recommendations and Best Practice Recommendations are separately available at [BookLink@] and [AML.org@]. The related AML libraries can be

downloaded directly within the AutomationML Editor as described in →section 5.5.5 How to import AutomationML libraries.

1.8  The AutomationML association 1.8.1  Initiators and members The main driver for developing AutomationML was the need for more efficient automation engineering workflows in a heterogeneous landscape of engineering providers. In the investigation of other industries, very similar problems were found in the development of computer games. 3D figures move in scenes, have joints and sequential logic and can even collide with each other virtually. The complex, data-intensive visualizations do not require expensive workstations, but can be calculated and displayed quickly and conveniently with standard PCs or inexpensive game consoles. However, the exchange formats available in this industry did not meet the industrial requirements for tolerances to be maintained and for the description of complex dependencies in the kinematics, for example for a six-axis robot. In video games, it does not matter whether somebody hits two or three centimetres higher or lower - in automotive engineering this would result in low-quality cars at best. The representation of multifaceted and precise production processes and ideally their further use for industrial control systems is not possible.

Fig. 1-18 Members of the AutomationML society in 2019 Now it is not the primary task of an automobile manufacturer to develop and maintain data exchange formats and this by no means independently of its suppliers. Therefore, in 2006 Daimler invited leading manufacturers and users of automation technology to solve this task together in a consortium to develop a neutral data exchange format. Since then, Daimler and a growing consortium of industrial and academic members are working on the technical concepts of AutomationML with the aim of sounding out the multitude of requirements for such a data format, implementing them technically and testing them in practice. Today, dozens of industrial members have joined the AutomationML society (→Fig. 1-18). 1.8.2  Possibilities of participation

With the foundation of an AutomationML Association, the AutomationML Consortium opened its doors to interested members in April 2009. The aim of the association is the joint further development and distribution of the standard. An association is the usual way to designate a legal entity as the owner of a data format, which is necessary for the regulation of the rights to its use. More important for the further development, however, are the AutomationML working groups, which serve as a platform for regular cooperation. They are organized flexibly according to current topics. An association is essential for the goal of an open standard. Open means not only open distribution, but also open participation. Every company or university can become a member in order to bring in its interests in the exchange of plant design data. For example, process automation and process engineers could join forces to further develop a role library for the process industry. In addition to legal questions and the organization of further development, the AutomationML Association takes care of the dissemination of the standard through joint trade fair appearances, trainings, presentations and an internet presence →(http://www.automationml.org). There, specifications, sample software and illustrative material are available for download. The website can also be used to contact AutomationML members, for example, to answer questions.

1.9  References for Chapter 1

[ART04] [DGE05] [DRA10] [DRA21] [DRBA11]

[DRBA12]

[ENGR09]

[FAY06] [GKF+09]

[GWF08]

[KRST09]

[MND+09]

F. Anhaeuser, H. Richert, H. Temmen: Degussa PlantXML – integrierter Planungsprozess mit flexiblen Bausteinen. atp, Vol. 46 (4), 2004, pp. 63– 72. R. Drath, K. Gohr, P. Erning: Datenaustauschkonzepte im Anlagenengineering. In: IT-Solutions in der Energieerzeugung. Berlin: VDE Verlag, 2005. R. Drath (Ed.): Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCopen XML und COLLADA. Ed. 1, Berlin Heidelberg: Springer-Verlag (VDI-Buch), 2010. R. Drath (Ed.): AutomationML – The Industrial Cookbook. De Gruyter Oldenbourg, ISBN 978-3-11-074592-4, Berlin, 2021. R. Drath, M. Barth: Concept for interoperability between independent engineering tools of heterogeneous disciplines. In: Proceedings of the International Conference on Emerging Technologies and Factory Automation (ETFA), Toulouse: IEEE, 2011. R. Drath, M. Barth: Concept for managing multiple semantics with AutomationML - maturity level concept of semantic standardization. In: Proceedings of the International Conference on Emerging Technologies and Factory Automation (ETFA), Krakow: IEEE, 2012. F. Engelmann, C. Großmann: Informationsqualität – Grundlagen. In: K. Hildebrand, M. Gebauer, H. Hinrichs, M. Mielke (Ed.): Daten- und Informationsqualität: Auf dem Weg zur Information Excellence. Wiesbaden: Vieweg+Teubner Verlag, 2009, pp. 1-46. A. Fay: Reduzierung der Engineering-Kosten für Automatisierungssysteme. Industrie Management Vol. 22 (2), 2006, pp. 29-32. K. Guettel, A. Koenig, A. Fay, P. Weber: Konzept zur Generierung von Steuerungscode unter Verwendung wissensbasierter Methoden in der Fertigungsautomatisierung. In: Tagungsband zum AutomationKongress 2009, Baden-Baden: VDI (VDI-Berichte 2067), 2009, pp. 309312. K. Guettel, P. Weber, A. Fay: Automatic generation of PLC code beyond the nominal sequence. In: Proceedings of the International Conference on Emerging Technologies and Factory Automation (ETFA), Hamburg: IEEE, 2008. O. Kroll, W. Still: Prolist NE100 in der Praxis – Erfahrungsbericht eines Anlagenbetreibers und eines Herstellers. In: Tagungsband zum Automation-Kongress 2009, Baden-Baden: VDI (VDI-Berichte 2067), 2009, pp. 65-68. M. Muehlhause, M. Neumann, C. Diedrich, S. Wuwer: Modellierung semantischer Beziehungen für unterschiedliche Informationsmodelle im

[PRSC03] [REDR09]

[RGF09]

[RHA02] [WBR+09]

[WMM11] [WMZ+10]

automatisierungstechnischen Umfeld. In: Tagungsband zum Automation-Kongress 2009, Baden-Baden: VDI (VDI-Berichte 2067), 2009, pp. 237-240. A. Pras, J. Schoenwaelder: On the difference between Information Models and Data Models. Request for Comments (RFC), Vol. 3444, 2003, pp. 1-8. M. Remmel, O. Drumm: Anwendungen semantischer Technologien zur Erstellung von Schnittstellen. In: Tagungsband zum AutomationKongress 2009, Baden-Baden: VDI (VDI-Berichte 2067), 2009, pp. 171174. S. Runde, K. Guettel, A. Fay: Transformation von CAEXAnlagenplanungsdaten in OWL – Eine Anwendung von Technologien des Semantic Web in der Automatisierungstechnik. In: Tagungsband zum Automation-Kongress 2009, Baden-Baden: VDI (VDI-Berichte 2067), 2009, pp. 175-178. G. Rauprich, C. Haus, W. Ahrens: PLT-CAE-Integration in gewerkeübergreifendes Engineering und Plant-Maintenance. atp, Vol. 44 (2), 2002, pp. 50-62. M. Wollschlaeger, A. Braune, S. Runde, U. Topp, M. Muehlhause, O. Drumm, C. Thomalla, A. Saboc, L. Lindemann: Semantische Integration im Lebenszyklus der Automation. In: Tagungsband zum Automation-Kongress 2009, Baden-Baden: VDI (VDI-Berichte 2067), 2009, pp. 167-170. A. Wiesner, J. Morbach, W. Marquardt: Information integration in chemical process engineering based on semantic technologies. Computers & Chemical Engineering, Vol. 35 (4), 2011, pp. 692-708. F. Waltersdorfer, T. Moser, A. Zoitl, S. Biffl: Version Management and Conflict Detection across heterogeneous Engineering Data Models. In: Proceedings of INDIN 2010, Osaka: IEEE, 2010, pp. 928-935.

AutomationML Web references [AML.org@] [BookLink@]

→www.automationml.org →www.automationml.org/amlbook

AutomationML Whitepaper (get latest version from the website)

[WP Part1@] [WP Part2@] [WP Part2@] [WP Part4@] [WP Part5@] [WP Part6@] [WP eCl@ss@] [WP OPC@]

→www.automationml.org/amlbook: Whitepaper AutomationML Part 1 – Architecture and general requirements, version 1.0 from July 2018. →www.automationml.org/amlbook: Whitepaper AutomationML Part 2 – Role class libraries, version 2.0 from Oct. 2014. →www.automationml.org/amlbook: Whitepaper AutomationML Part 3 – Geometry and Kinematics, version 2.0 from Jan. 2017. →www.automationml.org/amlbook: Whitepaper AutomationML Part 4 – AutomationML Logic, version 1.5.0 from Jan. 2017. →www.automationml.org/amlbook: Whitepaper AutomationML Part 5 – AutomationML Communication, version 1.0 from Sep. 2014. →www.automationml.org/amlbook: Whitepaper AutomationML Part 6 – AutomationML Component, version 1.0.0 from Oct. 2020. →www.automationml.org/amlbook: Whitepaper AutomationML and eCl@ss integration, version 1.0.1 from Dec. 2017. →www.automationml.org/amlbook: Whitepaper AutomationML OPC Unified Architecture Information Model for AutomationML, Version 1.0.0 from March

AutomationML Application Recommendations [AR APC@] [AR DRIVE MCAD@] [AR MH@] [AR MES ERP@] [AR AAS @]

→www.automationml.org/amlbook: Application Recommendation Automation Project Configuration, ID: AR APC, V 1.2.0., April 2020. →www.automationml.org/amlbook: Application Recommendation Drive Configurations (M_CAD aspects), ID: AR DRIVE MCAD, V1.0.0, April 2020. →www.automationml.org/amlbook: Application Recommendation Modelling of Material Handling in AutomationML, Version 1.0.0, March 2020. →www.automationml.org/amlbook: Application Recommendation Provisioning for MES and ERP – Support for IEC 62264 and B2MML. ID: ARMES-ERP, Version 1.1.0, Nov. 2018. →www.automationml.org/amlbook: Application Recommendation Asset Administration Shell Representation. ID: AR AAS, Version 1.1.0, Nov. 2019.

AutomationML Best practice recommendations [BPR RegExp@]

→www.automationml.org/amlbook: Best Practice Recommendation Constraints with regular expressions in AutomationML. ID: BPR CstrRegExp, V 1.0.0, Oct. 2014. →www.automationml.org/amlbook: Best Practice Recommendation ExternalDataReference. ID: BPR EDRef, V1.0.0., July 2016.

[BPR EDRef@] [BPR MLA@] [BPR ME@] [BPR RefVersion@] [BPR DatVar@] [BPR Container@] [BPR RefDes@] [BPR Units@] [BPR EI@]

→www.automationml.org/amlbook: Best Practice Recommendations Modelling of List Attributes in AutomationML. ID: BPR MLA, V 1.0.0, January 2016. →www.automationml.org/amlbook: Best Practice Recommendation Multilingual Expressions in AutomationML. ID: BPR MLingExp, V 1.0.0., March 2017. →www.automationml.org/amlbook: Best Practice Recommendation Naming of related Documents and their versions. ID: BPR RefVersion, V 1.0.0, December 2016. →www.automationml.org/amlbook: Best Practice Recommendations DataVariable. ID: BPR DatVar, V 1.0.0, May 2017. →www.automationml.org/amlbook: Best Practice Recommendation AutomationML Container. ID: BPR Container, V 1.0.0. Oct. 2017. →www.automationml.org/amlbook: Best Practice Recommendation Reference Designation. ID: BPR RefDes, V 1.0.0, Sept. 2017. →www.automationml.org/amlbook: Best Practice Recommendation Units in AutomationML. ID: BPR Units, V 1.0.0, August 2018. →www.automationml.org/amlbook: Best Practice Recommendations Modelling of electric Interfaces (Draft, Request for Comments). Nov. 2019.

Web references [DEX12@]

DEXPI: Data exchange with ISO 15926 – A way to improve doing business, →https://www.dexpi.net [Last access: 2020-11-15], 2012.

Standards and guidelines

[IEC 62424:Ed2] [IEC 62714:Ed1] [IEC 627141:Ed1] [IEC 627142:Ed1] [IEC 627143:Ed1] [IEC 627144:Ed1] [IEC 62714:Ed2] [IEC 627141:Ed2] [ISO 10303-21] [ISO 15926] [NE 100] [VDI/VDE 3697-1]

IEC 62424 Ed. 2: Representation of process control engineering – Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools. International Electrotechnical Commission, IEC, 2016. IEC 62714 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML). International Electrotechnical Commission, IEC, 2012. IEC 62714-1 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML) - Part 1: Architecture and general requirements, Edition 1. International Electrotechnical Commission, IEC, 2012. IEC 62714-2 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML) – Part 2: Role class libraries. International Electrotechnical Commission, IEC, 2015. IEC 62714-3 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML) - Part 3: Geometry and kinematics, Edition 1, International Electrotechnical Commission, IEC, 2017. IEC 62714-4 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML) - Part 4: Logic. International Electrotechnical Commission, IEC, 2020. IEC 62714 Ed. 2: Engineering data exchange format for use in industrial automation systems engineering (AutomationML). International Electrotechnical Commission, IEC, 2018. IEC 62714 Ed. 2: Engineering data exchange format for use in industrial automation systems engineering (AutomationML) - Part 1: Architecture and general requirements, Edition 2. International Electrotechnical Commission, IEC, 2018. ISO 10303-21. Industrial automation systems and integration - Product data representation and exchange - Part 21: Implementation methods: Clear text encoding of the exchange structure, 1996. ISO 15926. Industrial automation systems and integration - Integration of life-cycle data for process plants including oil and gas production facilities, 2007. NE 100. Use of Lists of Properties in Process Control Engineering Workflows, 2010. VDI/VDE 3697-1. Recommendation for the technical implementation of data exchange between engineering systems for PCE and PCS - Data exchange between PCS objects in accordance with NE 150 using AutomationML, 2018.

Notes 2

AutomationML is a registered trademark. ML means Markup Language. AML is also the abbreviation and .aml is the file extension of AML files.

Chapter 2  CAEX and AutomationML Guide Motivation, goals, innovations, and values of AutomationML Rainer Drath Content 2 The CAEX and AutomationML guide — 47 2.1 AutomationML architecture and modelling philosophy — 47 2.1.1 Introduction — 47 2.1.2 AutomationML architecture — 47 2.1.3 AutomationML submodels — 48 2.1.4 Object-oriented modelling philosophy in plant engineering — 48 2.1.5 Differences between AutomationML Edition 1 and 2 — 51 2.2 The CAEX 3.0 guide — 53 2.2.1 About CAEX as meta data model — 53 2.2.2 Persistence of a CAEX model: CAEX files — 54 2.2.3 General CAEX modelling principles — 55 2.2.4 The instance hierarchy — 61 2.2.5 How to model a CAEX InternalElement — 63 2.2.6 CAEX library and class types — 69 2.2.7 How to model CAEX system unit classes — 72 2.2.8 How to model CAEX interface classes — 77 2.2.9 How to model CAEX role classes — 81 2.2.10 How to model CAEX attribute types — 85 2.2.11 How to model paths — 91 2.2.12 Modelling of relations — 92 2.2.13 Overriding inherited information — 102 2.2.14 Modelling version information — 104 2.3 AutomationML Edition 2 versus CAEX 3.0 — 110 2.3.1 Overview — 110 2.3.2 Additional general modelling rules — 111 2.3.3 Additional AutomationML versioning rules — 111 2.4 AutomationML base libraries — 113 2.4.1 General modelling rules — 113 2.4.2 Basic Role Class library — 113 2.4.3 Basic Interface Class Library — 118 2.4.4 Basic Attribute Type Library — 123 2.5 Referencing external documents — 126 2.5.1 Referencing COLLADA and behaviour documents — 126 2.5.2 Referencing external CAEX documents — 126

2.5.3 Referencing future external documents in the scope of AML — 129 2.5.4 Referencing additional documents outside the scope of AML — 129 2.5.5 Referencing CAEX attributes to items in external documents — 133 2.6 Extended AutomationML Concepts — 135 2.6.1 Overview — 135 2.6.2 The AML port concept - modelling of complex interfaces — 135 2.6.3 The AML facet concept - modelling of attribute filters — 138 2.6.4 The AML group concept - filtering of objects — 141 2.6.5 Combination of facets and groups — 143 2.6.6 Modelling of processes – the PPR concept — 146 2.6.7 Internationalization, multilingual attributes — 153 2.6.8 Modelling of lists and arrays — 155 2.6.9 The AML Container Format — 157 2.7 Best practice recommendations for AML modelling — 160 2.7.1 Modelling of Regular Expressions — 160 2.7.2 Modelling of Units — 161 2.8 Conclusion and summary — 163 2.9 References for Chapter 2 — 164

2  The CAEX and AutomationML guide 2.1  AutomationML architecture and modelling philosophy 2.1.1  Introduction Engineering data are of a diverse nature, for example, signals, equipment, devices, their geometry, kinematics, behaviour, and interconnections. This data is usually created in different tools from different domains and the resulting fragmentation is the reason why there is no common data format established for a unified modelling of all these aspects. But there are established data formats for each of these aspects. The key idea of AML is to interconnect those different, already established, data formats and to define the modelling rules for mapping and interconnecting the various aspects of plant engineering. We name these data formats submodels. They are used on an “as-is” basis within their own specifications and are not branched for AML needs. 2.1.2  AutomationML architecture →Fig. 2-1 illustrates the basic AML architecture with its submodels for object hierarchies, geometry, kinematics and logic information across multiple file formats.

Fig. 2-1 AutomationML architecture

Each AML object in the object hierarchy may be a composition of child objects and may itself be part of a larger composition. The object tree in →Fig. 2-1 shows this by an Object A and a few child objects, which together form an object tree. In this way, simple components as well as production cells or complex systems can be described. Each object can reference geometry, kinematics or behaviour information stored in third party XML files. This enables cross domain modelling. 2.1.3  AutomationML submodels The first submodel that AutomationML has adopted is CAEX. CAEX forms the core of AutomationML, a hierarchy of objects can be defined to model a world of things. CAEX is domain independent, it is a meta language for object-oriented data modelling. And finally, it is used to interconnect the other submodels. →Table 2-1 summarizes the AutomationML submodels and the mandatory versions of the submodels. Table 2-1: AutomationML submodels Domain

Submodel data format

Object topologies Geometry and kinematics

CAEX according to IEC62424 COLLADA3 1.4.1 and 1.5.0 (ISO/PAS 17506:2012)

Behaviour

IEC 61131-10 or PLCopenXML

Syntactically, there is no difference between an AML object and a CAEX object since AML adopts CAEX on “as-is” basis. This means, each AML object is a CAEX object, but not every CAEX object is an AML object. The difference between a CAEX object and an AML object is only in modelling rules. A CAEX object follows the guidelines of the CAEX standard only, whereas an AML object is a CAEX object that additionally follows the modelling rules of the AML standard. For modelling geometry and kinematics, COLLADA has been chosen [COL08]. Behaviour is modelled by the data format PLCopen XML. In the future, additional parts of IEC 62714 may define further formats. Until then, external files can be referenced by a generic reference mechanism (see →section 2.5.4). Summary The AML standard does not define any new file format, instead it defines how the various data formats are interconnected. This is why the normative part of the IEC62714-1:2018 document consists of 32 pages only. 2.1.4  Object-oriented modelling philosophy in plant engineering This section discusses the object modelling philosophy required in plant engineering in contrast to object-oriented software programming. The general modelling philosophy of AutomationML pursues the vendor independent information modelling and storage of hierarchical object information. To be able to model

data with AutomationML, we must see the world from the perspective of things and their relations. Object-orientation is a powerful method for better control of complexity that has long been proven in the software industry for several decades. This applies to the internal architecture of software itself as well as the operating philosophy and data representation provided to a user of the software. But in plant design, on the other hand, object-orientation as a tool for efficient planning has gained practical relevance only in recent decades. Thinking in terms of objects has meanwhile been proven in engineering tools such as RobCAD, COSIMIR, COMOS, RobotStudio, Engineering Base, DELMIA4 and many others. The term object-orientation is used here from the perspective of a planner and addresses object-oriented engineering techniques such as data storage, representation and manipulation, see [FaDr05]. Microsoft Visio is a well-known example of a drawing tool with object-oriented operating philosophy. With such tools, a drawing is composed of objects whose properties and relations can be configured. Engineering tools such as Comos (see →Fig. 2-2) also offer a convenient object-oriented data representation in the form of hierarchical object trees [SCH02].

Fig. 2-2 Object tree modelled in a modern engineering tool AutomationML supports object-oriented concepts, such as instances, classes, inheritance, aggregation, composition, attributes and relations. These terms are well-known to computer scientists, but they are relatively new in automation industry and applied in slightly different ways. In AutomationML, an object acts as a “representative” of a real or logical planning asset, for example, a robot, a pump, a building or a function block. It is mapped by the CAEX element InternalElement. An object encapsulates properties, interfaces and its internal architecture and can itself be part of a superordinate structure. Classes are described by

means of a representative object in a class library. Therefore, the internal architecture of a SystemUnitClass is syntactically identical with that of an instance of the type InternalElement. An object instance, subsequently also referred to as AML object, represents a concrete example of an object with its own name and individual properties, for example a robot RB200_1. AN object instance differs from all other objects by at least one unique name or identifier. Object instances are the things we see and know from our daily life: tables, robots, PLCs, pumps, pipes. Example about the difference between class and instance If you buy a used car, you select a concrete instance of a car. But if you order a new car from a car dealer, you select a car type from a product catalogue. Later, you will get the concrete instance of the car delivered. Thus, the term instance describes a unique individual data object with individual properties. A class can be instantiated multiple times, for instance when a car type is produced many times, and all derived instances are from the same type. The counterpart of the instance is the class. It describes a predefined abstract data object that serves as a template for the creation of object instances. Classes are also known in the industry as object type, prototype, template or base object. The class concept has its roots in the proven module concept [PAR72] and consistently follows the concept of reuse. Thus, a class Robot can be instantiated several times and results in the object instances Rob1, Rob2 and Rob3, for example. Classes are managed in class libraries. In engineering, the concept of inheritance is a key to efficient engineering. New classes can be derived from a parent class by means of an inheritance relation. The instance inherits all properties, all intersections, and the internal structure of this parent class. Thus, a class SpecialRobot can be derived from the class RobotClass and inherit its “inner parts”. CAEX supports the inheritance between classes, and each class can only have one parent class. An important difference between object-oriented data modelling in AutomationML in contrast to object-oriented software programming is that changes or modifications of an instance are explicitly allowed. This means, that during the process of instantiating a class, all data of the class are copied to the instance, but then, the instance can be freely modified. This is a very powerful concept and reflects industrial reality: the class defines the starting point of engineering. Furthermore, modifications of the original class are not automatically updated or reflected in the instances. This is necessary because instances electronically represent real assets, and real assets do not change automatically when their respective types change. CAEX also implements the concept of aggregation and composition: Object instances as well as classes can be individually constructed from sub-objects. For instance, a car consists of other objects: four wheels, an engine, a car body, etc. Relations between objects represent their relationships with each other. CAEX implements inheritance relations, parent-child relations, instance-instance relations and class-instance relations, see →section 2.2.12.4. A powerful concept of the object-oriented data modelling is encapsulation. Each object encapsulates its class-defined data. The diameter of a tank is modelled as parameter of the tank object. Deleting, moving or copying a tank object in CAEX deletes, moves or copies all

related parameters as well. In this way, a single object can be modelled, analysed, manipulated and transported in the same way as millions of them. Exactly here is the value of the object-orientation: it enables cost savings with automated engineering steps, consistency and quality checks, data analytics, data synchronization, requirements modelling or the modelling of product catalogues. 2.1.5  Differences between AutomationML Edition 1 and 2 A standard matures with its application. Feedback from practical experiences is an indispensable guide for further development of a robust standard. Since AutomationML does not define its own data formats or develop derivatives of them, but rather integrates proven data formats in their original form, the AML society (AutomationML e.V.) always pursues the improvement and further development of the sub-data formats within their original committees. The CAEX standard [IEC 62424:Ed1] was originally released in 2008 in version CAEX 2.15 and adopted by AutomationML Edition 1 in 2012. In 2016, a new edition of the CAEX standard has been published [IEC 62424:Ed2] introducing CAEX 3.0. The improvements in CAEX 3.0 are significant, and AML adopted the new CAEX 3.0 version in 2018 with the new AutomationML Edition 2 [IEC 62714:Ed2]. Both standards were developed in close cooperation between the IEC 62714 (AutomationML) and IEC 62424 (CAEX) committees. CAEX attribute libraries can model standard attributes from external semantic standards as well as proprietary attribute libraries. This finally enables modelling of domain specific attribute libraries, and each attribute can reference its semantics, for example, by referencing eCl@ss or the IEC CDD. Based on this, AutomationML defines modelling rules for multilingual attributes, and attribute libraries can be stored as separate CAEX files. Further major improvements are: – Improved iteration support: explicit modelling of the creator of objects; every object can model its source tool and its identification within the source tool, which enables the tracing of changes in iterative engineering. – Improved interface modelling: the introduction of nested interfaces, which enables the modelling of complex interfaces. – Improved support for multiple roles – this simplifies the modelling of multiple object semantics. – The introduction of a namespace and version information - this simplifies the integration of CAEX into a higher-level standard, in this case AML. – Improved mapping: simplifications and improvements for links and mapping objects. Technically, these changes enable simplifications in the development of exporters, importers and the implementation of data exchange scenarios. In particular, the definition of standard attribute libraries and the traceability of data streams simplifies repeated and iterative data exchange in a heterogeneous tool environment. Since IEC 62714 consists of multiple parts and each part has its own standardization cycle, Ed. 1 is currently an active standard in parallel to the new AutomationML Ed. 2. Further active parts of AutomationML actually rely on the previous AML edition 1 based on CAEX 2.15. The smooth transferability of AML Ed. 1 to 2 is a main focus in the development and standardization of CAEX 3.0. Existing AutomationML models following CAEX 2.15 can be

transferred lossless to the new version CAEX 3.0. The software tools provided by AutomationML e.V. already support this [ASW20@]. Details on the differences between CAEX 2.15 and 3.0, respectively AML Edition 1 versus 2 are described at [Book-Link@]. Summary The biggest improvement in CAEX 3.0 is the introduction of an attribute type library. This enables the object-oriented modelling of attribute dictionaries and is the basis for semantic interoperability and machine readability. Attribute libraries are a major step for-ward in the digital representation of existing semantic standards. They reduce redundancy, improve human readability, enable machine readability and thus an automatic semantic interpretability. The names of attribute types and their instances thus become irrelevant, so that agreement on names will no longer be necessary in the future. This makes it possible to fulfil existing naming conventions for different participants without losing semantic interpretability.

2.2  The CAEX 3.0 guide 2.2.1  About CAEX as meta data model Objects and object hierarchies play a central role in AML. The following sections give a comprehensive introduction into CAEX. CAEX was originally developed for the data exchange of control-relevant information between tools of process engineering and control planning [EPP03], [DrFe04a][DrFe04b]. But CAEX is a general-purpose modelling language for objectoriented data. Its language elements are not restricted to process engineering but can also be used without restrictions in other domains, for example production planning or building automation. It supports the modelling of static object structures and has a powerful library concept that allows the storage of proven components, interfaces, requirements and roles. CAEX was initially standardized in [IEC 62424:Ed1]. The most recent standard is [IEC 62424:Ed2]. CAEX is a meta model. Often misunderstood, “meta” is a very natural concept. Meta models have major advantages over conventional data models. Example for a conventional data model Consider an address book modelled in a conventional way: each address provides predefined fields for name, address, telephone number etc. Each address follows a fixed building plan. But if you want to add a new field, for example, “GPS coordinates”, you likely cannot. A workaround is to add this to a comment field, but this field does not know the meaning and will not open a navigation tool when you click on it. Data models are usually fixed and not extensible. Extensions immediately would require a change of the model which quickly leads to version management challenges. Meta models are different. Instead of predefining the required data fields concretely, we model the data on a higher abstraction level. We all use meta models daily. A very common

meta format is our spoken language, for example German or English. Sentences follow abstract rules: grammar, orthography, sentence structure, and the used words have a semantics. Spoken languages are extensible, and they extend and change their vocabulary and semantics on daily basis. A meta concept follows human intuition better than static models. Example for a meta model In our example of the address book, a meta model would not predefine a fixed set of address relevant fields. Instead, it would have only one field named field, which has generic properties such as name, value and semantic. The meta model is abstract; it goes beyond the concrete items to abstract items. This makes the architecture of the address book very simple: it can store an infinite number of address entries and every address entry can hold fields, no matter how many, and the semantic of the fields is stored in a library which is again extensible. This concept can be extended, and the meaning of each field can be explicitly modelled. It covers all upcoming address entries, even the unknown. The address book model can be extended without changing the meta model. 2.2.2  Persistence of a CAEX model: CAEX files CAEX defines construction rules for object-oriented data modelling. The ability to model object information in CAEX documents is an important option for storing, archiving or submitting information. The storage as a file is however only one option to transfer object models; the object model can also be held in memory or transferred without any files, by means of software services. Traditionally, the ability to store the data as a file is called persistence or serialization. The construction rules of the CAEX modelling language are defined in an XML schema file CAEX_ClassModel_V.3.0.xml. This file follows the XML schema conventions and contains an electronic plan of the CAEX construction rules. If a software package generates a CAEX file, the CAEX schema is required to check this file. In this respect, the schema file must always be supplied with the CAEX document. Optionally, CAEX documents can be distributed over several documents. This is useful if, for example, a library is stored in a separate file. →Fig. 23 illustrates this: a CAEX model is usually a set of files: at least two: the document and the Schema file.

Fig. 2-3 CAEX document versus CAEX Schema

The CAEX 3.0 schema is standardized by IEC 62424 Ed. 2 and defines the structures of all CAEX data types. The Schema file can be downloaded [BookLink@] or can be generated by the AutomationML Editor as described in →section 5.5.7. The CAEX schema file is named CAEX_ClassModel_V.3.0.xsd. Each CAEX XML file must conform to the schema definition. These CAEX building blocks (subsequently referred to as CAEX elements) determine how classes, interfaces, attributes, instances, and all other elements must be syntactically structured. The CAEX schema acts as a “blueprint” for CAEX documents and allows an automatic conformity check of whether a CAEX document corresponds to this blueprint. This procedure is a basic function of XML and is supported by a wide range of tools worldwide. The following section introduces the essential CAEX elements and explains their application. For normative provisions of CAEX, please refer to [IEC 62424:Ed2]. 2.2.3  General CAEX modelling principles 2.2.3.1  The CAEX architecture →Fig. 2-4 illustrates the general CAEX 3.0 architecture by its schema definition. – The CAEX element represents the root node of a CAEX document. A CAEX document only has one root node. – The , , , and are elements to model organizational information about the document, for example version information. Details on how to model version information are described in →section 2.2.13. – The element allows modelling of references to external CAEX files. It is the basis for splitting object models into different files and to minimize model sizes by re-using library information stored separately. – The is the root node for project data. It holds a hierarchy of object instances. Multiple hierarchies are allowed. More details are given in 2.2.3.5 and 2.2.4.2. – The CAEX elements , , and are container elements for modelling different library types. They are extendable and allow the modelling of user-defined or normative classes.

Fig. 2-4 CAEX Schema Definition 2.2.3.2  Example CAEX structure →Fig. 2-5 illustrates the CAEX architecture by means of a section of a CAEX document, which contains a library MySystemUnitLib and an object hierarchy MyHierarchy. On the right side of the picture the corresponding CAEX-elements are highlighted.

Fig. 2-5 Exemplary illustration of the basic elements of CAEX The CAEX element is the starting point of the CAEX document. It holds version information about the document. The CAEX element with its classes of the type describes a library of predefined classes. A CAEX document can contain any number of libraries, which are distinguished by unique names in the document. In addition to these class libraries, CAEX supports interface and role libraries, which are explained in →sections 2.2.8 and →2.2.9. System unit class libraries are typically used in order to model vendor specific product catalogues. Their content is proprietary, the library is in the ownership of a company. In this example, the library defines two robot classes. The CAEX element represents the root node for an object tree. It consists of an arbitrarily deeply nested hierarchy of objects of the type . A CAEX document can store any number of hierarchies. The CAEX element describes a real or logical plant object with its attributes and intersections. The architecture of an is identical to that of a . This allows the creation of objects in the instance tree by copying classes or, conversely, to transport parts of the instance hierarchy back into a class library. In this example, it describes a station with a robot, a PLC and a conveyor. 2.2.3.3  Identification of instances and classes

In a heterogeneous tool landscape, different engineering tools use different concepts for the identification of objects, for example a unique name, a unique identifier or a unique path. Some tools allow changes of the identifiers over the lifetime, others do not. CAEX neutralizes this variety and defines one mandatory object identification concept. CAEX classes or types (RoleClasses, InterfaceClasses, SystemUnitClasses and AttributeTypes), attributes, libraries and the CAEX InstanceHierarchy are identified by their CAEX tag Name. Each name must be unique across its siblings. This concept assures that referencing a library, a class, a type or an attribute by its path delivers a unique result. Referencing of classes is done via full paths using the corresponding path separators according to 0. All CAEX instances (InternalElements and ExternalInterfaces) are identified by their CAEX tag ID. Once created, the identifier of the same InternalElement or ExternalInterface must not change over the lifetime of the corresponding object. To achieve this, CAEX recommends that the identifier should be a UUID, especially the GUID. Brackets, braces, dashes or spaces are allowed but ignored. 2.2.3.4  Modelling object semantics - the CAEX role concept Besides classes and instances known from object-oriented software programming, CAEX provides a special concept that is invented to describe systems on an abstract level, even before concrete devices are selected: the role concept. →Fig. 2-6 illustrates the value of the role concept by means of two hierarchies.

Fig. 2-6 Roles provide object semantics The left hierarchy is just a hierarchy of internal elements, but the meaning is not modelled. It requires additional knowledge to understand the meaning, usually human interpretation. The left structure is machine readable, but not machine interpretable. In the structure on the right, its role is explicitly modelled for each instance. A software package could present different icons based on the function or could provide search or analytics functionality. The role concept is a very natural concept. We all use it daily and it is well established in history without calling it role concept. An example illustrates this: The famous composer Wolfgang Amadeus Mozart used the role concept intuitively when composing his operas, in which actors play different roles on stage. The process of composing an opera is remarkably similar to that of engineering a plant. In a first step, for example, Mozart envisages the role

of a princess, without referring to a specific person. This role has a certain function in the opera, which is later implemented by a concrete actress. In a next step, Mozart formulates requirements for this role, for example, “should be able to sing high C”, “should have long blonde hair”, “should be able to ride”. Centuries later, today’s directors still use these requirements to advertise the role of the princess and select a suitable actress. Technically speaking, the actress “implements” the role. System engineers proceed similarly. The starting point of engineering is to describe a manufacturing process by combining abstract roles, still independent of their concrete technical implementation, for example conveyors, robots, turntables and a PLC. In the next step, engineers define the requirements and refine them stepwise. These requirements are used to identify and specify concrete devices that technically implement the requested functions. Such a procedure corresponds to a practical, iterative, engineering and human way of thinking. The role concept thus follows a proven procedure for decoupling the specification and implementation phases. All three phases are illustrated in →Fig. 2-7. Phase (1) is mapped with CAEX by first assigning meaningless objects of the type (example RB_100) to the instance hierarchy. In phase (2) the engineer assigns a suitable (here robot) from a role library. Here requirements (for example: “maximum load < 2t”) can be recorded; they later form the basis for the selection of suitable candidates. As soon as a suitable candidate is found, the referencing of a can be carried out in phase (3). The instance is thus implemented in a concrete technical way. A CAEX object thus has a relation to two classes: the abstract role and the concrete object type. The described CAEX model is available [BookLink@].

Fig. 2-7 The CAEX role concept A major advantage of role libraries is that they can be standardized, while product catalogues (system unit class libraries) of industrial manufacturers cannot. They are manifold and subject to permanent changes and further developments. But you can describe an industrial process in the manufacturing or process industry with few roles. These can be predefined and standardized in role libraries. Objects can even play multiple roles. How to do this is described in 2.2.5.9. Summary The CAEX role concept is used for the semantic identification of objects and is particularly important for the computational processing of the data, the modelling of requirements and the automation of planning steps. The so-called “Automation of Automation” is a key goal of engineering research cf. [GWF08], [YAB+06] or [SCEP07]. 2.2.3.5  How to analyse and model a technical system with CAEX

To understand object-oriented data modelling with CAEX in contrast to drawing-oriented engineering, an object-oriented analysis is recommended. →Table 2-2 shows typical steps of an object-oriented analysis of the engineering subject and illustrates the CAEX mapping. Table 2-2: Object-oriented analysis as preparation for CAEX modelling Object-oriented analysis

Examples

CAEX mapping

Identify the players or actors in the system of consideration Identify the abstract functionality or role of the players Identify the properties of the actors

Concrete robots, conveyors and motors, basically all “things” transport, robot, PLC, product, conveyor, tank length, price, colour, weight, order number Concrete nozzles, a USB Type A female, a digital output Max Load: 100kg Min level: 2mm

CAEX CAEX

CAEX

RobotType ColourType USB Type A Type MyAttributeTypeLib ABBProductCatalogue ControlFunctionRoleLib ElectricalInterfacesLib MyCarFactory

CAEX CAEX CAEX CAEX CAEX CAEX CAEX CAEX

Identify the interfaces of the players Identify the requirements of the actors Identify classes, attributes or interfaces Create library hierarchies

Create an AutomationML object hierarchy

CAEX CAEX CAEX CAEX

CAEX

Once you have identified the relevant objects and their ingredients, identify the related engineering objects in a source engineering tool and export them to CAEX. Proceed step by step and leave unknown things open. Check in between whether the relevant information is mapped to CAEX and whether the CAEX document reaches the recipient correctly. Correct the class and instance models in the source engineering tool if information is missing or incorrect and repeat the data exchange. Check the resulting CAEX models for consistency and completeness. Errors in the model always reflect errors in the source tool or in the data export, because CAEX itself only maps the data, but has no check functions. The engineering tools are responsible for the completeness and correctness of the engineering information. 2.2.4  The instance hierarchy 2.2.4.1  Overview CAEX instance hierarchies serve for the storage of individual and project related engineering information. They form the centre of the object model and contain all data objects including properties, interfaces, relations, and references. →Fig. 2-8 shows a simple example of an instance hierarchy of a manufacturing cell (download at [BookLink@]). The CAEX element is the root node of a concrete project and includes all required hierarchy levels and objects. AML can flexibly hold different hierarchies. The instances

themselves can have attributes and interfaces for their individual parameterization. The instance hierarchy depicts the topology of a concrete plant, sub-plant or views of it including internal relations.

Fig. 2-8 Example instance hierarchy Fig. 2-9 illustrates the CAEX model of the instance hierarchy.

Fig. 2-9 CAEX-modelling of an object tree It is represented by a CAEX element of the type . Its nested child objects are nested objects of the type , which all must have a Global Unique Identifier (GUID). 2.2.4.2  Three ways to model an instance hierarchy Instance hierarchies serve as root nodes for storing concrete engineering data in CAEX. General modelling rules for instance hierarchies are: – CAEX does not restrict the depth of the hierarchy levels, – CAEX does not restrict the architecture rules of a hierarchy, – CAEX does not define naming conventions for the hierarchies. There are three different ways for modelling instance hierarchies, useful for different application cases: without any classes, only with classes and a mixed way: – Modelling without classes: Instances can be directly modelled in the instance hierarchy in the form of nested InternalElements as an object tree. For each single object, all required attributes, interfaces and links etc. are defined on the instance level. This workflow supports data modelling without classes at all. This is useful, for example, if existing libraries are not the objective of the data exchange. In many industrial cases of data exchange, it is not recommended to transmit data without types. But it is explicitly allowed and useful as a starting point of a basic engineering or initial requirements modelling. – Modelling with classes only: The desired plant hierarchy is defined by a single InternalElement in the InstanceHierarchy. This InternalElement references one SystemUnitClass which defines the complete plant hierarchy. This workflow is useful if

the plant or unit structure is aimed to be a standard solution prepared for reuse. In this way, solution libraries can be modelled. – Mixed workflow: This is the typical workflow for practical use. Typical components are defined as SystemUnitClasses and their sub-structures are defined by aggregation of objects as InternalElements. Attributes may be predefined, and default attribute values may be set. The InstanceHierarchy is being used for the plant topology definition. In the next step, each defined internal hierarchical element can be associated with a role class in order to define the requirements to this object. Finally, it can be associated to a SystemUnitClass that describes the technical implementation of the object. An important limitation to inheritance in CAEX is that changes in a class are not automatically propagated to all instances. In CAEX, a class functions as a “copy template”; when instantiated, it is copied with its entire internal structure into the instance hierarchy, considering all inheritance relationships. The instance can then be freely modified, parameterized, supplemented or adapted. Nevertheless, the instance references its class; this reference allows a tool or user to trace the origin of the instance, to determine the changes if necessary and to perform an automatic update. 2.2.5  How to model a CAEX InternalElement 2.2.5.1  Example Let's assume we want to model a Tank B1 with CAEX. It should have a minimum volume of 12m3 and should be implemented by a certain concrete tank type (see →Fig. 2-10).

Fig. 2-10 Example - CAEX role concept 2.2.5.2  The architecture of an InternalElement To model Tank B1, first we need to understand the architecture of the CAEX data model of an internal element. This is shown in →Fig. 2-11 and comprises the following general properties:

– Attributes: allow the specification of object attributes – ExternalInterfaces: allow the specification of object interfaces – InternalElements: allow the specification of nested internal elements – SupportedRoleClass: allows specification of supported role classes – InternalLinks: allow specification of relations between interfaces

Fig. 2-11 Architecture of an InternalElement or SystemUnitClass A library of system unit classes consists of a hierarchy of system unit classes. In the same way, the instance consists of a hierarchy of internal elements. 2.2.5.3  Step 1: Modelling of a minimal instance Since we now know the structure of a CAEX InternalElement, let's model the example. In the first step, we create a new CAEX and name it B1 (see →Fig. 2-12). At first, this object has no meaning, no further details or definitions; it just acts as placeholder somewhere in the instance hierarchy.

Fig. 2-12 Example model for B1 2.2.5.4  Step 2: How to model the meaning of an object by associating a role According to the CAEX schema, every InternalElement has an optional CAEX element , which allows it to model the references to a role class, and to model required attributes or interfaces. In this example, we reuse an existing role class library associated with the role Tank by writing the path of the class Process-RoleClassLib/Tank into the value of the CAEX attribute RefBaseRoleClassPath. This association means that the InternalElement B1 plays the role of a Tank.

Fig. 2-13 Associating a role to an internal element 2.2.5.5  Step 3: How to model attributes Attributes describe certain properties of an object, for example its length. The architecture of the CAEX attribute definition is described in →Fig. 2-10. The most important aspects of an attribute are: – Value: This element allows the definition of the property value, for example “3.5”. The decimal separators shall be selected according to the AttributeDataType definition, for

example “xs:float” requires a “.” as decimal separator. – Unit: This element defines the unit of the attribute, for example “m”. – AttributeDataType: This element defines the data type of the attribute. If this optional attribute is not defined, the data type is assumed to be “xs:string”, whereas “xs” represents the XML namespace “→http://www.w3.org/2001/XMLSchema”.If the attribute is defined, the value must use the standard XML data types, for example “xs:boolean”, “ xs:integer”, and “xs:float”. Corresponding to the data type, the values of an attribute must conform to the XML rules, for example “xs:boolean” expects the values “true” or “false”, whereas “TRUE” or “FALSE” does not conform. – RefAttributeType: This element stores a path reference to an attribute type defined in an AttributeTypeLib. If the referenced attribute type is based on an XML data type, the AttributeDataType shall provide the base type of the referenced attribute. If the referenced attribute type is not based on an XML standard base type, the AttributeDataType may remain empty or not present. – DefaultValue: This element allows for the definition of the initial value of the attribute. It may be overridden by the value definition. – Constraints: This element allows for the definition of constraints. CAEX supports three constraint types: OrdinalScaledType, NominalScaledType and Unknown-Type. OrdinalScaledType allows for the definition of the “required value”, the “max value” and the “min value”. NominalScaledType allows for the definition of a discrete value range, for example the allowed value range of an attribute “safe” might have the value range “yes” and “no”. UnknownType allows for the specification of unknown constraints, for example regular expressions. They are outside of the CAEX standard and must be agreed to by the data exchange partners separately. – RefSemantic: This element allows for the definition of a semantic reference to a normative or informal dictionary, for example SI units, IEC 61987-1, NE150, IEC CCD or a proprietary web site. – Attribute: This element allows for the definition of attributes which may contain further attributes. This enables the description of hierarchical attribute structures. The semantic of an attribute is typically defined in external public or proprietary standards. The correctness of attributes is not in the scope of CAEX. The minimal attribute definition just defines a name. Hence, AutomationML can simply model an attribute list. All further elements are optional. →Fig. 2-14 demonstrates different aspects of attributes.

Fig. 2-14 Examples of CAEX attributes 2.2.5.6  Step 4: How to model a requirement In addition to the concrete properties of an internal element (properties or interfaces they actually have), the role concept allows the modelling of requirements (properties or interfaces which the internal element actually should have). Requirements are associated with the CAEX element . In this example, the tank should have a minimum volume of 12m3. →Fig. 2-15 shows the data model. An attribute is associated with the CAEX element and the constraint defines this attribute to be minimum value of 12 m3.

Fig. 2-15 How to define requirements 2.2.5.7  Step 5: How to reference a system unit class In engineering, devices are usually selected manually after specifying related requirements. →Fig. 2-16 demonstrates how to model this. Set the value of the CAEX attribute RefBaseSystemUnitPath to the path of the selected system unit class, and all needed properties are transferred; in this example the Volume of 15m3. This value is an assurance from the vendor.

Fig. 2-16 Referencing a system unit class 2.2.5.8  Step 6: How to map requirements to assurances: the MappingObject →Fig. 2-17 shows the overall example: internal element B1 is required to be a Tank with a minimum Volume of 12m3. Based on this requirement, the engineer has selected the

concrete VendorA_Tank37. The concrete tank assures the volume to 15m3, which fulfils the requirement. The question is: could this be processed automatically? Since the attribute naming is not necessarily the same for requirements and vendor assurances, the mapping should be modelled. For this, CAEX introduces the . The mapping object is useful, when requirements and vendor assurances should be automatically processed, for example for automatic device selection. →Fig. 2-17 illustrates this by means of the Tank B1.

Fig. 2-17 Mapping object The modelling guideline for mapping objects are: – If the related attributes’ names (or paths in case of nested attributes) are identical, no MappingObject is needed. – If the names are different, add a CAEX mapping object to the InternalElement. – For each name mapping, add a CAEX element AttributeNameMapping to the MappingObject. Define the name of the role attribute in the CAEX element RoleAttributeName. Define the name of the related attribute of the InternalElement (or SystemUnitClass) in the element SystemUnitAttributeName. – For each interface mapping, add a CAEX element InterfaceIDMapping to the MappingObject. Define the ID of the role interface in the CAEX element RoleInterfaceID. Define the ID of the related interface of the InternalElement (or SystemUnitClass) in the element SystemUnitInterfaceID. 2.2.5.9  How to associate multiple roles to an instance

CAEX supports referencing multiple roles in order to support industrial devices that can play multiple roles. An example is a multi-functional device that is a scanner, a printer or a fax device at the same time. In the following model, we assume that the roles Fax, Printer and Scanner are provided in a library. →Fig. 2-18 models the object MultiDevice01 with three attributes FaxBaudRate, PrintSpeed and FaxSpeed, and two interfaces PowerSupply and USB. Since this object can play three roles at the same time, the InternalElement MultiDevice01 models three separate CAEX RoleRequirements referencing the roles Printer, Fax and Scanner individually. The requirements of the three different roles are modelled separately and are illustrated by the individual role attributes speed of the printer, fax and scanner and the present role interfaces. For each CAEX RoleRequirement, an optional CAEX allows the definition of which attribute or interface of the corresponding role is associated to which attribute or interface of the related InternalElement. Given role attribute names in the MappingObject are relative to the referenced role class, hence each RoleRequirement forms its own context. The corresponding XML code of the example can be downloaded at [BookLink@].

Fig. 2-18 Modelling of multiple roles with CAEX 2.2.6  CAEX library and class types

2.2.6.1  Overview A main concept of object-orientation is the distinction between instances and classes. Instances are concrete individual objects, and classes are abstract types and can be understood as predefined templates. The term class and type are used synonymously. The engineering of complex plants in both the process and manufacturing industries is mostly no longer economically feasible without the reuse of proven templates. Libraries with their predefined classes are significantly responsible for the engineering efficiency gains, a success story of object-orientation. Therefore, the main advantage of CAEX is a comprehensive library concept. Libraries understand themselves as a class catalogue, holding reusable classes. These can be further refined with the help of relations within the class libraries, for example by inheritance or aggregation. The CAEX library concept distinguishes several types of libraries: the , the , the and the with their respective classes (see →Fig. 2-19). CAEX can model any number of these libraries, whereby the individual classes can be mapped as a hierarchy within their library, for instance to model a user-defined tree structure. However, the parentchild relationship between the classes has no semantics. This means that classes of the same type can inherit from each other and thus form class hierarchies - even across libraries or CAEX documents.

Fig. 2-19 Library types of CAEX A general modelling rule for the naming of libraries is: – Libraries and instance hierarchies are identified by their name. – Libraries with the same name are forbidden to be stored in the same CAEX file. This ensures the uniqueness of library names within a CAEX file. 2.2.6.2  SystemUnitClassLib Classes of type describe types of physical or logical plant objects or their combination (so-called units), for instance the type of a concrete robot, valve or tank. They may also model its technical implementation including its internal architecture, attributes, interfaces, nested internal elements and connections between the inner elements. An internal element can therefore contain further elements, which allows the description of any complex object structure through hierarchies. The role or function of a or its instances is defined by an association to an abstract .

SystemUnitClasses are combined in libraries of the type . With their help, for instance, product or solution catalogues can be modelled, published, distributed or sold electronically. 2.2.6.3  InterfaceClassLib A class of the type describes an interface type, for example, a flange, a signal, an electric interface, a nozzle or a general product node. Interfaces are used to map relations between objects. They are grouped together in libraries of the type . 2.2.6.4  RoleClassLib Classes of type also describe physical or logical plant objects, but on an abstract level and independent of a concrete technical implementation. Roles are the semantic counterpart of the system units. While system unit classes are usually used to map vendorspecific device types, roles abstract the variety of technical implementations and only map the basic functionality of a group of components. Roles can be used as placeholders in plant engineering and support implementation-independent basic planning. Examples of roles are Resource, Robot or PLC. The role concept is explained in detail in →section 2.2.3.4 Role classes are grouped together in libraries of the type . 2.2.6.5  AttributeTypeLib A class of type describes an attribute type and can be used to model properties (for example “length”) with their value, unit and description. Attribute types are grouped together in libraries of the type . They allow the modelling of proprietary or standard dictionaries and are a basis for the semantic interpretation of attributes. 2.2.7  How to model CAEX system unit classes 2.2.7.1  Example Let’s assume we want to model a product catalogue for a robot family. The library should model an abstract class RobotClass that models generic properties of all robots and should explicitly support the role of a robot. A second robot should be derived from the generic robot class and should provide specializations. Then, we want to model a cooperative robot system consisting of two concrete robots. →Fig. 2-20 shows the intended library which we will stepwise model in the next sub-sections.

Fig. 2-20 Example system unit class library 2.2.7.2  Step 1: Modelling a minimal system unit class →Fig. 2-21 illustrates a minimal system unit class library consisting of the library and one class. Names of classes or libraries must be unique between siblings. The ID is optional, while the actual identifier of the class is the name (to be correct it is the full path).

Fig. 2-21 A minimal system unit class 2.2.7.3  Step 2: How to model attributes →Fig. 2-22 illustrates the modelling of class attributes. After modelling the minimal class, we add a version number and some attributes following the attribute architecture described in 2.2.10.9.

Fig. 2-22 Modelling class attributes 2.2.7.4  Step 3: How to model derivations In order to derive a system unit class, we just model another class at an arbitrary position in the library. The hierarchical position has no semantics. The derivation is modelled by means of the CAEX tag RefBaseClassPath, which contains the path to the parent class. The new class does inherit all properties of the parent class, which are not modelled again in order to avoid redundancy. The new class can be extended, modified and overridden. →Fig. 2-23 illustrates this by means of the SpecialRobotClass derived from the RobotClass. Here, the attribute Weight is added to the inherited data.

Fig. 2-23 Derivation of a child system unit class 2.2.7.5  Step 4: How to model aggregations Our robot system consists two instances of the predefined robot classes. The modelling is illustrated in →Fig. 2-24. The new class CooperativeRobotsClass consists of two internal elements Robot01 and Robot02.

Fig. 2-24 Modelling a robot system aggregating two concrete robots 2.2.7.6  Step 5: How to model a system unit class hierarchy →Fig. 2-25 illustrates the resulting hierarchy of a system unit class library. Remember that the class hierarchy itself has no meaning; it is for structuring only. Inheritance must be modelled explicitly. It is absolutely acceptable to model all classes on the first level of a hierarchy.

Fig. 2-25 Example system unit class library For modelling product trees, it is recommended to model common properties on a common parent class and then to refine the classes to describe the product variants. Important: Do not confuse child internal elements and child classes. Child internal elements are baked into the class. Similar to attributes, child internal elements are an essential part of the class and will appear if the class is inherited. They model the internal technical implementation of the class. Child classes however will not appear and are not part of the upper class since the class hierarchy has no further meaning. 2.2.7.7  How to model supported role classes Since system unit classes are mostly in the ownership of a company and role classes are usually subject of standardization, it is helpful to model the mapping between them. To support this, the CAEX defines a sub-element element , which allows each class to define which role classes it supports. This enables a computer aided selection of suitable SystemUnitClasses for a certain RoleClass.

Fig. 2-26 Modelling of supported role classes 2.2.7.8  General architecture and modelling rules of a system unit class →Fig. 2-27 shows the architecture of a system unit class. General modelling rules are: – A SystemUnitClass can support an arbitrary number of RoleClasses. – Children or parents of the supported RoleClass are not automatically supported because they may be incompatible with the SystemUnitClass. If children of a RoleClass are also supported by a SystemUnitClass, they must be added into the SupportedRoleClass definition. – For each supported RoleClass, a mapping object can be defined that allows for the definition of the mapping between corresponding attribute names and interfaces. – The hierarchical model of system unit classes has no semantics; it is useful for organizational purposes. – Inheritance is modelled explicitly by referencing the parent class.

Fig. 2-27 General architecture of a CAEX SystemUnitClass 2.2.8  How to model CAEX interface classes 2.2.8.1  Example Let’s assume we want to model an interface class library; we need a nozzle, a specialized nozzle, a digital input and a digital output. →Fig. 2-28 illustrates the intended result.

Fig. 2-28 User-defined interface class library 2.2.8.2  Step 1: Modelling a minimal interface class →Fig. 2-29 illustrates a minimal interface class library consisting of the library MyInterfaceClassLib and one role class Nozzle. Both are identified by their name. Names of classes must be unique between siblings. Each interface class must be derived by one of the AutomationML base interface classes or their derived classes. In this case, we derive the Nozzle from the standard interface class AutomationMLBaseInterface.

Fig. 2-29 A minimal interface class 2.2.8.3  Step 2: How to model interface attributes →Fig. 2-30 illustrates the modelling of interface class attributes. In this example, we have added three attributes.

Fig. 2-30 Modelling interface attributes 2.2.8.4  Step 3: How to model derivations In order to derive an interface class, we just model another interface class at an arbitrary position in the interface class library. The real hierarchical position has no semantics. The derivation is modelled by means of the CAEX tag RefBaseClassPath, whose value represents the path to the parent class. The new class does inherit all properties of the parent class, which are not modelled again in order to avoid redundancy. The new class can be extended, and attributes can be overridden. →Fig. 2-31 illustrates this by means of the SpecialNozzle derived from the class Nozzle.

Fig. 2-31 Derivation of a child interface class 2.2.8.5  Step 5: How to model nested interfaces Interfaces may contain nested interfaces. An example is a USB port that has internal pins. →Fig. 2-32 illustrates this by adding a nested digital output signal to the Nozzle that provides

information about the nozzle. Important: Do not confuse child interfaces and nested interfaces. A nested interface must be considered as part of the class and will appear if the interface class is instantiated. Child interfaces will not appear once the interface class is instantiated.

Fig. 2-32 Nested interface 2.2.8.6  Step 4: How to model an interface class hierarchy →Fig. 2-33 illustrates a hierarchical interface class library containing classes for a nozzle, a special nozzle, a digital input and a digital output. For the modelling of class hierarchies, remember that the class hierarchies have no meaning; they are for structuring only. Inheritance must be modelled explicitly. It is absolutely acceptable to model all interface classes on the first level of the library hierarchy.

Fig. 2-33 Example interface class library

2.2.8.7  General architecture and modelling rules of an interface class →Fig. 2-34 shows the general architecture of an interface class. General modelling rules are: – Interfaces do not have a direction property. If required, this must be added as a CAEX attribute of the interface. – The hierarchical model of interface classes has no semantics but may be used to depict the user’s library structure. – Inheritance is modelled explicitly by referencing the parent class.

Fig. 2-34 General architecture of an interface class

2.2.9  How to model CAEX role classes 2.2.9.1  Example Let’s assume we want to model a role class library for our own purposes using typical roles needed for the modelling of a manufacturing cell. We need the role of a robot, a conveyor, a sensor and a turntable. →Fig. 2-35 illustrates the intended result.

Fig. 2-35 Intended user-defined role class library 2.2.9.2  Step 1: Modelling a minimal role class →Fig. 2-36 illustrates a minimal role class library consisting of the library My-RoleClassLib and one role class Robot. Both are identified by their name. Names of classes must be unique between siblings. In this case, we derive the robot from the predefined AML standard role class Resource described in →section 2.4.2.4.

Fig. 2-36 A minimal role class 2.2.9.3  Step 2: How to model role attributes and interfaces →Fig. 2-37 illustrates the modelling of role class attributes and interfaces. In this example, we have added three attributes and one digital input signal.

Fig. 2-37 Modelling role class attributes and interfaces 2.2.9.4  Step 3: How to model derivations In order to derive a role class, we just model another role class at an arbitrary position in the library. The hierarchical position has no semantics. The derivation is modelled by means of the CAEX tag RefBaseClassPath, with its value representing the path to the parent class. The new class inherits all properties of the parent class, which are not modelled again in order to avoid redundancy. The new class can be extended, and attributes can be overridden. →Fig. 238 illustrates this by means of the FastRobot derived from the Robot.

Fig. 2-38 Derivation of a child role class 2.2.9.5  Step 4: How to model a role class hierarchy →Fig. 2-39 illustrates the resulting hierarchical role class library containing classes for a robot, a laser sensor, a turntable and a conveyor with its specialized children. Remember that the class hierarchy has no meaning; it is for structuring only. Inheritance must be modelled explicitly. It is absolutely acceptable to model all role classes on the first level of a hierarchy.

Fig. 2-39 Resulting example role class library Role classes model the meaning of objects. Roles may be substantives (for example Robot) in order to model object roles (the world things), or they may be verbs in order to model skills capabilities or functions (for example transport). This enables the development and standardization of libraries of things as well as libraries of skills. Once a role class is assigned to an InternalElement, the meaning of the object becomes machine readable. However, after associating a role class to an InternalElement, the belonging role attributes and interfaces have no effect to the internal element itself, they model only requirements. In other words, required attributes and interfaces are modelled separately from the attributes and interfaces of the InternalElement, they even may be in conflict. Selecting devices that are not compliant with the requirements is a valid conflict. AutomationML allows modelling this conflict because it strictly differentiates requirements from vendor assurances. Example If the role of a blonde princess is awarded in an opera, a selected black-haired actress does not automatically become blonde by this choice. The contradiction of requirements and real properties is a matter of later clarification, as it could be intended or a mistake. Finding such contradictions is a topic of automatic consistency checks, enabled by separated data modelling.

2.2.9.6  General architecture and modelling rules of a role class →Fig. 2-40 shows the general architecture of a role class. The modelling rules are: – Role classes do not contain nested roles. – The hierarchical model of role classes has no semantics; it is useful only for organizational purposes. – Inheritance is modelled explicitly by referencing the parent class.

Fig. 2-40 General architecture of a role class 2.2.10  How to model CAEX attribute types

2.2.10.1  Example Let’s assume we want to model an attribute type library for general industrial purposes. →Fig. 2-41 illustrates the intended result.

Fig. 2-41 Intended attribute type library 2.2.10.2  Step 1: Modelling of a minimal attribute type First, we need to model the attribute type library. Attribute type libraries are recommended to model user specific, company specific, region specific, country specific etc. or normative

international standards with respect to attribute semantics, related to current or future attribute standards. This is the basis for the storage of agreed attribute semantics and enables independence from language and naming conventions. →Fig. 2-42 illustrates a minimal attribute type library consisting of the library GenericIndustrialAttributeTypeLib and one attribute type Level. Both are identified by their name. Names of attribute types must be unique between siblings.

Fig. 2-42 A minimal attribute type 2.2.10.3  Step 2: Properties of an attribute type The minimal definition of an attribute is just its name. This is already useful if lists of attribute names should be exchanged. But in most cases, further properties are of interest, but all of them are optional: they can be used but are not required. – Value: This element models the value of the attribute, for example “8.5”. The decimal separators shall be selected according to the AttributeDataType definition, for example “xs:float” requires a “.” as decimal separator. – Unit: This element defines the unit of the attribute, for example “m”. – AttributeDataType: This defines the data type of the attribute. If this optional attribute is not defined, the data type is assumed to be “xs:string”, whereas “xs” represents the XML namespace, e.g. “→http://www.w3.org/2001/XMLSchema”. If the attribute is defined, the value uses the standard XML data types, for example “xs:boolean”, “xs:integer”, “xs:float”, etc. For an XML datatype overview, see [XML Datatypes]. An overview gives [W3C20@]. The values of an attribute must conform to the XML rules, for example “xs:boolean” expects the values “true” or “false”, whereas “TRUE” or “FALSE” does not conform. – RefAttributeType: This element stores a reference path to an attribute type which is defined in an AttributeTypeLib. If the referenced attribute type is based on an XML data type, the CAEX attribute AttributeDataType shall provide this base type of the referenced attribute. If the referenced attribute type is not based on an XML standard base type, the AttributeDataType may remain empty or not present. – DefaultValue: This element allows for the definition of the initial value of the attribute. It may be overridden by the value definition. – RefSemantic: This element allows for the definition of a semantic references, see →section 2.2.10.4.

– Constraints: This element allows for the definition of constraints, see →section 2.2.10.5. – Attribute: This element allows for the definition of nested attributes, see →section 2.2.10.7. 2.2.10.4  Step 3: RefSemantic - How to model the semantics of attributes Machine readability requires semantics; either it is already known and agreed in advance, or it is referenced. CAEX supports semantic references; each attribute has an element that can hold semantic references to a normative or informal dictionary, for instance SI units, IEC 61987-1, a web site, etc. The syntax of this link is not part of the CAEX standard but must be provided by the semantic library owner. →Fig. 2-43 illustrates this by the attribute type IPCode, which models a reference to the IEC common data dictionary (CDD).

Fig. 2-43 Modelling the semantics of an attribute The syntax of the link is according to the specifications of the CDD. If the same attribute is also defined in another semantic library, it can be added as well, as the list of semantic links allows modelling multiple references. This concept allows CAEX to reference current or future semantic libraries and is flexible in adapting company standards or upcoming new semantic libraries. Benefit A key benefit of this technique is that the name of an attribute becomes irrelevant. Name the types as you want; the key is the reference, not the name. 2.2.10.5  Step 4: How to model attribute constraints Attributes are often constrained; a level should be within the max and min value, or a colour should be either blue or yellow. CAEX attributes support three constraint types: OrdinalScaledType, NominalScaledType and UnknowType. OrdinalScaledType allows for the definition of the “required value”, the “max value” and the “min value”. NominalScaledType allows for the definition of a discrete value range, for example the allowed value range of an attribute “safe” might have the value range “yes” and “no”. UnknownType allows the definition of any constraint; the syntax is not defined.

→Fig. 2-44 illustrates the modelling for our attribute Level. In this case, the level should be within the limits of 2...200mm, and the expected level is about 50mm.

Fig. 2-44 Modelling of constraints 2.2.10.6  Step 5: How to model derivations In order to derive an attribute type, we just model another attribute type at an arbitrary position in the library. The real hierarchical position has no semantics. The derivation is modelled by means of the CAEX tag RefAttributeType, whose value represents the path to the parent class. The new class inherits all properties of the parent attribute type, which are not modelled again in order to avoid redundancy. The new type can be extended, and attributes can be overridden. →Fig. 2-45 illustrates this by means of the RGB derived from Colour.

Fig. 2-45 Derivation of a child attribute type 2.2.10.7  Step 6: How to model nested attributes In many cases, attributes need a hierarchical structure. This is modelled by nested attributes. An example is a point attribute that requires modelling the x, y, and z position. →Fig. 2-32 illustrates this by adding nested attributes Red, Green and Blue to the RGB attribute type.

Important: Do not confuse child attribute types and nested attributes. Nested attributes are structural part of the attribute type and will appear if the attribute type is instantiated. Child attributes will not appear when the parent attribute type is instantiated.

Fig. 2-46 Nested attributes This technique is the basis for multilingual attributes as described in 2.6.7. Since nested attributes can be nested again, arbitrary hierarchical attribute structures can be modelled, which allows the definition of multi-dimensional arrays. The modelling of lists and arrays is described in 2.6.8. 2.2.10.8  Step 7: How to model an attribute class hierarchy →Fig. 2-47 illustrates a hierarchical attribute type library containing attribute types for general industrial purposes. For the modelling of attribute type hierarchies, remember that the hierarchy itself has no meaning and is for structuring only. Inheritance must be modelled explicitly. It is absolutely acceptable to model all attribute types on the first level of a hierarchy.

Fig. 2-47 Resulting hierarchical attribute type library 2.2.10.9  General architecture of an attribute type →Fig. 2-48 shows the general architecture of an attribute type.

Fig. 2-48 General architecture of an attribute type 2.2.11  How to model paths Paths are the basis for referencing classes or attribute types and require the definition of separators between different path elements. CAEX distinguishes between two separator types: alias separator and object separator. – Alias separator (used after an alias): “@” – Object separator (used between object hierarchies): “/” →Table 2-3 describes the modelling rules and examples for several application cases.

Table 2-3: Modelling rules for paths and examples Full path to

Modelling Rule

Example

Class

+ separator “/” + +

MySystemUnitLib/RobotClass [DemoLib]/[Tank/@01] Short path to a class in the next upper level of the library hierarchy: “RobotClass”

Class with Alias Class attribute Attribute type

Nested Attribute

Parent class Parent attribute type Parent attribute instance Attribute of an instance

+ alias separator “@” Path to the class +”/” +

+ separator “/” + +

+”/” + +”/” + + etc. If the referenced class or attribute is positioned in the next upper hierarchy level of the referencing item:

+ “/” +

ExternalLibAlias@ClassLib/PipeClass

ProcessEngineeringClassLib/Tank/height

MyAttributeTypeLib/IndustrialAttributes/Lev elType

MySystemUnitLib/RobotClass/Position/X

RobotClass Point Speed

d2c79ecb-0d84-4632-8e93-10f16d64fd9f d2c79ecb-0d84-4632-8e93-10f16d64fd9f/Level d2c79ecb-0d84-4632-8e9310f16d64fd9f/Pos/X alias@ d2c79ecb-0d84-4632-8e9310f16d64fd9f/Pos/X

The modelling rules for paths are: – If defined separators are potentially a valid part of object names, the following syntax shall be used: all path elements must be separated by square brackets “[” “]”. This allows for using the original names and the defined separators at the same time. – If the conflict case arises that the described brackets are part of object names, the brackets in the object names shall be escaped by means of common XML escape-

sequences. – It is allowed to use brackets also without any occurrence of conflicts. – A short path is allowed if the referenced class or attribute is positioned in the next upper hierarchy level of the referencing item. It comprises the name of the class or attribute type or the attribute only. CAEX does not check the validity of a path - neither the use of the normative separators nor the existence of the referenced item. The conformity with this standard requires the correct use of paths and the defined separators. 2.2.12  Modelling of relations 2.2.12.1  Overview Modelling technical systems requires mechanisms to set the data objects in relation to each other. A relation expresses physical or logical association between objects. This dependency may be of physical or logical nature. Parent-Child Relations (see →section 2.2.12.2): – parent-child relations between CAEX objects – parent-child relations between CAEX classes Inheritance relations (see →section 2.2.12.3) – inheritance relations between SystemUnitClasses – inheritance relations between RoleClasses – inheritance relations between InterfaceClasses – inheritance relations between AttributeTypes Class-instance relations (see →section 2.2.12.4) – relations between a SystemUnitClass and an instance of it – relations between a RoleClass and the assigned InternalElement – relations between an InterfaceClass and an instance of it – relations between an AttributeType and Attribute Instance-Instance relation (see →sections 2.2.12.5 and →2.2.12.6) – relations between CAEX ExternalInterface – relations between CAEX InternalElements

Fig. 2-49 Relation types in CAEX →Fig. 2-49 illustrates these types of relations by means of an example hierarchy. A more detailed description is given in the following sections. The related XML model is shown in →Fig. 2-50.

Fig. 2-50 XML-model of CAEX relations 2.2.12.2  Parent-child relation Parent-child relations between object instances or between classes are used to represent hierarchical object structures. Thus, an object robot can contain sub-objects arm and gripper. Child objects are modelled below their parent object and can themselves contain child objects. In this way, it is possible to model object hierarchies of any depth. Deleting an object also applies to the children. →Fig. 2-8 (see →section 2.2.3.5) shows a parent-child relation in the instance hierarchy. Parent-child relations are used both in the instance hierarchy and in all class libraries. →Fig. 2-51 illustrates this type of relationship in a class library. The

ParentChildRelationExampleClassLib contains a class ParentClass, which in turn contains a class ChildClass. Contrary to intuitive expectations, the parent-child relationship between classes does not represent an inheritance relationship, but only serves to represent user-defined library structures. Inheritance relationships are mapped using the CAEX tag RefBaseClassPath and are not limited to the next higher hierarchy level. In summary, parent-child relations between object instances represent an “as-is” relationship. Parent-child relations between classes have no meaning but serve only to map user-defined hierarchies.

Fig. 2-51 Parent-child relation within a class library 2.2.12.3  Inheritance relations CAEX supports inheritance between two classes. The inheritance relation is defined by a reference. Each CAEX class owns an attribute RefBaseClassPath which specifies the path of the corresponding parent class. The inheritance concept is identical for InterfaceClasses, RoleClasses, SystemUnitClasses and AttributeTypes. →Fig. 2-52 shows this with an example, in which a class SpecialRobot1234 inherits from the class Robot1234. As explained in →section 2.2.4.2, CAEX supports inheritance between two classes of the same type.

Fig. 2-52 Example of an inheritance relationship between classes

Further modelling rules for inheritance relations are – Inheritance is allowed among classes. A class can have an arbitrary number of child classes, but only one parent class. All changes in a class are automatically reflected by all child classes. – Inheritance means that all available parent and grandparent attributes, interfaces, internal elements, mapping objects or further content are automatically present in the child objects. – Inherited classes can be extended on the class level with new attributes, interfaces, etc. – Storage of inherited data: Inherited data is valid for the child data and can optionally be copied to the child physically in the XML document. Redefinition and storage of already inherited data is possible and useful in order to override or extend inherited information. If data is copied physically from a parent class to a child and changed on the parent class later on, the copied child data shall be updated. – Overriding of inherited data: Overriding of inherited properties is possible by the redefinition of the corresponding data with updated values in the child object. As long as given attribute constraints are defined in the parent class, the overridden data shall fulfil these requirements. – Deleting inherited data: Deleting of inherited properties is possible by the redefinition of the corresponding data again in the child object with the ChangeMode attribute set to “deleted”. – Inheritance is supported in a linear way. A child class may inherit from one parent class and may be a parent class of other classes at the same time. CAEX allows for the definition of parents, children, and grandchildren in this way with arbitrary deepness. The grandchild thus inherits from parents and grandparents etc. CAEX only supports inheritance from one parent. – If inheritance is required, the parent class specifies the full path of the class in the CAEX tag RefBaseClassPath. Ensure that the referenced class is valid and present. – If the desired parent class is placed one hierarchy level above the child class, the parent class can be specified by storing the name of the parent class in the CAEX tag RefBase-ClassPath without providing the full path. – Cross inheritance is not allowed; for example, a SystemUnitClass can only inherit from another SystemUnitClass. – Inheritance is optional. If inheritance is not required, leave the reference attribute RefBase-ClassPath empty or not be present at all. – A class can of course not inherit from itself or from a derivative of itself. – CAEX does not provide consistency checks of valid inheritance relations or of the valid existence of the reference item. 2.2.12.4  Class-instance relation Instances are characterized by a unique identifier and a parameter set. Regarding classinstance relations the following provisions apply. CAEX explicitly defines that the classinstance relationship is not an inheritance relationship, as discussed in →section 2.1.4. An example to create an instance is to copy a into a new

and then to assign the full path of this class to the CAEX tag Ref-BaseSystemUnitPath of the instance.

Fig. 2-53 Example of a class-instance relation →Fig. 2-53 shows this by means of an object ObjectA, which refers to its source class generic_Valve from the library mySystemUnitClassLib. The instance itself can be changed freely after the copying process. If the source-class of an instance changes, this does not entail a change of the instance. An automatic reflection or update of instance data according to a changed source class is a tool functionality and out of the scope of IEC 62424. The present path to the source class supports this functionality. This template-based object-orientation is in contrast to classic object-oriented software programming but needed in engineering. CAEX recommends that changes of a released class should be modelled as a new version of the class, which references the old version using the CAEX tag OldVersion. This makes it possible to track changes in class libraries during data exchange. The CAEX tag RefBaseSystemUnitPath does not necessarily have to reference a class but can alternatively reference an instance. This is CAEX-compliant and is the basis of the “mirror concept” according to IEC 62424. The referenced instance is called master object, while the referencing object acts only as a mirror image of the original and is therefore called “mirror object”. Both objects are regarded as identical, but changes may only be made to the original - these changes are “mirrored” in the Mirror Object. This allows one and the same object to be placed in several hierarchies. Thus, complex object networks with interlocked structures can be mapped. Further modelling rules for class-instance relations are: – A CAEX InternalElement or a CAEX ExternalInterface may be a singleton without a relation to any class. – If a CAEX InternalElement has a class-instance relation to a SystemUnitClass, it is created as a copy of this SystemUnitClass including the internal architecture of the class and all inherited information at the present time. For further usage, the copied source class is referenced in the CAEX tag RefBaseSystemUnitPath of the instance. This tag comprises the full path and name of the source class. Only one SystemUnitClass can be referenced. A class serves as a template in this way. – If a CAEX ExternalInterface has a class-instance relation to an InterfaceClass, it is created as a copy of this class including the internals of the class and all inherited information at the present time. For further usage, the copied source class is indicated

in the CAEX tag “RefBaseClassPath” of the ExternalInterface. This tag comprises the full path and name of the source class. Only one InterfaceClass can be referenced. – The relation between a CAEX InternalElement and a RoleClass is indicated by the CAEX tag RefBaseRoleClassPath of the belonging CAEX RoleRequirement. All RoleClass specifications must be copied to the corresponding CAEX object. If an attribute of a role class has no value, it may be removed from the instance data if not required. – The relation between a CAEX Attribute and a CAEX AttributeType is indicated by the CAEX tag RefAttributeType. All type specifications must be copied to the corresponding CAEX Attribute. If an attribute of the attribute type specification has no value, it may be removed from the CAEX attribute if required. – During the process of copying class data into an instance, all objects in the instance having an ID shall receive a new unique ID. The class is not changed. All references using the old IDs shall be updated accordingly across the whole CAEX document. – The extension or reduction of instance data compared to the source class is allowed. 2.2.12.5  Instance-instance relations between CAEX Interfaces Relations between object instances are modelled by linking object interfaces by connecting them with 's. All AML compliant interfaces must be derived directly or indirectly from an AML standard interface class. →Fig. 2-54 shows this using an example structure in which a start signal from R1 robot is connected to the signal input channel Channel01 of the IO-Board Board01, →Fig. 2-55 shows the XML structure.

Fig. 2-54 Relations between two instances

Fig. 2-55 XML-code for a Relation between two instances It is recommended to store links between objects at the top common parent object. Alternatively, it makes sense to store all links at the topmost object of the entire instance hierarchy. 2.2.12.6  Instance-Instance relations – the mirror concept CAEX supports modelling of multiple hierarchies at the same time. Since different hierarchical structures may depict the same data in different ways, it may be the case that a single instance needs to be part of multiple hierarchies. CAEX supports this by means of a “mirror concept”. →Fig. 2-56 explains this concept by means of two example structures LocationHierarchy and Resource Hierarchy and a corresponding library system unit class DemoLib. The internal element Tank1 is an instance of class C_Tank. This object has a second representation Tank1* which is positioned in a second hierarchy. Whereas master object Tank1 references its class C_Tank, Tank1* references the CAEX internal element Tank1. Hence, the object Tank1 acts as “master object” whereas Tank1* acts as “mirror object”. In the result, a single CAEX object is present at two positions.

Fig. 2-56 Multiple crossed structures The mirror concept can be applied in the same way to CAEX interface and Attributes. →Fig. 257 illustrates this by means of the attributes Price of the objects Tank or Pump. The same prices are modelled in another hierarchy at the object Prices which references the corresponding master attributes. Furthermore, this figure illustrates how mirror objects can be restructured in an alternative structure. But, by definition, all mirror objects always form leaves in an object tree.

Fig. 2-57 Example for mirror attributes and restructured mirror objects Modelling rules for the mirror concept are: – If more than one representation of a CAEX InternalElement, CAEX ExternalInterface or CAEX Attribute is required, each of them must be modelled as a corresponding CAEX InternalElement, CAEX ExternalInterface or CAEX Attribute at the required position. – One of them shall act as the “master object”. This master object holds all required information such as header information, attributes, interfaces, and internal elements and may have an instance-class relation to a CAEX class or type. – The other objects act as “mirror objects” and reference the “master object”. A “mirror object” acts as a pointer to the “master object”. For this, CAEX InternalElements shall

store the ID of the master object in the CAEX tag RefBaseSystemUnitPath, CAEX ExternalInterfaces shall store the ID of the master object in the CAEX tag RefBaseClassPath, and CAEX Attributes shall store the ID of the master attributes parent instance followed by the separator string “/” and the path of the attribute in the CAEX tag RefAttributeType. – A mirror object must not reference any class or type. – A master object must not have a back reference to one of its mirror objects. – If required, back references have to be handled by a software tool. – Mirror objects must not have children and must not store object related information except for the reference to the master object or the ChangeMode. Changes and modification of a mirror object must be exclusively modelled at the master object. – The mirror object may have a different name than the master object and may have its own header information. – A mirror CAEX InternalElement or ExternalInterface must have an own unique ID. A mirror object is considered to be identical to the master object. The individual ID supports distinguishing a mirror representation from the master. – If a master object is deleted, all corresponding mirror objects shall be also deleted in order to avoid inconsistencies. This is however a tool functionality out of the scope of CAEX or AutomationML. – It is possible to replace one of the mirror objects by the master object and delete the old master object. – If a mirror object is deleted, the master object shall not be affected. – CAEX InternalLinks shall interconnect master objects only. – A master object and its associated mirror objects shall be positioned within one or several CAEX instance hierarchies, within one SystemUnitClass, or within one InterfaceClass. – Master objects and associated mirror objects shall not be positioned across class borders. – Role Classes do not contain mirror objects. 2.2.13  Overriding inherited information 2.2.13.1  General concept Inheritance enables the economical use of data, because already inherited information is physically not stored at the child object. This is a key idea behind object-oriented data modelling: common data are stored at the most top class possible, and individual characteristics is modelled in the child classes. During instantiation of a class, inherited data is collected (dissolved) from the parents along the inheritance chain. This is why classes automatically reflect changes in the parent class. Overriding of already inherited information is explicitly supported by CAEX and allows for extending, removing, or modifying inherited data. Overriding is literally solved by “overwriting” and done by physically copying the inherited CAEX information into the child class. For test and development purposes, this can be done manually, but this might be a complex task and should be calculated by software. After this, the copied data can be freely modified.

2.2.13.2  Overriding attributes of a class Overriding an attribute of a class is achieved by physically copying the attribute from the inherited elements into the class. Here it can be freely modified. The identity between an inherited and an overridden attribute is its name, which must not be changed when it is overridden. If attribute constraints are defined in the parent class, the overridden data shall fulfil these requirements since the constraints are inherited too. However, the constraints may also be overridden. This general concept of overriding attributes is applicable to all CAEX class types. →Fig. 2-58 illustrates this by means of a SystemUnitClass, here the attribute Width is defined in the RobotClass, and the value of this attribute is overridden in the child class SpecialRobotClass. Overriding an attribute of an inherited InternalElement is a modification of the related InternalElement. This is described in the →section 2.2.13.3.

Fig. 2-58 Overriding an attribute 2.2.13.3  Overriding InternalElements or ExternalInterfaces In order to override an inherited InternalElement or ExternalInterface, it must be physically copied from the inherited elements. If the InternalElement is a sub element of a hierarchy, the overall parent branch starting from the related InternalElement upwards must be copied into the SystemUnitClass. Then, all unchanged information may be removed from the copy in order to avoid redundancy. Subsequently, the copied information it can be freely modified.

The identity between an inherited and an overridden item is again its name, which must not be changed when it is overridden. 2.2.13.4  Extending inherited data In order to extend inherited data, new attributes, interfaces, elements or links can be freely added. In case a required parent node is not present, it must be physically copied into the class, if required including the parent branch of the node. 2.2.13.5  Excluding inherited data In order to exclude inherited data, it must be physically copied into class, and the ChangeMode must be set to “delete”. 2.2.13.6  Undo overriding In order to undo the overriding, the physically copied parts of a class must be physically removed. Then, the original inheritance takes effect, and the overriding is undone. 2.2.14  Modelling version information 2.2.14.1  Overview Version information is helpful for trackable and transparent data exchange, and powerful for tracing information flow and navigating in a flood of different versions of information. As soon libraries, classes or instances are subject to modifications, version information is crucial to distinguish old and new data and to deal with modifications. CAEX supports manifold version information, useful for a variety of version related aspects (see →Table 2-4). These are deeply integrated into CAEX. These aspects are discussed in more detail in the following sections. Table 2-4: Version aspects of CAEX Version aspect

Use case

Version information for libraries, classes, and instances Source document information Source object information

Every CAEX object (library, class, instance, attribute, interface) has specific elements for storing version information. Examples are version number, description, revision, author, date etc. Each CAEX document has fields for storing information that identify its source tool(s).

SuperiorStandardVersion CAEX Schema Version

Every CAEX object (library, class, instance, attribute, interface) has specific elements for storing information about its origin object in the source tool. Each CAEX document provides information about which superior standard it belongs to. Each CAEX document identifies which Schema version it follows.

2.2.14.2  Version information for libraries, classes, instances, attributes A core element in the CAEX data model is the CAEX . It is embedded in the data model of CAEX libraries, classes, instances, attributes etc. This element has specific subelements for storing version information about the associated object. The CAEX header is a part of the CAEX basis type which is the root base class for every CAEX element. The provides the following data elements. ChangeMode: The value of ChangeMode can be state, create, delete and change. The value state is used for objects that have not changed since previous data exchange. The value create is used for new objects that have been created. The value delete is used if an object is to be deleted. The object is therefore not physically removed out of the CAEX file but marked as to be deleted. The value change is used if the object has changed. The ChangeMode is only valid for the item itself; for example, if an attribute has changed its value, only its value is marked with the ChangeMode value ”change”, not that of the host object of the attribute. Description, Version, Revision, Copyright: These attributes and elements allow storage of version information for each object. AdditionalInformation: This attribute allows storage of arbitrary additional information of any type. SourceObjectInformation, OriginID and SourceObjID: These CAEX items allow storing organizational information about the origin of each CAEX object. Details are specified in 2.2.14.3 and 2.2.14.4.

Fig. 2-59 General architecture of the CAEX Header

Fig. 2-60 Example – basic version information for an internal element The general modelling rules for version related information for libraries, classes, instances, or attributes are: – CAEX does not define a syntax or semantics of a version number, which has a string data type. – Versioning of libraries is mandatory, and every CAEX library must define its version number utilizing the CAEX element Version. Set the value of this element to an appropriate string, for example “1.0”. – CAEX libraries are identified by their name only, and therefore it is forbidden to store libraries with the same name but different version numbers in the same AML file. – Versioning of classes, instances or attributes is optional. If required, CAEX classes must define their version number utilizing the CAEX element Version, for example “3.0”. – A new version of a class should be modelled as a new class with another name. Within the new class, the full path of the old version of the class should be stored in the CAEX tag OldVersion of the CAEX element Revision. This provision supports tracking of changes across different versions of a class. – The creator of a CAEX document must ensure that only version-compatible classes and external documents are referenced. 2.2.14.3  Meta information about the AML source tool(s) To be able to interpret the data in an AML document, a reference to the source is useful. Since CAEX provides neutral syntax only and allows library based semantic definition, it can hold a mix of multiple semantic models, utilizing standardized as well as proprietary data. Therefore, it is important to know whether it comes from Siemens, ABB, EPLAN or COMOS etc. For this, each AML document has fields for storing information that identify its source tool(s).

→Fig. 2-61 illustrates this. Let’s assume a Tool A exports data to a CAEX document. In order to identify the owner of the data, CAEX provides a field SourceDocumentInformation that specifies dedicated fields to identify the source tool.

Fig. 2-61 SourceDocumentInformation The general modelling rules for source document information are: – Each CAEX document must provide information about the source(s). This information is comparable to a business card; it identifies the source of information. – The values of the origin information must be embedded by the tool that creates the CAEX document and must be of type xs:string. – A CAEX document can hold an arbitrary number of source identifiers. In a data exchange tool chain, all participating tools must add their origin information in the CAEX document. As a result, a CAEX document may contain information about multiple source tools of a data exchange tool chain. – A tool may remove the origin information of other tools. This may hinder the iterative data exchange with the other tools; hence, the removal of origin information of other tools is not recommended. – The origin information must be stored by means of the CAEX element SourceDocumentInformation of the root object of the CAEX document. SourceDocumentInformation models various aspects, the related attributes are listed in →Table 2-5.

Table 2-5: Attributes of the CAEX SourceDocumentInformation Name

Usage

Description

OriginName OriginID

mandatory mandatory

OriginVendor OriginVendorURL OriginVersion OriginRelease LastWritingDateTime OriginProjectTitle OriginProjectID

optional optional mandatory optional mandatory optional optional

The name of the origin tool. This may change over time. An identifier of the origin tool. This ID should not change over the lifetime of the origin. The vendor of the origin. The vendors URL. The version of the origin tool. Release information of the origin tool. Data and time of the CAEX document creation. The origin project title. An origin project identifier. This ID should not change over the lifetime of the origin.

→Fig. 2-62 illustrates the application of the CAEX SourceDocumentInformation by means of an example.

Fig. 2-62 Concept of CAEX SourceDocumentInformation 2.2.14.4  Meta information about source objects CAEX objects typically represent source objects created in their original tools. Especially in iterative engineering, when the process of exporting the data into CAEX happens, it is useful that every CAEX object knows exactly where it comes from. According to IEC62424 (see →section 2.2.14.3), each CAEX document provides information about the source tool that is the source of the AML data. The meta information about source objects goes one step further. AML allows the modelling of information about the original source object within the source tool. The modelling rules are: – CAEX recommends using the optional CAEX element SourceObjectInformation with its attributes OriginID and SourceObjID to identify the source tool of each CAEX object, for

example libraries, classes, instances, attributes. – The OriginID corresponds to the OriginID of the SourceDocumentInfo described in 2.2.14.3. – The SourceObjID corresponds to the proprietary identifier in the source tool. →Fig. 2-63 illustrates the concept: during export, the AML objects are informed about their individual origin. This supports difference calculations and repeated exports in an iterative engineering workflow.

Fig. 2-63 The concept of SourceObjectInformation 2.2.14.5  SuperiorStandardVersion CAEX may be adopted by different superior standards. The CAEX schema provides a dedicated field in order to identify which superior standard the CAEX document belongs to. The modelling rule to identify a CAEX 3.0 document as part of the AutomationML Edition 2 standard is: – Set the value of the CAEX element SuperiorStandardVersion to AutomationML 2.10” 2.2.14.6  CAEX Schema Version

The CAEX file format provides a dedicated field in order to identify its CAEX version. The current version is 3.0, adopted by AML Edition 2. The modelling rule is: – Set the value of the CAEX element SchemaVersion to “3.0”.

2.3  AutomationML Edition 2 versus CAEX 3.0 2.3.1  Overview AutomationML adopts CAEX on “as-is” basis, including the CAEX schema and modelling rules of the CAEX standard. This means there is syntactically no difference between a CAEX object model and an AutomationML object model. Every AutomationML object is a CAEX object model – but not vice versa. AutomationML Edition 2 defines a very small set of additional generic modelling rules; a large part of the AutomationML definition is in AutomationML libraries and best practice recommendations.

Fig. 2-64 relation between AutomationML and CAEX The main generic modelling rules on top of CAEX 3.0 are: – AutomationML refines general modelling rules for more restrictive identification of objects (see →section 2.3.2). – AutomationML defines rules about required versions of the selected file formats (see →section 2.3.3).

– AutomationML defines reference mechanisms to reference external files (see →section 2.5). – AutomationML provides a series of AutomationML standard libraries (see →section 2.4). – AutomationML defines mechanisms to model lists, arrays, multilingual attributes and regular expressions for modelling special aspects as ports, facets, groups and external documents (see →2.6). – AutomationML defines a Container format which allows bundling of multiple files into a single container file (see →section 2.6.9). Based on these rules, the AML society developed a series of modelling recommendations for different applications in industry. 2.3.2  Additional general modelling rules The following AutomationML rules are defined on top of the CAEX definitions: – In contrast to a CAEX object, an AML object must be directly or indirectly assigned to a standard AML RoleClass in order to specify its semantics. In the scope of AML, a CAEX object with no reference to an AML standard role class is named a user-defined object and not an AML object. – User-defined objects or classes should be assigned to a role class and must use AML standard attributes whenever applicable. However, user-defined objects or classes may be assigned to a standard AML role class, a user-defined role class, or no role class. In this case, those user-defined objects are not AML objects and are defined outside of the AutomationML standard. – The identification of instances (InternalElements or ExternalInterfaces) is more restrictive compared to CAEX: AML Edition 2 recommends the identification by means of GUIDS according to RFC4122. For the comparisons of two identifiers, it is defined that brackets, braces, dashes or spaces are allowed but are irrelevant. The following GUID examples are identical: – 48d23207-09e0-4104-82fb-344007d2b7f5 – { 48d23207-09e0-4104-82fb-344007d2b7f5 } – If attribute units are required, user-defined attributes must be based on the same unit system. AutomationML does not define a unit system, but it is suggested to use SI units according to ISO 80000-1. For units regarding information technology, it is suggested to use IEC 60027. 2.3.3  Additional AutomationML versioning rules On top of the CAEX versioning rules described in →section 2.2.14, AML defines further rules. 2.3.3.1  AutomationML Version After modelling of all the details of version information of libraries, classes, instances and attributes, the overall AutomationML document itself must be compliant to its AutomationML version. AutomationML is a standard that may evolve over time, this book is

related to AutomationML Edition 2 according to [IEC 62714:Ed2] from 2018. Hence, it is important that each AML document can identify which AutomationML version it is subject to. The AutomationML standard combines established data formats of a particular version. This rule is specified in IEC 62714 (see clause 0). That version information is interesting for the sustainable long-term application of AutomationML and helps to distinguish AutomationML Ed. 2 documents from earlier or future versions. The modelling rule is: – The creator of an AML document must ensure that only version compatible classes and external documents are referenced. Mixing AutomationML Ed. 2 with other AML versions is not allowed. All files of an AML document must follow the given AML version. 2.3.3.2  SuperiorStandardVersion CAEX is an independent standard and AML integrates CAEX. Hence AML acts as superior standard. CAEX could be adopted by other standards too. With respect to the application of CAEX 3.0 in the domain of AML Ed. 2, each CAEX file must therefore explicitly identify itself as belonging to AML Ed. 2 and thus confirm that it follows the rules of AML Ed. 2. The modelling rule is: – Set the value of the CAEX element SuperiorStandardVersion to “AutomationML 2.10”. →Fig. 2-65 illustrates the version information of an AML Ed. 2 compatible CAEX document. This information is mandatory.

Fig. 2-65 CAEX version information according the AML Edition 2

2.4  AutomationML base libraries 2.4.1  General modelling rules AutomationML defines essential base libraries needed for the modelling of core AutomationML concepts. The basic libraries are introduced in this section. The libraries are available for download at [BookLink@]. General modelling rules are: – All described attributes are part of the AML standard library and may be removed after the instantiation if not needed. – All AML objects must be associated directly or indirectly to the standard role class AutomationMLBaseRoleClass. – All AML interfaces must be associated directly or indirectly to the standard interface class AutomationMLBaseInterface.

2.4.2  Basic Role Class library →Fig. 2-66 shows the AML base role class library. These classes describe abstract and fundamental roles or functions.

Fig. 2-66 AutomationML base role class library 2.4.2.1  RoleClass AutomationMLBaseRole →Table 2-6 specifies the role class AutomationMLBaseRole. Table 2-6: RoleClass AutomationMLBaseRole Class name

AutomationMLBaseRole

Description

The role class AutomationMLBaseRole is a basic abstract role type and the base class for all standard or user-defined role classes. None AutomationMLBaseRoleClassLib/AutomationMLBaseRole

Parent class Path for element reference Attributes

None

2.4.2.2  RoleClass Group →Table 2-7 specifies the role class Group. Table 2-7: RoleClass Group Class name

Group

Description

The role class Group is a role type for objects that serve for the grouping of mirror objects that belong together from a certain engineering perspective. AML Group objects shall reference this role. Details and examples are specified in 2.6.4. AutomationMLBaseRoleClassLib/AutomationMLBaseRole

Parent class Path for element reference Attributes

AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Group Name: AssociatedFacet RefAttributeType: AutomationMLBaseAttributeTypeLib/AssociatedFacet Semantics: see 2.4.4

2.4.2.3  RoleClass Facet →Table 2-8 specifies the role class Facet. Table 2-8: RoleClass Facet Class name

Facet

Description

The role class Facet is a role type for objects that serve as sub-view on attributes or interfaces of an AML object. AML Facet objects shall reference this role. Details and examples are specified in 2.6.3. AutomationMLBaseRoleClassLib/AutomationMLBaseRole AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Facet

Parent class Path for element reference Attributes

None

2.4.2.4  RoleClass Resource →Table 2-9 specifies the role class Resource.

Table 2-9: RoleClass Resource Class name

Resource

Description

The role class Resource is a basic abstract role type and the base class for all AML resource roles. It describes plants, equipment or other production resources. AML resource objects shall directly or indirectly reference this role. If required, AML resource objects shall model relations to products and processes by means of a CAEX external interface of type PPRConnector. The PPR concept is specified in 2.6.6. AutomationMLBaseRoleClassLib/AutomationMLBaseRole

Parent class Path for element reference Attributes

AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Resource None

2.4.2.5  RoleClass Product →Table 2-10 specifies the role class Product. Table 2-10: RoleClass Product Class name

Product

Description

The role class Product is a basic abstract role type and the base class for all AML product roles. It describes products, product parts or product related materials that are processed in the described plant. AML product objects shall directly or indirectly reference this role. If required, AML product objects shall model relations to resources and processes by means of a CAEX external interface of type PPRConnector. The PPR concept is described in section 2.6.6. AutomationMLBaseRoleClassLib/AutomationMLBaseRole

Parent class Path for element reference Attributes

AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Product None

2.4.2.6  RoleClass Process →Table 2-11 specifies the role class Process.

Table 2-11: RoleClass Process Class name

Process

Description

The role class Process is a basic abstract role type and the base class for all AML process roles. It describes production related processes. AML process objects shall directly or indirectly reference this role. If required, AML process objects shall model relations to products and processes by means of a CAEX external interface of type PPRConnector. The PPR concept is described in section 2.6.6. AutomationMLBaseRoleClassLib/AutomationMLBaseRole

Parent class Path for element reference Attributes

AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Process None

2.4.2.7  RoleClass Structure →Table 2-12 specifies the role class Structure. Table 2-12: RoleClass Structure Class name

Structure

Description

The role class Structure is a basic abstract role type for objects that serve as structure elements in the plant hierarchy, for example a folder, a site or a manufacturing line. AML structure objects shall directly or indirectly reference this role. AutomationMLBaseRoleClassLib/AutomationMLBaseRole

Parent class Path for element reference Attributes

AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Structure None

2.4.2.8  RoleClass ProductStructure →Table 2-13 specifies the role class ProductStructure. Table 2-13: RoleClass ProductStructure Class name

ProductStructure

Description

The role class ProductStructure is an abstract role type for a product-oriented object hierarchy. AML product structure objects shall directly or indirectly reference this role. AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Structure AutomationMLBaseRoleClassLib/AutomationMLBaseRole/ StructureProductStructure

Parent class Path for element reference Attributes

None

2.4.2.9  RoleClass ProcessStructure

→Table 2-14 specifies the role class ProcessStructure. Table 2-14: RoleClass ProcessStructure Class name

ProcessStructure

Description

The role class ProcessStructure is an abstract role type for a process-oriented object hierarchy. AML process structure objects shall directly or indirectly reference this role. The application is explained in 2.6.6. AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Structure AutomationMLBaseRoleClassLib/AutomationMLBaseRole/ Structure/ProcessStructure

Parent class Path for element reference Attributes

None

2.4.2.10  RoleClass ResourceStructure →Table 2-15 specifies the role class ResourceStructure. Table 2-15: RoleClass ResourceStructure Class name

ResourceStructure

Description

The role class ResourceStructure is an abstract role type for a resource-oriented object hierarchy. AML resource structure objects shall directly or indirectly reference this role. The application is explained in 2.6.6. AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Structure AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Structure/ResourceStructure

Parent class Path for element reference Attributes

None

2.4.2.11  RoleClass ExternalData →Table 2-16 specifies the role class ExternalData. Table 2-16: RoleClass ExternalData Class name

ExternalData

Description

The role class ExternalData is an abstract role type for a document type and the base class for all document type roles. It describes different document types. AML document objects shall directly or indirectly reference this role. Examples are described in 2.5.4. AutomationMLBaseRoleClassLib/AutomationMLBaseRole

Parent class Path for element reference Attributes

AutomationMLBaseRoleClassLib/AutomationMLBaseRole/ExternalData None

2.4.3  Basic Interface Class Library →Fig. 2-67 shows the AML base interface class library. These classes describe abstract and fundamental interfaces.

Fig. 2-67 Basic AutomationML standard interface class library 2.4.3.1  InterfaceClass AutomationMLBaseInterface →Table 2-17 specifies the interface class AutomationMLBaseInterface. Table 2-17: InterfaceClass AutomationMLBaseInterface Class name

AutomationMLBaseInterface

Description

The interface class AutomationMLBaseInterface is a basic abstract interface type and shall be used as parent for the description of all AML interface classes. None AutomationMLInterfaceClassLib/AutomationMLBaseInterface

Parent class Path for element reference Attributes

None

2.4.3.2  InterfaceClass Order →Table 2-18 specifies the interface class Order.

Table 2-18: InterfaceClass Order Class name

Order

Description

The interface class Order is an abstract class that shall be used for the description of orders, for example a successor or a predecessor. AutomationMLInterfaceClassLib/AutomationMLBaseInterface AutomationMLInterfaceClassLib/AutomationMLBaseInterface/Order

Parent class Path for element reference Attributes

Name: Direction RefAttributeType: AutomationMLBaseAttributeTypeLib/Direction Semantics: see 2.4.4

2.4.3.3  InterfaceClass Port →Table 2-19 specifies the role class Port. Table 2-19: InterfaceClass Port Class name

Port

Description

The interface class Port is an interface type for interfaces that may contain several nested interfaces. It allows describing complex interfaces. AML Port interfaces shall reference this interface class. Details and examples are described in 2.6.2. AutomationMLInterfaceClassLib/AutomationMLBaseInterface

Parent class Path for element reference Attributes

AutomationMLInterfaceClassLib/AutomationMLBaseInterface/Port Name: Direction RefAttributeType: AutomationMLBaseAttributeTypeLib/Direction Semantics: see 2.4.4 Name: Cardinality RefAttributeType: AutomationMLBaseAttributeTypeLib/Cardinality Semantics: see 2.4.4 Name: Category RefAttributeType: AutomationMLBaseAttributeTypeLib/Category Semantics: see 2.4.4

2.4.3.4  InterfaceClass PPRConnector →Table 2-20 specifies the interface class PPRConnector.

Table 2-20: InterfaceClass PPRConnector Class name

PPRConnector

Description

The interface class PPRConnector shall be used in order to provide a relation between resources, products and processes. The PPR concept is described in 2.6.6. AutomationMLInterfaceClassLib/AutomationMLBaseInterface AutomationMLInterfaceClassLib/AutomationMLBaseInterface/PPRInterface

Parent class Path for element reference Attributes

None

2.4.3.5  InterfaceClass ExternalDataConnector →Table 2-21 specifies the interface class ExternalDataConnector. Table 2-21: InterfaceClass ExternalDataConnector Class name

ExternalDataConnector

Description

The interface class ExternalDataConnector is a basic abstract interface type and shall be used for the description of connector interfaces referencing external documents. The classes COLLADAInterface and PLCopenXMLInterface are derived from this class. All existing and future connector classes shall be derived directly or indirectly from this class. AutomationMLInterfaceClassLib/AutomationMLBaseInterface

Parent class Path for element reference Attributes

AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ExternalDataConnector Name: refURI RefAttributeType: AutomationMLBaseAttributeTypeLib/refURI Semantics: see 2.4.4

2.4.3.6  InterfaceClass COLLADAInterface Table 2-22 specifies the interface class COLLADAInterface.

Table 2-22: InterfaceClass COLLADAInterface Class name

COLLADAInterface

Description

The interface class COLLADAInterface is used in order to reference external COLLADA documents and to publish interfaces that are defined inside an external COLLADA document. Details are specified in section 2.5.1. AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ExternalDataConnector

Parent class Path for element reference Attributes

AutomationMLInterfaceClassLib/AutomationMLBaseInterface/COLLADAInterface Name: refURI RefAttributeType: AutomationMLBaseAttributeTypeLib/refURI Semantics: see 2.4.4 Name: refType Semantics: see 2.4.4 Name: target Semantics: see 2.4.4

2.4.3.7  InterfaceClass PLCopenXMLInterface →Table 2-23 specifies the interface class PLCopenXMLInterface. Table 2-23: InterfaceClass PLCopenXMLInterface Class name

PLCopenXMLInterface

Description

The interface class PLCopenXMLInterface is used in order to reference external PLCopen XML documents or to publish signals or variables that are defined inside of a PLCopen XML logic description. Details are specified in section 2.5.1. AutomationMLBaseInterface/ExternalDataConnector

Parent class Path for element reference Attributes

AutomationMLInterfaceClassLib/AutomationMLBaseInterface/PLCopenXMLInterface Name: refURI RefAttributeType: AutomationMLBaseAttributeTypeLib/refURI Semantics: see 2.4.4

2.4.3.8  InterfaceClass ExternalDataReference →Table 2-24 specifies the interface class ExternalDataReference.

Table 2-24: InterfaceClass ExternalDataReference Class name

ExternalDataReference

Description

The interface class ExternalDataReference is used in order to reference external documents out of the scope of AutomationML. Details are described in section 2.5.4. AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ExternalDataConnector AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ExternalDataReference

Parent class Path for element reference Attributes

Name: MIMEType RefAttributeType: AutomationMLBaseAttributeTypeLib/MIMEType Semantics: see 2.4.4

2.4.3.9  InterfaceClass Communication →Table 2-25 specifies the interface class Communication. Table 2-25: InterfaceClass Communication Class name

Communication

Description

The interface class Communication is an abstract interface type and shall be used for the description of communication related interfaces. Further communication related classes shall be directly or indirectly derived from this class. AutomationMLInterfaceClassLib/AutomationMLBaseInterface

Parent class Path for element reference Attributes

AutomationMLInterfaceClassLib/AutomationMLBaseInterface/Communication None

2.4.3.10  InterfaceClass SignalInterface →Table 2-26 specifies the interface class SignalInterface. Table 2-26: InterfaceClass SignalInterface Class name

SignalInterface

Description

The interface class SignalInterface shall be used for modelling signals. This interface type is configurable and allows description of digital and analogue inputs and outputs as well as configurable inputsoutputs. AutomationMLInterfaceClassLib/AutomationMLBaseInterface/Communication AutomationMLInterfaceClassLib/ AutomationMLBaseInterface/SignalInterface

Parent class Path for element reference Attributes

None

2.4.4  Basic Attribute Type Library

→Fig. 2-68 shows the AML base attribute type library. These types describe abstract and fundamental attributes.

Fig. 2-68 Basic AutomationML standard attribute type library →Table 2-27 summarizes their meaning and application.

Table 2-27: Attribute Types of the AML base libraries Attribute Name

Semantics

AssociatedExternalValue

This attribute contains sub-attributes which allow to interconnect a CAEX attribute to an item in an external document. The sub-attributes are described in Table 26. The application of the AssociatedExternalValue is described in section 2.5.5. The attribute AssociatedExternalValue itself does not have a value. AttributeDataType: empty Parent: AutomationMLBaseAttributeTypeLib

AssociatedFacet

Cardinality

Category

Direction

Path: AutomationMLBaseAttributeTypeLib/AssociatedExternalValue This attribute must be used for the definition of the name of a related Facet. The application is described in section 2.6.5 Example: AssociatedFacet = “PLCFacet”. AttributeDataType: xs:string Parent: AutomationMLBaseAttributeTypeLib/AssociatedFacet This attribute belongs to a CAEX ExternalInterface and must be used to describe the allowed maximum and minimum numbers of connections from/to this interface. The attribute Cardinality itself is a complex attribute and must not have a value. The corresponding sub-attributes are described in Table 2-28. AttributeDataType: This attribute has no AttributeDataType since the attribute has no value. Path: AutomationMLBaseAttributeTypeLib/Category This attribute belongs to a CAEX ExternalInterface and describes the category of this interface. The value of this attribute is user-defined. Only interface classes with the same category value are allowed to be connected. This standard does not predefine category values. Example: Category = “MaterialFlow” AttributeDataType: xs:string Path: AutomationMLBaseAttributeTypeLib/Category This attribute is used to describe a direction of a CAEX interface, for example of a signal or of an interface. Allowed values: In, Out or InOut. CAEX Interfaces using this attribute follow the following provisions: Interfaces with the direction In shall only be connected to interfaces with the direction Out or InOut. Interfaces with the direction Out shall only be connected to interfaces with the direction In or InOut. This information can be used, for example, to prove the validity of a connection. Examples: Direction = “Out” (for example a plug) Direction = “In” (for example a socket) Direction = “InOut” AttributeDataType: xs:string

Attribute Name DocLang

Frame

ListType

LocalizedAttribute

MIMEType

Semantics Path: AutomationMLBaseAttributeTypeLib/Direction The DocLang describes the language of a referenced document. The attribute shall have a value according to the RFC1766 standard. Example: DocLang = de – the document is in German language valid in Germany. DocLang = fr-CA – the document is in French language valid in Canada. AttributeDataType: xs:string Parent: AutomationMLBaseAttributeTypeLib Path: AutomationMLBaseAttributeTypeLib/DocLang The Frame describes the geometric position of the belonging InternalElement relative to its parent. It defines the following nested attributes: x: translation along the x axis of the parent coordinate system in meters y: translation along the y axis of the parent coordinate system in meters z: translation along the z axis of the parent coordinate system in meters rx: Rotation around the x axis of the shifted coordinate system in degrees (°) ry: Rotation around the y axis of the shifted coordinate system in degrees (°) rz: Rotation around the z axis of the shifted coordinate system in degrees (°) All nested attributes are of AttributeDataType: xs:string. The usage and examples are described in section 2.2.8.5. This attribute must be used for attributes that contain an unsorted list of attributes. The concept is described in section 2.6.8.2. AttributeDataType: empty Parent: AutomationMLBaseAttributeTypeLib/ListType This attribute must be used for sub-attributes describing a language alternative of its parent attribute. The concept is described in section 2.6.7.3 AttributeDataType: xs:string Parent: AutomationMLBaseAttributeTypeLib/LocalizedAttribute This attribute describes the type of a referenced document. The attribute must have values according to the Multipurpose Internet Mail Extensions (MIME) standard. Examples: - MIMEType = “application/pdf” - this means that this document is of file type pdf. - MIMEType = “application/xml”: this means that this document is of type xml. - MIMEType = “application/msword”: this means that this document is of type doc. - MIMEType = “application/msexcel”: this means that this document is of type xls. AttributeDataType: xs:string

Attribute Name

Semantics

OrderedListType

refURI

Parent: AutomationMLBaseAttributeTypeLib Path: AutomationMLBaseAttributeTypeLib/MIMEType The attribute “OrderedListType” shall be used for attributes that contain a sorted list of attributes. The concept is described in section 2.6.8.2. AttributeDataType: empty Parent: AutomationMLBaseAttributeTypeLib/OrderedListType This attribute must be used in order to store a path to an external document. AttributeDataType: xs:anyURI Path: AutomationMLBaseAttributeTypeLib/refURI

Table 2-28: Sub-attributes of the attribute Cardinality Attribute

AttributeDataType

Description

Example

MinOccur

xs:unsignedInt

The MinOccur value describes the minimum possible number of connections to or from the corresponding interface class. The attribute shall have values greater than or equal to 0.

MaxOccur

xs:unsignedInt

The MaxOccur describes the maximum possible number of connections to or from the corresponding interface class. The attribute shall have values greater than or equal to MinOccur, or 0 which means infinite.

MinOccur = 1 This means that this Port should be connected with at minimum one other Port. MaxOccur = 3 This means that this Port can be connected with a maximum of three other ports.

2.5  Referencing external documents AutomationML provides mechanisms to reference external documents, for example geometry files, logics information or other documents. The reference mechanism is flexible and utilizes the standard AML interface ExternalDataConnector or one of its derivatives. →Fig. 2-69 illustrates the general mechanism: the AML object references the external document by means of an external interface.

Fig. 2-69 Referencing external documents 2.5.1  Referencing COLLADA and behaviour documents References to COLLADA documents are modelled based on the AML standard interface class COLLADAInterface or one of its derivatives. This class is specified in →section 2.4.3.6 and details about the modelling are specified in →section 3.2 of this book. References to behaviour documents are described in Chapter 4 of this book. PLCopen XML documents are modelled based on the AML standard interface class PLCopenXMLInterface or one of its derivatives. This class is specified in →2.4.3.7. 2.5.2  Referencing external CAEX documents 2.5.2.1  How to model references to external CAEX documents CAEX documents can be split into several documents, and external CAEX documents can be referenced. Distributed documents can be understood virtually as one common object model, serialized in several CAEX documents. This is useful for many use cases, for example when an object model has become too large, or for outsourcing libraries, or when several partners are working on different parts of the object model, or for know-how protection. The modelling rules for splitting of CAEX document are:

– A reference to an external CAEX document is modelled by means of the CAEX element ExternalReference (see →section 2.2.3.1). – All referenced CAEX documents must be of the same CAEX schema version. – The referenced external CAEX documents must be valid and accessible. – Each CAEX ExternalReference must provide a valid URI to the external CAEX document and an alias which must be unique within the CAEX document. The Alias is the internal identifier for the external document. – The alias can be used, for example, for referencing classes or instances. In this case, the reference tag begins with the alias name, followed by the alias separator “@”, followed by the path to the referenced class or the ID of the referenced InternalElement or ExternalInterface. – CAEX InternalLinks or mirror objects may reference mirror objects that are stored in another file. In this case, the external file(s) are referenced as ExternalReference. – Across all split files, multiple occurrences of ExternalReferences to the same file(s) are allowed. Circular references between CAEX files are allowed. This means that a CAEX file may reference another CAEX file, but a split file of the same document may reference the same CAEX file again. →Fig. 2-70 illustrates the distribution of an object model in multiple files. The CAEX root file references three other files CAEXFile01, CAEXFile02 and CAEXLibrary.

Fig. 2-70 Distribution of the object model in several CAEX files 2.5.2.2  Example →Fig. 2-71 illustrates the modelling of CAEX ExternalReferences by means of an external file myExternalLibrary.aml. The Alias is myExternalLibrary, and the path of the reference is relative.

Fig. 2-71 ExternalReference example The paths to the external files follow the URI convention. It may be the file name only, with the path assumed to be identical to the path of the referencing CAEX document. It may be a path relative to the original path, or it may be an absolute path (which we do not recommend). It further may be a path to a website or an ftp server, etc. Finally, the reference should resolve the location of the file, and it is equivalent to store the file somewhere in the cloud or on a local server. Example paths are: – myExternalLibrary – ../ExternalFiles/ProductLibrary.aml – File://localhost/c:/Temp/ExternalCAEXFile01.aml – →http://www.abc.com/ExternalCAEXFile02.aml →Fig. 2-72 shows how the alias is used: in this example the internal element mySensor01 references the class mySensor, which is stored in an external CAEX document with the alias myExternalLibrary. The tag RefBaseSystemUnitPath models the path, starting with the alias, followed by the alias separator @ and the full path of the corresponding class.

Fig. 2-72 Example reference to a class stored in an external CAEX file

2.5.3  Referencing future external documents in the scope of AML Future extensions of AutomationML may add additional interface types for referencing further document types. They will be specified in separate parts of the AutomationML standard series. The modelling rules for such extensions are: – Additional references to further documents must be modelled with additional interface classes and must be directly or indirectly derived from the standard interface class ExternalDataConnector. – The storage of references should be done reusing the existing standard attributes provided by the standard interface classes. 2.5.4  Referencing additional documents outside the scope of AML 2.5.4.1  Modelling rules AutomationML supports the referencing of external documents, which are not in the scope of this standard, for instance, manuals, certificates, icons, instructions or specific engineering results like native control programs. The modelling rules are: – A document which is outside of the scope of IEC 62714 must be modelled by means of a CAEX InternalElement. This InternalElement must have a direct or indirect association to the RoleClass ExternalData (see →section 2.4.2.11). The referenced role must specify the content type of the document, for example “bill of material” or “user manual”. More than one role with different content types can be assigned to a document; for example, if the document contains contents of several types, for example “bill of material” and “user manual”. – Each document can reference several files if necessary, for example if it is split into different files. – The document object models the reference to the external document by one or more ExternalInterfaces which must be directly or indirectly derived from the interface class ExternalDataReference. – This ExternalInterface must model the URI to the external document by means of the predefined CAEX attribute of type refURI which is inherited from the AML standard interface class ExternalDataConnector and must additionally model the type of the document by means of the predefined CAEX attribute MIMEType of type MIMEType which is inherited from the AML standard interface class ExternalDataReference. – If a document is language specific, it must contain a CAEX attribute of type DocLang. If a document contains more than one language, it shall contain an unsorted attribute list with attributes of type DocLang. 2.5.4.2  Example for a single external MS Excel document Let us assume we want to model an MS Excel document associated with a device object. →Fig. 2-73 illustrates the modelling steps:

– Starting point of the model is an InternalElement that models the device. – Create a CAEX InternalElement as child of the device object and associate the role ExternalData to this. – Assign a CAEX ExternalInterface to this document derived from ExternalData-Reference. – Set the attributes of the reference: refURI is the path to the document (in this example specification.xlsx), and set MIMEType (in this example application/msexcel) – Optionally: assign an attribute of type DocLang to the Document and define the language. →Fig. 2-73 shows the modelling steps in the AML Editor. →Fig. 2-74 shows the resulting XML structures illustrating the modelling details.

Fig. 2-73 Example for referencing an external MS Excel document

Fig. 2-74 XML structure for referencing an external Excel document 2.5.4.3  Example for multiple external documents Let’s assume that we want to model an AML object of a tool that requires references to three different documents: a German user guide as PDF, a German bill of material as PDF and an English bill of material as MS Word document. →Fig. 2-75 illustrates what we want.

Fig. 2-75 Example for referencing multiple external documents The modelling steps are: – Step 1: We define a new role class library and add additional document types, in this example UserManual and BillOfMaterial, derived from the AML standard role ExternalData. Further document types may be added as required (see →Fig. 2-76).

Fig. 2-76 Refinement of document roles based on ExternalData – Step 2: We model the tool as CAEX InternalElement in the InstanceHierarchy. – Step 3: We add three child InternalElements that each play the required document role. Each of these InternalElements gets an attribute amlDocLang which models the

requested language.

Fig. 2-77 AML Model of the tool with three document references – Step 4: For each document link, the attributes refURI and MIMEType are set. The resulting AML document can be downloaded at [BookLink@]. Further examples are provided in [BPR EDRef@] 2.5.5  Referencing CAEX attributes to items in external documents 2.5.5.1  Modelling rules Sometimes it may be useful to associate a CAEX attribute with a related item in an external document (for instance an external Excel document which is outside of the scope of the AutomationML standard). The modelling rules for this are: – Each reference between a CAEX attribute and an item in an external document is modelled by a CAEX ExternalInterface as described in →section 2.5.4. – For each reference between a CAEX attribute and an item in an external document, this CAEX ExternalInterface models one additional attribute of type AssociatedExternalValue which has three nested attributes. – RefCAEXAttribute: The first nested attribute RefAttributeType mirrors the CAEX attribute. This means that the ID of the attribute’s parent object, separated by “/” and the name of the attribute is modelled as the value in this attribute. The name of this attribute is irrelevant, but unique among its siblings. – refURI: The second nested attribute of type refURI references the item in the external document. This reference must reference the same document or a sub-document of the external document that is referenced in the parent InternalElement. The syntax of this reference is outside of the scope of AutomationML and requires a referenceable external document element, for example an EXCEL Alias. – Direction: The third nested attribute of type Direction models the direction of the information flow. The attribute value is In if the external attribute is consumed by the

CAEX attribute (then the external item is leading), or the attribute value is Out if the CAEX attribute is leading and the external item consumes the value of the CAEX attribute. The value InOut is not allowed. 2.5.5.2  Example Let’s assume we want to extend the previous model. The device should have an attribute Price and it should be linked to an external MS Excel document. →Fig. 2-78 illustrates the modelling steps: – Add a CAEX attribute Price to the Device object. – Add a CAEX attribute of type AssociatedExternalValue to the reference interface. – Set the value of the first nested attribute refCAEXAttribute to the path of the CAEX attribute (in this example, 7468c3d4-9052-4d11-8de4-a8a6576b3d33/Price). – Set the value of the second nested attribute refURI to the external document (in this example, Specification.xlsx#DevicePrice). The syntax is user-defined. – Set the value of the third nested attribute Direction to In since the external document is the leading source for the content of the attribute. →Fig. 2-78 shows the modelling steps in the AML Editor. →Fig. 2-79 shows the resulting XML structures illustrating the modelling details.

Fig. 2-78 Referencing an attribute in an EXCEL document

Fig. 2-79 XML structure for referencing external items

2.6  Extended AutomationML Concepts 2.6.1  Overview In cooperation with industrial partners, the AutomationML Association developed several useful extended concepts. – The AML Port concept allows a high-level description of complex interfaces. AML Ports consist of a set of AML interfaces that belong together, similar to plugs or sockets. – The AML Facets concept allow the storage of a subset of attributes and interfaces of an AML object. They can be considered as views into engineering data. – The AML Group concept allow the storage of separate views on a subset of AML objects. They can be used to filter objects of the plant tree for different engineering tools. – The AML PPR concept (PPR=Process-Product-Resource) allows high level structuring of engineering data based on a combined process-centric, product-centric or resourcecentric view including relations between them.

– The AML multilingual expressions allow storage of a textual expression in different languages. – AML Lists and attribute arrays allow modelling of attribute lists or arrays of attributes. – The AML container format allows encapsulating multiple files into a package. 2.6.2  The AML port concept - modelling of complex interfaces 2.6.2.1  Motivation

Fig. 2-80 A complex nested electrical interface

In practice, interfaces are often combined to form combination plugs or sockets (see →Fig. 280). Super connectors bundle several sub connectors into a superordinate format. This makes it easier to connect, for example, conveyor modules with each other. We call them ports. If such ports are connected, the nested ports are automatically linked, for example, pneumatics, safety signals, network data and power supply. Ports are often mechanically designed in such a way that only suitable ports can be connected. The connection of ports automatically implies the correct connection of the nested interfaces. 2.6.2.2  How to model a port The modelling rules utilize the ability of CAEX 3.0 to model nested interfaces. The following steps are required for port modelling: 1. Model the port as a CAEX Interface of the associated AML object, this interface must be directly or indirectly derived from the AML standard interface class Port. 2. Model the nested interfaces. They can be of any type. Nested interfaces can be nested again, and there is no limit on the hierarchical depth. 3. To connect two ports, create a CAEX InternalLink between both ports. This link alone implies that the nested interfaces are correctly connected without further links. 4. Optionally it is allowed to model the connections between the nested interfaces individually. 5. Optionally set the attribute Direction of the port; the allowed values are In, Out and InOut. This enables automatic direction compatibility. 6. Optionally set the attribute Cardinality, which allows modelling of the min or max occurrence of connections. 7. Optionally set the attribute Category to specify the category of the port. The syntax is user-defined. This is useful for automatic compatibility checks. 2.6.2.3  Example →Fig. 2-81 gives an example for the AML Port concept. The object Station comprises the subobjects Module A and Module B. Both sub-objects have a port with nested sub-interfaces. Each port is modelled by means of a Port interface, derived from the AML standard InterfaceClass Port, and comprising a set of nested interfaces. The standard interface is linked using a CAEX InternalLink. This relation means that both ports are connected to each other. The internal linking of the sub-interfaces is not modelled in detail; only the Ports are connected. In addition to this concept, AML allows modelling and storage of each individual link between the sub-interfaces.

Fig. 2-81 Port concept →Fig. 2-82 illustrates the object model and →Fig. 2-83 describes the AML implementation of the example system described in →Fig. 2-81.

Fig. 2-82 Object-oriented modelling of the modules

Fig. 2-83 AML structure of the port example 2.6.3  The AML facet concept - modelling of attribute filters 2.6.3.1  Overview The idea behind the facet concept is that AML objects may have hundreds of attributes or interfaces, but for a certain engineering task, only a subset of them are of interest. It would be very practical, if we could prepare the data in a way that external software algorithms (outside of AutomationML) could easily get only the data that is important to it. For example, consider that an attribute of an object would name a useful PLC code template and interfaces would describe inputs or outputs of or to this template. Thus, a PLC code generation algorithm that only needs the template name and the inputs and outputs could automatically generate PLC code from this information. A facet provides exactly what this external algorithm would need. It is an AML object providing a sub-view on attributes or interfaces of the parent AML object. This concept

serves for the filtering of attributes and interfaces and to focus on dedicated data only. For this, AutomationML defines the AML RoleClass Facet. 2.6.3.2  How to model a facet The modelling rules for a facet are: – Identify attributes and interfaces of an AutomationML InternalElement or SystemUnitClass that are of special interest and that should be filtered. – Model the facet as a CAEX InternalElement with a direct or indirect association to the RoleClass Facet. An AML Facet object must be a child object of the relevant InternalElement or SystemUnitClass. – An InternalElement or SystemUnitClass may have an arbitrary number of Facet objects. – Facets are identified by their unique ID. Their names are display names only. – Each Facet attribute mirrors an arbitrary number of existing attributes of the parent object. Mirroring of sub-attributes and other subordinated attributes within the parent object is possible. – An AML Facet object must contain only mirror attributes or mirror interfaces (see →section 2.2.12.6 for more details on the mirror concept). – Facets may have an arbitrary number of facet attributes and facet interfaces. – Facet attributes which are not part of the parent object are not permitted. – Each Facet interface must mirror an existing interface of the parent object. Mirroring of nested interfaces within the parent object is possible. – Facet interfaces which are not part of the parent object are not permitted. – Facets shall not contain new child objects, attributes or interfaces. – Facet objects cannot be nested. – Facets shall not modify existing attributes or interfaces. 2.6.3.3  Example →Fig. 2-84 explains the AML Facet concept by means of an example: the object “Conveyor1” comprises the attributes A and B as well as the interfaces X and Y. The assigned Facet object PLCFacet refers to the attribute A and the interface X, whereas the assigned Facet object HMIFacet refers to the attributes A and B as well as to the interface Y. Hence, both Facets provide a filtered view on certain engineering information which is relevant for different engineering tasks.

Fig. 2-84 Facet example Use case: The attribute A may be the name of a vendor specific PLC code template describing the automation functionality of the object Conveyor1. The interface X may be the name of an input signal required for this code template. The attribute B may be the name of a specific HMI template for the conveyor, and the interface Y may be a signal that should be presented on the HMI. With this information, a PLC or HMI generator is able to generate an HMI screen automatically. The related AML structure is shown in →Fig. 2-85.

Fig. 2-85 AML structure to model the facets 2.6.4  The AML group concept - filtering of objects 2.6.4.1  Overview The idea behind the group concept is that an instance hierarchy could comprise hundreds of different AutomationML objects, but for a certain engineering task, only a subset of them is of interest. It would be very practical if we could prepare the objects in a way that external software algorithms (outside of AutomationML) could easily get only the objects that are important for their task.

For example, consider an engineering algorithm looking for all conveyors of a plant in order to automatically generate the related conveyor function blocks. Thus, it would be very helpful for the algorithm if we could provide a certain view of the plant that would only deliver the objects it needs. A group provides exactly this: structuring already existing objects in an individual way, allowing a software algorithm to easily get the hierarchy that is important to it. 2.6.4.2  Modelling rules The modelling rules for an AML group are: – Identify the objects of interest in the existing object model. – Model an AML group as a CAEX InternalElement with a direct or indirect association to the RoleClass Group. – An AML group object may be modelled at an arbitrary position of an InstanceHierarchy or a SystemUnitClass. – Groups are identified by their unique ID. Their names are display names only. – An InternalElement or SystemUnitClass may have an arbitrary number of Group objects. – An AML group object contains only mirror InternalElements and/or further Group objects (see 2.2.12.6 for more details on the mirror concept). – Group objects can be nested but shall not be used to describe plant hierarchies. – An AML group object may store additional information as attributes or interfaces in order to describe group specific information. Those additional attributes or interfaces are not identical to attributes or interfaces of the contained mirror objects. – It is not allowed to change existing attributes, interfaces or ports of mirror objects or to add additional information to the mirror objects. – If used, the attribute AssociatedFacet must have a value that provides a valid name of an existing Facet of each mirror object. The application of this attribute is described in 2.6.5. 2.6.4.3  Example →Fig. 2-86 illustrates the group concept. It consists of a Station that contains the objects Conveyor1, Conveyor2, Robot and PLC. Additionally, the objects Group1 and Group2 mirror the objects of interest. Group1 gives a focused view on conveyors only, whereas Group2 only contains PLC relevant objects.

Fig. 2-86 Group example The AML model is shown in →Fig. 2-87.

Fig. 2-87 AML structure for the group example 2.6.5  Combination of facets and groups 2.6.5.1  Overview Both the group and the facet concept help external engineering tools to get the data provided from their special perspective. A combination of both concepts makes it even more valuable. It would be very practical if an algorithm could easily find both the objects of interest (in a group) and their respective attributes and interfaces (in facets). For example, consider an engineering algorithm looking for all conveyors of a plant to automatically generate the related conveyor function blocks. It would then need certain attributes or interfaces of the conveyors to interconnect the function blocks. Thus, it would be very helpful for the algorithm if a certain view of the plant could be provided that only delivers the objects it needs.

The association between the group and facet concept is modelled by means of the attribute AssociatedFacet. Imagine an algorithm which automatically generates HMI templates for all conveyors. It looks for a group that provides the conveyors only, and it finds the attribute AssociatedFacet which provides the names of the facets of interest. Then, for each conveyor, the algorithm would go to the facet object and immediately find the attributes and interfaces, ready for use. 2.6.5.2  Example →Fig. 2-88 presents an example with a combination of the Group and the Facet concept. The shown instance hierarchy depicts an AML object Station comprising the AML objects Conveyor1 and Conveyor2. These conveyors each own two attributes A and B and two interfaces X and Y. Furthermore, two facets PLCFacet and HMIFacet filter attributes and interfaces of interest. The AML object Groups presents nested groups Group1 and Group2. Both refer to the conveyor objects but have different Facet associations. Now, a PLC code generation algorithm may run through the instance hierarchy identifying all groups with an association to a PLCFacet and then perform the code generation by evaluating the referenced PLCFacet. In a similar manner, an HMI generation algorithm may run through the instance hierarchy identifying all groups with an association to an HMIFacet and then perform the HMI generation by evaluating the referenced HMIFacet. The AML model of this example is available for download at [BookLink@].

Fig. 2-88 Combination of the facet and group concept 2.6.5.3  Example use case The following example describes the fictitious functionality of an algorithm that is to generate a user interface from an HMI template. For this purpose, the algorithm must identify the conveyors in the plant, instantiate a template for each conveyor and then assign the signals and attributes. We assume, that attribute B of an AML conveyor object contains the name of an HMI faceplate, which is to be used as the basis for visualizing the conveyor belt together with the desired process variables.

Fig. 2-89 HMI-Faceplate B An engineering algorithm determines all those objects that are to be visualized in the user interface and finds Conveyor1 and Conveyor2. Based on the individual interfaces Y for both conveyor belts, the engineering algorithm instantiates the template B twice, representing both conveyor belts, and connects the corresponding instance interfaces Y. The result is an HMI display and operating screen which contains individual images for both conveyor belts with access to the respective process signals.

Fig. 2-90 Combined generated HMI 2.6.6  Modelling of processes – the PPR concept 2.6.6.1  Overview The PPR concept has proven to be an effective means of mastering complex planning structures. It is the basis for a variety of industrial applications, for example material handling (refer to the Industrial Cookbook (see [DRA21] Chapter 13), for complex industrial toolchains (see [DRA21] Chapter 20), for AML-based Enterprise Control System Integration (see [DRA21] Chapter 25), or in research activities (see [DRA21] Chapters 30, 33, 34 and 35). The PPR concept has its roots in the digital factory and the associated necessity of

electronically describing all planning data involved in the production process. Here, a threepart division into resource, process and product data has proven itself in practice and is already available in digital factory software tools [SCDR09]. Resources, products and processes are interrelated; a product is handled with resources which in turn carry out processes. This three-view concept (see →Fig. 2-91) is also pursued in other projects and areas, for example, in the area of Manufacturing Execution Systems (MES) with ISA95, which is similar to this model (see also [IEC 62264] and [AKS+07]).

Fig. 2-91 Base elements of the Product-Process-Resource concept In production engineering, the focus is often on the product to be manufactured. This determines which processes are applied to the materials and intermediate products used

and which resources or machines, systems or components are required for them. Resources are used to transport, treat and process partial products into a discrete end product. The result of the production process is measured, for example, by the number of units produced. This classification can be transferred to process engineering with the difference that there are usually no discrete end products or piece goods. In process engineering, resources such as boilers, pumps or valves, which are connected to each other via pipes or hoses, for example, process starting materials continuously or discontinuously in so-called batches into end products. These can be liquid or solid materials, for example, beverages, food or chemicals, whereby production is characterized by chemical or biotechnological processes and reactions. The end products are then not measured in discrete quantities, but for example in volumes or mass. In AutomationML, a resource refers to a facility involved in production. Examples include systems, robots, tools, machines, devices, as well as software and associated status and potentially even messages. This corresponds to the use and designation of resources in the Digital Factory. Accordingly, in the way understood here, resources can be both the hardware components of a production system, for example, machines or conveyor technology, but also the associated software systems such as process visualization. Within AutomationML, resources are represented by the plant topology, which is mapped as an object hierarchy with CAEX. In AutomationML, a product is understood as a produced partial, intermediate or end product. This can be structured hierarchically. An example is a car with the sub-products body, wheels, gearbox, engine, etc. The products include test and inspection results as well as product data and corresponding documentation. In AutomationML, products do not have to be piece goods; liquids are also products and can be classified and stored systematically with rollers. In AutomationML, a process represents a production process including associated subprocesses. It describes actions that are carried out by resources. This includes process parameters, the process flow and engineering. In the technical field [BRO07], a process is referred to as a process that changes structure. This also corresponds to the use in AutomationML. In production engineering, the end product is manufactured from various sub-products, in process engineering, for example, chemical conversions are carried out on substances. – In a resource centric view, resources form the central component within the model: they execute processes and handle products. In AML, a resource is an entity involved in production including plants, robots, machines, their state, equipment, possible messages and so on. According to this, resources can be hardware components of a production system, as well as software systems, for example SCADA systems. Within AML, resources are typically modelled in a plant hierarchy forming the plant topology. – In a product centric view, the produced product is in the focus of consideration. It determines which processes should be applied to the materials or intermediate products and which equipment should be used. This is valid in the field of continuous, discrete or batch control. A product in AML depicts a produced good. It can be built up hierarchically. It is essential that products do not have to be final products. Test results belong to products as well as product data and the corresponding documentation. – In a process centric view, processes form the central items of the model. A process in AML represents a production process including sub-processes. Process parameters,

the process chain and the process planning form part of the processes. In technical terms, processes modify products. This corresponds to the usage in AML, as final products are produced out of different sub-products, or chemical treatments change substances. However, processes have relations to resources and vice versa. All three views have their own justification; none of them is leading. The PPR concept consists of completely modelling all three views in parallel and independently. Then, all representations of the resource, product and process are linked to each other. As a result, we get a modelling network that provides information at any time about: – What process utilizes what resource to work on what product. – What resource is involved in which process on what product. – What product is processed in which process using which resources. Conversely, if a component fails, an immediate response can be given: – If a process fails: which resources and which products is affected? – If a resource fails: which process and which product is affected? – If a product fails: which resource and which process is affected? Finally, the division in three separate hierarchies is very helpful. The Integrated Enterprise Modelling [BMS06] also considers this division. In the research project Modale [ABH04], as well as in the research project ProduFlexil [EOB07], [SBO+08], a distinction was also made between resources, products and processes. A product is, for example, a console or a car body; a process is, for example, a welding process or conveying process; and a resource is, for example, a transport system or a turntable. Also [YGC+07], as well as [DYM+07] deal with the division of all components involved into processes, products and resources. Examples of common definitions can be found in [MIC05]. [SoOl02] deals with the feature-based integration of products, processes and resources and references other sources on this topic. 2.6.6.2  Example The concept is explained using the concrete examples shown in →Fig. 2-92. It consists of an infeed and outfeed conveyor belt C1 and C2, as well as a turntable TT1 and a robot RB1 as resources of the plant. The robot mounts wheels on the car bodies. Both the wheels and the car bodies (with and without wheels) are shown as products. The production processes in this example are transport, turning and assembly.

Fig. 2-92 Example for the Product-Process-Resource concept In →Fig. 2-93 the conveyor belts, the turntable and the robot of our example are assigned the role Resource. The body with wheels and the body without wheels, as well as the wheels themselves, are assigned to the Product role. The Process role corresponds to the processes of transport, turning and assembly. All elements are stored as an independent instance hierarchy in the corresponding subtrees.

Fig. 2-93 Elements of the PPR example Each element in the example has a PPRConnector interface. The complete links of the example are represented in →Fig. 2-94. The solid lines represent links from resources to processes, the dotted lines links from processes to products and the dashed lines are links between resources and products. This reveals the complexity. Thus, redundant connections can be omitted.

Fig. 2-94 Links within the example 2.6.6.3  Modelling of the three structures In the first step, three internal elements have to be created, associated with the standard role classes ProductStructure, ProcessStructure or ResourceStructure (see →Fig. 2-95).

Fig. 2-95 Step 1 - modelling the PPR concept

In a second step, the identified products, process steps and resources need to be modelled (see →Fig. 2-96).

Fig. 2-96 Step 2 - modelling the PPR concept In order to be able to model a connection between the elements, all elements are provided with a PPRConnector interface (see →Fig. 2-97). Via this interface, CAEX s can be used to create connections between the elements and thus semantically answer the question of who is related to whom. A few examples: a resource can be linked to the products it can handle; or a resource can describe processes that can be performed on the resource. In the application example, each of the elements has such a PPRConnector interface. The number of links quickly becomes confusing; this can be reduced by omitting redundant links.

Fig. 2-97 Step 3 - modelling the PPR concept In the last step, the links between the related process steps, products and resources have to be modelled. The AML model is available at [BookLink@]. 2.6.7  Internationalization, multilingual attributes 2.6.7.1  Motivation Engineering data is often planned in several languages. Switching between languages onthe-fly in international teams for global cooperation is helpful but requires multi language

support when modelling and exchanging data. The concept of multilingual expressions aims at storing multi language information within the same AML file. 2.6.7.2  Modelling principles The modelling rules for multilingual expressions are: – A multilingual attribute is modelled as a CAEX attribute. The value of this attribute is the default expression, which is used if no specific language is requested or the requested language is not modelled. – A language expression of the attribute is modelled as a nested attribute which references the AutomationML standard attribute type LocalizedAttribute. – The name of each child-attribute shall be the language of the expression in compliance with RFC 1766, for example de for German, fr for French or en for English. The value of the language attributes shall be the translated text in the related language. – Compound language abbreviations are for example en-US for American English or frCA for Canadian French. – A list of abbreviations is available at →https://docs.microsoft.com/enus/windows/win32/wmformat/language-strings →Fig. 2-98 shows this using the example of a robot whose attribute Price is stored in different languages.

Fig. 2-98 Multilingual attributes 2.6.7.3  Modelling of multilingual attribute type libraries We recommend modelling multilingual expression in the attribute data type library, which can help eliminate redundancies. Once defined, these multilingual attributes can be instantiated, and the translations can be removed from the instances. Summary

A key benefit of this technique is that language variants of an attribute are stored only once in the attribute type library. →Fig. 2-99 illustrates this by remodelling the attribute of →Fig. 2-98.

Fig. 2-99 Multilingual attribute type library 2.6.7.4  How to outsource an multilanguage attribute library AML libraries can be stored as separate files, which reduces complexity in the project file and simplifies reuse. The starting point is an AML document containing both the project data and the attribute type library. The steps to manually externalize the multilingual attribute type library are: – Step 1: Create a copy of the project AML document. Perform the following actions with the copy of the AML document: – Rename the copy appropriately, for example “MultiLanguageAttributes.aml”. – Open the document and remove any non-related content except the Attribute Type library of interest. – Step 2: In the original file: – Delete the attribute type library. – Create a new CAEX . – Create an Alias, name the Alias and store the path of the external AML document. – Update all references from attributes by replacing the original path by the new alias. In the result, we have two files: the project file without the library, and a second AML document with the multi-language library only. 2.6.8  Modelling of lists and arrays 2.6.8.1  Motivation Let’s assume we want to model that our radio player knows a list of frequencies. For this, we need the ability to model lists. Or let’s assume the outdoor temperature of a temperature sensor should be archived over time. For this, we need the ability to model arrays, which are

lists with multiple entries; in this example, the value pair date/temperature. Or let’s assume a robot should store its positions over time including time stamp; this could also be modelled as an array. 2.6.8.2  How to model a list Lists consist of items of the same data type and may contain further lists, enabling the modelling of arrays of arbitrary dimensions. A list is modelled in AML as a list attribute containing nested child attributes. The list attribute acts as a container for the list. CAEX Attributes do not explicitly model the order of the items. Therefore, the ordered list and the non-ordered list need to be modelled explicitly. The modelling rules for lists are: – For a non-sorted list, create a CAEX attribute and reference the AML standard attribute ListType. For a sorted list, reference the AML standard attribute OrderedListType. This CAEX attributes has no Value, DefaultValue or Unit. Header information is allowed. – Model the items as child attributes of the list. All items must have the same type. – Unsorted entries must have unique names within the list. Sorted entries must be identified by a leading consecutive number: 1, 2, etc. Leading zeros are allowed 0001, 0002, and so on.

Fig. 2-100 Unsorted list 2.6.8.3  How to model an array An array is modelled as a list of lists. The modelling rules for arrays are: – Create a CAEX attribute and reference the AML standard attribute ListType or OrderedListType. This CAEX attributes has no Value, DefaultValue or Unit. Header information is allowed.

– Model the rows of an array as child attributes of the list. All items are of type ListType or OrderedListType. – Model the columns of the array as child attributes of each sub list item. – This technique can be used multiple times in order to model multi-dimensional arrays. →Fig. 2-101 shows this using the example of a robot whose positions are stored in an array Positions over time. Each position has 4 entries: Time, X, Y, Z.

Fig. 2-101 Array 2.6.9  The AML Container Format 2.6.9.1  Motivation Since an AML file may consist of many sub documents (for example external CAEX libraries, referenced geometry files, manuals, icons, logos, etc.), AML supports a container format following the Open Packaging Conventions (OPC). The container format packages multiple

related files into a single file. It is a zip compressed file that follows the ECMA OPC conventions. Table 2-29: Container format relationship types Relationship types

Description

Definition

Root

A root AML file is an AML file acting as entry point into the AML container. It is used for instance data. A library AML file is an AML library which contains RoleClassLibs, Interface-ClassLibs, SystemUnitClassLibs and/or AttributeTypeLibs. Similar to the root AML file, the library AML file is an entry point into the AML container. AML containers may contain library files only. A COLLADA file is a geometry and kinematics document. A PLCopenXML document models logics information. The container may contain any file types, for example pdf, xml, xlsx etc. The CAEX schema file is the XML schema of CAEX.

Relationshiptype: →http://schemas.automationml.org/container/relationship/RootDocumentMime type: “model/vnd.automationml+xml”

Library

Collada

PLCopenXML AnyContent

CAEXSchema

Relationshiptype: →http://schemas.automationml.org/container/relationship/LibraryMime type: “model/vnd.automationml+xml”

Relationshiptype: →http://schemas.automationml.org/container/relationship/ColladaMime type: →“model/vnd.collada+xml” Relationshiptype: →http://schemas.automationml.org/container/relationship/PLCOpenXMLMime type: “model/vnd.plcopen+xml” Relationshiptype: →http://schemas.automationml.org/container/relationship/AnyContentMime type: “application/x-any” or user-defined according to the Mime specification. Relationshiptype: →http://schemas.automationml.org/container/relationship/CAEXSchemaMime type: ”text/xml”

2.6.9.2  How to model an amlx document Following the OPC convention, the AutomationML standard defines the relationship types according to →Table 2-29. The general modelling rules are: – An AML container is stored as an ECMA OPC archive which provides data compression. – An AML container must be either self-contained or environment-connected. – A self-contained AML container must include all related documents which are only locally interlinked with each other.

– An environment-connected AML container may contain links to URIs to public documents outside of the AML container. – AML container documents have the file extension ”.amlx”. 2.6.9.3  Example Let’s assume a simple AML project structure with all AML standard libraries outsourced in one external AML file; resulting in a project consisting of two AML. Both are packaged as an amlx document. →Fig. 2-102 illustrates the result: instead of dealing with multiple files, we get one container file that contains everything.

Fig. 2-102 Example project to be packaged in an AML container The extension amlx is a ZIP compressed file. →Fig. 2-103 illustrates the content of the example*.amlx document: we find the expected partial document and additional organizational files.

Fig. 2-103 Example: Insides of an amlx document Now let’s look into the organizational files. The file [Content_Types].xml defines the known suffixes and their types according to the MIMEType definitions (see →Fig. 2-104).

Fig. 2-104 The content of the file [Content_Types].xml The folder_rels comprises two further files: the hidden file .rels and the file AMLContainerExample.aml.rels (see →Fig. 2-105).

Fig. 2-105 Container example: content of the folder _rels The file.rels provides a list of all contained files and defines each file’s type, file name and identifier (see →Fig. 2-106).

Fig. 2-106 Relationship types in the container format →Fig. 2-107 shows the content of the file AMLContainerExample.aml.rels. It contains the relationship between the root AML file and the interconnected separate library file.

Fig. 2-107 Relationships in the container document

2.7  Best practice recommendations for AML modelling Besides the AutomationML standard, the AutomationML society has developed and published a couple of best practice recommendations based on feedback from industrial experiences [BookLink@]. Most of the best practice recommendations have been written for AML Ed. 1 and are already implemented in AML Ed. 2. This section gives overviews of the recommendations for modelling regular expressions and attribute units. 2.7.1  Modelling of Regular Expressions 2.7.1.1  Motivation Imagine we want to model an attribute that should fulfil a certain format, name convention or complex rules. For instance, signal names have to start with a number, or an inventory number must fulfil the convention of xxxx-yyyy-zzzz. There are many applications where strings must follow certain construction rules. 2.7.1.2  Modelling principles The description of those rules can be modelled with regular expressions. The modelling rules are: – The regular expression is a string that follows the Standard Perl Compatible Regular Expressions PCRE according to [PCR20@]. – The regular expression has to be modelled as a CAEX constraint of the corresponding attribute. – The type of the constraint must be “UnknownType”. – The name of the constraint must be “aml-RegExp”. – The value of the sub attribute Requirements of the constraint holds the regular expression. 2.7.1.3  Example For example, we want to model an attribute part number that should comply with the following formatting rules:

1. 2. 3. 4. 5.

The first letter has to be an “F”, followed by 10 numeric digits, followed by a “-”, followed by a capital letter. The last character is a numeric digit.

The regular expression for the naming convention is: ^F[0-9]{10}\-[A-Z][0-9]$. The corresponding AML model is illustrated in →Fig. 2-108 and available at [BookLink@].

Fig. 2-108 Regular expressions 2.7.2  Modelling of Units 2.7.2.1  Motivation An important aspect of the data exchange within the engineering process is the exchange of quantities. A quantity consists of a number – for example as a result of a measurement - and a unit of measurement. Units play an important role, since they give the context of how the number must be interpreted. This section summarizes the best practice recommendation [BPR Units@]. Different systems of units are available, which standardize one set of base units as well as derived units. IEC 62714-1 Ed. 2 recommends using the International System of Units (SI). Firstly, it only provides the semantical definition, not a syntactical one. But syntax is needed to unambiguously represent a unit in a machine-readable manner.

Secondly, the International System of Units (SI) is sometimes not sufficient for the scope of AutomationML. Sales, packaging, shipping, transportation, or information technology units are not considered: for example, dimensionless quantities like pieces, lots, or boxes. To overcome both problems, this best practice recommends using the UNECE Recommendation N°20 “Codes for Units of Measure Used in International Trade”. 2.7.2.2  Modelling principles The UNECE Recommendation N°20 “Codes for Units of Measure Used in International Trade” [UNECE 10@] provides a comprehensive set of quantities. Additionally, each quantity has an unambiguous identifier, called “common code”. The modelling recommendation for AutomationML is: – Instead of using the unit itself, the common code shall be used. – The common code must be stored in the standard attribute “Unit” of the CAEX Attribute. – This specification is applicable to IEC 62714 Edition 1 and Edition 2. 2.7.2.3  Example →Fig. 2-109 illustrates the modelling of an attribute Volume with the unit litre.

Fig. 2-109 Units

2.8  Conclusion and summary This Chapter is an introduction into the basics and fundamental elements of the objectoriented modelling language CAEX 3.0 as submodel of AutomationML. It corresponds to Layer 1 in the four-layer concept as illustrated in →Fig. 2-110: it is built on top of the XML Layer 0 but does not provide comprehensive domain models of layer 2. Chapter 2 is the foundation for the development of object-oriented domain models based on XML which the fundament of the industrial application.

Fig. 2-110 Chapter 2 focuses on layer 1 of the four-layer model The next Chapter 3 is dedicated to the modelling of Geometry and Kinematics. Download Libraries and examples of this Chapter are available at [BookLink@].

2.9  References for Chapter 2

[ABH04] [AKS+07] [BMS06] [BRO07] [DRA21] [DrFe04a] [DrFe04b] [DYM+07] [EOB07] [EPP03] [FaDr05] [GWF08] [MIC05] [PAR72] [SBO+08]

[SCDR09] [SCEP07] [SCH02] [SoOl02] [YAB+06] [YGC+07]

A. Abecker A, M. Bauer M, M. Hefke: MODALE - Modellbasiertes Anlagen-Engineering, kundenorientierte Dienstleistungen für Anlagensteuerung und – kontrolle. Forschungsoffensive “Software Engineering 2006” – Eröffnungskonferenz, Berlin, 2004. M. Adams, W. Kühn, T. Stör, M. Zelm M: DIN EN 62264. Die neue Norm zur Interoperabilität von Produktion und Unternehmensführung – Teil 1. In: atp – Automatisierungstechnische Praxis (49) 5.2007, Oldenburg Industrieverlag, 2007, pp. 52-57. P. Bernus, K. Mertins, G. Schmidt: Handbook of Architectures of Information Systems. DOI →https://doi.org/10.1007/b137905, Springer-Verlag Berlin Heidelberg, 2006. Brockhaus - Die Enzyklopädie in 30 Bänden, 21., neu bearbeitete Auflage. Leipzig, Mannheim: F.A. Brockhaus 2005-07. R. Drath (Ed.): AutomationML – The Industrial Cookbook. De Gruyter Oldenbourg, ISBN 978-3-11-074592-4, Berlin, 2021. R. Drath, M. Fedai: CAEX – ein neutrales Datenaustauschformat für Anlagendaten. Teil 1. In: atp Automatisierungstechnische Praxis 46, Heft 2, Oldenbourg-Verlag, 2004, S. 52 - 56; R. Drath, M. Fedai: CAEX – ein neutrales Datenaustauschformat für Anlagendaten. Teil 2: In: atp Automatisierungstechnische Praxis 46, Heft 3, Oldenbourg-Verlag, 2004, pp. 20-27. A. F. Cutting-Decelle, R.I.M. Young, J. J. Michel, R. Grangel, J. Le Cardinal, J. P. Bourey: ISO 15531 MAN-DATE: A Product-process-resource based Approach for Managing Modularity in Production Management. In: Concurrent Engineering, 15/2007, pp. 217-235. M. Ebel, M. Okon, M. Baumann: “ProduFlexil”: Flexible Produktion mit SOA-Architektur und Plug-and-WorkMechanismus. Tagungsband zum Stuttgarter Softwaretechnik Forum (Science meets business), 2007, pp. 6574. U. Epple: Austausch von Anlagenplanungsdaten auf der Grundlage von Metamodellen. atpAutomatisierungstechnische Praxis 45, Heft 7, 2003, pp. 2-11. A. Fay, R. Drath: Objektorientierte Beschreibung einer Chemieanlage: Möglichkeiten und Vorteile. DECHEMA Jahrestagung, Wiesbaden, In: Chemie Ingenieur Technik CIT, 77, No. 8, 2005, pp. 1072. K. Guettel, P. Weber, A. Fay: Automatic generation of PLC code beyond the nominal sequence. In: Proceedings of the International Conference on Emerging Technologies and Factory Automation (ETFA), Hamburg, ISBN 1-4244-1506-3, IEEE, 2008. J.J. Michel: Terminology Extracted from Some Manufacturing and Modelling Related Standards. CEN/ TC 310 N1119R2, 2005. Parnas D.L. (1972): Communications of the ACM, Vol. 15, No. 12, December 1972 pp. 1053 – 1058. M. Schleipen, M. Baumann, M. Okon, M. Neukäufer, F. Fedrowitz, M. Feike, N. Popova, M. Nick, S. Schneickert, M. Wessner: Veränderungen im Konzeptions- und Konstruktionsprozess durch modular aufgebaute Anlagen mittels Ambient Intelligence-Technologien. Stuttgarter Softwaretechnik Forum (Science meets business), 2008, pp.57-67. M. Schleipen, R. Drath: Three-view-concept for modelling process or manufacturing plants with AutomationML. In: Proceedings of the IEEE Conference on Emerging Technologies Factory Automation (ETFA), 2009. S. Schmitz, U. Epple: Automatisierte Projektierung von HMI-Oberflächen. In: VDI-Berichte Nr. 1980, S. 127-137, 2007. J. Schüler: Workflow / fachübergreifende Integration / eine Utopie? In: VDI-Berichte Nr. 1684, VDI-Verlag Düsseldorf, 2002. pp. 7-16. R. Soenen, G. Olling: Feature Based Product Life-Cycle Modelling. IFIP TC5/WG5.2 & WG5.3 Conference on Feature Modelling and Advanced Design-for-the-Life-Cycle Systems (FEATS 2001), Valenciennes, France, Springer-Verlag New York, 2001. S. Y. Yim, H. G. Ananthakumar, L. Benabbas, A. Horch, R. Drath, N. F. Thornhill: Using process topology in plant-wide control loop performance assessment. In: Computers & Chemical Engineering 31, 2006, pp. 86-99. R. I. M. Young, A. G. Gunendran, A. F. Cutting-Decelle, M. Gruninger: Manufacturing knowledge sharing in PLM: a progression towards the use of heavy weight ontologies. In: International Journal of Production Research, Vol. 45, No. 7, 2007, pp. 1505–1519.

AutomationML Web references

[BookLink@] [BPR EDRef@] [BPR Units@]

→www.automationml.org/amlbook →www.automationml.org/amlbook: Best Practice Recommendations: ExternalDataReference. ID: BPR EDRef, V1.0.0., July 2016. →www.automationml.org/amlbook: Best Practice Recommendations: Units in AutomationML. ID: BPR Units, V 1.0.0, August 2018.

Web references [PLCopen 2009@] [PCR20@]

PLCopen: →http://www.plcopen.org/

[UNECE 10@] [W3C20@]

UNECE Recommendation N°20 Codes for Units of Measure Used in International Trade. Available at →http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_Rev7e_2010.zip.

PCRE - Perl Compatible Regular Expressions. Available at →http://www.pcre.org/

→http://www.w3.org/TR/xmlschema-2/#built-in-datatypes

Standards and guidelines [IEC 62424:Ed1] [IEC 62424:Ed2] [IEC 62714:Ed1] [IEC 62714:Ed2] [IEC 62264] [COL08] [IEC62264] [KHR09]

IEC 62424 Ed. 1: Representation of process control engineering requests in P&ID diagrams and data exchange between P&ID tools and PCE-CAE Tools. International Electrotechnical Commission, IEC, 2008. IEC 62424 Ed. 2: Representation of process control engineering – Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools. International Electrotechnical Commission, IEC, 2016. IEC 62714 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML). International Electrotechnical Commission, IEC, 2012. IEC 62714 Ed. 2: Engineering data exchange format for use in industrial automation systems engineering (AutomationML). International Electrotechnical Commission, IEC, 2018. IEC 62264-1: Enterprise – Control System Integration – Part 1: Models and Terminology, International Standard, 2013. COLLADA – Digital Asset Schema Release 1.5.0, 2008. IEC 62264 (2003) Enterprise-control system integration. Khronos (2009), →http://de.wikipedia.org/wiki/Khronos_Group

Notes 3

COLLADA is the trademark of a product supplied by the Khronos Group [KHR09]. This information is given for the convenience of users of AutomationML. Equivalent products may be used if they can be shown to lead to the same results.

4

Mentioned tool names in this book are usually trademarks of their respective software vendors. This information is given for the convenience of the reader. Equivalent products may be used if they can be shown to lead to the same results.

Chapter 3  Modelling of Geometry and Kinematics Modelling of geometry and kinematics information with COLLADA and integration into CAEX Rainer Drath Steffen Lips Content 3 Modelling of Geometry and Kinematics — 169 3.1 Introduction — 169 3.2 Modelling of geometry and kinematics with COLLADA — 170 3.2.1 Overview of COLLADA 1.5 — 170 3.2.2 Geometry modelling — 171 3.2.3 Kinematics description — 187 3.3 Examples — 200 3.3.1 BREP: Flange with hole — 200 3.3.2 Facetted model: flange with hole — 203 3.3.3 Kinematics of a screw with formula — 204 3.4 Interlinking COLLADA and CAEX — 206 3.4.1 Extensions of AML libraries for geometry and kinematics — 206 3.4.2 How to reference a COLLADA document — 207 3.4.3 Attributes refURI, Frame and refType — 207 3.4.4 How to model attachments — 208 3.4.5 Modelling rules — 209 3.5 Summary — 211 3.6 References for Chapter 3 — 212

3  Modelling of Geometry and Kinematics 3.1  Introduction This chapter is dedicated to the data exchange of geometry and kinematics with AutomationML by adopting and referencing COLLADA XML. Geometry models are important ingredients for the visual simulation of physical assets. Their useful application for modelling and simulation of industrial processes is known for several decades in the academia. But in industrial reality, the creation of simulation models mostly did not pay off because the benefits generated from them did not exceed the necessary costs. In the last decade, this has changed a lot due to significant improved tool support, computational power, network bandwidth and availability of know-how. The break-even is achieved in many applications. 3D modelling of products, plant components, machines or robots has received a considerable boost in the last 10 years and is now offered by a variety of engineering tools for different industries. The use of simulation models for automation devices is increasingly worthwhile in plant simulations for specific use cases is already used in various degrees of detail. But still, it’s computer games that give industry a preview of its own future: complex worlds with their modular buildings, characters and landscapes are simulated in a 3D world. Imagine we would be able to assemble industrial production facilities plants including automation technology on a similar easy-touse basis by combining available simulation models from different vendors. We could develop and optimize control strategies and test them risk-free. The benefits are obvious, the author predicts that virtual engineering will become a matter of course in the future. But one of the cost intensive hurdles of beneficial introduction of simulations in industry is the exchange of geometries and behaviour models between tools of different vendors. This is still problematic and cost-intensive, for example when geometry and kinematics is part of it. For AutomationML, this area is therefore of particular importance. It is precisely in this application that previous data formats fail, and considerable effort is required to transfer planned manufacturing cells from one tool to another. →Section 3.2 explains how geometry and kinematics are modelled with COLLADA, followed by examples explained in →section 3.3. →Section 3.4 shows how COLLADA models are referenced from a CAEX object model and how to model attachments. The interlinking between CAEX and COLLADA re-uses the flexible interface mechanisms of CAEX and supports the modelling of geometric scenes out of a hierarchical object model of independent geometry models. Especially a hierarchy of CAEX objects with individual geometries is a valuable source of digital

models of geometry scenes, and AutomationML provides the means to model different geometry resolutions, attachments and many other relevant aspects useful for engineering data exchange.

3.2  Modelling of geometry and kinematics with COLLADA 3.2.1  Overview of COLLADA 1.5 This section describes the open industry standard COLLADA adopted by AutomationML. After a short overview of the development history, the contents and functionalities of the current version of COLLADA are presented. The main focus is on the relevant aspects for AutomationML - the description of geometry and kinematics. The basic structure of a COLLADA document is only covered briefly. For further explanations of the functions not mentioned here, please refer to [COL08] and [AMB06] for further reading. A glance into the children's rooms reveals the potential that can be expected in the future: today's generation of children grows up with 3D games as a matter of course. Modern game consoles calculate breathtakingly realistic and amazingly complex environmental simulations. Applications like Google Earth provide detailed geometric images of our world. 3D images have become a normal part of today's software landscape and enable the visualization of virtual worlds. Since the computer games industry has always been a few steps ahead of the process or manufacturing industry in terms of both hardware development and software integration, it is not surprising that it has encountered exactly the same problems as the automation industry today: a wide range of different tools, each operating on its own data format. For that reason, the project COLLADA (COLLAborative Design Activity) was launched at SIGGRAPH in San Diego in 2003 - at that time still under the patronage of Sony Computer Entertainment. Based on an analysis of all data formats from the field of Digital Content Creation (DCC) available on the market, an intermediate format was to be defined, which would guarantee the transmission of the necessary information from one tool to the next. In the following three years, innovations were always introduced in time for SIGGRAPH – In 2004 the version 1.0 was announced in Grenoble. – In 2005 version 1.3.1 was released in Dublin. COLLADA now supported the exchange of geometries, materials and animations. – In 2006 version 1.4.1 was released in Vienna, after COLLADA was handed over to the care of the Khronos organization. Important new features are the introduction of a physics model and the support of shader languages. This version remained stable for the next two years and was increasingly implemented by DCC tools.

– In 2007 the members of the AutomationML consortium joined the Khronos Organization. The working group “Automation” was founded. – 2008 version 1.5 was announced at SIGGRAPH in Crete. The content of COLLADA was extended by models for the description of exact geometries (“Boundary Representation”) and kinematics. – Since 2009 further topics relevant for automation are in engineering. 3.2.2  Geometry modelling 3.2.2.1  Introduction The geometry of plant components is the most “visible” part of AutomationML. Complex scenes can be composed of individual geometries. A COLLADA document can be assigned to each AutomationML object of the plant hierarchy (see Chapter 2). An example of a plant component is a robot - see →Fig. 3-1.

Fig. 3-1 The 3D geometry of a plant component “robot” The geometry description is done by XML documents, whose structure is defined in a COLLADA schema file, which is freely available under [KHR09@]. To describe a complex component with COLLADA many details have to be modelled. The following section deals with the basic structure of COLLADA documents and explains the application of essential COLLADA elements. 3.2.2.2  Structure of a COLLADA document

The element is the root element of every COLLADA document. The mandatory attribute version is of type xs:string and has the value 1.5.0 for COLLADA 1.5. A COLLADA document is divided into four main sections: The first section is the mandatory element . The first section is the mandatory element , where the creation and modification date of the COLLADA document is stored. Furthermore, information about the unit of measurement used in the document or the publisher of the document can be specified. The second section contains various library elements. These can be used to organize the different data of a component to be displayed; for instance, in or all single geometries or all used materials of the modelled component are defined. The element forms the third section. A scene defines the graphically displayed elements. Usually a visual scene is instantiated, which composes the different geometries hierarchically and is stored in . In the element , which forms the last bleed, COLLADA offers the possibility to store additional data in the form of XML.

Fig. 3-2 Generic Structure of a COLLADA document 3.2.2.3  Boundary Representation (BREP) BREP models offer the possibility to describe geometries exactly - in contrast to facetted models, which are only optimized for visualization and only describe the shell or hull - but not what is possibly inside.

BREP models describe shapes of one dimension by shapes of the next lower dimension and its boundaries. →Fig. 3-3 shows this using a hull. The given shape is a boundary of the three-dimensional space. It describes a solid or - in simple terms - it describes where material is and where it is not. Within the 3-dimensional shell there are several boundaries of the two-dimensional space. The solid is limited by two cylinders (inside and outside) and two planes (top and bottom). Both planes are also bounded by two circles, i.e., one-dimensional elements. As can be seen, two different classes of elements are necessary. One class describes the pure unlimited geometry - for instance surfaces like cylindrical surfaces or lines like straight lines or circles - and the other class describes the type of boundary - for instance faces and edges. In this way it is possible to describe shapes exactly - wire meshes, for example, only provide an approximate description. High-quality precision is a prerequisite for industrial use. COLLADA 1.5 offers a complete model for the description of geometries using BREP. Although each BREP kernel of the different CAD products is slightly different from the others, a lossless transformation to and from COLLADA - and thus also among each other - is possible.

Fig. 3-3 BREP model of a sleeve The basic geometric elements are listed in →Table 3-1.

Table 3-1: Listing of the geometric elements Element

Description

Point Curve Surface

Geometric element of dimension 0 Geometric element of dimension 1 Geometric element of dimension 2

The limiting elements define the boundaries of the geometric elements and are listed in Tab. 3.2. As can be seen, there is a geometrical correspondence to the limiting elements Vertex, Edge and Face: point, curve and surface. The limiting elements of one class also form the basis for the elements of the next higher class. An edge is therefore limited by vertices (points). A Wire is limited by Edges etc. Consequently, limiting elements of a type always and exclusively consist of limiting elements of the previous type, i.e., edges always consist of vertices. Wires are always composed of edges, Wires always become Faces, and so on. Each limiting element has a direction (basic orientation), which is defined by the mathematical definition of the geometry or by the order of connection. Table 3-2: Listing of the limiting elements in the order of their complexity Element

Description

Vertex Edge Wire Face Shell Solid

Limiting element of dimension 0 (point) Limiting element of dimension 1 (edge) Composition of adjacent edges Limiting element of dimension 2 (surface) Composition of adjacent faces Limiting element of dimension 3

This can either be retained or reversed for the assembly of a limiting element of the next higher class. This is necessary, for example, when several edges (curves) are joined together to form a Wire. In the following example the edges E1, E2 and E3 are limited by the vertices (points) V1, V2 and V3. In order for the 3 edges to be joined together to form a Wire, the 3 edges must be rectified. To do this, either edge E3 or, as shown in →Fig. 3.4, edges E1 and E2 must be reversed.

Fig. 3-4 Orientation of Edges In principle, any geometry, however complex, can be described with these means. In most CAD formats that can represent BREP models, however, parametric information is often also stored. Parametric information is limiting information in the parametric space of the considered element. For example, an edge that is bounded by two vertices can also be described by two parameters in the space of the corresponding curve. For example, an edge described by a straight line of the form (x|y|z) = l(1|1|0) is bounded by the vertices V1(0|0|0) and V2(2|2|0). The two vertices are defined in the parametric space of the curve by the parameters l=0 and l=2, i.e., the edge can also be described using these two numerical values. Similarly, faces can be described by 2D curves in their parametric space. The basic structure of a BREP geometry in COLLADA is shown in →Fig. 3-5.

Fig. 3-5 Basic structure of the element BREP models are introduced by the COLLADA element . The elements , and are used as containers for the geometric elements that can be used in the BREP model. In addition to the curves and surfaces in 3D space, these are also the optional curves in 2D space of the considered surface. A list of the supported curves and surfaces in COLLADA can be found in →Table 3-3 and →Table 3-4. Table 3-3: List of all supported curve descriptions Element

Description

Vertex Element



Limiting element of dimension 0 (point) Description line circle/arc ellipse/elliptical arc Parable

Table 3-4: List of all supported surface descriptions Element

Description





plane cylinder cone torus sphere Rotation and extrusion surfaces Non-Uniform Rational B-Spline surfaces

In the following elements, all data to which the limiting elements refer, are logically summarized. These are, besides the “scoped identifiers” (SID) of the previously described curves and surfaces, the coordinates of the vertex points and the possible orientations.

Fig. 3-6 Structure of the delimiting elements Now all information necessary to create a BREP geometry is available. Starting with the vertices, the model can be built. These are created with the COLLADA element . Through the element it refers to the previously defined 3D points. The indexing of the vertices is determined by the order of the points. The

first vertex has the index 0 and is the first point of the referenced element. The element has four elements and one

element. The offset attribute of the elements specifies how the index list of the

element is to be interpreted. As shown in →Fig. 3-6, in this example 4 indices each determine an edge. The first index indicates the geometric representation of this edge. The following two indices indicate the boundaries of this edge by a start and an end vertex. The last index references a pair of parameters that determine the boundary of the edge in the parametric space of the curve. The element has two elements, one and one

element. The element specifies how many edges the wire consists of. In the given example, the first wire consists of four edges, i.e., the first eight indexes of the

element form this wire, whereby one pair of indexes always references an edge and specifies its orientation. All other elements work analogously. More examples with detailed explanations are described in →section 3.3. 3.2.2.4  Tessellated geometries In order to visualize geometries, they must first be “tessellated”, i.e., they are converted into a format that is suitable for graphics processing units (GPU). This data preparation is quite time-consuming. For this reason, most data formats in the CAD environment also store the result of a tessellation. If a geometry changes, only the corresponding part is re-tessellated. →Fig. 3-7 shows a tessellated representation of previously introduced geometry object “sleeve”.

Fig. 3-7 Tesselated representation of a sleeve COLLADA provides a comprehensive set of polygon-based geometry descriptions for tessellation. Tesselated geometries are introduced by the element . This results in a similar distribution of the data as in the BREP model. First, all source data necessary for the description is provided in containers, which are then referenced by graphics primitives. This source data is essentially vertex data - that

is, points or 3D positions. Further source data can also be normal vectors, texture coordinates, colour coordinates etc. Fig. 3-8 shows the general structure of a polygon-based geometry in COLLADA.

Fig. 3-8: Building a polygon-based geometry in COLLADA

The element (see →Fig. 3-9) defines individual line segments by a start and an end point. A element can contain more than one line. Always two vertices model an individual line. The number of lines is stored in the attribute count.

Fig. 3-9 The element Connected lines can be described more compactly by the element than with . As shown in →Fig. 3-10, the first segment of a strip is defined by the first two vertices. Each further vertex defines a further line segment whose end point is this vertex itself and whose starting point is the end point of the previous segment. The attribute count specifies the number of defined strips.

Fig. 3-10 The element

A polygon is defined by its edges and is essentially a closed line strip, see →Fig. 311. Polygons can be very complex and are therefore only partially or not at all supported by many visualization tools, since they can consist of more than 3 vertices, which can lead to the following problems: – The polygon is not planar. – The polygon is concave. – The polygon intersects itself. – The polygon defines holes. The attribute count specifies the number of polygons.

Fig. 3-11 The element with a hole In a more compressed form, polygons are described by the element , see →Fig. 3-12. The element defines how many vertices a polygon consists of. The attribute count specifies how many polygons are described in total.

Fig. 3-12 The element The simplest form of a polygon is a triangle. This shape of a polygon is always planar, convex and cannot intersect itself. Triangles are described by the element , see →Fig. 3-13. The attribute count specifies the number of individual triangles.

Fig. 3-13 The element A triangle strip is a set of triangles that share one edge each. It is described by the element , see →Fig. 3.14. The first triangle is defined by the first three vertices. The edge defined by the last two vertices is the first edge of the next triangle, which is completed by the following vertex.

Fig. 3-14 The element A variation of triangle-strips forms the triangle-fan. Again, the first triangle is formed by the first three vertices. In contrast to the Triangle-Strip the first edge of the following triangle is the one formed by the first and last vertex of the previous triangle. Thus, all triangles of a triangle fan have one common vertex. Triangle-fans is described by the element , see →Fig. 3-15.

Fig. 3-15 Das element 3.2.2.5  Modelling product trees The previous sections described how to create geometries. However, a complete component (for instance a robot) would not be described by a single geometry, but by several. This has the advantage that the individual components can be shown or hidden in the visualization or can be reused for other components, for example

because they are the same in different designs of the component. This results in a so-called product tree, which combines individual geometries and partial products into a complete product. In COLLADA, such a product tree is described by a hierarchy of elements. Each element can have elements as children. In addition, the geometric position of such an element can be determined by various transformations relative to the parent element. A list of possible transformation elements is shown in →Table 3-5. Table 3-5: List of transformation elements Element

Description





4x4 transformation rotation about an axis Shift along a vector Scaling vector Skew

Fig. 3-16 Geometry of a component “KR150-1” Each of these transformations can be used in arbitrary order as often as desired. After positioning, the desired geometry is instantiated. This is done using the element , which refers to the geometry to be instantiated using the attribute url. →Fig. 3-16 and →Fig. 3-17 show a robot component and its product tree in the XML representation of COLLADA.

Fig. 3-17 Visual scene of the “Robot” component 3.2.2.6  Modelling of materials Materials determine the appearance of a geometry. A geometry can be provided with different colours or textures. However, the type of materials is not stored in the geometry definition, otherwise it would be firmly connected to the geometry.

This would mean that a geometry with a different material would have to be described again from scratch. Therefore, in COLLADA materials are only linked to geometry when it is instantiated. To define a material, a so-called effect must first be described. Effects are defined by the COLLADA element , which represents the illumination behaviour of a surface, for instance reflection or transparency. For example, a simple red surface is described as shown in →Fig. 318-

Fig. 3-18 Definition of an effect This effect can now be used by a material definition. To do this, the effect is instantiated as shown in →Fig. 3-19.

Fig. 3-19 Definition of a material After the material is defined, it can be used by a geometry. This is done by the element . Here the material definition is “bound” to a specific material symbol name of the instantiated geometry. These symbol names are defined in the geometry definition by the material attributes of the graphic primitives (for instance ), see →Fig. 3-20.

Fig. 3-20 Binding of a material 3.2.2.7  Modelling of different levels of detail COLLADA 1.5 offers the possibility to store different levels of detail for a component or for sub-components. Using the attribute proxy of the COLLADA element , an application can run through the different levels of detail and use the representation required for the corresponding task. It is possible and advantageous to split models of different levels of detail into several COLLADA documents.

Fig. 3-21 Different levels of detail For example, if the application has a BREP modeler, it searches for the BREP representation of the object to be processed. If, on the other hand, it only wants to place a few placeholders, it looks for a mesh description that, in the simplest case, only represents a bounding box. 3.2.3  Kinematics description 3.2.3.1  Requirements for a kinematics description

The kinematics of plant components includes the physical causal relationships between their components, which is given by joints, for example. When developing a generic description of kinematic models with COLLADA, attention was paid to the fact that the data model can be further developed in the future. Top priority was given to the strict separation of geometry and kinematics, since the task of a kinematic model is to provide all necessary information that an application needs to solve an inverse kinematic problem. Furthermore, both target groups of COLLADA - the automation industry and the games industry - should be reflected in the design. This means that it must be possible to easily model simple kinematics without overloading it with the necessary information that for instance an industrial robot programmer needs. The following sections cover all aspects that can be modelled with the current version of COLLADA. 3.2.3.2  Description of joints COLLADA 1.5 provides two joint primitives: The rotational base joint defines the degree of freedom as rotation around an axis. The translational base joint defines the degree of freedom as a translation along an axis. From these two basic joints all kinds of joints can be derived. →Table 3-6 gives an overview of the common joint types.

Table 3-6: List of common joint types, illustrations from [MW09@] Name of the joint

Degrees of freedom

Prismatic joint

1x trans.

Revolute joint

1x rot.

Cylindrical joint

1x rot., 1x trans.

Planar joint

1x rot., 2x trans.

Spherical joint

3x rot.

Example

Name of the joint

Degrees of freedom

Universal joint

2x rot.

Screw

1x rot., 1x trans.

Example

A joint is defined by the COLLADA element . This can contain any number of elements of the type or , which are the basic joints. A basic joint itself consists of the element , which defines the axis of the degree of freedom. Optionally, the value range in which a base joint may move can be restricted. The unit of the value range depends on the type of joint and is always degrees (°) for revolute joints and the unit defined for the component or document (for instance mm) for prismatic joints. →Fig. 3-22 shows the definition of a prismatic joint and a universal joint.

Fig. 3-22 Definition of joints 3.2.3.3  Kinematic models Kinematic models are the basis for the calculation and solution of kinematic problems, such as the path planning of a welding process. Kinematic models or

kinematic chains are systems of rigid bodies, so-called links, which are connected by joints. Kinematic models are defined by the COLLADA element . First, all joints are listed that are used by this kinematic model. Any of the joints previously defined in can be instantiated by the element. It is also possible to define new joints. Then the kinematic chain is defined. It always begins with the element . Further links can be attached to this link using the element. The transformation elements and can be used to position the following link accordingly. The following →Fig. 3-23 shows how a simple 1-joint kinematics is constructed.

Fig. 3-23 Example of a simple kinematic model As illustrated in the example, the COLLADA element positions the joint along the coordinate system of the parent link. A kinematic chain is typically a sequence of links and joints. The occurrence of cycles is quite possible and even common. These cycles - or “closed loops” - are represented in COLLADA by the

elements and . Such a cycle is shown in →Fig. 3-24. As we see, one “partial chain” is defined by the links l1 and l2 and another by the links l1, l3, l4 and l2. Both chains are independent of each other until they are brought together by the joint j4. One chain uses this joint by the element , the other by the element . Both elements must always appear as a pair in a valid kinematic model. However, the order in which they are used is not important, meaning the elements can be interchanged.

Fig. 3-24 A simple cycle 3.2.3.4  Representation of formulas As shown in the previous two sections, any complex kinematics can be created by using the COLLADA elements , , and . However, calculations with kinematics that contain cycles are

complex and are therefore not supported by all tools. Nevertheless, such tools seem to be able to solve this kind of kinematics. To do so, they use a trick: The original kinematic chain with one cycle is split into two separate chains. To make sure that the overall kinematics behave exactly like the original one, some joints are calculated by a given formula. The second partial chain is connected to the first chain by formulas and thus provides the same result as the kinematics with cycle when simulating or calculating the inverse. For the above example, the joint j2 would have to be calculated with a formula or the joints j1, j3 and j4. Since this is a simple parallelogram, the following formulas for a parallelogram can be given for the joints j1, j3 and j4: j1 (j2 ) = j2 j3 (j2 ) = −j2 j4 (j2 ) = −j2

COLLADA 1.5 uses the W3C standard MathML [W3C03@] to map formulas. The COLLADA element defines a formula. First, the element determines where the result of the calculation should be written to. Then follows the MathML description of the formula to be used, embedded in the element. →Fig. 3-25 shows an example of the corresponding COLLADA source code. Formulas often use predefined functions. An example of this are trigonometric functions such as SASA (Side-Angle-Side-Angle) or SASS (Side-Angle-Side-Side). These in turn use the function atan2, which is not part of the known function set of MathML. To avoid having to multiply these functions for each formula, they can be pre-defined in a corresponding library. An importing tool can then, if it implements this function itself, skip reading it. A small example of such a pre-definition is given in →Fig. 3-26. Here a simple function is described, which adds two numbers together. The transfer parameters are each defined by the element and can then be used with their symbolic name.

Fig. 3-25 Kinematic model with formulas

Fig. 3-26 Predefined function The following code excerpt shows how this function can be used within a formula.

Fig. 3-27 Using a function 3.2.3.5  Articulated systems Kinematic models only describe the degrees of freedom of a system. Since it can actually be used for a simulation system, it must be enriched with further information. COLLADA 1.5 distinguishes between the enrichment of purely kinematic aspects, which form the basis for the solution of an inverse problem, and purely dynamic aspects, which determine the behaviour of the kinematics during the travel of a path. To enrich a kinematic model with such information, “articulated systems” are used. An articulated system is defined by COLLADA element . The next step is to determine which aspects of the model are to be described. This is done using the element or the element . A list of the kinematic or dynamic properties that can be defined can be found in →Table 3-7.

Table 3-7: Kinematic aspects Property

Element

Description

Joint activity

Joint locks

Soft limits

Indexing

Coordinate systems



In a kinematic system a joint can be active or passive. All active joints must be considered in a kinematic calculation. Passive joints are calculated in a second step, as they are not decisive for the solution of the problem. It is possible that in a kinematic system some joints are locked for certain tasks. In a calculation, the corresponding degrees of freedom are not considered for these joints. When defining joints, it was already possible to determine their limits. These limits are hard, i.e., they cannot be overcome by physical means alone. In a kinematic system, “soft” limits can be defined in addition to these “hard” limits. These are useful, for example, to prevent two links from colliding with each other from the start. Each joint in a kinematic system has a corresponding position in the equation system of the kinematic problem. This position in the so-called joint vector is defined by an index. Different coordinate systems can be defined, which are necessary for the calculation of a problem. In detail these are the following: the origin coordinate system defines the origin for all calculations of the kinematic system This coordinate system must be defined. the tip coordinate system defines the coordinate system at the end of the kinematic chain. This coordinate system must be defined. the object coordinate system can be used to define a space for a workpiece. the tool coordinate system can be used to define the space of a tool used by the kinematic system.

To describe kinematic aspects, a model is first instantiated in the element . Within the instance, the parameters of the model are published for further use by the element . These elements are: – the reference to the instantiated model, – the references to the joints of the model and – the determination of an axis value of the corresponding joint. In the element the kinematic aspects of a joint are defined, for instance the activity or the index in the joint vector. The properties that are specified here can also be published again by a parameter. →Table 3-8 shows the definition of a kinematic system based on a kinematic model with two joints. The property locked of the second joint is published by a parameter.

Table 3-8: Dynamic aspects Property

Element

Description

Speed

Acceleration



Jerk

For each joint and for the end effector a speed can be defined which must not be exceeded. For each joint and for the end effector, an acceleration can be defined which must not be exceeded. A distinction is made between positive and negative acceleration. For each joint and for the end effector a jerk can be defined which must not be exceeded.

Fig. 3-28 Articulated system with kinematic aspects The element is structured similarly to the element . Here too, an instance is created first, but not that of a kinematic model, but that of an articulated system. Within this instance, its parameters can now be used, which were previously published as described above. There are two ways to use a parameter. On the one hand, a value can be defined with the element . Or the parameter can be re-published with the element . In this way, a parameter that was originally defined in a kinematic model can be passed on

through a whole chain of articulated systems until it is assigned a certain value. And again, further aspects - in this case dynamic aspects - can be added to the corresponding joint using the element. →Fig. 3-29 shows how the kinematic system created above is extended to a dynamic system.

Fig. 3-29 Articulated system with dynamic aspects Other types of articulated systems are conceivable for the future. Humanoid robots, for example, need a system to describe the balance behaviour so that the robot does not fall over during its movements. The given design in COLLADA allows the definition of a new type of articulated system that could be seamlessly integrated.

3.2.3.6  Combining kinematics and geometry In the previous clauses of this section, it was shown how a kinematic system can be created and how it can be extended by various aspects. Now a simulation tool should also be able to visualize its calculations and results, for example, it should be able to visualize the movement of a component. Consequently, the results of the kinematics must be incorporated into the geometry. For this purpose, a kinematic scene must first be created - analogous to a visual scene. This is done in the corresponding library using the COLLADA element . Within this scene any number of kinematic models or articulated systems can be instantiated. Using the parameterization mechanism described in the previous section, parameters can again be inherited by the kinematic scene. An example of a kinematic scene is shown in →Fig. 3-30. Here, the dynamic system already defined above was instantiated.

Fig. 3-30 Kinematic scene In this instance the inherited parameters are published again - except for one. The parameter that defines the locking of the second joint is overwritten here by the

element with a new value. For example, in this kinematic scene the second joint of the original kinematic model is locked. As described in →section 3.2.2.2 the element defines what the user will later see on the display. And this is where the combination between the visual and the kinematic scene happens. Both scenes must first be instantiated by the elements and . Within the instance of the kinematic scene, the first step is to determine which kinematic model is linked to which component in the product tree. This is done using the COLLADA element . Then the joints of the kinematic model are coupled to the corresponding transformations in the product tree. This is done by the element , whose attribute node references the transformation element in the visual scene that is to be moved by this joint. →Fig. 3-31 shows the connection of the kinematic scene described above to a geometry. In the element the joint of the kinematic model is referenced and the element defines the joint value it should have in this scene.

Fig. 3-31 Coupling between kinematics and geometry 3.2.3.7  Composite kinematics

Kinematics can be composed in different ways - for instance if a glue gun, which is a simple kinematics, is to be used by a robot. The glueing gun has little influence on the kinematics, since it only changes the “Tool centre point” (TCP) of the robot. Placing a robot on a linear motion axis is another form of composite kinematics. The difference between these two forms of composition is as follows: In the first case, a tool is only placed. If the robot travels along a process path, it is controlled by one controller each, just like the tool. The kinematics of the tool has no decisive influence on the way the robot follows the path. This type of composition corresponds to an “attachment” and is described in AutomationML by a COLLADA interface in the CAEX roof format, which is dealt with in the following →section 3.3. The second type of composition described has a significant influence on the engineering of the process path, since the linear motion unit represents an additional external axis. The robot and the travel axis form a kinematic unit, so to speak. And this is exactly how they are treated in reality. They are controlled by a common controller. In other words, the definition of an articulated system is the generic description of a robot controller.

Fig. 3-32 Articulated system of combined kinematics →Fig. 3-32 shows how such a connection between a robot and a driving axis could look like. In an articulated system the two kinematic models are instantiated. For a

program to control this system, it only needs to know how the axes are numbered. This is determined, as described above, by the element . For all the following steps, this system can now be regarded as one unit.

3.3  Examples 3.3.1  BREP: Flange with hole This section will explain the application of the BREP model of COLLADA 1.5, which is shown in the following figure →Fig. 3-33, by means of a simple example. It does not cover the whole model, but only the description of the hole on the upper rectangular surface.

Fig. 3-33 Flange with hole The geometric elements are therefore the six 3D points, six curves and one surface shown in →Fig. 3-34.

Fig. 3-34 Schematic representation of the topology To model this example, first the vertices are defined, as listed in →Table 3-9. Table 3-9: Definition of vertices Vertex

3D-coordinates

V1 V2 V3 V4 V5

-10, 7.5, 0 10, 7.5, 0 -10, -7.5, 0 10, -7.5, 0 0, 5, 0

The following →Table 3-10 lists the definition of the individual edges. Each individual edge has a basic orientation, given by the definition of the corresponding curve. From this basic orientation the definition of the start and end vertex results.

Table 3-10: Definition Edges Edge

Startvertex

Endvertex

E1

V1

V2

Curve ⎛

x

⎞

⎛

−10

⎞

1

⎛

⎞

⎜ y ⎟ = ⎜ 7.5 ⎟ + λ ⎜ 0 ⎟ ⎝

E2

V3

V4

⎛

z x

⎠

⎝

⎞

⎛

⎠

0 −10

⎝

⎞

0

⎛

⎠

1

⎞

⎜ y ⎟ = ⎜ −7.5 ⎟ + λ ⎜ 0 ⎟ ⎝

E3

V1

V3

⎛

z x

⎠

⎝

⎞

⎛

⎠

0 −10

⎝

⎞

⎠

0 0

⎛

⎞

⎜ y ⎟ = ⎜ 7.5 ⎟ + λ ⎜ −1 ⎟ ⎝

E4

V2

V4

⎛

z x

⎠

⎝

⎞

⎛

⎠

0 10

⎞

⎝

⎛

0 0

⎠

⎞

⎜ y ⎟ = ⎜ 7.5 ⎟ + λ ⎜ −1 ⎟ ⎝

E5

V5

V6

⎛

z x

⎠

⎝

⎞

⎛

0 0

⎠

⎞

⎝

⎛

0

cos ρ

⎠

⎞

⎜ y ⎟ = ⎜ 0 ⎟ + 5 ⎜ sin ρ ⎟ ⎝

E6

V6

V5

⎛

z x

⎠

⎝

⎞

⎛

0 0

⎠

⎝

⎞

⎛

0 cos ρ

⎠

⎞

⎜ y ⎟ = ⎜ 0 ⎟ + 5 ⎜ sin ρ ⎟ ⎝

z

⎠

⎝

0

⎠

⎝

0

⎠

Next, the Wires are defined. In this example there are two Wires, namely an outer and an inner one. For a Wire to be defined correctly, all edges belonging to a Wire must be oriented in the same direction. If the basic orientation can be maintained, the orientation of the Edge is FORWARD and it is REVERSED in the other case. Table 3-11: Definition Wires Wire W1

W2

Edge

Orientation

E1 E4 E2 E3 E5 E6

FORWARD FORWARD REVERSED REVERSED FORWARD FORWARD

The last thing to be specified is the face. It uses both Wires already created. One Wire borders the face, the other one cuts a hole in it. To determine exactly this difference between “bordering” and “cutting out”, the orientation is used again. If

the orientation of a wire is aligned with the normal of the surface to be bounded, the wire is a border. In the other case it cuts a hole into the surface. Table 3-12: Definition Face Face

Wire

Orientation

F1

W1 W2

REVERSED FORWARD

As shown in the table above, the first wire with opposite orientation must be used. This results from the basic orientation of the Wires as shown in →Fig. 3-35.

Fig. 3-35 Basic orientation of the Wires The remaining faces are described analogously and can then be assembled into a shell and from there into a solid. 3.3.2  Facetted model: flange with hole The geometry from the above example is described below as polygon-based geometry. The given BREP model was triangulated for this purpose. The result is a

representation of the geometry approximated by triangles as shown in →Fig. 3-36. Using 336 points, 112 triangles are described.

Fig. 3-36 Triangulated geometry The rounding of the hole is approximated with a manageable number of triangles, yet the transitions between two triangles do not appear angular. This is guaranteed by the normal belonging to each triangle point. The following →Fig. 337 illustrates this. In the example on the left the transition between the two triangles is hard-edged, for example the normal to each triangle point is perpendicular to its associated triangle surface. In the right example, the transition is soft. At the common edge, the normal was used for both triangles, which the arc in the BREP model has in this position.

Fig. 3-37 Hard and soft edge transition 3.3.3  Kinematics of a screw with formula This example describes the kinematic model of a screw in a nut. The model is very clear and yet contains many aspects described in the previous sections.

Fig. 3-38 Schematic diagram of a screw The kinematics consist of two components - a screw and its associated nut, which are connected to each other by a joint. The shaft length is 20 mm. One rotation travels a distance of 0.5 mm, which is defined in the parameter pitch. The nut can make 12 turns of the thread before it reaches the shaft. The joint is composed of two primitives: a translational and a basic rotational joint. In this example, the joint

definition is done within the kinematic model. The relation between rotation and countersinking of the nut is defined by the following screw formula: dcountersinking = dP itch ⋅

ρRotation 360

The description in COLLADA is shown in →Fig. 3-39 as XML code.

Fig. 3-39 Definition of the kinematic model

3.4  Interlinking COLLADA and CAEX 3.4.1  Extensions of AML libraries for geometry and kinematics In order to interlink CAEX and COLLADA, the standard interface class COLLADAInterface and the attribute type Frame are important. But further standard classes are required. The first extension in the AutomationMLBaseRoleClassLib is the role class Frame as specified in →Table 3-13. An AML object with the RoleClass Frame can be used to define reference coordinate systems like attachment points. This RoleClass can be inherited to add semantics. Examples for inherited frames are tool frame, base frame, process frame, work piece frame, etc. Table 3-13: RoleClass Frame Class name

Frame

Description Parent class Path reference for element

The role Frame denotes a cartesian right-handed coordinate system. AutomationMLBaseRoleClassLib/AutomationMLBaseRole AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Frame

The second extension in the AutomationMLInterfaceClassLib is the new interface class AttachmentInterface as specified in →Table 3-14. Table 3-14: InterfaceClass AttachmentInterface Class name

COLLADAInterface

Description

The InterfaceClass AttachmentInterface specifies an interface for geometric or kinematic links between AML objects with RoleClass Frame. AutomationMLInterfaceClassLib/AutomationMLBaseInterface

Parent class Path for element reference

AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ AttachmentInterface

Furthermore, the AutomationML standard defines the attribute Frame as part of the basic attribute type library (see →section 2.4.4). This specifies a coordinate system that is positioned relative to the coordinate system of the parent object in the topology. It consists of further sub-attributes: x, y, z, rx, ry and rz. These subattributes allow model the translation and rotation along the X, Y or Z axis and hence to precisely place an object within its parent coordinate system. These subattributes are described in →Table 3-15 and also determine the sequence of processing.

Table 3-15: Sub Attributes of the AML attribute Frame Attribute

Description

x y z rx ry rz

Translation along the X axis of the parent coordinate system in meters Translation along the Y axis of the parent coordinate system in meters Translation along the Z axis of the parent coordinate system in meters Rotation around the X axis of the shifted coordinate system in degrees (°) Rotation around the Y axis of the shifted coordinate system in degrees (°) Rotation around the Z axis of the shifted coordinate system in degrees (°)

3.4.2  How to reference a COLLADA document The previous sections described how COLLADA 1.5.0 maps geometry and kinematics information of a plant component. In order for this information to be assigned to an AML object, it must be referenced from CAEX. →Fig. 3-40 shows this: the AutomationML object 110RB_200 references a COLLADA document. This is done by means of a CAEX COLLADAInterface defined in the AML basic interface class library (see →section 2.4.3.6). Its attribute refURI contains the Uniform Resource Identifier (URI) of the COLLADA document, which contains the geometry and kinematics of this object.

Fig. 3-40 Reference of a CAEX object to COLLADA

3.4.3  Attributes refURI, Frame and refType In addition to the reference to the COLLADA document, the geometric positioning of the object relative to its parent object can be specified in CAEX. →Fig. 3-41 shows an example of a COLLADA interface with its attributes refURI and Frame. The attribute refType determines how the referenced resource is to be used. It can take the values “implicit” and “explicit”, whereby the latter is the default value if no value is specified. The modelling rules are described in 3.4.5.

Fig. 3-41 XML code for a COLLADA interface 3.4.4  How to model attachments The COLLADA interface can also be used to create a connection between two AutomationML objects. An example of such a link is “attaching” a gripper to a robot as shown in →Fig. 3-42. For this purpose, the robot and the gripper publish the corresponding attachment points in the CAEX object model and link them to each other using standard CAEX mechanisms. The modelling principle is shown schematically in →Fig. 3-42. Both AML objects Robot and Gripper have a reference to any COLLADA geometry objects by using explicit references. Furthermore, both AML objects have a child internal element that are assigned to the RoleClass Frame, in this example attGeometry. Each attGeometry has an implicit external interface derived from the interface class COLLADAInterface that references a defined

in the COLLADA document. Additionally, each frame has another external interface derived from the interface class AttachmentInterface. These are connected or linked via CAEX InternalLinks.

Fig. 3-42 Simple example attachment between two geometries

Fig. 3-43 Structure for attachments between objects in CAEX 3.4.5  Modelling rules The modelling rules for refencing a COLLADA document from an AML object model are: – A reference from an AML object to a COLLADA document is modelled by means of a CAEX ExternalInterface derived from the AML InterfaceClass COLLADAInterface.

– An AML object may have zero, one or multiple interfaces of type COLLADAInterface. – The COLLADA document is referenced by its URI within the attribute refURI of this CAEX ExternalInterface. The modelling rules for the attribute target are: – The value of the attribute target points at an element within the COLLADA document and follows the syntax of a SID path. – If the attribute target is not present or its content is empty and the URI has no fragment, the element scene of the COLLADA document must be considered. – The document and entry point for a COLLADA document must be resolved as specified in →Table 3-16. Table 3-16: Rules for resolving document and entry point SID path of attribute target starts with an ID SID path of attribute target starts without an ID Attribute target is missing, or its value is empty

URI with fragment

URI without fragment

URI specifies the document. SID path specifies the entry point.

URI specifies the document. SID path specifies the entry point.

URI specifies the document and a corresponding element for the entry point. SID path specifies the entry point. URI specifies the document and the entry point.

Undefined status. This combination shall not be used. URI specifies the document. The element “scene” specifies the entry point.

The modelling rules for the attribute refType are: – If a COLLADA document is explicitly referenced, the content of the document is part of the plant topology. This means that the geometrical representation of a component is only described in this document. An implicit reference, on the other hand, is used to describe a component that has already been described and placed in the topology in more detail or under a different aspect. This document is not to be used to build the overall scene, because it would otherwise be inserted into the scene twice. – The value of the attribute refType can be “explicit” or “implicit”. Other values are not allowed. – The value “explicit” of the attribute refType is used for AML objects (henceforth named explicit AML objects) that are part of a data representation. An example of explicit AML objects is the geometry of a robot and a conveyor in a common geometric scene.

– The value “implicit” of the attribute refType is used for AML objects (henceforth named implicit AML objects) that are used for special purposes for referencing objects that are already represented, for instance for publishing frames or referencing of objects that are already represented. An example of implicit AML objects is the reference of a robot’s geometry that has been already explicitly referenced. The implicit referencing avoids double representation of geometries. – Objects in the COLLADA document only may be referenced using value “implicit” if they are part of an COLLADA object or identical with an COLLADA object, which already was referenced with value ”explicit”. Implicit AML objects must be modelled as direct or indirect children of explicit AML objects. The modelling rules for the attribute Frame are: – If an InternalElement or a SystemUnitClass requires to represent its geometric position in relation to other objects, this is modelled by an attribute of type Frame. – Each frame must be based on a three-dimensional, orthogonal, right-handed coordinate system. – The relative translations x, y and z as well as the rotations rx, ry and rz are specified as sub-attributes in the frame attribute. The relative translations x, y and z must be given in relation to the parent InternalElement, InstanceHierarchy, SystemUnitClass, or SystemUnitClassLibrary. The rotations rx, ry and rz must be executed in the order rx, ry and rz around fixed axes of the parent InternalElement. The frame attribute affects its containing AML object and all its children. – If the attribute Frame is not specified, the default values of x, y, z, rx, ry and rz are interpreted as 0. – If the attribute Frame is specified, all sub-attributes x, y, z, rx, ry and rz must be listed. Any unused sub-attribute must have the default value 0. – The elements InstanceHierarchy and SystemUnitClassLib specify a threedimensional, orthogonal, right-handed coordinate system with standard basis. The positive z axis is considered upward, the positive x direction defines the right axis, and the negative y direction defines the forward axis. – The value of attribute Unit of frame attribute must be “m”. The modelling rules for attachment interfaces are: – An AML object can have zero or one AttachmentInterface as direct child. – A link between two attachment interfaces is modelled as CAEX InternalLink as a unidirectional connection with fixed geometric coupling.

– The relative transformation from the AML object referenced by the attribute RefPartner-SideA to the object referenced by the attribute RefPartnerSideB must remain constant even if the object of RefPartnerSideA is transformed, resulting into a corresponding transformation of RefPartnerSideB in case of a transformation of RefPartnerSideA. A transformation of RefPartnerSideB does not modify the transformation of RefPartnerSideA. RefPartner-SideA and RefPartnerSideB are attributes of the CAEX InternalLink element. – As an attachment point is part of an AML object, the attachment interface must be part of the corresponding AML object. – If an attachment interface is child of an AML object with the RoleClass Frame or an inherited RoleClass, the object to be moved shall be the parent AML object of the AML object with the RoleClass Frame or an inherited RoleClass (even if the parent AML object has the RoleClass Frame or an inherited RoleClass). – If an AML object owning an attachment interface has the RoleClass Frame or an inherited RoleClass and it has an interface of type COLLADAInterface, the parent AML object must have an interface of type COLLADAInterface as well. The COLLADA interface of the parent AML object represents the boundary of the geometry of the attached geometry. – If an attachment refers to a geometric element, a COLLADA interface must reference a COLLADA node of the visual scene. The attachment must move the complete geometry (recursive up to the node attribute of a element) of the attached object without modification of the kinematic state of the attached object. – If an attachment refers to a kinematic element, a COLLADA interface must reference a COLLADA element inside a COLLADA element. The attachment must affect the joint configuration of the attached kinematic object when moving the parent AML object of the attached object. The importing tool is responsible for the calculation of such coupled kinematic elements. – To establish a bidirectional connection, two unidirectional links are necessary, with each link in opposite direction to the other one. – An attachment interface may be linked more than once. Further general modelling rules are: – In cases of a COLLADA document (henceforth named main document) referencing other COLLADA documents (henceforth named subdocuments) according to the rules of instantiation and external referencing as specified in ISO/ PAS 17506 all references to elements within the referenced COLLADA subdocuments shall only be done via the COLLADA main document.

3.5  Summary The combination of geometry and kinematics could not be mapped in any freely available data format so far. Due to suggestions of the AutomationML consortium in the Khronos Group, the combination was introduced into COLLADA version 1.5. Thus, for the first time it is possible to map and exchange kinematic geometries manufacturer independent. COLLADA 1.5 thus represents an essential result of the AutomationML activities and can be used for the exchange of kinematized geometries. This enables the saving of cost-intensive expenditures for manual conversion and postkinematization of objects that have to be imported from a third-party tool. The chapter is divided into four sections and gives a comprehensive overview of how to use COLLADA 1.5 in AutomationML. After an overview of the history of COLLADA, the chapter first deals with the different ways of defining geometry. It explains how to create geometries and finally how to combine them into a product. The use of materials as well as the management of different levels of detail conclude the first part. The second part deals with the modelling of kinematic models starting with the definition of joints up to the composition of different systems to a complete kinematics. The connection between COLLADA and CAEX and their possible interactions form the third part. A series of illustrative examples concludes this chapter.

3.6  References for Chapter 3 [AMB06] [COL08]

Rémi Arnaud, Mark C. Barnes: COLLADA – Sailing the gulf of 3D Content Creation. A K Peters, Ltd., Wellesley, Massachusetts, 2006. COLLADA – Digital Asset Schema Release 1.5.0, 2008.

AutomationML Web references [BookLink@]

→www.automationml.org/amlbook

Web references [MW09@] [W3C03@] [KHR09@]

→http://www.mathworks.com/access/helpdesk/help/toolbox/physmod/mech/9783110746235007, accessed 2009. W3C Math Home. available at →http://www.w3.org/Math/, accessed 2020-1222. Khronos Group. Available at: →http://de.wikipedia.org/wiki/Khronos_Group,accessed: 2020-1221.

Chapter 4  Modelling of Behaviour Referencing and integration of behaviour models with the AutomationML submodels IEC 61131-10 Arndt Lüder Nicole Schmidt Rainer Drath Content 4 Modelling of Behaviour — 215 4.1 Introduction and Motivation — 215 4.1.1 Who is using behaviour models? — 216 4.1.2 What behaviour models are of interest? — 217 4.2 AutomationML approach for representing behaviour models — 218 4.3 How to reference external behaviour models — 219 4.3.1 General: how to assign behaviour models to system objects — 219 4.3.2 How to assign models of controlled good case and uncontrolled behaviour — 219 4.3.3 How to assign interlocking models — 222 4.4 How to model behaviour with IEC 61131-10 — 225 4.4.1 General approach — 225 4.4.2 How to model sequences of controlled behaviour — 226

4.4.3 How to model state-based models of uncontrolled behaviour — 227 4.4.4 How to model interfaces — 228 4.4.5 How to model interlocking models — 229 4.5 Example — 230 4.5.1 Modelling an example machine — 230 4.5.2 Modelling the drives — 230 4.5.3 Modelling the inputs and outputs of the drives — 231 4.5.4 Modelling of interlocking behaviour — 231 4.6 Modelling of complex behaviour or protected models via FMU — 232 4.7 Discussion and Conclusion — 233 4.8 References for Chapter 4 — 233

4  Modelling of Behaviour 4.1  Introduction and Motivation The engineering of production systems is a multi-disciplinary and multi-model process involving several sets of engineering information. Within this process, on the one hand, the structure of the production system, covering all system elements and their relations, and on the other hand, the behaviour of the system elements and their interaction, are designed and implemented. Therefore, different appropriate models are developed. This chapter describes the modelling of the behaviour of system elements with AutomationML in the different production system engineering phases. →Fig. 5-1 illustrates different types of behaviour models in the engineering process covering different relevant engineering information.

Fig. 4-1 Engineering phases and behaviour information involved Without claiming completeness or generality, a variety of behaviour models are of interest.

In product engineering, models covering the sequence of manufacturing steps to create a product are developed. These models are enriched in the basic engineering phase representing the sequence of production resource orchestrations resulting in the execution of the required product creation process. Here, for example, additional supporting process steps like transport or quality management are integrated. Additionally, first process validations are executed. Therefore, basic resource behaviour models are used. In the detail engineering phase, the provided behaviour models are translated to detailed behaviour implementation models. These models can represent the specifications of process execution, given as automation device orchestration sequences, and the specification of safety conditions, given as device interlocking rules. Furthermore, the detail engineering translates these specifications to control system implementations including PLC source code, PID controller configurations etc. The results of the detail engineering are validated during virtual commissioning. For this purpose, either the models of the device orchestration and device interlocking are combined with models of the plant physics to form evaluable models, or the achieved source code is combined with models of the plant physics for the same purpose. Theoretically all created models can and will be applied also within the operation and maintenance phases of the production system. But currently, the resource orchestration models have the highest relevance. They are combined with product creation process models representing the executed production process results related to individual products or individual production resources. It is easy to understand that all these models are related to each other. It is therefore obvious to look for a common representation methodology for all this information in order to

be able to transfer it without loss between the different engineering tools used by the engineers involved. 4.1.1  Who is using behaviour models? Several engineering roles are involved in the development and use of behaviour models. Subsequentially representative roles will be named and assigned to the main engineering phases. Product engineers execute the product engineering, sometimes supported by engineers with manufacturing technology knowledge. These engineers rely on three types of models: models for the products to be produced with their integrated materials and work-in-progress (Bill of Material, BOM); models for the production processes required to achieve the product in its sequence (Bill of Operations, BOO); and models for the production system resource requirements needed to execute the production processes. Thus, the behaviour models refer to sequences of manufacturing processes as they are common in the good case of successful production. During the basic engineering, production system planners take the resource requirements of the production system and assign real manufacturing resources to each of the production steps defined in the BOO. In addition, they add necessary process steps and resources required to interlink and support the selected manufacturing resources such as transportation systems or consumable supply. In doing so, they define the total quantity of all resources in the production system (Bill of Resources, BOR) and expand the BOO with additional supporting process steps and the BOM with necessary consumables. Like product engineers, production system planners discuss behavioural models that relate to sequences of manufacturing processes, usually in the good case of successful production. In

addition, necessary emergency cases, such as shut down processes, are considered if they are required by BOR elements and lead to BOR and BOO extension. Detail engineering is a usually a highly distributed engineering phase, often involving process engineers, mechanical engineers, electrical engineers, control engineers, to name a few of the most relevant. They cooperatively take the high-level production system engineering of the basic planning phase (BOM, BOO, BOR) and detail it into a complete detailed documentation of the production system applicable to assemble it. Here, the BOR is broken down to the individual purchasable objects and the BOO is detailed towards the minimal individually controllable actions of the resources. Thereby the behaviour models are becoming increasingly detailed and cover the interaction of the individual control devices and their signals. Nevertheless, these models usually cover the behaviour in the good case and represent emergency processes and emergency stops as causal chains of signal sequences. During detail engineering and the subsequent virtual commissioning, virtual commissioning engineers and plant optimizers perform simulation actions to validate (and optimize) behaviour of the production system on different levels of detail. They use the behavioural models developed in the basic and detail engineering phases and combine them with models of the (theoretically possible) overall behaviour of the production system physics (uncontrolled behaviour) that can be derived from the BOR. The resulting models cover the production system and its control on different level of detail and can be used, for example, to discuss the safety and optimality of the production system. 4.1.2  What behaviour models are of interest?

In the various engineering activities, various behaviour related information must be exchanged that relates to the controlled and uncontrolled behaviour of the production system that is relevant on the different level of detail of BOO and BOR. The controlled good case behaviour can be represented in early phases of the engineering by models such as Gantt and PERT charts, while timing and signal diagrams are used in later engineering phases. The controlled bad case behaviour is mainly given by Boolean logic or cause and effect models and by sequences of the expected shut down processes given as signal diagrams. Models of the uncontrolled behaviour need to be distinguished with respect to the required knowledge protection. In the case of high-level models that don’t require protection, automata-based models such as state diagrams are increasingly used. In case of lower-level models that represent vital engineering knowledge, knowledge-protecting models such as FMU (functional mock-up unit) are used. In all cases, the models of interest are applied in different levels of detail. Therefore, means for model enrichment and for consistency management are required. →Fig. 4-2 shows the assignment of the most relevant behaviour model types to the engineering phases in which they are applied. In [IEC 62714-4:Ed1], the term logic models is applied for the information sets discussed in this chapter. There, a differentiation related to sequencing, behaviour, and interlocking information is presented were sequencing information is defined as information that describes the instructions to the controlled system, behaviour information as information that describes the responses of the controlled system to the sequencing information and to other external interactions, and, finally, interlocking information as information related to the safety of the controlled system.

Fig. 4-2 Engineering phases and behaviour models involved In this chapter we avoid using this terminology as it may lead to confusion based on a possible wide definition of the term logic. Nevertheless, sequencing information of [IEC 62714-4:Ed1] is interpreted as controlled good case behaviour, behaviour information of IEC 62714-4 is identified as uncontrolled behaviour, and interlocking information of IEC 62714-4 is identified as controlled bad case behaviour.

4.2  AutomationML approach for representing behaviour models In the following, the methodology for representing behaviour models with AutomationML is explained based on Part 4 of the AutomationML Standard [IEC 62714-4:Ed1]. For further details of this methodology refer to the standard document. As indicated in the previous sections, behavioural models refer to individual elements of the production system, even if they are located at a very different level of the production system’s resource hierarchy. This fact is directly applied in behaviour modelling. As depicted in the →Fig. 4-3, each relevant

object references its behaviour model as well as (if necessary) the interface to the behaviour. The behaviour model wraps both the model and the interface representation. All different types of behavioural models such as Gantt charts, PERT diagrams, impulse diagrams, signal diagrams, state diagrams, boolean logic, cause and effect models as well as models with different purposes (sequences, state machines, interlocking) are represented in one common abstraction of these models given by the Intermediate Modelling Layer (IML). IML enables a unique mapping of the different model types to the same model representation language that is used to represent models and interfaces. As model representation language, an AutomationML logic XML schema has been defined by extending, reusing, and restricting the [IEC 61131-10] schema.

Fig. 4-3 Methodology of behaviour model representation In the following, the different building blocks for representing behaviour models are presented by discussing the referencing of behaviour models in general first and then looking at the different types of models.

4.3  How to reference external behaviour models

4.3.1  General: how to assign behaviour models to system objects The assignment of behaviour models can be split into two main groups of models that are integrated in a similar but slightly different way: models representing controlled good case behaviour (sequences of controlled processes) or uncontrolled behaviour (state machines) on the one hand and models representing controlled bad case behaviour (interlockings). 4.3.2  How to assign models of controlled good case and uncontrolled behaviour The assignment of behaviour models representing controlled good case behaviour (sequences of controlled processes) or uncontrolled behaviour (state machines) to AML objects is based on the integration of a proper CAEX ExternalInterface within the CAEX InternalElement representing the considered AutomationML object. This ExternalInterface must be directly or indirectly derived from the interface class External-DataConnector which is predefined for that purpose. This interface class provides the Attribute refURI that allows naming the UUID for referencing the interface or behaviour to be addresses. Both interfaces need to be linked to each other by using an InternalLink element to represent their dependency. This structure is depicted in →Fig. 4-4.

Fig. 4-4 Basic structure of behaviour assignment [IEC62714-4:Ed1] defines a number of role and interface classes relevant for behaviour modelling. They are depicted in →Fig. 4-5 and →Fig. 4-6 will be described in the following.

Fig. 4-5 Interface classes for model and interface referencing

Fig. 4-6 Role classes for model and interface referencing These role and interface classes reflect the history of AutomationML and PLCopen development. Initially in 2009 [DRA10] a first version of behaviour modelling has been presented by AutomationML exploiting PLCopen XML, an XML based data format for PLC project representation. In the meantime, PLCopen XML has been continued and has become IEC 61131-10. Therefore, AutomationML utilizes IEC 61131-10 projects for the modelling of behaviours. Nevertheless, by reasons of compatibility also the previous PLCopen XML files are still supported. The first step is to associate the CAEX InternalElement, that should reference a behaviour model, to the role class LogicModelObject, see →Fig. 4-6, defined in AutomationMLLogicRoleClassLib. Second, at least one of the following ExternalInterfaces is added to this InternalElement. For referencing IEC 61131-10 based behaviour models, the interface class library AutomationMLLogicInterfaceClassLib has been developed (see →Fig. 4-5). This library contains seven interface classes for

different purposes. Five of them are applied for referencing controlled good case behaviour or uncontrolled behaviour, three directly and two indirectly (as abstract classes to base the other four on them). The other two interface class are used to reference interlocking models as discussed later. – The interface class LogicModelInterface as well as all derived interface classes are used to reference complete behaviour models (as shown in →Fig. 4-4) or elements with these behaviour models. The class itself can be understood as abstract class, it does not define a detailed semantics of the referenced model. – The derived interface class SequencingLogicModelInterface (and future derivations) is used to reference a behaviour model that contains controlled behaviour (sequences). It is used to model for example the good case behaviour of a controlled unit or a shutdown sequence. Usually, this sequence is represented by a function block within the IEC 61131-10 model (see →section 4.4). – The derived interface class BehaviourLogicModelInterface (and future derivation) is used to reference a behaviour model that contains an uncontrolled behaviour model. It is used to model for example uncontrolled behaviour of a system unit. This behaviour is also usually represented by a function block of the IEC 61131-10 model (see →section 4.4). – The interface class LogicModelElementInterface is used to reference an element of a behaviour model. This can be for example a step within a sequence model, a state within a state based model or similar elements. – A more specific element of a behaviour model is a variable representing an interface or an internal data point within the behaviour model. Such a behaviour model element is

referenced by the interface class VariableInterface as shown in →Fig. 4-4. For referencing PLCopen XML based behaviour models (and to ensure compatibility to older versions of AutomationML) the interface class PLCopenXMLInterface is used for referencing a PLCopen XML document. Additionally, the class library AutomationMLPLCopenXMLInterfaceClassLib is available which contains the class Variable-Interface for referencing variables within an PLCopen XML document. – The interface class PLCopenXMLInterface has been defined within the standard interface class library AutomationMLInterfaceClassLib of AutomationML Part 1. It is applied similar to the interface class LogicModelInterface to reference a behaviour model given as POU within a PLCopen XML file. In addition, the interface class VariableInterface from the AutomationMLPLCopenXMLInterfaceClassLib is used in the same way as the VariableInterface from the AutomationMLLogicInterfaceClassLib in order to reference variables of a POU within PLCopen XML files. – The use of PLCopen XML will not be further considered in this section. For more details see the deprecated old version of AutomationML Part 4 [WP Part4@]. 4.3.3  How to assign interlocking models The assignment of behaviour models representing states (interlockings) to AutomationML objects is based on a combination of exploiting structure objects with suitable defined roles and the integration of proper interfaces. An interlocking is

characterized by two sides, the source group and a target group of objects. – The source group defines a set of system elements that can indicate a hazardous situation if they together enter a certain state. – The target group defines a set of system elements that must go in a certain state if the dangerous state of the source group is entered. The source or target group can contain a single object or a collection of objects. A simple example is two drives that must not be switched on at the same time. Thus, one can be the source group while the second one is the target group and vice versa. Here the target group has to go to switched off in case the source group is switched on. The source and target group are modelled each as CAEX InternalElements referencing the role classes InterlockingSourceGroup and InterlockingTargetGroup respectively. These objects are of structural nature and do not represent a physical item. In order to fill these groups with objects, we mirror an arbitrary number of InternalElements (that are defined somewhere in the AutomationML document). The mirror concept is described in →section 2.2.12.6. In addition, these InternalElements must contain an ExternalInterface derived from the interface class InterlockingConnector in order to connect the source and target group. To integrate the interlocking behaviour model, an CAEX ExternalInterface is used to reference the external model. This interface must be directly or indirectly derived from InterlockingLogicModelInterface, especially from one of the interface classes defined for that purpose. As indicated above, this interface class provides the ExternalInterface with an Attribute refURI that is used to reference the UUID of the

interface or behaviour to be addresses. This ExternalInterface is used to reference the signals that are used to indicate the hazardous state, the response to the state, and the overall model. Furthermore, the input and output signals of the interlocking behaviour model shall be represented by appropriate ExternalInterfaces derived from VariableInterface which are linked by using the refURI attribute to the related variable and by InternalLink elements to the related ExternalInterface of InterlockingLogicModelInterface class. This structure is depicted in →Fig. 4-7. To support the modelling of interlockings, the interface class library AutomationMLLogicInterfaceClassLib and the role class library AutomationMLLogicRoleClassLib contains the following additional predefined classes (as shown in →Fig. 4-6). – The role class InterlockingSourceGroup is derived from the standard role class Group of the AutomationMLBaseRoleClassLib and is used to indicate an InternalElement playing the role of a source group. This groups the source objects together which are able to enter a dangerous state and thereby defines an interlocking source. – The role class InterlockingTargetGroup is derived from the standard role class Group of the AutomationMLBaseRoleClassLib and is used to indicate an InternalElement playing the role of a target group. This groups the target objects together which shall react to prevent the dangerous state and thereby defining an interlocking target. – The interface class InterlockingLogicModelInterface and each derived class is used to reference an interlocking

model represented by a function block given in an IEC 61131-10 project. – The interface class InterlockingVariableInterface and each derived class is used to reference the interlocking state (usually the safe state) defined by the logic within an interlocking related function block. – The interface class InterlockingConnector is defined in the AutomationMLInterfaceClassLib by deriving it from AutomationMLBaseInterface. This interface class and all derived interface classes are used to reference between interlocking source group and interlocking target group.

Fig. 4-7 Basic structure of interlocking assignment

4.4  How to model behaviour with IEC 61131-10 This section, now that we've covered how to reference external behaviour models in the first place, is about modelling behaviour itself. There are different types of behaviour models to be represented by AutomationML: – Gantt charts, PERT charts, impulse diagrams, and signal diagrams are used to model controlled sequences in the considered system. – State diagrams are used in order to model the uncontrolled discrete behaviour of a system element via Boolean Logic and cause and effect models for interlocking models. Remark: physical or continuous behaviour is not covered in this methodology. To provide a common abstraction for all the various model types, the AutomationML team has developed the Intermediate Modelling Layer (IML). It enables a unique mapping of the different model types to the same model representation language based on IEC 61131-10. Therefore, an extension of the IEC 61131-10 schema has been developed and specified in [IEC 62714-4:Ed.1]. This extension is based on usual XML extension mechanisms and in line with the definitions of [IEC 61131-10]. To not exceed the intended scope of this section, not all details of IML and its [IEC 61131-10] representation can be discussed here. Hence, we focus on the most relevant model elements. The complete details are given in [IEC 62714-4:Ed.1]. 4.4.1  General approach For each behaviour model, an AMLLogic model is applied by extending the XML schema of [IEC61131-10] following the

extension schema of [IEC 62714-4:Ed.1]. This behaviour model provides a data structure derived from IEC 61131-10 projects while enabling a detailed representation of the model types named above. The main model elements are shown in →Fig. 4-8. For each type of a behaviour model, the AMLLogic element is used. It contains at first a WriterHeader object intended to contain the meta data covering identification information of the source tool and the source information of the behaviour model as well as information of the development history. An example is depicted in the right upper part of →Fig. 4-9. The second main sub element of the AMLLogic element is the FunctionBlock representing the behaviour model of interest. This model is given by the model itself represented by the MainBody element and its interface represented by interface variables contained within the InputVars element for input interfaces and OutputVars for output interfaces. Each FunctionBlock elements has an attribute uuid containing a unique identifier of UUID type. This can be utilized to reference the FunctionBlock element within the refURI attribute of external interfaces instantiated from the SequencingLogicModelInterface, BehaviourLogicModelInterface, or SequencingBehaviourLogicInterface interface classes as presented above. The MainBody element itself can represent an IML model used to cover an intended controlled sequence, a Sequential Function Chart (SFC) to cover a state-based model for an uncontrolled behaviour of a system element, or a Function Block Diagram (FBD) covering an interlocking model.

Fig. 4-8 Behaviour model structure of the AMLLogic element 4.4.2  How to model sequences of controlled behaviour IML models are intended to represent Gantt charts, PERT charts, impulse diagrams, and signal diagrams, for instance models representing intended controlled sequences in the considered system. Their common ground is their nature as models presenting sequences of states and state transitions were intended activities are assigned to the states. To cover such models, the MainBody type aml:IML is exploited. In this case the main body contains IMLStep and IMLTransition elements. An IMLStep is representing a state, action, etc. in the represented model while an IMLTransition is

modelling the representing a state transition. IMLSteps and IMLTransitions are linked by referencing their related connection points. To model parallelization or alternatives additional modelling elements are available. →Fig. 4-9 represents an example of a Gantt chart. The model type is indicated in the MainBody attribute logicModelType as Gantt-Chart. This Gantt chart has two actions executed in a sequence. This results in two IMLStep elements and one IMLTransition element as depicted. Each IMLStep element and each IMLTransition element has an attribute uuid containing a UUID as unique identifier. This value can be used to reference these elements out of the refURI attribute of the external interface instantiated from the LogicModelElementInterface interface class as named above.

Fig. 4-9 Sequencing example with WriterHeader 4.4.3  How to model state-based models of uncontrolled behaviour SFCs are used to model state diagrams used to represent the uncontrolled behaviour of a system element. Here the common pattern of SFC and state diagrams are used explicitly. To cover such models, the MainBody type SFC is exploited. In this case the main body will contain SfcObjects of types like Step and Transition. An SfcObjects of type Step represents a state in the model while an SfcObjects of type Transition represents a state transition. SfcObjects are linked by referencing their related

connection points. Additional modelling elements are available for modelling parallelization or alternatives →Fig. 4-10 shows an example of a state diagram. The model type is indicated in the MainBody attribute type as SFC. This state diagram has three states, one as initial state and two for modelling a loop. This results in tree SfcObject elements of type Step and three SfcObject elements of type Transition as depicted.

Fig. 4-10 State based model example with interfaces 4.4.4  How to model interfaces

To model the interface to models of intended controlled sequences (Gantt charts, PERT charts, impulse diagrams and signal diagrams) and representing models of uncontrolled behaviour (state diagrams) of a system element, the InputVars and Output-Vars objects of the FunctionBlock object are utilized. They are nested within the sub object Parameters of the FunctionBlock object. Both, InputVars and OutputVars objects, contain Variable objects that represent the model interfaces. Variable objects within InputVars objects represent behaviour inputs while Variable objects in OutputVars objects represent behaviour outputs. Examples of such interfaces are given in →Fig. 4-10. Each Variable element has an attribute uuid containing a UUID as unique identifier. This value can be used to reference these elements out of the refURI attribute of the external interface instantiated from the VariableInterface interface class (and all classes derived from it) as named above. 4.4.5  How to model interlocking models Function Block Diagrams are used to represent interlocking models given by Boolean logic or cause and effect models. Again, the common features of these models are explained first. To cover such models, the MainBody type FBD is used. In this case, the main body will contain Network objects that consists of FbdObjects. These FbdObjects can represent logic blocks, data sources, and data sinks were data sources and sinks can be assigned to input and output variables. Also, SfcObjects are linked by referencing their related connection points. →Fig. 4-11 represents an example of a Boolean Logic. The model type is indicated in the MainBody attribute type as FBD. This model consists of a network of one AND-block, two input

signals that are attached to input variables and one output signal. This results in tree FbdObject elements as depicted.

Fig. 4-11 Interlocking example

4.5  Example This clause illustrates the explained modelling concepts by means of a simple example. This example comprises a machine containing two drives, see →Fig. 4-12. Related example AML files can be downloaded from [BookLink@].

Fig. 4-12 Two drives in a machine example 4.5.1  Modelling an example machine The machine is modelled by an CAEX InternalElement named Machine derived from the role class ResourceStructure. This machine should get a sequencing model of model type Gantt chart as depicted in →Fig. 4-9, which is stored in the file Machine_Sequence_2Drives.xml. For this, the object Machine additionally references the role class LogicModelObject to represent the fact that it contains a behaviour model. To reference this external model to the Machine, it has an CAEX interface SequencingLogicModelInterface derived from the interface class SequencingLogicModelInterface. The refURI attribute of this ExternalInterface is referencing the object with the UUID 2edd1b2e-64e1-4d2f-9fa6-12022d2ea768 (a FunctionBlock element) within the IEC61131-10 file Machine_Sequence_2Drives.xml. 4.5.2  Modelling the drives

The machine has two drives. Each drive is modelled by an InternalElement named DriveX derived from the role class ResourceStructure containing an CAEX interface Move derived from the VariableInterface and representing a Boolean signal to switch the drive on. Each drive should contain an uncontrolled behaviour model as of state machine type as given in →Fig. 4-10. Hence, the objects Drive1 and Drive 2 are associated to the role class LogicModelObject to represent the fact that they contain a behaviour model. To assign the uncontrolled behaviour to both drives, they get each an interface BehaviourLogicInterface derived from the interface class BehaviourLogicModelInterface. The refURI attribute of this interface is referencing the object with the UUID e7a28279-952c-465d-850e-cf234a3d27da (a FunctionBlock element) within the IEC61131-10 file drive_behaviour.xml. 4.5.3  Modelling the inputs and outputs of the drives To represent the inputs and outputs of this behaviour, each drive object gets two interfaces Move and Moving. The refURI attribute of Move reference the Variable object with the UUID 69200d1f1752-4d5c-92efcd6fdb697e9f within the IEC61131-10 file drive_behaviour.xml. Moving, also derived from the interface class VariableInterface, the Variable object with the UUID 69200d1f1752-4d5c-92efcd6fdb697e9g within the same IEC61131-10 file. These both interfaces are linked to the ExternalInterface BehaviourLogicInterface using InternalLink objects to represent that they belong to the related behaviour. 4.5.4  Modelling of interlocking behaviour In the machine, we assume that the behaviour of both drives can lead to a dangerous situation, if both drives are switched on at the same time. Therefore, an interlocking model needs to be

integrated. Thus, an InternalElement named InterlockingSourceGroup derived from the role class InterlockingSourceGroup containing a mirror object of the Drive1 InternalElements and an InternalElement named InterlockingTargetGroup derived from the role class InterlockingTargetGroup containing a mirror object of the Drive2 InternalElement are used. Both InternalElements contain an ExternalInterface InterlockingConnector derived from the interface class InterlockingConnector that are linked to each other using an internal link to represent their dependency. To additionally attach the interlocking logic of the interlocking as shown in →Fig. 4-11, the InterlockingSourceGroup InternalElement contains an interface InterlockingLogicModel derived from the class InterlockingLogicModelInterface. The refURI attribute of this interface is referencing the object with the UUID 8d5952dc-05fd4fb4-bbf8-64b6815c1d58 (an FunctionBlock element) within the IEC61131-10 file interlocking_2drives.xml. In addition, the “switchon” signals of both drives are cloned resulting in an ExternalInterface Move1 with refURI attribute content referencing to the Variable objects with UUIDs 46d7b82a-b7cf-40b0-bb5392d1477dbce4 and 746f9a22-236e-4933-9fd0-dfe66166f39c within the IEC61131-10 file interlocking_2drives.xml. Again, these both interfaces are linked to the ExternalInterface InterlockingLogicModel using InternalLink objects to represent that they belong to the related interlocking behaviour.

4.6  Modelling of complex behaviour or protected models via FMU The (so far) presented approach of behaviour modelling is mainly applicable to low-level and discrete behaviour models applied in early engineering phases. These models are able to present behaviour up to a certain level of detail and a certain

level of correct representation of the physical system behaviour. In addition, these models are human readable as long as no encryption is applied. In the case of required higher-level models such as (differential or integral) equation systems, which represent detailed physical behaviour of a system component and target essential engineering knowledge, the IEC 61131-10 based modelling approach cannot be applied. Here an Integration of FMUs enabling more detailed models and knowledge protecting is possible. To attach an FMU to a system element, an approach with the same basic ideas as shown above can be applied. Therefore, the InternalElement that should contain a FMU references the role class LogicModelObject or a role class derived from it and contains two types of ExternalInterfaces. One interface is derived from the interface class VariableInterface to represent the FMU interfaces and the other type is derived from an interface class such as FMUInterface that is derived from the interface class ExternalDataConnector. Both reference the FMU zip file by means of the refURI attribute and the related objects within them as shown in →Fig. 4-13. This approach is defined for example in [WP Part6@] (see also [DRA21], Chapter 14).

Fig. 4-13 FMU based behaviour modelling

4.7  Discussion and Conclusion Within this chapter, the AutomationML capabilities to model behaviour of different types of production systems are considered. With the application of IEC 61131-10 and FMU based models, two approaches are presented covering several model types. These approaches are already in practical use, for example within the AutomationML component [DRA21] (Chapter 14). Nevertheless, the currently provided approaches and the model types covered by them are not all-embracing. Further model types and further use cases are already under discussion in the AutomationML association. Interested parties with currently not covered model types and/or use cases are requested to join the AutomationML association to integrate these cases in the behaviour modelling framework of AutomationML in a cooperative way.

All mentioned AutomationML examples are available at [BookLink@].

4.8  References for Chapter 4 [BookLink@] [Dra10] [IEC 6113110] [IEC 627141:Ed1] [IEC 627144:Ed1] [WP Part4@] [WP Part6@]

→www.automationml.org/amlbook R. Drath: Data exchange in plant design with AutomationML. Integration with CAEX, PLCopen XML and COLLADA. Springer (VDIBuch), Heidelberg (2010). IEC 61131-10 Ed. 1: Programmable controllers - Part 10: PLC open XML exchange format, Edition 1, International Electrotechnical Commission, IEC, 2019. IEC 62714-1 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML) - Part 1: Architecture and general requirements, Edition 1. International Electrotechnical Commission, IEC, 2012. IEC 62714-4 Ed. 1: Engineering data exchange format for use in industrial automation systems engineering (AutomationML) - Part 4: Logic. International Electrotechnical Commission, IEC, 2020. →www.automationml.org/amlbook: Whitepaper AutomationML Part 4 – AutomationML Logic, version 1.5.0 from Jan. 2017. →www.automationml.org/amlbook: Whitepaper AutomationML Part 6 – AutomationML Component, version 1.0.0 from Oct. 2020.

Chapter 5  The AutomationML Editor A free editor from the AutomationML society for viewing, editing or documenting AutomationML documents. Lorenz Hundt Josef Prinz Rainer Drath Content 5 The AutomationML Editor — 237 5.1 Introduction — 237 5.2 Purpose of Usage — 238 5.3 User Interface — 239 5.4 Editing Functions — 241 5.4.1 General UI concept: how to create, modify and delete objects — 241 5.4.2 How to create libraries — 242 5.4.3 How to create new classes — 242 5.4.4 How to model inheritance between classes — 243 5.4.5 How to associate roles to a SystemUnitClass — 243 5.4.6 How to modify inheritance relations — 244 5.4.7 How to create and edit attributes — 245 5.4.8 How to edit attribute constraints — 245 5.4.9 How to override an inherited attribute of a class — 247

250

5.4.10 How to override inherited elements of a class — 248 5.4.11 How to undo inheritance — 249 5.4.12 How to exclude inherited data — 249 5.4.13 How to create a InstanceHierarchy — 250 5.4.14 How to create an ExternalInterface — 250 5.4.15 How to create, delete and modify an InternalLink —

5.4.16 How to create instances — 251 5.4.17 How to associate roles to an InternalElement — 252 5.4.18 How to model RoleRequirement attributes or interfaces — 252 5.4.19 How to remove RoleClass associations — 253 5.4.20 How to model Mapping Objects — 253 5.5 Extended Functionality — 253 5.5.1 How to navigate between referenced classes or instances — 254 5.5.2 How to split and merge CAEX Documents — 254 5.5.3 How to convert between CAEX 2.15 and CAEX 3.0 — 255 5.5.4 How to validate an AutomationML document — 255 5.5.5 How to import AutomationML Libraries — 256 5.5.6 How to generate an AMLX Container — 257 5.5.7 How to save the CAEX-Schema — 259 5.5.8 How to create high-quality screenshots for documentation — 259 5.6 Customization of the AutomationML Editor — 260 5.6.1 Software updates, news, recent documents and libraries — 260 5.6.2 How to show-hide details — 260 5.6.3 How to use individual Themes and Layout’s — 261 5.6.4 How to use Plugins — 262 5.7 How to send Feedback — 262 5.8 Summary — 263 5.9 References for Chapter 5 — 263

5  The AutomationML Editor 5.1  Introduction This Chapter gives an introduction into the AutomationML Editor and describes typical use cases, the user interface as well as its main functions. The AutomationML Editor – Available for free at [BookLink@] under MIT license. – Video Tutorial available at [VT20@]. The AML Editor has been developed by the AML society in order to visualize major AutomationML concepts and to view, create and edit AML/CAEX files. It is suited for educational purposes and is a perfect entry point for learning, experimenting and understanding AML. It provides powerful features for creating, visualizing, documenting, manipulating and downloading available external AML libraries. →Fig. 2-102 shows the AutomationML Editor in a typical view for an edited AutomationML document and many of its functions.

Fig. 5-1 The AutomationML Editor Over the years, AutomationML Editor became a powerful tool with a comprehensive Plugin architecture that allows for extending its functionalities and you may feel tempted to use it professionally. However, keep in mind that this tool is not developed on the level as expensive commercial applications. It does not represent the entire modelling scope of AML and is not designed as industrial engineering tool. Summary The AML Editor has been developed by the AML society in order to visualize major AutomationML concepts and provides functionality to visualize, create and edit AML/CAEX files. The AML Editor is suited for educational purposes and a perfect entry point for learning, experimenting and understanding AML. However, the

AML Editor does not represent the entire modelling scope of AML and is not suited as industrial engineering tool.

5.2  Purpose of Usage The main purpose for which the AutomationML Editor was developed and provided by the AutomationML Association can be divided into four categories. Visualization of AutomationML Documents The AutomationML Editor is used for clear visualization of AutomationML documents, especially for the submodel CAEX. The individual main elements of an CAEX document of type CAEX InstanceHierarchy, SystemUnitClassLib, RoleClassLib, InterfaceClassLib and AttributeTypeLib are displayed in clearly arranged tree views. Furthermore, the relations between the individual AutomationML objects are displayed. This allows users to quickly understand the structures and relationships of AutomationML documents. Editing of AutomationML Documents The AutomationML Editor is used to edit AutomationML documents. All information within the document can be edited. Editing is possible in the different tree structures and tables which are also used for visualization. Basic Consistency Checks of AutomationML Documents The AutomationML Editor can be used to check the conformance of AutomationML documents against related IEC standards: the CAEX schema and the AutomationML modelling rules. Among other things it can be automatically tested for example whether all objects have unique IDs, the meta data is correct, referenced classes or external documents are present or relations between objects can be resolved. Thus, the

AutomationML Editor serves to analyse and improve the quality of AutomationML documents. Modelling of new Concepts To test new concepts that are to be realized with AutomationML, an easily accessible editor is necessary. The AutomationML Editor fulfils this function.

5.3  User Interface The user interface of the AutomationML Editor is divided into seven sections, which can be individually arranged. Additional it is possible to show or hide each of the sections.

Fig. 5-2 The AutomationML Editor UI sections →Fig. 5-2 shows these seven sections, which are briefly introduced below. 1. Menu and tool bar

The first section represents the menu and the tool bar. Via the arranged menus and buttons, the main functions of the editor can be executed. Examples for these functions are creating a new file, loading an existing file, saving the current AutomationML document or saving the CAEX schema. You also find some quick access icons for essential functions, like navigation, undo/redo, validation, transformation for CAEX version, etc. 2. Document Information Editor The second section, the Document Information Editor, consists of three tabs: – AMLFile: In this tab you can edit essential meta information about the AutomationML document. – Internal Links: In this tab the user can see and check all modelled InternalLinks of the AutomationML document. – Document Validation: In this tab a basic validation of the AutomationML document can be executed. 3. InstanceHierarchy Editor The editor presents a tree view of all InstanceHierarchies of the AutomationML document and provides basic editing and management functions for the objects in these InstanceHierarchies. 4. SystemUnitClass library Editor The editor presents a tree view of all SystemUnitClassLibraries of the AutomationML document and provides basic editing and management functions for the SystemUnitClasses in these SystemUnitClassLibraries. 5. RoleClass library Editor The editor presents a tree view of all RoleClassLibraries of the AutomationML document and provides basic editing and management functions for the RoleClasses in these RoleClassLibraries. 6. InterfaceClass library Editor

The editor presents a tree view of all InterfaceClassLibraries of the AutomationML document and provides basic editing and management functions for the InterfaceClasses in these InterfaceClassLibraries 7. AttributeType library Editor The editor presents a tree view of all AttributeTypeLibraries of the AutomationML document and provides basic editing and management functions for the AttributeTypes in these AttributeType libraries. This section is only available when you work with AutomationML document on basis of CAEX version 3.0. If your document is in CAEX version 2.15, it is not available and visible. 8. Properties Editor The seventh section the Properties Editor consist of three tabs: – Header: In this tab all header and identification information of the actual selected object are presented and can be edited. – Attributes: In this tab all attributes of the actual selected object are presented and can be edited. – Relations: In this tab all relations of the actual selected object are presented.

5.4  Editing Functions Within this subsection, some of the main functions of the AutomationML Editor are explained. It focuses on the topics how to create the main objects of an AutomationML document and how to edit relationships between them. The AutomationML Editor provides for most of the following functions different ways how to execute them. In this section always the most common way is described.

5.4.1  General UI concept: how to create, modify and delete objects For all visible objects in the object trees, the AutomationML Editor provides common functions to create, modify or to delete objects. This is valid for all libraries, classes, attribute types and instances. 5.4.1.1  How to create a new object Almost every window of the editor has a separate toolbar containing buttons for creating and deleting objects. Which type of object is created depends on which object is currently selected. If several alternatives exist, a corresponding selection option is displayed. This way, only the most common objects can be added to a selected object. Creating more and less common object types can be done via the context menu of the selected object, which is activated via the right mouse button. 5.4.1.2  How to modify an object Similar to modern programming tools as Microsoft Visual Studio, the properties of an object are displayed in a Properties Editor. The Properties Editor always shows the properties of the currently selected object, grouped into separate aspects. In the following subsections some concrete examples are given. 5.4.1.3  How to delete an object With the green + -button, new objects can be created. With the red x-button, the selected object can be deleted. The subsequent

sections provide refinements for this general approach. 5.4.2  How to create libraries To create a library object via the green +-button or a context menu, no other object must be selected in the respective editor, for example in the RoleClass library Editor, as shown in →Fig. 53. In the Properties Editor, which is also shown, details such as the name of the currently selected object can be edited. Object names can also be edited by pressing the F2 key.

Fig. 5-3 Create a Library 5.4.3  How to create new classes To create a new class via the green +-button or a context menu, the appropriate parent class or library object, for instance RoleClassLibrary, must be selected as shown in →Fig. 5-4. The green button react context sensitive and provides valid object dependent on the current selection. A new class is always created as a child object of the selected object. This allows modelling hierarchical class structures. However, the hierarchy of classes does not reflect inheritance relations and is intended

for organizational purposes only. Inheritance relationships must be explicitly modelled and can be defined from one child class to any other parent class (of the same type) in any position of any library, according to the rules described in Chapter 2.

Fig. 5-4 Create a Class 5.4.4  How to model inheritance between classes The easiest way to create an inheritance relationship between classes is to drag and drop the parent class onto the child class. →Fig. 5-5 shows an example for this approach. After dragging the parent class onto the child class, the AutomationML Editor provides a choice how to interpret this drag and drop action. Here, select Class inheritance.

Fig. 5-5 Create an inheritance relation between classes A second possibility to define inheritance relationship is to manually enter the full path (it is just a string) of the parent class. This is provided by the Properties Editor under the Header tab in the Relations/Class reference section. Remark Inheritance relationships and all other relationship types are constantly monitored by the AutomationML Editor while editing. If the definition of a referenced object changes or is deleted, the editor automatically adjusts all references accordingly and silently. 5.4.5  How to associate roles to a SystemUnitClass The easiest way to associate a RoleClass to a SystemUnitClass is to drag and drop the RoleClass onto the SystemUnitClass. →Fig. 5-6

shows an example for this approach. The RoleClass will be added as SupportedRoleClass of the SystemUnitClass. To assign multiple RoleClasses, the drag and drop procedure can be done multiple times.

Fig. 5-6 Associate a role to a SystemUnitClass 5.4.6  How to modify inheritance relations If you want to replace an existing inheritance relationship of a class, there are three possibilities. – The first possibility is to perform another drag and drop from the correct parent class to the child. It may be necessary to check whether the existing relationship has been changed or a new one has been added. – The second possibility is to select the child object and to switch to the Header tab in the properties field to make the field class reference visible. Then, drag and drop the new parent class into the field class reference. This automatically

enters the full path of the parent class into this field. Do not accidentally select the parent class in between, otherwise the Properties Editor immediately switches to the properties of the parent class and the field class reference of the child class is no more visible. – The third possibility is to manually edit the class reference directly in the Properties Editor under the Header tab in the respective class reference field. Inheritance relations in AutomationML are defined by the CAEX Path of the referenced class. The CAEX Path of a parent can be copied via the context menu of the parent object in the tree view. Then, paste it to the input field. If you want to remove an inheritance relation, just navigate to the class reference field of the child class in the Properties Editor and manually remove the path to the parent class. Then press ENTER. 5.4.7  How to create and edit attributes To create an attribute, the object to which the attribute is to be assigned must be selected and the Attributes tab in the Properties Editor must be activated. In the Attributes tab you can create attributes and sub attributes using the + -button. When the attribute is created, the attribute properties can be edited, and additional properties can be added. The AutomationML Editor groups attribute into different views which can be hidden to make it easier to edit the different properties of the created attribute. →Fig. 5-7 shows an example of how an attribute is created and shows the button which can be used to change the visibility of properties of an attribute.

Fig. 5-7 Create an attribute 5.4.8  How to edit attribute constraints To restrict the value range of attributes with a constraint the constraint aspect has to be made visible. A constraint can be added there simply by pressing the + button, see →Fig. 5-8. You can choose between the three constraint types NominalScaledType, OrdinalScaledType or UnknownType.

Fig. 5-8 Edit an attribute constraint The following constraint types are available: OrdinalScaledType The OrdinalScaledType is typically used to limit numerical values of attributes with a numeric datatype, for instance max and min values. The Editor monitors this constraint: if a value outside of this range is entered, the Editor does not accept this value. NominalScaledType The NominalScaledType can be used to define an enumeration of possible values, for instance a colour could be constrained to the values blue, yellow and red. These constraints are monitored by the editor. To simplify selecting valid values, the editor provides the enumerations defined as popup list in order to ensure that only allowed values are presented. UnknownType The UnknownType is only interpretable by a consuming tool and therefore not monitored by the editor.

Remark When entering a value to a constrained attribute, the AutomationML Editor does only accept valid values. In case of a violation, an error message appears. If an attribute data type is defined, the editor checks during the definition of a constraint whether the defined value range is compatible to the defined data type. 5.4.9  How to override an inherited attribute of a class Inherited values are marked in the editor with a little arrow. Those values are write-protected by the AML Editor. In order to modify an inherited attribute, it must be overridden. For this purpose, the single item definition mode must be activated in the tab Attribute. To do this, right-click on the inherited attribute and select the option override in the context menu. Afterwards, the inherited attributes are marked with a !. After overriding, the attribute can be edited like a normal attribute. Technically, this option copies the inherited attribute physically to the related object. An overridden attribute can be reversed to a pure inheritance relation. For this, right click the overridden attribute and select Undo override in the context menu. Then, the attribute is again a common inherited attribute.

Fig. 5-9 Override an inherited attribute 5.4.10  How to override inherited elements of a class By default, the AutomationML Editor does not display inherited content, because inherited data is not physically present in the class. In order to override inherited content (internal elements, interfaces, attributes or links), the inherited data must be first visualized, and can then be overridden. In order to visualize the inherited data of a class, open the context menu of the class and select the menu item Show inherited elements (see →Fig. 5-10). The inherited content is then

presented in grey colour in order to distinguish inherited data from physical data.

Fig. 5-10 Visualize inherited content In order to override an InternalElement or an ExternalInterface of a class, select the context menu of the inherited item and select override (see →Fig. 5-11). The AML Editor physically copies the overridden item to the class. If the item is a sub element of a hierarchy, the parent branch is copied as well. Now, the data can be modified.

Fig. 5-11 Override an InternalElement 5.4.11  How to undo inheritance In order to undo an override, the inherited data needs to be deleted. For this, open the context menu of the related item and select Undo override (see →Fig. 5-12). This removes the overridden content, and the original inheritance takes effect.

Fig. 5-12 Remove inherited data 5.4.12  How to exclude inherited data In order to exclude inherited data, select the context menu Exclude. This sets the ChangeMode to delete. The excluded object is marked with a cross (see →Fig. 5-13).

Fig. 5-13 Exclude inherited data 5.4.13  How to create a InstanceHierarchy A CAEX InstanceHierarchy is created just like a library, see →section 5.4.2. 5.4.14  How to create an ExternalInterface There are two simple ways to create an ExternalInterface. The first way is to select an InterfaceClass in an InterfaceClassLibrary and drag and drop it on the class or instance which should get the interface. Then an ExternalInterface with the corresponding class reference is created. The second possibility is to select the object where the interface should be created and use the green + -button to add an ExternalInterface. A new interface is created, which has no references to an interface class yet, see →Fig. 5-14. The

reference can be edited manually in the Properties Editor under the Header tab in the field class reference.

Fig. 5-14 Create an ExternalInterface 5.4.15  How to create, delete and modify an InternalLink An InternalLink is created by selecting an ExternalInterface and drag and drop it onto a second one. After that, a dialog appears where you have to select the option Create InternalLink, see →Fig. 5-15. The paste dialog contains an input field to specify a name for the InternalLink. If no name is entered, a default name is created.

Fig. 5-15 Create an InternalLink To delete the created InternalLink, the InternalLink lines must be made visible, and the respective visible line has to be selected. The delete operation can be executed via a context menu of the selected line. In order to modify an existing link, select the line that visualizes the link. When the line is selected, two anchor points are shown. These anchor points can be dragged to redirect the selected end of the InternalLink to a different ExternalInterface. 5.4.16  How to create instances The easiest way to create an instance of a SystemUnitClass within an InstanceHierarchy is to select it and drag and drop it to the position in the instance hierarchy where the instance is to be created. →Fig. 5-16 shows gives an example for the creation of an instance. Additional it shows the dialogue that appears during the creation. This procedure of creation an instance within an InstanceHierarchy will work of course in the same way if you

create an instance within a SystemUnitClass.

Fig. 5-16 Create an Instance of a SystemUnitClass 5.4.17  How to associate roles to an InternalElement RoleClasses can be assigned to InternalElements by drag and drop. After dragging the RoleClass onto the InternalElement, a menu appears where you can choose if the assignment should be RoleRequirement or SupportedRoleClass. In this menu you can also choose how to handle the attributes of the RoleClass, see →Fig. 5-17.

Fig. 5-17 Associate a RoleClass to an InternalElement 5.4.18  How to model RoleRequirement attributes or interfaces To model RoleRequirement attributes and interfaces, the RoleRequirement node of a corresponding object must be selected. In the next step, right click on this node. In the appearing context menu, you can create role requirement attributes and interfaces under the entry Add, see →Fig. 5-18. The role requirement attributes and interfaces can be edited in the tree view or the Properties Editor now.

Fig. 5-18 Model role requirement attributes or interfaces 5.4.19  How to remove RoleClass associations RoleClass associations can be easily removed in the tree views of the AutomationML Editor. To do this, select the appropriate RoleRequirements node and press the Delete-key to delete the association. If RoleRequirement nodes are not visible in the Editor, select the menu Display/Display RoleRequirements Nodes. 5.4.20  How to model Mapping Objects To create a mapping between a RoleRequirement attribute or interface with an attribute or interface of an InternalElement or SystemUnitClass the following steps are necessary. – First, a MappingObject must be created under the RoleRequirement node. This can be done in the context menu. Right click onto the RoleRequirements node and select Add/MappingObject. The MappingObject is created.

– In the next step, the mapping contend can be defined. This is done in the menu that appears when you right click on the MappingObject. Here, the AttributeNameMapping or InterfaceIDMapping can be selected. – The concrete values for the mapping are then edited in the Properties Editor under the Header tab, see →Fig. 5-19.

Fig. 5-19 Model a mapping object

5.5  Extended Functionality The following sections describe extended functions of the AutomationML Editor. These provide features as navigation, split and merge, conversion, validation, import and export functionality and more. For most of these features, the AutomationML Editor provides different ways how to execute them and the section will describe the most common way. 5.5.1  How to navigate between referenced classes or instances The AutomationML Editor provides navigation features that help to navigate across referenced items.

– If a class has a parent class, the menu Goto base class appear in the context menu. Selecting this item jumps to the parent class. – If a class has child classes or instances that reference this class, another context menu item appears: Find all class references. Selecting this item, the AutomationML Editor jumps to the first reference item and provides a selection form to jump to the next one. – In the context menu of an instance that references a class, the item Goto referenced class jumps to the class. – If an ExternalInterface is linked to another ExternalInterface, right-mouse-click at the ExternalInterface and select the item Goto related ExternalInterfaces. 5.5.2  How to split and merge CAEX Documents The AutomationML Editor provides split and merge functionality. The split function is useful when a part of a CAEX file should be outsourced into a separate CAEX file. References between the remaining CAEX document and the split file are automatically maintained, if needed, the resulting CAEX files reference each other. The merge function merges all split files back into one CAEX document. In order to demonstrate this, we want to split the AutomationMLInterfaceClassLib into a separate file. The steps to achieve this are: 1. Select the InterfaceClassLibrary. 2. Select the Set Split Point button in the tool bar. 3. Save the library in a separate file using the button Save split model parts. 4. In the result, the library becomes a split file, it is saved in an additional document, and removed from the original

document as well. If the remaining document contains references to objects contained in the split part, the AutomationML Editor creates an ExternalReference in the original document and automatically renames all references into the split part using the Alias of the ExternalReference. 5. In case that the original document is part of an AutomationML Container (see →section 5.5.6), the split part is added as a container part and the path-Property of the ExternalReference is set to the relative address of the created container part. To revert the split and to reinsert the library back into the document, select the button Merge all external references in the toolbar, see →Fig. 5-20. Then the library will be inserted back into the document. The previously changed references are resolved and modified to their original values.

Fig. 5-20 Split and merge CAEX documents 5.5.3  How to convert between CAEX 2.15 and CAEX 3.0

The AutomationML Editor provides a function to convert AutomationML documents based on CAEX 2.15 to documents in CAEX 3.0 and vice versa. The function can be found in the toolbar of the editor, see →Fig. 5-21.

Fig. 5-21 Convert CAEX version 5.5.4  How to validate an AutomationML document Another feature of the AutomationML Editor is the ability to validate AutomationML documents. For this purpose, click the Document Validation button in the tool bar, or click the Document Validation button in the Document Information Editor section under the Document Validation. The result of the validation is then presented to the user in eight groups. These groups are for example ID validation or Class path validation. Additionally, it is possible to repair some of the validation issues automatically. Fig. 5-22 shows the validation of an AutomationML document. Remark The validation feature is very helpful for quality checks and troubleshooting. The automatic error correction should however only be used for test and development purposes, because it repairs the errors only for the moment. It does not fix the cause of the errors.

Fig. 5-22 Validation of AutomationML documents Invalid Occurrences are highlighted and if selected, the related objects are selected in their respective editor. 5.5.5  How to import AutomationML Libraries

Fig. 5-23 Import libraries from AutomationML To import AutomationML libraries, select File/Import/from File or from AutomationML in the menu bar. If you have selected from AutomationML, the dialogue shown in →Fig. 5-23 appears. In this menu you can select the libraries provided by the AutomationML Association for import. If you select a library that already exist within your AutomationML document an additional dialogue will enable you to choose which version shall be used within your document. 5.5.6  How to generate an AMLX Container In an AutomationML Container, AutomationML documents and all external files and documents referenced therein are collected

locally and archived in a ZIP compressed document. An AutomationML Container can be created with the AutomationML Editor in two ways. – The first and most common option is to save a document as AutomationML Container. If this option is selected, all referenced external files are localized and the user can decide whether to include the successfully localized data in the container, see →Fig. 5-24. If an externally referenced document is included in an AutomationML container, all absolute references in the original document are automatically changed to the relative address of the created part within the created container. – The second option is to create a new container using tab AMLFile in the Document Information Editor, see →Fig. 5-25. In this case, the currently edited document and the referenced external files will be added directly to the container. In this view the user can also change various properties of the AutomationML container, such as the storage location or the compression rate.

Fig. 5-24 Select AutomationML Container Parts

Fig. 5-25 AutomationML Container Properties If an AutomationML document contains external references to AutomationML libraries (for instance in a split document), then all externally referenced libraries are also part of the container. Using the file tab AMLFile in the Document Information Editor each of these parts can be loaded into the editor and edited independently. For this purpose, the button behind the document name must be pressed. If the button is “green”, this indicates that this is the currently edited document.

When a document in an AutomationML Container is edited, the file icon in the AutomationML Editor's header changes, see →Fig. 5-26.

Fig. 5-26 AutomationML document vs. AutomationML Container 5.5.7  How to save the CAEX-Schema The AutomationML Editor offers the function to save the CAEX schema to a certain position. This is helpful when the CAEX document is opened in third party XML tools: those tools validate the CAEX document against the CAEX schema and requires access to the Schema file. This function can be found in the menu bar Tool/Save CAEX Schema. 5.5.8  How to create high-quality screenshots for documentation The AutomationML Editor provides a function to create a 300-dpi high-quality screenshot of an AutomationML tree, for instance an InstanceHierarchy, library or any part of it. This feature is very helpful for documentation purposes and also works for large object hierarchies that are larger than the screen.

To create the screenshot, select the top element. Then, select the Tool/Capture Tree (to file) or Tool/Capture Tree (to clipboard). Alternatively, the shortcuts CTRL or CTRL+SHIFT+P can be used. After executing the function, the form appears (see →Fig. 5-27) presenting a preview. Click on Capture to complete this function. Afterwards, the screenshot is stored in the clipboard or stored as file.

Fig. 5-27 Capture a AutomationML tree as high-quality screenshot

5.6  Customization of the AutomationML Editor 5.6.1  Software updates, news, recent documents and libraries

The AutomationML Editor provides a specific page for recent document, software updates, libraries, relevant documents and news. Select the menu View/Browse models and views. This form highlights software updates, recent documents, libraries and news from the AutomationML society. →Fig. 5-28 shows an example view.

Fig. 5-28 The AutomationML browser for recent documents, news, updates and libraries 5.6.2  How to show-hide details Within the AutomationML Editor it is possible to show and hide details like RoleClass references or InternalLinks. →Fig. 5-29

shows the icons in the tool bar that can be used for this.

Fig. 5-29 Show-hide details 5.6.3  How to use individual Themes and Layout’s The AutomationML Editor allows the user to customize the UI to the individual needs and preferences. Therefore, different themes are available, that can be found in the toolbar under the point View/Themes. Additional it is possible to arrange the different sections of the editor via drag and drop. →Fig. 5-30 for example shows the same AutomationML file in two different configured AutomationML Editors.

Fig. 5-30 Individual AutomationML Editor themes 5.6.4  How to use Plugins Another way to customize the AutomationML Editor, which is not limited to displaying AutomationML documents, is to use

Plugins. These can be integrated into the AutomationML Editor via the Plugin Manager. The Plugin Manager can be found in the menu bar under Plugins/Plugin Manager. Under Plugins it is furthermore possible to activate or deactivate the installed Plugins. Plugins provide in general additional functionalities to the AutomationML Editor and can be developed individually from each user of the AutomationML Editor. For details on plugin programming refer to [DRA21], (→section 3.6). →Fig. 5-31 shows the Plugin Manager and the Plugin XML Viewer. The XML Viewer and the PLCopenXML Viewer are preinstalled Plugins. Other Plugins are available via the Plugin Manager which if the access to an AutomationML specific Plugin repository ore a userdefined repository is possible.

Fig. 5-31 The AutomationML Editor Plugin Manager and XML Viewer

5.7  How to send Feedback The AutomationML editor provides a built-in feedback function. With the button (see →Fig. 5-32), suggestions for improvements

or bug reports are directly submitted to the development team.

Fig. 5-32 The AutomationML Editor Feedback Button

5.8  Summary The AutomationML Editor is a tool that allows creating, modification, visualization and saving AutomationML documents with a current focus on CAEX object models. It was designed in order to simplify modelling, testing and explaining new concepts. The functions provided go far beyond those of a simple text or XML editor and support the user to fully exploit and correctly apply the available AutomationML concepts. This section focuses on essential features. Feel invited to test the editor, this is the best way to understand AutomationML. Only essential functions can be shown, to get to know all concepts it is best to test the editor. Have fun trying it out!

5.9  References for Chapter 5 [BookLink@] [Dra21]

[VT20@]

→www.automationml.org/amlbook R. Drath (Ed.): AutomationML – The Industrial Cookbook. De Gruyter Oldenbourg, ISBN 978-3-11-074592-4, EAN E-Book: 9783110745979, DOI →https://doi.org/10.1515/9783110745979, Berlin, 2021. AutomationML e.V.: AutomationML Editor: YouTube video tutorial →https://www.youtube.com/watch?v=YBCVM3puKZU, accessed 2020-10-10.

Abbreviations AAS AML AMLX API AR AR APC ASCII B2MML BOM BOO BOR BPR BREP CAD CAE CAEX CAN CAx CDD COLLADA CSV DCC-Tools DEXPI ERP FBD FDI FMU

Asset Administration Shell AutomationML, Automation Markup Language Container format of AutomationML Application programming Interface Application Recommendation Application Recommendation Automation Project Configuration American Standard Code for Information Interchange Business to Manufacturing Markup Language Business Object Model, or Bill of Material Bill of Operations Bill of Resources Best Practice Recommendation Boundary Representation Computer Aided Design Computer Aided Engineering Computer Aided Engineering Exchange Controller Area Network Computer-Aided X IEC common data dictionary COLLAborative Design Activity Comma-Separated Values Digital Content Creation-Tools Data Exchange in the Process Industry Enterprise Resource Planning Function Block Diagram Field Device Integration Functional Mockup Unit

GUID HMI ICSS ICSS ID IE IEC IH IML IO IODD ISO LCA MCAD MES MIME MIT MTP NE OPC P&ID PAS PCE PCS PDF PID PLC PLM POU PPR SASA

Global Unique Identifier Human Machine Interface Integrated Control and Safety System Integrated control and safety systems Identifier InternalElement International Electrotechnical Commission InstanceHierarchy Intermediate Modelling Layer Input/Output IO Device Description International Organization for Standardization lowest common ancestor Mechanical Computer Aided Design Manufacturing Execution System Multipurpose Internet Mail Extensions Massachusetts Institute of Technology Module Type Package Namur Empfehlung – NAMUR Recommendation Open Platform Communications P&ID Piping and Instrumentation diagram, a preferred graphical representation of a process plant Publicly Available Specification Process Control Equipment Process Control System Portable Document Format Proportional–Integral–Derivative controller Programmable Logic Controller Product Lifecycle Management Program Organization Unit Process-Product-Resource SASA Side-Angle-Side-Angle

SCADA SOArc group STEP SUC TCP IP UML USB UTC UUID VC VDI WP XML

Supervisory Control and Data Acquisition Service-Oriented Architectures and Real-Time Control group Standard for the Exchange of Product model data SystemUnitClass Transmission Control Protocol/Internet Protocol Unified Modelling Language Universal Serial Bus Universal Time Coordinated Universally Unique Identifier Virtual commissioning Verein Deutscher Ingenieure; German Association of Engineers Whitepaper eXtensible Markup Language

Biographies About the Editor

Prof. Dr.-Ing. Rainer Drath Professor for Mechatronic Systems Engineering Pforzheim University of Applied Sciences Institute of Smart Systems and Services Faculty of Technology Tiefenbronner Str. →65 75175 Pforzheim, Germany

Email: [email protected] Prof. Dr.-Ing. Rainer Drath is professor for Mechatronic Systems Engineering at the University of Applied Sciences Pforzheim. He is one of the architects of CAEX and AutomationML and a board member of the AutomationML Association. He studied automation technology at Ilmenau University of Technology from 1990-1995 and received his doctorate in 1999. After a research stay in Japan, he worked at the ABB Research Center Germany as a scientist, group leader, programme manager and senior principal scientist. His research focuses on the development of innovative methods for improving automation engineering in an interdisciplinary and heterogeneous environment. Rainer Drath is the editor and author of the first AutomationML book in 2010, author of more than 250 papers/ speeches and more than 60 patents. He is the recipient of several atp best paper awards, the ETFA best paper award 2014 and the recognised Industrial IT-Research Award 2010. In 2021, he received the Perspective Award from Pforzheim University.

About the Co-Authors

Pascal Habiger, M.Sc. Research assistant Pforzheim University of Applied Sciences Institute of Smart Systems and Services Tiefenbronner Str. 65 75175 Pforzheim, Germany E-Mail: [email protected] Pascal Habiger is a research assistant at the Institute of Smart Systems and Services at Pforzheim University of Applied Sciences since July 2019. His primary research focus is plug & produce of heterogeneous and structure-variable manufacturing modules based on Industry 4.0 asset administration shells and semantic information models.

Steffen Lips, Dipl.-Ing. Project Manager NetAllied Systems GmbH Eisenbahnstraße 35 88212 Ravensburg, Germany E-Mail: [email protected] Steffen Lips studied civil engineering at the Ruhr University in Bochum. Since 2007, he has been a project manager at NetAllied Systems GmbH and was responsible, among other things, for the technical development of AutomationML in the COLLADA area. Today he is also in charge of the integration of 3D viewing solutions in webbased applications. Dr.-Ing. Nicole Schmidt IT consultant Daimler Protics GmbH

Gutenbergstr. 20

70771 Leinfelden-Echterdingen, Germany E-Mail: [email protected] Dr.-Ing. Nicole Schmidt received her M.S. degree in mechatronics in 2012 and her Ph.D. degree from Otto von Guericke University Magdeburg in 2018. She is currently working as IT consultant for data standardization and harmonization at Daimler Protics. During her work at AutomationML’s office (2012-2017), she became the working group leader of AutomationML’s standardization committees: DKE/AK 941.0.2, TC 65/SC 65E/WG 9. She advises the AutomationML board in this role.

Prof. Dr.-Ing. habil. Arndt Lüder Head of Teaching- and Research Area Factory Automation Otto-v.-Guericke University Faculty Mechanical Engineering, Institute of Ergonomics, Manufacturing Systems and Automation (IAF) Universitätsplatz 2 39106 Magdeburg, Germany E-Mail: [email protected] Prof. Dr.-Ing. habil Arndt Lüder works since 2001 at IAF where he is leading the research area factory automation. His work is focused on application of object-and agent-oriented implementation technologies, mechatronic concepts, and component-based engineering processes in factory automation. He is member of the board of the AutomationML association. Josef Prinz (Diploma computer scientist) Senior expert software development and digital factory inpro

Steinplatz 2

D-10623 Berlin, Germany E-Mail: [email protected] Many years of expertise in the development and use of software systems for planning and simulation of manufacturing systems, primarily in the automotive industry. Active in the AutomationML Association since 2009. Responsible and main contact person for the development of the C# AutomationML Engine and for the AutomationML Editor. Dr.-Ing. Lorenz Hundt Expert for Automation Engineering inpro Steinplatz 2

10623 Berlin, Germany E-Mail: [email protected] After studying electrical engineering, Lorenz Hundt received his doctorate in 2012 from the Faculty of Mechanical Engineering at Otto von Guericke University on the topic of exchanging behavioural descriptions. Since 2012, he has been working at inpro on the topic of AML, among others. Within AutomationML association, he leads the AutomationML component description working group.

Trademarks AutomationML COLLADA COMOS COSIMIR DELMIA DEXPI eClass Engineering Base EPLAN Khronos Microsoft Excel Microsoft Visio RobCad W3C WinMOD

AutomationML e.V. Sony Computer Entertainment Inc. Siemens Industry Software Inc EF Robotertechnik GmbH Dassault Systémes DECHEMA Gesellschaft für Chemische Technik und Biotechnologie e.V. eCl@ss e.V. AUCOTEC AG EPLAN Software & Service GmbH Khronos Group, Inc. Microsoft Corp. Microsoft Corp. Siemens Industry Software Inc Massachusetts Institute of Technology Mewes & Partner GmbH

Index A AMLX Container 1, 2 AutomationML 1 – AutomationMLBaseAttributeTypeLib 1 – AutomationMLBaseRoleClassLib 1 AutomationMLBaseRole 1 ExternalData 1 Facet 1 Group 1 Process 1 ProcessStructure 1 Product 1 ProductStructure 1 Resource 1 ResourceStructure 1 Structure 1 – AutomationMLInterfaceClassLib 1 AutomationMLBaseInterface 1 COLLADAInterface 1 Communication 1 ExternalDataConnector 1 ExternalDataReference 1 Order 1 PLCopenXMLInterface 1 Port 1 PPRConnector 1 SignalInterface 1 – Exclusions 1 – Extended Concepts 1

Arrays 1 Combination of Group and Facet Concept 1 Container Format 1 Facet Concept 1 Group Concept 1 Internationalization 1 Lists 1 Multilingual Attributes 1 PPR Concept 1 – Goals 1 – IEC 62714 series 1 – Key innovations 1 – Modelling Philosophie 1 – Modelling Principles 1 – Values 1 AutomationML Association 1 – Members 1 – Participation 1 AutomationML attributes – AssociatedExternalValue 1 – AssociatedFacet 1 – Cardinality 1 – Category 1 – Direction 1 – DocLang 1 – Frame 1, 2, 3 – Listtype 1 – LocalizedAttribute 1 – MaxOccur 1 – MIMEType 1 – MinOccur 1 – OrderedListType 1 – refType 1

– refURI 1, 2 AutomationML Editor 1 – AML Container 1 – Attributes 1 – Create and edit objects 1 – Create classes 1 – Create libraries 1 – Editing Functions 1 – Extended Functionality 1 – High Resolution Screenshots 1 – Import Libraries 1 – Inheritance 1 – Mapping Object 1 – Overriding Class attributes 1 Exclude 1 Inherited elements 1 Undo 1 – PlugIns 1 – Role Association 1 – Split and Merge Documents 1 – submit Feedback 1 – Themes and Layout 1 – User Interface 1 – Validate 1 AutomationML specifications – Application Recommendations 1 – Best Practice Recommendations 1 – Whitepapers 1 B Behaviour modelling 1 – AML libraries 1 – AMLLogic element 1

– complex behaviour 1 – Example 1 – FMU 1 – interlocking models 1 – logic behaviour 1 – model types 1 – referencing logics 1 – sequence models 1 – Stakeholder 1 Best Practice Recommendations 1 – Regular Expressions 1 – Units 1 C CAEX – Identification of instances and classes 1 – Modelling Elements AttributeTypeLib 1 CAEXFile 1, 2 ExternalReferences 1 FileName 1 Header 1 InstanceHierarchy 1, 2, 3, 4 InterfaceClassLib 1 InternalElement 1 MappingObject 1 RoleClassLib 1 SchemaVersion 1, 2 SourceDocumentInformation 1, 2 SourceObjectInformation 1 SuperiorStandardVersion 1, 2 SystemUnitClass 1 SystemUnitClassLib 1, 2 – Modelling Principles 1

Attribute Constraints 1 Attributes 1 AttributeType 1, 2 AttributeTypeLip 1 InstanceHierarchy 1 InterfaceClass 1 InterfaceClassLib 1 InternalElement 1 MappingObject 1 Meta Information about the Source tool 1 Mirror Attributes 1 Mirror Concept 1 Modelling of requirements 1 Modelling of Source Object Infomation 1 Multiple crossed structures 1 Multiple Roles 1 Nested Attributes 1 Nested Interfaces 1 Paths 1 RoleClass 1 RoleClassLib 1 Semantics of attributes 1 SupportedRoleClass 1 SystemUnitClass 1 SystemUnitClassLib 1 Version information 1 – Role Concept 1 – XML schema file 1 COLLADA – Articulated systems 1 a comined kinematics 1 – BREP 1 Examples 1

– BREP-Elements Curve 1 Point 1 Surface 1 – BREP-Limitations Edge 1 Face 1 Shell 1 Solid 1 Vertex 1, 2 Wire 1 – Combining geometry and kinematics 1 – Elements 1 1 1 1 – Formulas 1 – Kinematic scene 1 – Kinematics description 1 joints 1 models 1 – Levels of detail 1 – Modelling of materials 1 – Product trees 1 – Tesselation 1 – Transformation elements 1 D Data exchange – Options and Approaches 1 Differences between AML Edition 1 and 2 1 F

Four layer concept 1 G Geometry and Kinematics 1, 2 – COLLADA 1 – Modelling of attachments 1 I IEC 61131- 1, 2 IEC 62714 – Part I 1 – Part II 1 – Part III 1 – Part IV 1 – Part V 1 Initiators 1 Intermediate Modelling Layer 1 M Mapping Object 1 Modelling object semantics 1 O Object-oriented data modelling – Aggregation 1 – Class 1 – Composition 1 – Encapsulation 1 – Inheritance 1 – Instance 1 – Object 1 – Object-oriented analysis 1 – Relations 1 – with CAEX 1, 2 P PPR Concept 1 References

– Attributes in External Documents 1 – COLLADA 1, 2 – External Documents 1 in the scope of future AML 1 outside AML 1 – PLCopen XML 1 Relations 1 – between Instances 1 – Class-Instance-Relations 1, 2 – Inheritance Relations 1, 2 – Instance-Instance-Relations 1 – Parent-Child-Relation 1 – Parent-Child-Relations 1