EU MAYA Meta Data Model PDF

Ref.
Ares(2017)2236801 - 02/05/2017
EC HORIZON2020
Project Co-Funded by the European Commission
Grant Agreement n° 678556
Project Start Date: 1st October 2015
Multi&disciplinArY integrated simulAtion and forecasting tools, empowered by digital continuity

and continuous real world synchronization, towards reduced time to production and optimization
D2.1 MAYA META DATA MODEL REFERENCE
Dissemination level Public

Lead beneficiary Siemens CT
Authors Elisa Negri, Irene Roda, Marco Macchi, Jan Christoph Wehrstedt,
Giovanni Dal Maso, Rafi Blumenfeld, Michele Ciavotta, Stephan
Weyer, Jumyung Um, Birthe Boehm, Torben Meyer, Silke Munske,
Veronika Brandstetter, Diego Rovere, Marcel Keinan
Reviewers See above
Planned date of delivery 31.03.2017
Date of issue 31.03.2017
Version 1.0
D2.1 MAYA Meta-Data Model Reference
TABLE OF CONTENTS
Table of Contents ............................................................................................................................................... 2
List of Abbreviation and Glossary....................................................................................................................... 3
1 Executive Summary .................................................................................................................................... 4
2 Introduction................................................................................................................................................ 5
3 Evaluation of Standards towards Simulation Models and Simulation Tools ............................................. 7
3.1 Automation Markup Language .......................................................................................................... 7
3.2 Systems Modelling Language ............................................................................................................. 8
3.3 eCl@ss Advanced ............................................................................................................................... 8
3.4 OWL .................................................................................................................................................... 8
3.5 STEP AP242XML.................................................................................................................................. 9
3.6 Selection of a Standard ...................................................................................................................... 9
3.7 Additional Standards ........................................................................................................................ 10
3.8 Simulation Tools ............................................................................................................................... 11
4 MAYA Meta Data Model Reference ......................................................................................................... 13
4.1 Base Model ....................................................................................................................................... 14
4.2 Assets and Behaviours...................................................................................................................... 18
4.3 Prototypes Model............................................................................................................................. 20
4.4 Resources Model .............................................................................................................................. 24
4.5 Device Model.................................................................................................................................... 27
4.6 Project Model ................................................................................................................................... 30
4.7 Product Routing Model .................................................................................................................... 34
4.8 Security Model ................................................................................................................................. 54
5 Sample Application and Mapping of Data Model .................................................................................... 59
5.1 Example for Data Model to describe Simulation Models ................................................................ 59
5.2 Mapping of Conveyor Example to Meta Model ............................................................................... 66
5.3 Sample Application within Smart Factory Test Bed ......................................................................... 67
5.4 First Use of Digital Representation .................................................................................................. 69
A. Evaluation of Use Case Requirements on MAYA CPS Data Model [CONFIDENTIAL] ............................... 71
A.1 FinnPower Use Case [CONFIDENTIAL] ............................................................................................. 71
A.2 Volkswagen Use Case [CONFIDENTIAL] ........................................................................................... 81
Bibliography...................................................................................................................................................... 94
List of Figures.................................................................................................................................................... 95
List of Tables ..................................................................................................................................................... 96
2
List of Abbreviation and Glossary

Acronym Explanation
aka also known as
AutomationML – Automation Mark-up Language – a format for exchanging

AML engineering data on the production facility and process. It combines several
standards such as AP242 , PLCOpen and others.
CAD Computer-aided Design
CAM Computer-aided Manufacturing
CNC Computerized Numerical Control
CPPS Cyper Physical Production System
CPS Cyber Physical System
CSI Centralized Support Infrastructure
DES Discrete Event Simulation
IP Internet Protocol
IT Information Technology
JT Jupiter Tessellation – a format for storing geometric information.
MSF MAYA Simulation Framework
OLP Robotic Off line Programming
OOP Object Oriented Programming
PLC Programmable Logic Controller
PS Process Simulate
PSC Process Simulate Commissioning
SME Small and Medium-sized Enterprises
STEP Standard for the Exchange of Product model data
UML Unified Modeling Language
UUID Universally Unique Identifier
XML eXtensible Markup Language
3
1 Executive Summary
Within this deliverable, the Meta Data Model is presented which is one of the main pillars of the MAYA
project architecture. The meta data model was developed to fit to FinnPower and Volkswagen use cases
and internal MAYA project architecture requirements and is approved by the MAYA project participants.
The Meta Data Model can be mapped to AutomationML for data exchange with other tools and covers the
following aspects:
- description of a CPS on its own as well as a CPS based simulation model

- static data (3D model, kinematics structure, etc.)
- behavioural models
- aggregation of CPS into hierarchical structures to model full plant layouts
- duality of CPS templates that constitute libraries of reusable components and CPS instances that
represent real/simulated devices
- production scenarios or product routings for simulations
- simulation results
- security aspects due to its usage in an industrial environment
Within this document, also the necessary evaluations are described for setting a basis for the Meta Data
Model. As a preparation for creating the meta data model, an evaluation of existing standards with respect
to MAYA requirements is conducted and simulation tools which have to be considered in MAYA are
discussed in short. It is also shown that the Meta Data Model can be mapped to AutomationML and also a
sample application of the model, the modelling approach and a first use is presented. In the appendix,
additional evaluations of the FinnPower and Volkswagen use cases are described with focus on the Meta
Data Model which provided a sound basis for the model definition.
4
2 Introduction
The aim of MAYA is to develop simulation methodologies and multidisciplinary tools for the design,
engineering and management of CPS-based (Cyber Physical Systems) discrete manufacturing factories, in
order to strategically support production-related activities during all phases of the factory life-cycle. The
basis of this aim is digital continuity and real-world synchronization. Thus, for the MAYA project, a project
architecture has been developed which proposes a technical solution for the MAYA objectives, see Figure 1.
One of the main pillars of the MAYA project architecture is the Meta Data Model which integrates all
relevant data with respect to the MAYA objectives.
Figure 1 - MAYA project architecture and Meta Data Model
The MAYA Meta Data Model will have to support static data (3D model, kinematics structure, etc.) and
behavioural models as well as the aggregation of CPS into hierarchical structures to model full plant
layouts. It also has to consider the duality of CPS templates that constitute libraries of reusable components
and CPS instances that represent real/simulated devices. In addition, production scenarios or product
routings together with simulation results have to be covered. And beside these functional requirements,
also security aspects have to be covered, among others.
Within this deliverable, the Meta Data Model is presented that has been created based on general
requirements as described in D1.1[1] and D1.2 [3] as well as on further use case elaborations and
foundational work such as an examination of existing standards. The resulting data model covers the
requirements by the MAYA project as the MAYA project members decided in a sequence of reviews.
In this document, as a first step towards a data model, suitable standards as a basis for the Meta Data
Model are examined in chapter 3. Within this chapter, also the covered simulation tools are discussed in
short as well as the relation of the model to AutomationML. Chapter 4 contains the core of this deliverable:
5
the description of the Meta Data Model. Finally, chapter 5 shows the mapping of the model to
AutomationML and a sample application as well as the modelling approach and a first use of its digital
representation. In appendix 0 of this document, the VW and FinnPower scenarios are analysed in more
depth which provided a basis for the definition of the data model together with the requirements defined
in MAYA D1.2 [3].
6
3 Evaluation of Standards towards Simulation Models and

Simulation Tools
The meta data model needs a basis on which data is saved and processed. In the project MAYA, a total of
35 standards for different kinds of application are gathered and have to be evaluated. After research for all
35 standards has been done, the number can be narrowed down. Reasons for exclusion are:
• Graph databases like Neo4j, Apache Cassandra or OrientDB are possible solutions but they are
designed for far larger amounts of data. Cassandra is used by Twitter and was used for example by
Facebook
• A few standards are only suitable for data transfer but not for saving them – for example Apache
Storm.
• CAEX, Collada and PLCOpen are combined in AutomationML and are therefore not considered
separately.
• Others only address very specific fields and/or are not extensible and customizable - like JT..
• For some standards, it was not possible to find enough information for a deeper analysis or a high
amount of money has to be paid to get access - like ISA-95.
After this initial research the following five most promising standards are selected and further evaluated:
• AutomationML [4]
• SysML [5]
• Ecl@ss Advanced [6]
• OWL [7]
• STEP AP242XML [8]
3.1 Automation Markup Language

Automation Markup Language, which is also-called AML or AutomationML, is a neutral, XML-based data
format, which is available as open standard (IEC 62714). Initiated by Daimler in October 2006 a syndicate
was founded with the following members: Daimler, ABB, KUKA, Rockwell Automation, Siemens, netAllied
and Zühlke as well as Universität Karlsruhe and Otto-von-Guerike-Universität Magdeburg. This syndicate,
which was transformed to an association in 2009, aimed for a new data format for the digital factory. This
free standard combines the three common standards CAEX, Collada and PLCOpen XML. CAEX, which itself is
an XML Schema, is used to describe the structure and topology of the system. For the geometry
representation as well as kinematic data Collada is used, while PLCOpen XML implements the logic like
behaviour or input/output-connections. Each component of a manufacturing plant is represented as object,
which can be part of another object or inherit objects. There are two ways to generate easily a new
AutomationML document: the AutomationML Editor and the AutomationML Engine. The editor is nice to
demonstrate how AutomationML works and how a document is structured, but for further tasks the engine
is more suitable. The engine is also the base for the editor and allows you to generate and manipulate
AutomationML documents via C# program code. In order to use it several libraries have to be included into
the Visual Studio project. AutomationML is divided in four different main elements: Instance Hierarchy,
System Unit Class Library, Role Class Library and Interface Class Library. In the Interface Class Library, all
kinds of interfaces can be generated. In AutomationML you differentiate between internal and external
interfaces. In the Role Class Library, general roles like a robot or part can be defined. These roles can be
assigned to other elements to allow a quick identification. In the System Unit Class, general types can be
defined. These are more specific than the roles and can be used to derive instances in the Instance
Hierarchy. In the Instance Hierarchy, the actual system is described as Internal Elements, which can inherit
other Internal Elements or can have attributes. Each of these four main elements can have Internal
7
Elements and Attributes. An Internal Element can again consist of Internal Elements and Attributes, while
an Attribute can only consist of other Attributes.
3.2 Systems Modelling Language

The Systems Modelling Language (SysML) is a general purpose visual modelling language for systems
engineering applications. SysML is defined as a profile of the Unified Modelling Language (UML) standard,
and supports specification, analysis, design, verification and validation. SysML is based on the UML 2
standard and is a graphic modelling language. It consists of nine diagram types that are shown in Figure 2.
Although SysML will not be chosen as standard for the meta model, it is a useful tool for documentation
and presentation. Activity diagrams are used to document and present the development process and to
show procedures while block diagrams are used to show the structure of the model. Also, use case
diagrams are used to visualize the interaction with the user.
Figure 2 - Diagram types in SysML
3.3 eCl@ss Advanced

eCl@ss is a product classification and description standard for information exchange between customers
and their suppliers. eCl@ss is characterized by a four-level hierarchical classification system. Each level adds
a two-token prefix to the eCl@ss-code, together forming an eight-character numeric code. In addition to
the classification, eCl@ss provides for each class in the classification hierarchy a so-called application class,
which is characterized by certain defined properties, which can be used to describe the classified item.
The general idea of the eCl@ass approach is that the designer of the system stores the eCl@ss
identification number of each component. This number can be looked up in an eCl@ss database, where
general information about each component is stored. Unfortunately, this solution does not support logic
behaviour.
3.4 OWL
OWL stands for Web Ontology Language and is used to describe terms and their relation. It was defined by
the World Wide Web Consortium (W3C) and is an important part of the semantic web initiative, which aims
to make the web more structured and machine readable. It is the most popular language to use when
creating ontologies. Consisting of properties, classes and relations it can be used to describe ontologies that
are defined according to the following principle: ’An ontology formally defines a common set of terms that
are used to describe and represent a domain’[1][2][1].
8
There are three variants of OWL:
• OWL Lite: It is the easiest of the three languages, because it simplifies some things like cardinality,
that only offers 0 and 1. Because of this constraint, it is not very widely used.
• OWL DL: It includes all OWL language constructs, but still has restrictions, for example a class
cannot be an instance of another class, while it can be a subclass of many classes.
• OWL Full: Its freedom in description is so high that there is no guarantee that it can be handled by a
computer. It is unlikely that any reasoning software will be able to support complete reasoning for
every feature of OWL Full.
These OWL variants are subsets of each other: An OWL Lite Ontology is an OWL DL ontology and an OWL
DL ontology is an OWL Full ontology.
Both OWL DL and OWL Lite require that every resource either be a class, object property, datatype
property or instance. A consequence of this is that a resource cannot be treated as both a class and an
instance. Also, the category of each resource must be explicit in all ontologies (i.e., each resource must
have an rdf:type statement). This means that in OWL Lite and OWL DL it can’t be used a resource as a class
without describing it as such elsewhere in the document.
OWL Full has the same features as OWL DL, but with less restrictions. It is possible to treat a class as an
instance, and there is no need to explicitly declare the type of each resource.
3.5 STEP AP242XML

ISO10303 ’Automation systems and integration - Product data representation and exchange’, which is
known as STEP is a CAD exchange data format. Its development began in 1984 and in 1993 the first ISO
standard was released. STEP consists of Application Protocols (AP), each of them implementing a specific
part. The recently introduced AP 242 Managed Model Based 3D Engineering is an evolution of STEP 203
and 214. It deals with machining features and geometric dimensioning and tolerance especially with
electro/electronic-mechanical products. It is a very widespread and stable standard, but there is no support
for logic behaviour. So it is without extension through another format not suitable for a meta model for
robot solutions.
3.6 Selection of a Standard

The six most promising standards were further evaluated and a value benefit analysis was performed. The
evaluated aspects were: accessibility, costs, coverage of data, documentation, extensibility, integration in
C#, spread and stability:
• Accessibility: This describes how easy and intuitive data can be saved using this method.
• Costs: The least important aspect are costs, but it is also nice to have free standards and not to
worry about licensing and fees. Low costs also allow faster spread.
• Coverage: Of course, the standard should already cover data that is needed for the model, as far as
possible.
• Documentation: Documentation is chosen as an analysis aspect for two reasons. Firstly a good
documentation is always an indication for a good supported and faultless working software.
Secondly due to the time limit of this work and the need to familiarize with a lot of other things like
Process Simulate a good documentation allows fast learning.
• Extensibility: In order to be able to expand the model, for example if new information should be
added, extensibility is a point to be considered.
• Integration in C#: Integration in C# is an important aspect, because the standard has to be
compatible to the Process Simulate API.
9
• Stability: Stability is important, because the concept and developed software solutions should be
reliable and should not fail.
• Spread: Referring to the requirement ’Use of common and supported software and standards’
widespread standards have to be preferred.
Based on these criteria AutomationML was selected, with the highest score of 98, like it is shown in Table 1.
In order to evaluate these criteria a literature research as well as user interviews were performed. Based on
this research the standards were evaluated. The value benefit analysis in Table 2is only used to illustrate
and summarize the aspects on which this decision was made. The range of the Score is from 0 to 9, with 0
meaning there is no fulﬁlment and 9 as perfect score. This score is multiplied with the weighting coeﬃcient
of each criterion, resulting in the total score. These total scores are summed up for each standard and the
one with the highest value is the most suitable one. Like in every value benefit analysis there can be a
personal influence.
AutomationML 98
SysML 89
OWL 72
STEP AP242XML 55
eCl@ss Advanced 68
Table 1 - Total evaluation of different standards
Table 2 - Detailed evaluation of different standards
3.7 Additional Standards

3.7.1 JT
The standard JT (Jupiter Tessellation) was also evaluated, but rejected very early. It has become an
International Standard ISO 14306:2012. It was rejected because it is only suitable to save geometric
information. Therefore, it cannot be used as the main standard of the meta model, but can act as
supporting standard to save 3D information. The advantages for JT are that it is very lightweight, has small
10
file sizes and that it is widely supported by engineering tools that deal with CAD-files. There is ongoing work
in AML so that JT will be an option, besides COLLADA, as the format for the geometry. To be noted is that it
is the only CAD-format that is natively supported by Process Simulate, all other formats have to be
converted.
3.7.2 ISO 10303 / ISO14649

The ISO10303 and ISO14649 standards have been developed to introduce interoperability into
manufacturing enterprises so as to meet the challenge of responding to production on demand. In
particular, they represent data models used for exchanging product data and product routing. Table 3
shows the series of ISO standards and additional standards about product, process and machine. In curse of
the meta modelling, they will be relevant for the UML classes for product routing.
Table 3 - Current status of ISO 14649 and related standards
3.8 Simulation Tools

Based on the requirements collected in D1.2 Reference Framework Requirements [3] and on the industrial
scenario (D1.1 Industrial Requirements and Use Cases [1] and D1.4 Validation Scenario definition [9]) the
data model should also support simulation tools (Discrete Event Simulation, virtual commissioning, time
study). There are many types of simulation tools available that cover different disciplines. The following is
the classification of the different types of simulation models as defined in Pathfinder-CSA-FP7 Initiative
(http://www.pathfinderproject.eu/contributors.asp), section 3.3.2:
• Timing of change
o Static: independent of time
o Dynamic: evolves over time
▪ Continuous: variable of time is continuous
▪ Discrete: can be event-based or time-stepped
• Randomness
o Deterministic: the repetition of the same simulation will result in the same output
o Stochastic: the repetition of the same simulation will not always produce the same output.
• Data organisation
o Grid-based: data are associated with discrete cells at specific locations in a grid and updates
take place to each cell according to its previous state and those of its neighbours
o Mesh free: data of individual particles and updates look at each pair of particles
In MAYA, we focus on dynamic simulation models (both event-based and time-stepped), both deterministic
and stochastic.
11
In order to reliably simulate devices, the description of their behaviour should be provided by the
manufacturer or supplier. Furthermore, MAYA aims at bringing the simulation as early as possible in the
design phase, creating simulation models based on actual design data. Supporting AutomationML allows
data exchange (in this case importing all the data that characterize a device in a digital format). Thus in the
data model we will take into consideration the mapping between AML and Meta Data Model concepts. For
example, the adoption of the AML semantic described in AML whitepapers (and defined in AML standard
libraries) provides a straightforward mapping between kind of resources (see section 5.2).
12
4 MAYA Meta Data Model Reference

This chapter documents the Meta Data Model developed in the context of Task 2.1. It is organized into
eight sections, that correspond to the eight main semantic areas in which is organized the data model:
1. Base Model (§4.1): documents low level utility classes that are used for the definition of high level
classes of the other sections.
2. Assets and Behaviours (§4.2): documents classes and concepts related to the possibility of using
external data sources to define additional resource models.
3. Prototype Model (§4.3): introduces the concepts of resource prototypes and resource instances,
that are at the basis of the model reuse paradigm and documents the classes defining the resource
model prototypes.
4. Resource Model (§4.4): documents all the classes related to representation of intelligent and
passive resources constituting the model of a manufacturing plant.
5. Device Model (§4.5): documents all the classes related to the representation of the data connection
with the physical devices, including the definition of all the relevant I/O signals that are exchanged
with the digital counterpart.
6. Project Model (§4.6): documents all the classes that represent complex multi-disciplinary simulation
projects and that enable simulation tools to share plant models and results through the Maya
framework.
7. Product Routing Model (§4.7): documents all the classes related to the definition of a discrete
product, of the manufacturing processes and of the production plans that should be used for plant
simulation.
8. Security Model (§4.8): documents the classes that are related to the access control and that define
the authentication and authorization levels needed to work on a certain resource.
Each section is introduced with a diagram view (based on UML Class Diagram) that contains only the classes
composing that specific data model area and their relationships with the main classes belonging to the
other data model areas. Therefore, it is possible to find the same class representation (e.g. Property class)
in many different diagrams, but each class is documented only once in the proper semantic section.
Each class is then presented in a dedicated sub-section that is organized with:
• a short description of what the class represents, how it fits into the overall picture and which are its
relevant generalization relations, when applicable;
• a table, like Table 4, reporting all the fields of the class (represented in the UML diagram by
attributes and relationships)
Field Type Description
Name of the attribute or Field type. Collections are identified Short description of the field with indications on
relation by the 2 square brackets “[]” default values and value constraints.
Table 4 - Field documentation sample table
Whenever relevant for improving the comprehension of the model application, sample instance diagrams
(based on UML Object Diagram notation) are provided.
13
4.1 Base Model

This section documents some low-level and general-purpose classes that are shared by the other higher
level models described in the following sections. In particular, the classes related to the possibility of
modelling generic simple and composite properties of plant resources are documented.
Figure 3 - Class Diagram of the base classes
14
4.1.1 IdentifiedElement
IdentifiedElement represents the base (abstract) class for every element that is identified by an id.
id string Identification of the element.

The element is identified across the entire plant by this
univocal attribute. Often, a Universally Unique
Identifier (UUID) is used.
name string Name of the element, a more human readable tag that can be
used to identify the element within the plant model.
4.1.2 Documentation
Documentation provides documentation for resources.

externalDocumentation ExternalDocumentation[] Collection of classes that provide external documentation for
the resources.
Length is 1 to n.
description string HTML string that identifies the documentation.
4.1.3 MetaInfo
MetaInfo represents additional information attached to a resource or prototype class.
vendor string Name of vendor.
version string Version of the resource.
creation long Date and time (from epoch date) of creation of the resource,
expressed in milliseconds.
lastUpdated long Date and time (from epoch date) of last modification of the
resource, expressed in milliseconds.
sourceTool string Name of the simulation tool used by the resource.
4.1.4 Property
Property is an abstract class derived by IdentifiedElement and represents runtime properties of every
resource and prototype. These properties are relevant information that can be dynamically assigned and
read by the simulation tools.
constraints PropertyConstraint[] Constraints of the property. The value of this attribute

indicates limits of the property.
It is an array of 0 to n elements.
references PropertyReference[] Array of references to a property.
15
The length can be 0 to n.
4.1.5 PropertyConstraint
PropertyConstraint is an abstract class and represents constraints of the property.
4.1.6 PropertyReference
PropertyReference represents reference to a property.
4.1.7 NumberProperty
NumberProperty is abstract and it is an extension of Property. It represents a numeric property of the
object.
unit string Unit of measurement of the property.
4.1.8 IntProperty
IntProperty is a NumberProperty and represents an integer number property of the object.
value integer Integer value of the property.

Can be null.
4.1.9 FloatProperty
FloatProperty is a NumberProperty and represents a decimal number property of the object.
value float Float value of the property.

Can be null.
4.1.10 StringProperty
StringProperty is a Property and represents a characteristic of the object.
value string Value of the characteristic of the object.

Can be null.
4.1.11 FrameProperty
FrameProperty is a Property and represents the frame position of the object.
16
x float Value of the x coordinate.
y float Value of the y coordinate.
z float Value of the z coordinate.
rx float Rotational angle around the x axis.
ry float Rotational angle around the y axis.
rz float Rotational angle around the z axis.
4.1.12 CompositeProperty
CompositeProperty is a class derived by Property and represents a composition of different properties of
every resource and prototype. This composition is modelled to create a list of simple properties of the
resource, or even a multilevel structure of CompositeProperty instances.
property Property[] List of properties of the resource.

The length is 0 to n.
Figure 4 shows a possible application of the base model classes to represent properties, meta information
and documentation of a sample CPS. A resource (in this case CPS4) can have many properties instances
associated to it and these properties can be simple (as ToolLength, EnergyConsumption and TempCPS4) or
composite properties that allow creating structured properties (CurrProd).
Figure 4 - Object diagram of the base model
17
4.2 Assets and Behaviours

As stated in deliverable D1.3 – Reference Framework Architecture [10], the goal of the MAYA CPS Semantic
Data Model is providing a gluing infrastructure that refers existing interoperability standards and integrates
them into a single extensible CPS definition.
For this reason, the implemented model includes the mechanisms to reference external data sources.
Figure 5 - Class diagram for assets and behaviours
4.2.1 ExternalReference
ExternalReference is abstract and extends IdentifiedElement. This class represents a generic reference to a
data source that is external to the Meta Data Model (e.g. a file stored on the CSI). The external source can
contain any kind of binary data in proprietary or interoperable format, depending on the type of resource.
Using external references allows avoiding re-defining data models and persistency formats for all the
possible technical aspects related to a certain resource. The approach that has been adopted is like the one
adopted in AutomationML, where additional data is stored in external files using already existing standards
(e.g. Collada for 3D models or PLCOpen for plc code).
type string Content type of the resource. This string should contain
“standardized” strings to identify the category of content that
is stored in the external reference. MIME Types (Media
Types) for the definition of the file formats and format
contents transmitted on the Internet represents a good
starting point to use and extend.
e.g. An external Collada file would define “type” as
18
“model/vnd.collada+xml”.
format string Specifies, if needed, source format details that are not
specified by the “type” attribute.
uri string Uniform Resource Identifier (URI) that fully identifies the
external data source.
amlInterface ExternalDataConnector Interface for external data connections.
4.2.2 ExternalDataConnector
ExternalDataConnector represents AML connections to external data. It should be needed to maintain the
connection between the Meta Data Model and the AutomationML persistency format. Nevertheless, since
the mapping of data model onto the Automation ML format is still an ongoing process, this class and the
attributes of type ExternalDataConnector are likely to evolve in the next few project months and fully
specified in the new releases of this technical specification.
4.2.3 Asset
Asset is an extension of ExternalResource. This class represents a reference to an external relevant model
expressed according to interoperable standard or binary format that behavioural models want to use. An
important feature that MAYA CPS data model should support is the possibility to create links between
runtime properties and properties defined inside assets and between properties defined by two different
assets. Assets can be considered static data of the CPS because they represent self-contained models (e.g.
3D Models) that should be slowly changing.
4.2.4 Behaviour
Behaviour is an extension of ExternalResource. This class represents a reference to runnable behavioural
models that implement: (i) functionalities and operative logics of the physical systems and (ii) raw data
stream aggregation and processing functions. Simulation Tools should be able to use directly the former to
improve reliability of simulations whereas the latter should run inside the CSI to update the runtime
properties of the CPS model.
4.2.5 ExternalDocumentation
ExternalDocumentation is an ExternalReference and represents the external reference to the
documentation of the resource.
19
4.3 Prototypes Model

This section is meant to describe the classes and concepts related to the definition of prototype resources
that can be defined once and reused many times to create different plant models.
4.3.1 Prototypes and instances

One of the most exploited features of manufacturing plants is the fact that they are mostly composed of
standard “off the shelf” components (machine tools, robots, etc.) that are composed in a modular way.
Thanks to this and with a good organization of modules, in fact, it is possible to speed up the simulation set
up, reusing as much as possible already developed models. For this reason, usually simulation software
tools adopt a mechanism based on the definition of libraries of models that can be applied to assemble a
full plant layout.
MAYA data model aims at natively supporting the same efficient re-use approach implementing the classes
to describe “ready to use” resources, called “prototypes” and “instances” of such elements that are the
actual resources composing plants. The relationship that exists between prototypes and instances is the
same that in OOP exists between a class and an object (instance) of that class.
A prototype is a Resource model that is complete from a digital point of view, but it is still not applied in
any plant model. It contains all the relevant information, assets and behaviours that simulation tools may
want to use and, ideally, device manufacturers should directly provide Prototypes of their products ready
to be assembled into production line models.
Figure 6 - Prototype-Resource Object Diagram
As shown in Figure 6, a Resource instance is a ResourcePrototype that has become a well identified,
specific, resource of the manufacturing plant. Each instance shares with its originating Prototype the initial
definition but during lifecycle, its model can diverge from the initial one because properties and even
models change. Therefore, a single ResourcePrototype can be used to instantiate many specific resources
that share the same original model.
4.3.2 Prototypes and instances aggregation patterns

An important aspect that Meta Data Model defines is the one related to the composition of resources into
higher level resources. This concept is at the basis of the creation of a hierarchy of resources within a plant
and it is an intrinsic way of organizing the description of a manufacturing system. Nevertheless, depending
on each specific discipline, there are many ways resource instances (and therefore CPSs) can be grouped in
a hierarchical structure. For example, spatial relationships define the topological hierarchy of a system but
from a safety grouping or electrical perspectives the same resources should be organized into different
hierarchies (e.g. in the automotive a cell safety group contains the robot and the surrounding fences, but
from an electrical point of view fences are not represented at all).
20
For this reason, Meta Data Model provides an aggregation system that is based on two levels:
• a first main hierarchy structure that is implemented in the two base classes for prototypes and
instances, AbstractResourcePrototype and AbstractResource;
• a second level, discipline dependent, that is defined in parallel to the main one and that should be
contained inside domain specific Assets.
The former hierarchy level is meant to provide a reference organization of the plant that enables both
simulation tools and the CSI to access resources in a uniform way. In fact, the main hierarchy has the
fundamental role of controlling the “visibility level” of resources, setting the lower access boundaries that
constrain the resources to which the secondary (“parallel”) hierarchies should be associated.
Figure 7 - Example of usage of main and secondary hierarchies
Figure 7 shows an example of application of the main resources hierarchy and the secondary, domain
specific one. The main hierarchy organizes the two robots and the surrounding security fence with a natural
logical grouping since ABB_Robot1, ABB_Robot2 and SecurityFence belong physically to the same
production cell, Painting_Cell1. Even if this arrangement of the instances is functional from a management
point of view, it is not directly corresponding to the relationships defined in the electrical schema of the
plant, for which the only meaningful resources are the two robots. Imagining that an electric connection
exists between the two robots, a secondary, domain specific schema (in this case the domain is the electric
design) needs to be defined separately. The Painting_Cell1 resource acts as the aggregator of the two robot
CPSs, therefore it has the “visibility” on the two resources of the lower level (Level 1), meaning that they
exist and it knows how to reference them. For this reason, the electrical schema that connects ABB_Robot1
and ABB_Robot2 is defined at Level 2 as the “ElectricConnections” Asset associated to the Painting_Cell1.
This asset, if needed, is allowed to make references to each electric schema of the lower level resources.
21
Figure 8 - Prototype Model class diagram
4.3.3 AbstractResourcePrototype
AbstractResourcePrototype is abstract and extends IdentifiedElement, see Figure 8. It represents the base
class containing attributes and relationships that are common both to prototypes of intelligent devices and
to prototypes of simple passive resources or aggregation of prototypes. The main difference between
prototype and instance classes is that the former doesn’t have any reference to a Plant model, because
they represent “not-applied” elements.
Each AbstractResourcePrototype can aggregate other AbstractResourcePrototype (that is CPSPrototype

and ResourcePrototype instances), and it can use its Assets and Behaviours to create higher level complex
models and functionalities starting from the lower level ones.

properties Property[] Runtime properties of the prototype. Each property of
the resource represents a relevant piece of
information that can be shared (accessed and
modified) by the simulation tools, and by the
functional and behavioural models.
The length of the array can be 0 to n.
metaInfo MetaInfo Contains meta information about the resource

instance, useful to keep track of the prototype vendor,
version and the tool that created it.
Can be null.
22
documentation Documentation Contains documentation of the prototype.

Can be null.
assets Asset[] Array of references to external data sources related to

the prototype that should be treated as black box
formats. E.g. the 3D geometry files of the resource.
behaviours Behaviour[] Array of references to external data sources related to

the prototype that contain shareable simulation
models, that allow interoperability of simulation tools.
resources AbstractResourcePrototype[] List of the resources that this prototype aggregates. All
the aggregated resources are prototypes. This field
implements the hierarchy relationships among
resources inside a plant. See §Prototypes and
instances aggregation patterns.
4.3.4 ResourcePrototype
ResourcePrototype extends AbstractResourcePrototype. This class represents the prototype of a generic
passive resource of the plant that hasn’t any electronic equipment capable to send/receive data to/from its
digital counterpart, or an aggregation of multiple resource prototypes. Examples of simple resources are
cell protection fences, part positioning fixtures, etc.
Resource class is the direct instance class of a ResourcePrototype.
Since a ResourcePrototype must be identifiable within the libraries of prototypes, its ID attribute should be
set to a valid UUID that should be unique within an overall MAYA framework deployment.
4.3.5 CPSPrototype
CPSPrototype extends AbstractResourcePrototype. This class represents a prototype of an “intelligent”
resource that is a resource equipped with an electronic device, capable to send/receive data to/from its
digital counterpart. A CPSPrototype defines the way its derived instances should connect to the physical
devices to maintain synchronization between shop floor and simulation models.
CPS class is the direct instance class of a CPSPrototype.
Since a CPSPrototype must be identifiable within the libraries of prototypes, its ID attribute should be set to
a valid UUID that should be unique within an overall MAYA framework deployment.
device Device Describes how CPS instances should connect to the physical
layer. This object characterizes all the I/Os that can be
received and sent from and to the real equipment.
This field cannot be null.
23
4.4 Resources Model

From Meta Data Model perspective, each simulated plant can be represented as a bunch of resources
(machine tools, robots, handling systems, passive elements, etc.). Each resource can have a real physics
counterpart to which it can be connected or not. This section of the model is meant to document the
classes that support the description of resource instances (see §Prototypes and instances for the
definition of the instance concept).
Figure 9 - Class diagram of resources section
4.4.1 AbstractResource
AbstractResource is abstract and extends IdentifiedElement. This class represents the generalization of the
concept of plant resource. As cited at the beginning of the section, a plant is a composition of intelligent
devices (e.g. machines controlled by PLC, IoT ready sensors, etc.) or passive elements (fences, fixtures, etc.).
Even if such resources are semantically different, from a simulation point of view, they have a certain
number of common properties. This fact justifies, from a class hierarchy perspective, the definition of a
base class that CPS and Resource classes extend.
24
An AbstractResource is identified by its ID which must be unique within the same plant.
digitalOnly boolean This flag indicates whether this resource (be it a CPS or a
simple resource) has a physical counterpart somewhere in the
real plant or if it is purely a virtual element.
In design phase of a plant that goes on green field, resources
will all have digitalOnly = true, while during the
reconfiguration of a plant there will be a mixed condition with
some resources having the flag set to true (the ones existing
in the running production lines) and some others set to false
(the ones that are going to be evaluated with simulation).
properties Property[] Runtime properties of the resource. Each property of the

resource represents a relevant piece of information that can
be shared (accessed and modified) by the simulation tools,
and by the functional and behavioural models.
metaInfo MetaInfo Contains meta information about the resource instance,

useful to keep track of the resource vendor, version and the
tool that created it.
Can be null.
documentation Documentation Contains documentation of the resource.

Can be null.
assets Asset[] Array of references to external data sources related to the

resource instance that should be treated as black box
formats. E.g. the 3D geometry files of the resource.
behaviours Behaviour[] Array of references to external data sources related to the

resource instance that contain shareable simulation models
that allow interoperability of simulation tools.
plant Plant Reference to the plant model this resource belongs to. Each
resource exists (even when purely virtual) inside a plant
model, so this field can never be null.
resources AbstractResource[] List of the resources that this instance aggregates. This field
implements the hierarchy relationships among resources
inside a plant. See §Prototypes and instances aggregation
patterns.
4.4.2 Resource
Resource extends AbstractResource. This class represents a generic passive resource of the plant that
hasn’t any electronic equipment capable to send/receive data to/from its digital counterpart. Examples of
simple resources are cell protection fences, part positioning fixtures, etc.
Since each Resource is also an AbstractResource, it must have a unique ID within the plant.
25
resourcePrototype ResourcePrototype Each resource can be an instantiation of a prototype resource

that has been defined in a library of models (usually stored in
the CSI) that simulation tools can access and use. See
§Prototypes and instances.
This field can be null if the resource doesn’t derive from the
instantiation of a prototype.
4.4.3 CPS
CPS extends AbstractResource. This class represents each “intelligent” device belonging to the plant
equipped with an electronic device capable to send/receive data to/from its digital counterpart. A CPS can
be connected with the physical device to maintain synchronization between shop floor and simulation
models.
A CPS can be an aggregation of other CPSs and simple Resources, using its Assets and Behaviours to
aggregate lower level models and functionalities.
Each CPS must be identified by a string ID that must be unique within the plant.
cpsPrototype CPSPrototype Each CPS can be an instantiation of a prototype CPS that has
been defined in a library of models (usually stored in the CSI)
that simulation tools can access and use. See §Prototypes
and instances.
This field can be null if the CPS doesn’t derive from the
instantiation of a prototype.
device Device Represents the description of the device that ensures the
data connection between the physical and the digital
contexts. This object characterizes all the I/Os that can be
received and sent from and to the real equipment.
This field cannot be null, while it is possible that the device,
even if fully defined is not connected to real electronic
equipment.
principal Principal Each CPS has a related access level that is defined in
compliance with the security data model described in section
“Security Data Model” and implemented by the CSI.
26
4.5 Device Model

This section contains the documentation of the classes needed to model the electronic equipment of the
intelligent resources. This equipment is described in terms of the interfaces that can be used by the digital
tools to open data streams with the real devices.
Figure 10 - Class diagram of devices section
4.5.1 Device
Device is an IdentifiedElement and represents an electronic equipment of physical layer that can be
connected to the digital counterpart to send/receive data.
deviceConnection DeviceConnection It contains all the details to open data streams with the
physical device. E.g. for Ethernet based connections it
contains IP address as well as information on ports,
protocols and possibly the security parameters to apply
to receive access rights to the specific resource.
The field can be null.
deviceConfiguration DeviceConfiguration It contains details on the device hardware and software

configuration (e.g. version of the running PLC code).
27
This object can be updated dynamically based on data

read from the physical device to reflect the actual
working condition of the device.
The field can be null.
deviceIO DeviceIO It contains the map of Input/Output data signals that

can be exchanged with the physical device.
The field cannot be null. If no signal can be exchanged
with the device, the DeviceIO map is present but
empty.
Normally this should not happen (except during the
drafting phase) because if a device doesn’t allow any
data exchange with its digital counterpart, it means it
should be treated as a passive resource.
4.5.1 DeviceConnection
DeviceConnection represents a data connection to a physical equipment. It should contain all the
parameters to open I/O streams with the real devices, including security parameters needed to receive
access rights to resources. Currently this class is an empty base class that will be extended with
specialization classes that will include specific attributes to connect to the devices identified in the
industrial scenarios.
4.5.2 DeviceConfiguration
DeviceConfiguration represents a device configuration. As DeviceConnection this class will be specialized
and completely defined during the implementation phase.
4.5.3 DeviceIO
DeviceIO represents a map of input and output signals that can be exchanged with a specific device.
inputSignals DeviceSignal[] Array of DeviceSignal describing input signals.

Signal direction is seen by the device; therefore, this is
the list of data that can be sent TO the device.
The field cannot be null.
Length of the array can be 0 to n
All DeviceSignal instances belonging to this collection
must have direction attribute set to
SignalDirection.Input.
outputSignals DeviceSignal[] Array of DeviceSignal describing output signals.

Signal direction is seen by the device; therefore, this is
the list of data that can be received FROM the device.
Length of the array can be 0 to n
All DeviceSignal instances belonging to this collection
must have direction attribute set to
SignalDirection.Output.
4.5.4 DeviceSignal
DeviceSignal is an IdentifiedElement and represents a single data signal.
28
Type SignalType Specifies data type of the specific signal.
Direction SignalDirection Specifies the direction of the signal. This value must be
correctly set keeping in mind that the I/O subject is the
device.
4.5.5 SignalDirection
SignalDirection is an Enumeration and represents the direction of signal: whether it is sent or received by
the device.
Value Description
Input Signal that can be sent TO the device. Device receives.
Output Signal that can be received FROM the device. Device sends.
4.5.6 SignalType
SignalType is an Enumeration and represents the type of signal sent or received by the device.
Value Description
BYTE 1 byte value.
INT 4-byte integer value.
FLOAT 4-byte single precision floating value.
BIT 1 bit value.
BLOB Unlimited bunch of bytes.
29
4.6 Project Model

This section describes the classes related to the management of projects, scenarios and results of
simulations for a certain plant that are produced and consumed by simulation tools.
Figure 11 - Class diagram of the Project Model section
4.6.1 Project
A project is an IdentifiedElement. It can be considered mainly as a utility container of different simulation
scenarios that have been grouped together because they are related to the same part of the plant (e.g.
different scenarios for the same painting cell of the production line).
A project could identify a design or a reconfiguration of a part of the plant for which each
SimulationScenario represents a hypothesis of layout of different resources.
30
resource AbstractResource[] Collection containing all the resources used in the

different simulation scenarios contained in this project.
plant Plant Each project is related to a part of a plant or to a whole

plant.
scenarios SimulationScenario[] Collection of the simulation scenarios that have been

developed for this particular Project instance.
4.6.2 Plant
Plant is an extension of IdentifiedElement and represents an aggregation of projects and resources. A plant
instance could be considered as an entry point for simulation tools that want to access models stored on
the CSI. It contains references to all the resource instances that are subject of SimulationScenarios. In this
way, it is possible to have different simulation scenarios, even with simulation of different types, bound to
a single resource instance.
Note: the fact that different simulations of different nature can be set up for the same resource (be it a cell,
a line, etc.) is not related to the concept of multi-disciplinary simulation that is, instead, implemented by
the MAYA Simulation Framework and refers to the possibility of running concurrent, interdependent
simulations of different types (e.g. DES simulation end energy simulation as in FinnPower use case).
The ID of the Plant must be unique within the overall MAYA framework deployment.
projects Project[] Collection of Project instances that are related to this

plant.
Array size can be 0 to n.
resources AbstractResource[] Collection of all resource instances used in the projects

and in the simulation scenarios. A plant model can
contain several instances for the same real resource
because they have been used to test different
configuration scenarios.
geoLocation string Simple attribute related to the geo positioning of the

plant when it represents the digital avatar of an existing
physical manufacturing plant.
company string Name of the company this plant belongs to.
4.6.3 SimulationScenario
SimulationScenario is an extension of IdentifiedElement and represents the run of a SimModel producing
some SimResults. A simulation scenario refers to a root resource that is not necessarily the root resource
instance of the whole plant, because a simulation scenario can be bound to just a small part of the full plant
(see Volkswagen scenario, where each single cell is simulated separately). A simulation scenario can set up
a multi-disciplinary simulation, defining different simulation models for the same resource instance to be
run concurrently by the MAYA Simulation Framework.
31
project Project Project this scenario is associated to.

This field cannot be null, a scenario exists only related
to a Project.
rootResource AbstractResource Reference to the root resource to which the SimModels

are related.
results SimResult[] Array of results obtained by running the (potentially

multi-disciplinary) models of this scenario.
models SimModel[] Collection of simulation models bound to this scenario.

Setting up multiple models for the same root resource,
is the basis for the execution of multi-disciplinary
simulations with the MAYA Simulation Framework.
This field cannot be null.
4.6.4 SimResult
SimResult represents a result obtained by running the models bound to a SimulationScenario.

model SimModel The simulation model that produced this result.
This field can’t be null.
scenario SimulationScenario Containing the simulation scenario to which the

simulation model is bound.
4.6.5 SimModel
SimModel is an IdentifiedElement and represents a simulation model run in a particular
SimulationScenario. Each model can assemble different behavioural models of the root resource into a
specific simulation model, creating scenario specific relationships that are stored inside simulation assets
that can be expressed both in an interoperable format (e.g. AutomationML) when there is need for data
exchange among different tools or in proprietary formats.
The ID of a SimModel instance must be unique within a SimulationScenario.
results SimModel[] Results obtained by running this simulation model.

assets Asset[] Collection of references to data sources containing the

description of the actual simulation model.
scenario SimulationScenario Reference to the containing SimulationScenario.

The object diagram reported below shows a possible application of the Project Model: a set of simple
resources and CPSs is organized into two hierarchies, one representing the actual demo line and a second
32
hierarchy modelling a hypothesis of redesign of the demo plant. All the Resource and CPS instances belong
to the plant model Plant1 (relationships in this case have not been reported to keep the diagram tidy). The
user wants to perform two different simulations, one for each root resource. For this reason, he sets up
two SimulationScenario instances: MD-DESScenario1 and DESScenario2. Each one refers to a different root
resource. The former is a multi-disciplinary scenario of the DemoPlantNew that will use a combination of a
DES model and an Energy Consumption model, while the latter represents a simple DES only scenario of the
original DemoPlant. These scenarios are aggregated in a Project instance (BendingCellProject) that belongs
to the Plant1 project and that is meant to compare the performance of the plant using two different set-
ups of the bending cell. For DESScenario2 there are already simulation results Result2
Figure 12 - Object diagram of the Project Model
33
4.7 Product Routing Model

In this paragraph, a full description of the product routing section of the meta data model is given.
Structural choices as well as requirements consideration are reported, with a particular focus on the
validation points that have been reviewed by experts. In order to describe this part of the model, each class
is treated separately and clusters of functional areas have been created for simplicity. All attributes,
cardinality indications and relationships are described with respect to the single entity and in the general
data model perspective.
4.7.1 Relationship between Product Routing Model and ISO 14649-10 Standard
The product routing section of the data model has been developed according to the ISO 14649-10 standard,
“Industrial automation systems and integration -- Physical device control -- Data model for computerized
numerical controllers -- Part 10: General process data”, that was deeply analysed and chosen as best-fitting
standard for the product feature - operation coupling part. Its characteristics and focus areas are suitable
from the functional point of view, as it tackles some aspects that the model needs to cover in exactly the
same application environment. In fact, it supports the communication between CAD and CNC. ISO 14649-10
specifies the process data which is generally needed for NC programming in any of the possible machining
technologies. These data elements describe the interface between a computerised numerical controller
and the programming system (i.e. CAM system or shop-floor programming system). On the programming
system, the programme for the numerical controller is created. This programme includes geometric and
technological information. It can be described using this part of ISO 14649 together with the technology-
specific parts (ISO 14649-11, etc.). This part of ISO 14649 provides the control structures for the sequence
of programme execution, mainly the sequence of working steps and associated machine functions 1. The
standard ISO 14649-10 gives a set of terms and a certain hierarchy among them, though without specifying
the type of relations. Being focused on process data for CNC (Computerized Numerical Control), the
terminology is deeply technical in describing all different types of manufacturing features, mechanical
parameters and measures. The relationship between workpiece features, operations and sequencing is of
relevance for the purpose of this work, so a number of entities have been selected. Only after that, the
distinction between classes and attributes was made, together with the definition of the types of
relationships and references among the classes.
1 ISO 14649. http://www.iso.org/iso/catalogue_detail?csnumber=34743
34
Figure 13 - Schedule and workpiece representation
4.7.2 Schedule
“Schedule” class is an IdentifiedElement that represents a project scheduling, which is unique and has the
specific aim of defining the sequence for producing a number of different workpieces (1. . . *), as shown in
Figure 13.
releaseDateAndTime long Represents the date and time of the scheduling.

It is set to null if the project has not been deployed on
the factory floor yet, otherwise the specific time is
registered on the moment of release.
owner string Specifies the responsibility and contact person in charge

of coordinating all involved resources.
state ScheduleStatus Each schedule instance can be in different states that

may change in time. These are described by the state
attribute which is of type ScheduleStatus.
35
realizedWorkpiece Workpiece[] List of root workpieces that will be realized by this

scheduling. The length of this array can be 1 to n.
4.7.3 ScheduleStatus
Enumeration representing the allowed states of a Schedule instance.
Value Description
Notstarted This status describes when the schedule instance is programmed but not yet started its
routing on the production system.
Inprogress This status describes when the schedule instance is already started on the production
system, but not yet completed.
Complete This status describes when the schedule instance is already completed, therefore it is not on
the production system anymore.
4.7.4 Workpiece
Workpiece class represents the part or product that needs to be machined, assembled or disassembled.
Each schedule realizes at least one workpiece, but it may also realize different product variants, with
various features. Each product variant is a different instantiation of the class “Workpiece" and extends the
IdentifiedElement class. Being a central entity for the data model, the workpiece has a further development
side that concerns the production scheduling and product routing. Manufacturing methods and instructions
are not contained in the workpiece information, but are determined by the operations themselves.
tolerance float Machining global tolerance.
material Material[] Material of the workpiece. The workpiece

may be made of one or more materials
(Cardinality = 1...*).
geometry Geometry Geometry of each workpiece, as specified

in the requirements. Geometry can be
only one and must be indicated
(Cardinality = 1).
workpiece Workpiece Each workpiece may be a composition of

a number of workpieces that are
assembled. In this case, the different sub-
assemblies, components and assembled
products are considered separately as
they have different manufacturing
features, geometries, materials.
required_program_structure ProgramStructure[] The program structure that defines the

sequence of working steps is created
based on the workpiece characteristics.
Each program structure is defined only for
a single workpiece ID (Cardinality = 1).
Each workpiece can have more than one
program structure, even if only one is
used, based on different criteria, as the
36
machine availability (Cardinality = 1…*).
manufacturing_feature ManufacturingFeature[] Characteristic of the workpiece, that

requires specific operations. Each
manufacturing feature is connected to
one workpiece (Cardinality = 1), while
each workpiece can have more than one
manufacturing features (Cardinality =
1…*).
assembly_workpiece_subset AssemblyWorkpieceSubset[] It indicates the set of workpieces to be

assembled to compose a workpiece
(Cardinality = 2…*).
disassembly_workpiece DisassemblyWorkpiece[] It indicates the workpieces in which an

initial workpiece can be disassembled. A
workpiece can have one or more
“Disassembly Workpieces” because there
can be more than one-way to disassemble
a product (Cardinality = 1…*). Instead, it is
possible to obtain from a single product
two workpieces or more through the
performed operations (Cardinality = 2…*).
4.7.5 Geometry
Geometry is an important reference for the specification of the workpiece geometry.
asset Asset References to external documentation, that are needed for 3D visualization
and CAD or CAM operations. Lower levels of physical specifications are given
with the support of JT and COLLADA.
4.7.6 Material
The material(s) of a workpiece may be specified as it (they) could influence some technological process
parameters. The Material Class extends the IdentifiedElement Class.
4.7.7 ProgramStructure
ProgramStructure determines how the different operations are executed for a specific work piece, i.e. in
serial or parallel, see also Figure 14. A program structure, at low level, is composed of single, ordered steps,
called “Executables". Depending on the type of program structure, the executables are realized in series or
in parallel. The program structure thus defines how the different steps are executed and at the same time
gives some flexibility in the choice, by taking into account data from the system.
structureType ProgramStructureType Determines how the different operation steps are

executed, if in parallel or in serial.
programStructure ProgramStructure[] A general program structure can be decomposed in

sub-structures, that are program structures themselves
37
machiningExecutable MachiningExecutable[] Executables of the machining type that compose the

program structure (Cardinality = 0…*).
assemblyExecutable AssemblyExecutable[] Executables of the assembly type that compose the

disassemblyExecutable DisassemblyExecutable[] Executables of the disassembly type that compose the

4.7.8 ProgramStructureType
Enumeration representing the allowed types of a ProgramStructure instance.
Field Description
Parallel Parallel structure means that the operations could be performed at the same time, without
priorities or operations that are pre-conditions to other operations.
Serial Serial structure means that operations should be performed sequentially, as each operation is a
pre-condition of the following ones.
Figure 14 - Program structure representation
4.7.9 MachiningExecutable
Machining executables initiate actions on a machine and need to be arranged in a defined order. They
define all those tasks that cause a physical transformation of the workpiece. MachiningExecutable class
extends the IdentifiedElements class and is a generalization of machining working steps and machining NC
functions, since both of these are special types of machining executables. Hierarchically it is also a sub-class
of program structures, being their basic units, as it constitutes the steps needed for the execution of the
38
program structure. Starting from the machining executable, the connected classes are represented in
Figure 14.
4.7.10 AssemblyExecutable
AssemblyExecutable also extends IdentifiedElement class.
AssemblyExecutable are a specialization of program structures and generalizations of working steps or NC

functions. As in the case of machining executables, they initiate actions on a machine and need to be
arranged in a defined order: assembly executables include all those operations that allow creating a single
product from two or more work pieces. Starting from the assembly executable, the connected classes are
represented in Figure 14.
4.7.11 DisassemblyExecutable
DisassemblyExecutable is derived from IdentifiedElement. DisassemblyExecutables are generalizations of
working steps or NC functions. As in the case of machining and assembly executables, they are also a
specialization of program structures, being their basic units, as these three classes constitute the steps
needed for the execution of the program structure. Thus, it can be imagined that one or more machining
executables, one or more assembly executables and one or more disassembly executable compose
program structure. Disassembly executables also initiate actions on a machine and need to be arranged in
a defined order: disassembly executables perform an opposite activity with respect to assembly, which
means that from a single part it extrapolates more than one part. Starting from the disassembly executable,
the connected classes are represented in Figure 14.
39
Figure 15 - Machining executable representation
4.7.12 MachiningNcFunction
MachiningNcFunction is an IdentifiedElement and a specialization of MachiningExecutable that
differentiates from the machining working step for the fact that it is a technology-independent action, such
as a handling or picking operation or rapid movements. It has a specific purpose and given parameters. If
needed, other parameters regarding speed or other technological requirements can be added as attributes.
actuator CPS It identifies the resource or system that is responsible for the
action related to the NC function.
4.7.13 MachiningWorkingStep
MachiningWorkingStep is an IdentifiedElement that is also a specialization of MachiningExecutable, the
most important one for the purpose of this work. It is the machining process for a certain area of the
workpiece and as such it is related to a technology like milling, drilling, bending. It cannot exist independent
40
of a feature, but rather specifies the association between a distinct feature and an operation to be
performed on the feature. It creates an unambiguous specification which can be executed by the machine.
An operation can be replicated for different features, while a working step is unique in each part program
as it spans for a defined period of time and relates to a specific workpiece and a specific manufacturing
feature. Each working step thus defines the conditions under which the relative operation has to be
performed. This means also that the operation related to the machining working step must be in the list of
possible operations related to a certain manufacturing feature (Figure 15).
next MachiningWorkingStep[] It defines which working steps must be

performed after the current one
(Cardinality = *).
relatedManufacturingFeature ManufacturingFeature The feature on the workpiece that the

working step is going to create (Cardinality
=1).
machiningOperation MachiningOperation The unique machining operation that is

associated to a specific workingstep
(Cardinality =1).
workpieceSetup MachiningWorkpieceSetup It defines the position of the workpiece for

machining (Cardinality = 1).
4.7.14 MachiningWorkpieceSetup
MachiningWorkpieceSetup has a direct reference to the workpiece and is defined for each machining
working step, since it defines its position for machining. In fact, it may change according to the position of
the single machining feature on the workpiece. In fact, also the reference to the manufacturing feature for
which it is defined is unique: a single workpiece setup, in fact, refers to only one machining working step,
that is meant to realize a defined feature.
workpiece Workpiece It relates to the specific workpiece under machining

(Cardinality = *).
setupInstructions MachiningSetupInstructions[] It defines the operator instructions. It is optional, as

the instructions are not necessarily described. It could
also be possible that more than one guideline may be
available. (Cardinality = *)
4.7.15 MachiningSetupInstructions
For each single operation in time and space, precise setup instructions may be specified, connected to the
workpiece setup, such as operator instructions and external material in the forms of tables, documents and
guidelines. MachiningSetupInstructions class extends the IdentifiedElement class.
description string A simple name describing the information contained in the

instructions.
eexternalDocumentation ExternalDocumentation[] External references to documents, tables or guidelines.
41
(Cardinality = *).
4.7.16 ManufacturingFeature
ManufacturingFeature is an IdentifiedElement that is a characteristic of the workpiece, that requires
specific operations. For 3D simulation and Computer Aided Design it is fundamental to have the physical
characteristics specifications: as shown in Figure 15, the workpiece manufacturing features are a relevant
piece of information for modelling and simulation, as they determine the required operations.
requiredMachiningOperation MachiningOperation[] Operations that are required to obtain a

manufacturing feature. It could be more than one
(Cardinality = *). These are not necessarily
performed one after the other, but it is the program
structure that determines the sequence of
operations of the work programme. The cardinality
n on the operation side allows for the choice of the
best possible machining operation, among the ones
allowed for the single working step. On the other
side, having different possible manufacturing
features for a single operation type demonstrates
the flexibility of operations with regards to
requirements (Cardinality = *).
4.7.17 MachiningOperation
MachiningOperation is an IdentifiedElement that specifies the contents of a machining working step and is
connected to the tool to be used and a set of technological parameters for the operation. The tool choice
depends on the specific working step conditions (Figure 15). The more information is specified for tool and
fixture, the more limited the list of possible matches is. Therefore, only the relevant, necessary values
should be specified.
toolDirection string It defines the tool orientation with respect to the

manufacturing feature
startPosition Vector3 Starting position of the tool on the workpiece to

perform the operation.
requiredTools MachiningTool[] Tool(s) to be used for the operation. An operation

may not require a tool.
toolpath MachiningToolpath[] The toolpath(s) chang(es) to fit the dimensions of the

workpiece and of the features to be realized
technology MachiningTechnology Contains parameters or other technological

information needed for the operation.
fixture Fixture[] The fixture is connected to the machining operation

and will change according to the workpiece and the
machine on which the operation is performed
42
(Cardinality = *).
generatedScrap Scrap[] Discarded waste material as a by-product of the

operation. The scrap is connected to one single
operation at a time (Cardinality = 1), but an operation
may produce more than one scrap (Cardinality = *).
4.7.18 Bending
Bending class is an example of specialization of machining operation, for the scope of the developed model.
Machining operation could be a generalization of more operation types, in addition to the class Bending.
For simplicity, it was chosen to only input Bending, as it is one of the main operations carried out in the
FinnPower demonstrator line.
4.7.19 Scrap
Scrap represents the discarded waste material as an undesired outcome of the machining operations on
the workpiece features. It may happen that the scraps are actually materials apt for reprocessing, but this is
not compulsory.
4.7.20 MachiningTechnology
MachiningTechnology collects a set of parameters, such as feed rate or tool reference point. The addition
of new attributes would expand the possibilities of technological specifications.
feedrate float Optimal linear speed of the machine tool
toolReferencePoint Vector3 Reference starting position of the tool at the beginning of

the operation
4.7.21 MachiningToolpath
Toolpath(s) to be followed during an operation. One or more toolpaths are specified for each machining
operation.
externalReference Asset Reference to COLLADA documentation giving the

kinematics specifications for the tool movement.
machiningTechnology MachiningTechnology This connection guarantees that technological

parameters are observed (Cardinality = 1).
4.7.22 MachiningTool
MachiningTool is an IdentifiedElement that defines tools needed for different machining operations.

maxFeedrate float Defines the maximum linear speed achievable by the tool.
43
4.7.23 Fixture
Fixture class is an IdentifiedElement that represents the fixtures required by machining operations, if any.
Given that the same operation may be performed under different conditions, the choice of a fitting fixture
is done for the single working step.
44
4.7.24 Assembly and Disassembly
Figure 16 - Assembly Executable representation
45
Figure 17 - Disassembly representation
46
In the last Figures (Figure 16 and Figure 17), assembly executable and disassembly executable branches are
examined, even though their development are very similar to the machining executable branch. In fact,
they differ only for a low number of details and specifications. These differences are presented in the
following subsections.
4.7.25 AssemblyWorkpieceSubset
AssemblyWorkpieceSubset is an IdentifiedElement that is in a similar position as ManufacturingFeature,
but it is relative to assembly. While in machining, the workpiece features need to be shaped, in the
assembly parts must be assembled into a workpiece.

requiredAssemblyOperation AssemblyOperation[] Operations that are required to assemble parts in a
workpiece. It could be more than one (Cardinality =
*). These are not necessarily performed one after
the other, but it is the program structure that
determines the sequence of operations of the work
programme. The cardinality n on the operation side
allows for the choice of the best possible assembly
operation, among the ones allowed for the single
working step. On the other side, having different
possible assembly workpiece subsets for a single
operation type demonstrates the flexibility of
operations with regards to requirements (Cardinality
= *).
4.7.26 DisassemblyWorkpiece
DisassemblyWorkpiece is an IdentifiedElement that is in a similar position as ManufacturingFeature and
AssemblyWorkpieceSubset, but it is relative to disassembly. While in machining, the workpiece features
needs to be shaped and in the assembly parts must be assembled into a workpiece, in the disassembly
case, the workpiece can be disassembled into more than one workpieces.
requiredDisassemblyOperation DisassemblyOperation[] Operations that are required to disassemble a

workpiece. It could be more than one
(Cardinality = *). These are not necessarily
performed one after the other, but it is the
program structure that determines the
sequence of operations of the work
programme. The cardinality n on the
operation side allows for the choice of the
best possible disassembly operation, among
the ones allowed for the single working step.
On the other side, having different possible
disassembly workpieces for a single operation
type demonstrates the flexibility of
operations with regards to requirements
(Cardinality = *).
4.7.27 AssemblyOperation
AssemblyOperation is an IdentifiedElement that specifies the contents of an assembly working step and is
connected to the tool to be used and a set of technological parameters for the operation. The tool choice
depends on the specific working step conditions (Figure 16). The more information is specified for tool and
fixture, the more limited the list of possible matches is. Therefore, only the relevant, necessary values
should be specified.
toolDirection Vector3 It defines the tool orientation with respect to the

workpiece to be assembled.
startPoint Vector3 Starting position of the tool on the workpiece to

perform the operation.
requiredAssemblyTools AssemblyTool[] Tool(s) to be used for the operation. An operation

may not require a tool.
toolpath AssemblyToolpath Toolpaths change to fit the dimensions of the

workpiece and of the points to be assembled
(Cardinality=0…*).
assemblyTechnology AssemblyTechnology Contains parameters or other technological

assemblyFixture Fixture[] The fixture is connected to the machining operation

and will change according to the workpiece and the
machine on which the operation is performed
(Cardinality = *).
consumes Consumable[] Materials needed for the assembly operation.
4.7.28 DisassemblyOperation
DisassemblyOperation is an IdentifiedElement that specifies the contents of a disassembly working step
and is connected to the tool to be used and a set of technological parameters for the operation. The tool
choice depends on the specific working step conditions (Figure 17). The more information is specified for
tool and fixture, the more limited the list of possible matches is. Therefore, only the relevant, necessary
values should be specified.

toolDirection Vector3 It defines the tool orientation with respect to
the workpiece to be disassembled.
startPoint Vector3 Starting position of the tool on the workpiece

to perform the operation.
requiredDisassemblyTool DisassemblyTool[] Tool(s) to be used for the operation. An

operation may not require a tool (Cardinality =
0…*).
toolpath DisassemblyToolpath[] Toolpaths change to fit the dimensions of the

workpiece and of the features to be realized.
48
disassemblyTechnology DisassemblyTechnology Contains parameters or other technological

fixtures Fixture[] The fixture is connected to the machining

operation and will change according to the
workpiece and the machine on which the
operation is performed (Cardinality = *).
produces Scrap[] Discarded waste material as a by-product of

the operation. The scrap is connected to one
single operation at a time (Cardinality = 1), but
an operation may produce more than one
scrap.
(Cardinality = *)
4.7.29 Consumable
Materials needed to assemble pieces, such as glue, screw, nail or simply a metal bar needed for welding
operation. Since those elements can be consumed during the assembly process, this class is named
“Consumable” and is an IdentifiedElement.
4.7.30 AssemblyTechnology
AssemblyTechnology collects a set of parameters, such as tool reference point. The addition of new
attributes would expand the possibilities of technological specifications.

feedrate float Optimal linear speed of the machine tool.
toolReferencePosition Vector3 Reference starting position of the tool at the beginning of

the operation.
4.7.31 DisassemblyTechnology
DisassemblyTechnology collects a set of parameters, such as tool reference point. The addition of new
attributes would expand the possibilities of technological specifications.

feedrate float Optimal linear speed of the machine tool.
toolReferencePosition Vector3 Reference starting position of the tool at the beginning of

the operation.
4.7.32 AssemblyToolpath
Toolpath(s) to be followed during an operation. One or more toolpaths are specified for each assembly
operation.
asset Asset Reference to COLLADA documentation giving the

kinematics specifications for the toolmovement.
49
assemblyTechnology AssemblyTechnology This connection guarantees that technological

4.7.33 DisassemblyToolpath
Toolpath(s) to be followed during an operation. One or more toolpaths are specified for each disassembly
operation.

asset Asset Reference to COLLADA documentation giving the
kinematics specifications for the tool movement.
disassemblyTechnology DisassemblyTechnology This connection guarantees that technological

4.7.34 AssemblyTool
AssemblyTool extends the IdentifiedElement class and defines tools needed for different assembly
operations.

4.7.35 DisassemblyTool
DisassemblyTool extends the IdentifiedElement class and defines tools needed for different disassembly
operations.
4.7.36 AssemblyWorkingstep
AssemblyWorkingstep extends the IdentifiedElement class and is a specialization of AssemblyExecutable,
the most important one for the purpose of this work. It is the assembly process for a certain area of the
workpiece and as such it is related to a technology like welding or gluing. It cannot exist independent of a
component subset to assemble a workpiece, but rather specifies the association between a distinct
component subset and an operation to be performed to assemble it. It creates an unambiguous
specification which can be executed by the assembly machine or robot. An operation can be replicated for
different component subsets, while a working step is unique in each part program as it spans for a defined
period of time and relates to a specific workpiece to be assembled with a specific set of components. Each
working step thus defines the conditions under which the relative operation has to be performed. This
means also that the operation related to the assembly working step must be in the list of possible
operations related to a certain assembly workpiece subset (Figure 16).
next AssemblyWorkingstep[] It defines which working steps must be

performed after the current one
50
(Cardinality = *).
assemblySubset AssemblyWorkpieceSubset The set of components to be assembled in

the working step (Cardinality = 1).
performedAssemblyOperation AssemblyOperation The unique assembly operation that is

associated to a specific working step
(Cardinality = 1).
workpieceSetup AssemblyWorkpieceSetup It defines the position of the workpiece

for assembly.
(Cardinality = 1).
4.7.37 DisassemblyWorkingStep
DisassemblyWorkingstep extends the IdentifiedElement class and is a specialization of
DisassemblyExecutable, the most important one for the purpose of this work. It is the disassembly process
for a certain area of the workpiece and as such it is related to a technology like cutting. It cannot exist
independent of a workpiece to be disassembled into different pieces, but rather specifies the association
between a distinct disassembly workpiece and an operation to be performed to disassemble it into specific
workpieces. It creates an unambiguous specification which can be executed by the disassembly machine.
An operation can be replicated for different disassembly workpieces, while a working step is unique in each
part program as it spans for a defined period of time and relates to a specific disassembly workpiece and a
specific set of disassembled pieces. Each working step thus defines the conditions under which the relative
operation has to be performed. This means also that the operation related to the disassembly working step
must be in the list of possible operations related to a certain disassembly workpiece (Figure 17).
next DisassemblyWorkingStep[] It defines which working steps must

be performed after the current one
(Cardinality = *).
workpiece DisassemblyWorkpiece The workpiece to be disassembled

into more workpieces during the
working step (Cardinality = 1).
performedDisassemblyOperation DisassemblyOperation The unique disassembly operation

that is associated to a specific
workingstep.
(Cardinality = 1).
disassemblyWorkpieceSetup DisassemblyWorkpieceSetup It defines the position of the

workpiece for disassembly
(Cardinality = 1).
4.7.38 AssemblyNcFunction
AssemblyNcFunction extends the IdentifiedElement class and is a specialization of AssemblyExecutable that
differentiates from the assembly working step for the fact that it is a technology-independent action. It has
a specific purpose and given parameters. If needed, other parameters regarding speed or other
technological requirements can be added as attributes.
51
4.7.39 DisassemblyNcFunction
DisassemblyNcFunction extends the IdentifiedElement class and is a specialization of
DisassemblyExecutable that differentiates from the disassembly working step for the fact that it is a
technology-independent action. It has a specific purpose and given parameters. If needed, other
parameters regarding speed or other technological requirements can be added as attributes.
4.7.40 AssemblyWorkpieceSetup
AssemblyWorkpieceSetup has a direct reference to the workpiece and is defined for each assembly working
step, since it defines its position for assembly. In fact, it may change according to the position of the areas
to be assembled on the components to be assembled. In fact, also the reference to the assembly workpiece
subset for which it is defined is unique: a single workpiece setup, in fact, refers to only one assembly
working step that is meant to assemble a defined set of components into a workpiece.
workpiece Workpiece[] It relates to the specific workpiece to be

assembled (Cardinality = *).
Assembly_setup_instructions AssemblySetupInstruction[] It defines the operator instructions. It is

optional, as the instructions are not
necessarily described. It could also be
possible that more than one guideline may be
available (Cardinality = *).
4.7.41 DisassemblyWorkpieceSetup
DisassemblyWorkpieceSetup has a direct reference to the workpiece and is defined for each machining
working step, since it defines its position for disassembly. In fact, it may change according to the position of
the single disassembly area on the workpiece (e.g. cutting line). In fact, also the reference to the
disassembly workpiece for which it is defined is unique: a single workpiece setup, in fact, refers to only one
disassembly working step that is meant to realize a defined feature.
workpiece Workpiece[] It relates to the specific workpiece under

machining (Cardinality = *).
Disassembly_setup_instructions DisassemblySetupIns It defines the operator instructions. It is optional,

truction[] as the instructions are not necessarily described.
It could also be possible that more than one
guideline may be available (Cardinality = *).
52
4.7.42 AssemblySetupInstruction
guidelines. AssemblySetupInstruction class extends the IdentifiedElement class.

instructions.
externalDocumentatione ExternalDocumentation[] External references to documents, tables or guidelines.

(Cardinality = *).
4.7.43 DisassemblySetupInstructions
guidelines. DisssemblySetupInstructions class extends the Identified Element class.

instructions.
externalDocumentation ExternalDocumentation[] External references to documents, tables or guidelines.

(Cardinality = *).
4.7.44 Gluing and Welding

Gluing and Welding classes are examples of specializations of AssemblyOperation, for the scope of the
developed model. AssemblyOperation could be a generalization of more operation types, in addition to the
classes Gluing and Welding.
4.7.45 Cutting
Cutting class is an example of specialization of DisassemblyOperation, for the scope of the developed
model. DisassemblyOperation could be a generalization of more operation types, in addition to the class
Cutting. For simplicity, it was chosen to only input Cutting, as it is one of the main operations carried out in
the FinnPower demonstrator line.
53
4.8 Security Model

The phases of requirement gathering and analysis highlighted that security and privacy are two of the
principal issues that must be properly addressed in MAYA platform.
In MAYA security and privacy will be enforced focusing mainly on the following aspects:
• The implementation of suitable authentication/authorization mechanisms
• Securing communication and data storage via encryption
These aspects fall under the so-called Privacy-Enhancing Technologies (PETs).
More in details, authentication is the process of confirming the identity of an external actor in order to
avoid possible malicious accesses to the system resources and services. Authentication, however, is only
one side of the coin, it is in fact tightly coupled with the concept of authorization, which can be defined as
the set of actions a software system has to implement in order to grant (authenticated) users the
permission to execute an operation on one or more resources. Authentication and authorization are
concepts related with both security (unwanted possible catastrophic access to inner resources) and privacy
and data protection issues (malicious access to other users’ data).
Securing communication is the third piece of this security and privacy puzzle and it is as necessary as
authentication and authorization. As a matter of fact, most physical devices (e.g. wireless networks) show
very few privacy guaranties; and in many cases it is practically impossible to secure wide networks against
eavesdroppers. Nonetheless, confidentiality and privacy are fundamental rights (acknowledged by the
European Convention on Human Rights) and must be enforced over often unsecure (communication and
storage) infrastructures. For this reason, MAYA platform is committed to employ state-of-the-art
encryption mechanisms (e.g. SSL and TLS) on both data storage and transport.
In the following sections of the document the part of Meta Data Model devoted to security/access control
management are reported and discussed. The elements of the MAYA meta-model that play a role in
security-related scenarios are depicted in Figure 18.
54
Figure 18 - Class diagram for the security section of the MAYA Meta Data Model
4.8.1 Principal
Often called Security principal in literature, is the entity that has to be authenticated and authorized. This is
an abstract class and extends IdentifiedElement.

description string The attribute description is used to provide a user-
friendly characterization for the object
4.8.2 User
The abstract User class extends Principal with two new attributes that enable for credentials-based
authentication and authorization mechanism.
login string The attribute login identifies the username, one of the
55
two pieces of information needed to carry on the

identification process based on credentials
password string The attribute password is the other piece of information

for the credentials-based authentication. It is stored in
an encrypted way in order to avoid password leaking
even if the CSI is somehow tampered
4.8.3 Human
This class extends User including further information to perform a two-step registration, which is a sign-in
process that can be briefly described as follows: when a human user is created in the system the
“activated” attribute will be set to false and an email with an activation link will be sent to the user’s email
address. Once the user clicks on the activation link the activated attribute is set to true and the user is
enabled to interact with the platform in the ways defined by its role.
surname string This attribute contains the user’s family name.
firstname string This attribute is meant to store the user’s first name.
email string This is the user’s email address provided during the
registration phase.
activated boolean Activated is set to false when the user’s profile is created
and to true when the two-phase activation process is
successfully completed.
4.8.4 CPS
This class extends User representing a CPS. With respect to Human a CPS does not require a two-step
registration. The only piece of information added to User is the related prototype.

prototype CPSPrototype This attribute contains a reference to the prototype the
CPS is derived from.
4.8.5 Client
The Client class extends Principal and provides a definition for one of the main concepts specified by the
Internet standard OAuth 2.0 Authorization Framework: namely, the client. A client in OAuth 2.0 protocol is
able to act in behalf of a certain user.
clientId string This attribute contains the client identification name. It

fully mirrors the login attribute defined in the User class.
secret string This attribute is meant to store a string shared between

the platform and the client. It is used in the same way
the User’s password is used.
users Set<User> This attribute is the set of Users the Client can operate in
56
behalf of. This set must contain at least one element.
4.8.6 Role
A Role is essentially an aggregation of authorities over the resources that must be protected against
malicious accesses, called Resources in the model. A security principal can assume several roles. It is
important to note that since the Role can contain several authorities possibly insisting on the same
resources, all of them must be logically concatenated (AND) and evaluated in order to decide to permit or
negate the access to resources.
name string This attribute contains the role name. It is used in order
to provide a human-friendly definition for the roles.
principal Set<Principal> This attribute is meant to store a set of references to

Principal Objects (Clients, Human or CPSs). This set must
contain at least one element.
authority Set<Authority> This attribute is meant to store a set of references to

Authority Objects. This set must contain at least one
element.
4.8.7 Authority
This class represents the authority, that is a permission granted by the system to execute a certain action
on a set of resources. Essentially, an authority is defined by a certain action, by a Boolean value (Allow) that
is used to permit or negate the authority to execute the action on a set of resources.
name string This attribute contains the authority name. It is used in

order to provide a human-friendly definition for the
authority
action ActionEnum This contains the type of interaction that the Principal is
allowed or not allowed to perform on the associated set
of resources. The actions available are READ, WRITE,
CREATE, DELETE, ALL (of the previous ones), NONE (of
the previous ones).
allow boolean This Boolean serves to allow or negate the action

defined by the attribute “action”.
resourceSet ResourceSet This attribute represents the reference to a set of

resources that can be shared among several authorities.
4.8.8 ResourceSet
This class represents a set of Resources. With respect to language built in sets ResourceSet features a
proper id, inherited from the IdentifiedElement Class and a name for a more user-friendly management.
The rationale of this class is to allow to group together different resources and assign them to a certain
authority with agility.
57
name string This attribute contains the set name. It is used in order
to provide a human-friendly definition for the resource
set
resource Set<Resource> This attribute is meant to store a set of references to

Resource Objects. This set must contain at least one
element.
4.8.9 Resource
In the CSI, wherein all the relations among services are implemented by means of REST endpoints, it seems
natural to map the concept of resource onto that of URI. Nonetheless, to provide for flexibility in the
definition of the authorities we decided not to use the language built-in URI (like Java URI) but to use a
more general String to represent an URI with wildcards. In particular, the permitted wildcards are: “?” and
“*”. The symbol “?” allows to express the concepts of “whichever the next element of the path is” whereas
the “*” indicates all the possible endpoint completions. In this way, for instance it is possible to formulate
the following (very expressive) set of path: “/projects/?/scenarios/*” representing the whole set of
scenarios (and all the possible path completions) for each possible project id (the second segments of the
path).

uri string This attribute contains a String extending the concept of
URI with wild cards in order to represent several
resources at once.
Name string This attribute contains the resource name. It is used in

order to provide a human-friendly definition for the
resource.
58
5 Sample Application and Mapping of Data Model

The following chapter describes first sample applications of the data model for modular assembly lines
• AutomationML As File Format for Data Exchange to describe simulation models

• Modelling of a modular assembly linewithin a vendor-independent factory laboratory
• Mapping of an AML conveyor sample to the data model.
5.1 Example for Data Model to describe Simulation Models

5.1.1 AutomationML as File Format for Data Exchange
To address complexity and extensibility, Meta Data Model will be composed of interconnected federated
models, using existing standards, or part of them. AutomationML will be supported as a file format for data
exchange. In addition to the semantic defined in the AML whitepapers, MAYA will need to define some
extension to explicitly support simulation and behaviour. Inside MAYA, the classification of different
entities can be based on AML standard library. In particular the devices types are described inside the roles
library named “AutomationMLDMIRoleClassLib” (Discrete Manufacturing Industry) and
“AutomationMLExtendedRoleClassLib”, detailed in AML Whitepaper part 2. Figure 19 represents the
complete hierarchy of the AML standard library proposed for adoption in MAYA. The colours show the role
library in which they are defined.
59
Figure 19 - Hierarchy of the AML standard library proposed for adoption in MAYA
60
5.1.2 Structure of the model

The following section gives an example how information about a CPS could be saved in AutomationML. The
used example is strongly based on Process Simulate.
The development of data for a Process Simulate model for a cell can be divided into three different phases:
1. Component development
2. Layout development
3. Logic/Behaviour development
The three stages result in five different AutomationML files. The relations between the files can be seen in
Figure 20. The file component model corresponds with the component phase. Several component files are
referenced in a layout model file that again corresponds with the layout phase. But the next level is the cell
model file, which references not only the layout file but also the behaviour model file as well as the logic
model file. These three files - logic, behaviour and cell -are generated in the last phase, Behaviour/Logic
development.
Figure 20 - Relations between AutomationML files
For this example, several new roles were defined in AutomationML:
1. Logic
a. Modules
b. Signals
2. Behaviour
a. Operations
b. Mapping
c. External Logic Block
3. Layout
4. Mapping
61
5.1.3 Component Information

In this file, all information is saved, that is needed to configure a complete Process Simulate resource. The
information can be divided into two main sections: Logic and Mechanic.
Logic includes Constants, Parameters Exits, Entries and Actions.
Figure 21 - Exemplary description of a gripper
Mechanic is again subdivided into Geometry and Kinematic. Geometry includes a reference to the JT model
of the component (the COLLADA format is not used here). Kinematic defines Poses Links and Joints.
5.1.4 Kinematic
Because JT is used instead of COLLADA there has to be another way to store kinematic information. This is
done by a CAEX description of Links, Joints and Poses. This is not 100% following the IEC norm and is due to
the fact that we are using Process Simulate.
62
Figure 22 - Exemplary description of kinematic information
5.1.5 Logic
CAEX is currently also used to describe logic, but in the future it would be worth to think about changing it
to PLCOpen to be later more congruent to the actual automation software.
63
Figure 23 - Exemplary description of the logic
5.1.6 Layout Information

The Layout information’s main aspect is the Location of a component. Therefore Translation and Rotation
Coordinates are needed. The other two aspects are based on Process Simulate:
- Attachment: Which resources are physically linked and move together

- Mounted Tools: Which tools are mounted to the robot
64
Figure 24 - Exemplary description of layout information
65
5.2 Mapping of Conveyor Example to Meta Model

A conveyor was modelled completely at the relevant level of detail – with focus on virtual commissioning and which
will be used for preliminary evaluation of the meta model. It is modelled in AutomationML and associated data
formats. The model includes a PLC with control logic, the geometry and the signal connections between conveyor,
light barriers and the PLC.
Table 5 shows the mapping of the entities of the conveyor to the MAYA meta data model and
AutomationML. The conveyor itself was modelled as an object in the AutomationML instance hierarchy and
besides some attributes it has a COLLADA interface as well as a JT interface because both options were
checked. Moreover, it has two material flow interfaces: one at the beginning and one at the end. Two light
barriers were modelled in the same COLLADA file and linked to their own instance element objects as well
as their logic interfaces. In this case, the PLC does not have a geometry representation but the Boolean
interfaces were modelled as PLCOpen-XML interfaces, see also Figure 25.
Meta Model Class Entities of Conveyor AutomationML types
CPS Conveyor SystemUnitClassLib
MetaInfo
Documentation ExternalDataConnector
PLC; Engine; Light Barrier

Device Role Classes: Resource
Start; Light Barrier End
PLC Interfaces;
Device Connection Conveyor interfaces;
Engine
Plant Role classes: ResourceStructure
ExternalDataConnector; Collada
Asset Collada, JT
Interface
PLC Logic Interface; Engine

Behaviour Logic Interface; Material External Data Connection
Flow
Property Output
Device Signal Input & Output
Device IO Input & Output
Table 5 - Mapping of conveyor sample table to the meta model and AML types
66
Figure 25 - Relevant models and data
The wiring between PLC, light barrier and conveyor was modelled utilizing internal links between the
interfaces of the objects. The PLC object contains logic interfaces that reference an external PLCOpen-XML
file (control logic). The engine object of the conveyor references another external PLCOpen-XML file
(behaviour logic). Within the PLCOpen-XML files globalID attributes were used as anchor points. The link
between the PLC and conveyor engine is modelled, the mechatronic connection between the geometry and
the outcome of the logic is still missing. Building on existing work, it will be one focus of future work within
the project (Figure 25).
5.3 Sample Application within Smart Factory Test Bed

The following chapter contains a first sample application of the Meta Data Model for a modular assembly
line within a DFKI Living Lab. The SmartFactoryKL is a vendor-independent factory laboratory and
environment for prototypical implementation and evaluation of developed technologies, concepts and
modern ICT applications within automation systems.
5.3.1 Demonstrating Environment

The demonstrator is a multi-vendor production system driven by representatives of research and industry,
is characterized by its scalable and modular structure and covers the paradigms of Industrie 4.0. The
production line currently consists of nine individual modules with different functionalities (Figure 26).
Those modules can be combined in any way to provide the necessary production functionality, but they can
also work individually, e.g. if only one module functionality is required. Modules can easily be removed or
added during the plant operation, which gives the ability to the plant operator to select the manufacturing
module of the provider that is most suited to the given requirements.
67
Figure 26 - Testbed with CPS-based modules at DFKI-SmartFactoryKL
This fact makes the demonstrator suitable for a first sample application for demonstrating the capabilities
of MAYA aspects within a realistic Plug ‘&’ Produce environment. The CPS-paradigm within this
demonstrator facilitates the integration, adaptation and replacement of so called CPS-based production
units working independently from each other by adopting the Plug-and-Play principle of industrial
technologies, e.g. in case of scaling up or down the production capacity to satisfy unpredictable market
demands or to respond flexibly to disruptions and failures[11].
5.3.2 Target with MAYA Components

In terms of engineering of such modular factories a fundamental issue will be maintaining the relevant
digital information all along the production life-cycle across a varied set of digital tools, allowing data to be
enriched and used as needed for each phase. The usage of engineering and simulation tools grow in
importance to support such decision-making processes within these production processes as previously
described to react in a timely manner to critical influences on production management. Therefore, first the
demonstrators’ accurate digital representation will be indispensable and second must flexibly change and
adapt with its physical counterpart especially to mirror any changes made in the real world via plug-and-
play within the simulation environment. As a first step, the MAYA meta-model will serve as a basis and
template to set up this semantic representation of each CPS-based production module. It’s a sample
application of parts of the Meta Data Model within this testbed. Each individual module gets its own digital
representation with functional and communicational characteristics as well as engineering models of its
own manufacturer (Figure 27). Each modules’ representation is characterised by the following classes and
attributes out of the data model:
Classes Attributes
IdentifiedElement ID, name
MetaInfo vendor, version, owner, type
Property, NumberProperty, StringProperty name, unit, value for velocity of all conveyor belts
ExternalReference type, format, string of geometrical models
ExternalDataConnector type, format, string of electrical planning data
DeiceConfiguration, DeviceSignal type, value for MQTT messages and signales
68
Figure 27 - Instantiation of each individual production module
5.4 First Use of Digital Representation

To follow up the use of the digital representation of each module, the ongoing work is focusing first on
implementing a short prototypical connection and automatic configuration mechanism between the real
and digital world to recognize and handle any changes made in the scalable real world within the digital
environment. Therefore, the MAYA Meta Data Model has to provide relevant meta data sets for each
individual CPS-based production module. After recognition and configuration, it will be possible to adapt its
digital counterpart by providing relevant engineering models. For demonstrating successful recognition and
configuration of additional production modules, a 3D visualization simulator called DyVisual 2 displays the
current topology of the whole production plant and its status. Use of simulation tools can be focus in
further investigations.
Figure 28 - Data Model supporting integration and adaptation of units
The proposed mechanism during plug-and-play identifies a sleep state, isolation state, configuration state
and loading state. Sleep state means that the module just turns on without any connection. Isolation state
describes that a network manager detects the module within a registry where it is possible to read out first
links to related CPS prototypes. Afterwards the modules switches to configuration state. The information
model is read out and general metadata (here: ID, name, type, vendor) can be used for the module’s
integration and its technical release to open the communication channel based on the Connection
2 http://catalogue.fitman.atosresearch.eu/enablers/dynamic-visualisation-and-interaction-dyvisual/documentation
69
Configuration for MQTT messages and signals of the module. For the visualization simulator in DyVisual the
geometrical model and properties for the conveyor belt can be read out. Real data signals can be mapped
to the visualization which allow to visualize a first approach of a digital twin of the demonstration. In
conclusion, it can be said that all relevant data needed for a first sample application are well defined in the
Meta Data Model. It makes it easy to set up the digital representation of each CPS-based module with
functional and communicational characteristics in a standardised format. During further proceedings the
models will be additionally supplemented to obtain an almost complete representation for involved IT
systems and further use cases.
70
Bibliography
[1] MAYA D1.1 Industrial Requirements and Use Cases
[2] Gruber, T.: Toward principles for the design of ontologies used for knowledge sharing, Int. J. Hum.
Comput. Stud. 43 (1995) 907–928.
http://www.sciencedirect.com/science/article/pii/S1071581985710816 (accessed September 29,
2014).
[3] MAYA D1.2 Reference Framework Requirements.
[4] <AutomationML/>. www.automationml.org, accessed on March 24, 2017.
[5] SysML – The Systems Modeling Language. http://www.omgsysml.org/, accessed on March 24, 2017.
[6] eCl@ass – Classification and product description. http://www.eclass.eu/, accessed on March 24, 2017.
[7] OWL – Web Ontology Language. https://www.w3.org/OWL/, accessed on March 24, 2017.
[8] STEP AP242 Project. http://www.ap242.org/http://www.ap242.org/, accessed on March 24, 2017.
[9] MAYA D1.4 –
[10]MAYA D1.3 – Reference Framework Architecture
[11]Weyer, Stephan, et al.: Towards Industry 4.0-Standardization as the crucial challenge for highly
modular, multi-vendor production systems. IFAC-PapersOnLine, 2015, 48. Jg., Nr. 3, S. 579-584.
94
List of Figures
Figure 1 - MAYA project architecture and Meta Data Model ............................................................................ 5
Figure 2 - Diagram types in SysML ..................................................................................................................... 8
Figure 3 - Class Diagram of the base classes .................................................................................................... 14
Figure 4 - Object diagram of the base model ................................................................................................... 17
Figure 5 - Class diagram for assets and behaviours ......................................................................................... 18
Figure 6 - Prototype-Resource Object Diagram ............................................................................................... 20
Figure 7 - Example of usage of main and secondary hierarchies ..................................................................... 21
Figure 8 - Prototype Model class diagram ....................................................................................................... 22
Figure 9 - Class diagram of resources section .................................................................................................. 24
Figure 10 - Class diagram of devices section .................................................................................................... 27
Figure 11 - Class diagram of the Project Model section .................................................................................. 30
Figure 12 - Object diagram of the Project Model ............................................................................................ 33
Figure 13 - Schedule and workpiece representation ....................................................................................... 35
Figure 14 - Program structure representation ................................................................................................. 38
Figure 15 - Machining executable representation ........................................................................................... 40
Figure 16 - Assembly Executable representation............................................................................................. 45
Figure 17 - Disassembly representation ........................................................................................................... 46
Figure 18 - Class diagram for the security section of the MAYA Meta Data Model ........................................ 55
Figure 19 - Hierarchy of the AML standard library proposed for adoption in MAYA ...................................... 60
Figure 20 - Relations between AutomationML files......................................................................................... 61
Figure 21 - Exemplary description of a gripper ................................................................................................ 62
Figure 22 - Exemplary description of kinematic information .......................................................................... 63
Figure 23 - Exemplary description of the logic ................................................................................................. 64
Figure 24 - Exemplary description of layout information ................................................................................ 65
Figure 25 - Relevant models and data.............................................................................................................. 67
Figure 26 - Testbed with CPS-based modules at DFKI-SmartFactoryKL ........................................................... 68
Figure 27 - Instantiation of each individual production module ..................................................................... 69
Figure 28 - Data Model supporting integration and adaptation of units ........................................................ 69
95
List of Tables
Table 1 - Total evaluation of different standards ............................................................................................ 10
Table 2 - Detailed evaluation of different standards ....................................................................................... 10
Table 3 - Current status of ISO 14649 and related standards .......................................................................... 11
Table 4 - Field documentation sample table .................................................................................................... 13
Table 5 - Mapping of conveyor sample table to the meta model and AML types .......................................... 66
96

EU MAYA Meta Data Model PDF

Uploaded by

Copyright:

Available Formats

EU MAYA Meta Data Model PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EU MAYA Meta Data Model PDF

Uploaded by

Copyright:

Available Formats

Ref.

Multi&disciplinArY integrated simulAtion and forecasting tools, empowered by digital continuity

D2.1 MAYA META DATA MODEL REFERENCE

Dissemination level Public

List of Abbreviation and Glossary

aka also known as

AutomationML – Automation Mark-up Language – a format for exchanging

CAD Computer-aided Design

CAM Computer-aided Manufacturing

CNC Computerized Numerical Control

CPPS Cyper Physical Production System

CPS Cyber Physical System

CSI Centralized Support Infrastructure

DES Discrete Event Simulation

JT Jupiter Tessellation – a format for storing geometric information.

MSF MAYA Simulation Framework

OLP Robotic Off line Programming

OOP Object Oriented Programming

PLC Programmable Logic Controller

PSC Process Simulate Commissioning

SME Small and Medium-sized Enterprises

STEP Standard for the Exchange of Product model data

UML Unified Modeling Language

UUID Universally Unique Identifier

XML eXtensible Markup Language

- description of a CPS on its own as well as a CPS based simulation model

Figure 1 - MAYA project architecture and Meta Data Model

3 Evaluation of Standards towards Simulation Models and

3.1 Automation Markup Language

3.2 Systems Modelling Language

Figure 2 - Diagram types in SysML

3.3 eCl@ss Advanced

There are three variants of OWL:

3.5 STEP AP242XML

3.6 Selection of a Standard

Table 1 - Total evaluation of different standards

Table 2 - Detailed evaluation of different standards

3.7 Additional Standards

3.7.2 ISO 10303 / ISO14649

Table 3 - Current status of ISO 14649 and related standards

3.8 Simulation Tools

4 MAYA Meta Data Model Reference

Each class is then presented in a dedicated sub-section that is organized with:

Field Type Description

Table 4 - Field documentation sample table

4.1 Base Model

Figure 3 - Class Diagram of the base classes

Field Type Description

id string Identification of the element.

Field Type Description

description string HTML string that identifies the documentation.

Field Type Description

vendor string Name of vendor.

version string Version of the resource.

sourceTool string Name of the simulation tool used by the resource.

Field Type Description

constraints PropertyConstraint[] Constraints of the property. The value of this attribute

references PropertyReference[] Array of references to a property.

The length can be 0 to n.