Deliverable: D3 - openMOSAddress Wolfson School of Mechanical and Manufacturing Engineering ... The elements and expected operation of system are detailed in D3.1 (Open Plug‐and‐

Project co-funded by the Horizon 2020

P f th E U i

Deliverable: D3.7

Common Semantic Model

Deliverable Responsible: Loughborough University

Version: 1.0

22/01/2018

Dissemination level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (excluding the Commission Services)

Ref. Ares(2018)404707 - 23/01/2018

2

Project Information

Acronym openMOS

Name Open dynamic manufacturing operating system for smart plug‐and‐produce automation components

Theme FOF‐11‐2015: Flexible production systems based on integrated tools for rapid reconfiguration of machinery and robots

Grant agreement 680735

Start date 1, October 2015

Duration 36 months

Contact Information

Company Name Loughborough University

Address Wolfson School of Mechanical and Manufacturing Engineering

Loughborough University

LE11 3UE

United Kingdom

E‐Mail [email protected]

Phone +44 (0) 1509 227618

Fax

Project co-funded by the Horizon 2020

P f th E U i

Version Control Version

Date Change

0.1 28/10/2017 Initial Draft (Full Document)

0.2 24/11/2017 Addition of Sematic Models for Adjustments, Observations and Assessments

0.3 2/12/2017 Addition of AutomationML Descriptions

0.4 23/12/2017 Changes to the Illustrative Example, Introduction and Conclusion

0.5 15/01/2018 Final Draft for Review

1.0 22/01/2018 Final Draft addressing Reviewers Comments

List of Authors

Name Role Affiliation Email

Niels Lohse Author Loughborough University

[email protected]

Pedro Ferreira Author Loughborough University

[email protected]

Paul Danny Anandan

Author Loughborough University

[email protected]

4

Table of Contents 1. Introduction ...................................................................................................................... 13

2. openMOS Semantic Model Overview ............................................................................... 15

2.1. Introduction............................................................................................................... 15

2.2. Assembly Process Semantic Model ........................................................................... 17

2.2.1. Skill Concepts Definition .................................................................................... 17

2.2.2. Skill Model Definition ........................................................................................ 19

2.2.3. Attributes Description ....................................................................................... 20

2.3. Assembly Equipment Semantic Model ..................................................................... 25

2.3.1. Equipment Concept Definition .......................................................................... 25

2.3.2. Equipment Model Definition ............................................................................. 26


2.4. Process Execution Model for Deployment and Usage of Recipes ............................ 29

2.4.1. Recipes Concept Definition ............................................................................... 29

2.4.2. Process Execution Model Definition ................................................................. 30


2.5. Assembly Product Semantic Model .......................................................................... 31

2.5.1. Product Concept Definition ............................................................................... 31

2.5.2. Product Model Definition .................................................................................. 32


2.6. Adjustment Semantic Model ..................................................................................... 36

2.6.1. Adjustment Concept Definition ......................................................................... 36

2.6.2. Adjustment Model Definition............................................................................ 37


2.6.4. Equipment Adjustment Model Definition ............ Error! Bookmark not defined.


2.6.6. Skill Adjustment Model Definition .................................................................... 42


2.6.8. Recipe Adjustment Model Definition ................................................................ 43


2.6.10. Execution Table Adjustment Model Definition ................................................. 44

5


2.7. Observation Semantic Model .................................................................................... 47

2.7.1. Observation Concept Definition ........................................................................ 47

2.7.2. Equipment Observation Model Definition ........................................................ 47


2.7.4. Process Observation Model Definition ............................................................. 49


2.8. Assessment Semantic Model .................................................................................... 52

2.8.1. Assessment Concept Definition ........................................................................ 52

2.8.2. Equipment Assessment Model Definition ......................................................... 53


2.8.4. Process Assessment Model Definition .............................................................. 55


3. AutomationML Model ....................................................................................................... 57

3.1. Overview of AutomationML Libraries ....................................................................... 58

3.2. Role Class Library ....................................................................................................... 59

3.3. Interface Class Library ............................................................................................... 64

3.3.1. Product Interfaces ............................................................................................. 65

3.3.2. Process Interfaces ............................................................................................. 65

3.3.3. Resource Interfaces ........................................................................................... 65

3.3.4. PPR Interfaces ................................................................................................... 66

3.4. System Unit Class Library .......................................................................................... 66

3.5. Instance Hierarchy ..................................................................................................... 69

3.5.1. Instantiation of Assembly Equipment ............................................................... 69

3.5.2. Instantiation of Recipes for Assembly Equipment ............................................ 71

3.5.3. Instantiation of Execution Tables for Sub‐Systems ........................................... 72

3.5.4. Establishing Interface Relationships for Instances ............................................ 72

4. Illustrative Example ........................................................................................................... 74

4.1. Overview ................................................................................................................... 74

4.2. Product’s Assembly Requirements ........................................................................... 74

4.3. Assembly Equipment Specification and Skills Representation ................................. 75

6

4.4. Assembly Process Specification ................................................................................. 75

4.5. Execution Tables for Sub‐Systems ............................................................................. 77

5. Conclusion ......................................................................................................................... 81

6. References ............................................................................ Error! Bookmark not defined.

7

Table of Figures

Figure 1 – Overview of openMOS Components and their Interactions ...................................... 14

Figure 2 – Overview of Targets for openMOS Semantic Model.................................................. 15

Figure 3 – Overview of Relationships Between Skill, Skill Requirement and Recipe .................. 16

Figure 4 – Overview of Skill Execution Semantic Model ............................................................. 18

Figure 5 – Assembly Equipment Semantic Model ....................................................................... 27

Figure 6 – Process Execution Semantic Model ............................................................................ 29

Figure 7 – Assembly Product Semantic Model ............................................................................ 32

Figure 8 – Adjustment Semantic Model ...................................................................................... 35

Figure 9 – Equipment Adjustment Semantic Model ................................................................... 38

Figure 10 – Skill Adjustment Semantic Model ............................................................................ 42

Figure 11 – Recipe Adjustment Semantic Model ........................................................................ 44

Figure 12 – Execution Table Adjustment Semantic Model ......................................................... 46

Figure 13 – Equipment Observation Semantic Model ................................................................ 48

Figure 14 – Process Observation Semantic Model ...................................................................... 50

Figure 15 – Equipment Assessment Sematic Model ................................................................... 53

Figure 16 – Process Assessment Semantic Model ...................................................................... 55

Figure 17 – Overview of Self‐Description and Integrating System Information ......................... 57

Figure 18 – AutomationML Editor ............................................................................................... 58

Figure 19 – Flow of how to describe an AutomationML System ................................................ 59

Figure 20 – openMOS AutomationML file .................................................................................. 60

Figure 21 – AutomationML Base Role Class Library .................................................................... 61

Figure 22 – openMOS Role Class Library ..................................................................................... 62

Figure 23 – Skill Role Class .......................................................................................................... 63

Figure 24 – Interface Class Library .............................................................................................. 64

Figure 25 – openMOS System Unit Class Library (1) ................................................................... 67

Figure 26 – openMOS System Unit Class Library (2) ................................................................... 68

Figure 27 – Simplified Structure of an InstanceHierarchy .......................................................... 69

Figure 28 – Overview of a simple Instantiation of an Equipment ............................................... 70

Figure 29 – Overview of Instantiating a Sub‐System .................................................................. 71

Figure 30 – Overview of Recipe Instantiation ............................................................................. 71

8

Figure 31 – Overview of Execution Table Instantiation .............................................................. 72

Figure 32 – Overview of Precedence Connection in AML ........................................................... 73

Figure 33 – Overview of Establishing PPR Relationships in AML ................................................ 73

Figure 34 – Overview of the MASMEC Production System ......................................................... 74

Figure 35 – Overview of Mapping Product Requirements with the Assembly Equipment’s Recipes

..................................................................................................................................................... 76

Figure 36 – Overview of Mapping the Skill Requirements of the Composite Skills .................... 78

Figure 37 – Overview of Product Deployment and the Usage of Task Execution Tables ........... 80

9

List of Tables Table 1 – Skill class attributes ..................................................................................................... 20

Table 2 – AtomicSkill class attributes .......................................................................................... 20

Table 3 – CompositeSkill class attributes .................................................................................... 21

Table 4 – SkillType class attributes .............................................................................................. 21

Table 5 – SkillRecipe class attributes ........................................................................................... 21

Table 6 – SkillRequirement class attributes ................................................................................ 22

Table 7 – Parameter class attributes ........................................................................................... 22

Table 8 – ParameterType class attributes ................................................................................... 23

Table 9 – ParameterSetting class attributes ............................................................................... 23

Table 10 – KPIType class attributes ............................................................................................. 23

Table 11 – KPI class attributes ..................................................................................................... 24

Table 12 – KPISetting class attributes ......................................................................................... 24

Table 13 – InformationPort class attributes................................................................................ 24

Table 14 – Port class attributes ................................................................................................... 25

Table 15 – ParameterPort class attributes .................................................................................. 25

Table 16 – ControlPort class attributes ....................................................................................... 25

Table 17 – Equipment class attributes ........................................................................................ 27

Table 18 – SubSystem class attributes ........................................................................................ 28

Table 19 – Workstation class attributes ...................................................................................... 28

Table 20 – Transport class attributes .......................................................................................... 28

Table 21 – Module class attributes ............................................................................................. 28

Table 22 – PhysicalPort class attributes ...................................................................................... 28

Table 23 – TaskExecutionTable class attributes .......................................................................... 30

Table 24 – TaskExecutionAssigment class attributes .................................................................. 30

Table 25 – ProductProcessExecutionAssignment class attributes . Error! Bookmark not defined.

Table 26 – ProductInstanceProcessExecutionAssignment class attributes ................................ 31

Table 27 – Product class attributes ............................................................................................. 33

Table 28 – Part class attributes ................................................................................................... 33

Table 29 – SubAssembly class attributes .................................................................................... 33

Table 30 – Component class attributes ....................................................................................... 33

10

Table 31 – ProductInstance class attributes ............................................................................... 34

Table 32 – PartInstance class attributes ..................................................................................... 34

Table 33 – SubAssemblyInstance class attributes ....................................................................... 34

Table 34 – ComponentInstance class attributes ......................................................................... 34

Table 35 – Adjustment class attributes ....................................................................................... 37

Table 36 – EquipmentAdjustment class attributes ..................................................................... 39

Table 37 – PhysicalAdjustmentSetting class attributes .............................................................. 39

Table 38 – PhysicalAdjustmentParameter class attributes ......................................................... 39

Table 39 – ParameterType class attributes ................................................................................. 40

Table 40 – Calibration class attribute .......................................................................................... 40

Table 41 – PhysicalAdjustment class attribute ........................................................................... 40

Table 42 – CreateCompositeSkill class attribute ......................................................................... 40

Table 43 – DeleteCompositeSkill class attribute ......................................................................... 41

Table 44 – EquipmentReplacement class attributes ................................................................... 41

Table 45 – ReconfigurationChange class attributes .................................................................... 41

Table 46 – RemoveModule class attribute.................................................................................. 41

Table 47 – AddNewModule class attribute ................................................................................. 41

Table 48 – SkillAdjustment class attribute .................................................................................. 42

Table 49 – CreateNewRecipe class attributes ............................................................................. 43

Table 50 – RecipeAdjustment class attributes ............................................................................ 43

Table 51 – EditRecipe class attributes ......................................................................................... 43

Table 52 – DeleteRecipe class attribute ...................................................................................... 44

Table 53 – RecipeAdjustment class attributes ............................................................................ 45

Table 54 – AddNewLine class attributes ..................................................................................... 45

Table 55 – DeleteLine class attributes ........................................................................................ 45

Table 56 – EditLine class attributes ............................................................................................. 45

Table 57 – Observation class attributes ...................................................................................... 49

Table 58 – Equipment Observation (Functionality, Quality and Performance) class attributes . 49

Table 59 – Equipment Observables (Temperature, Pressure, Voltage, Current, Flow, Force, Noise,

Vibration, EnergyConsumption and OperationalSpeed) class attributes ................................... 49

Table 60 – Observation class attributes ...................................................................................... 51

11

Table 61 – Process Functionality Observation class attributes ................................................... 51

Table 62 – Process Quality Observation class attributes ............................................................ 51

Table 63 – Process Performance Observation class attributes ................................................... 51

Table 64 – Process Functionality Observables (Temperature, Pressure, Voltage, Current, Torque

and Force) Class Attributes ......................................................................................................... 52

Table 65 – Process Quality Observables (Product Damage, Spillage) class attributes ............... 52

Table 66 – Process Performance Observables (ExecutionTime and EnergyConsumption) class

attributes ..................................................................................................................................... 52

Table 67 – Assessment class attribute ........................................................................................ 54

Table 68 – Equipment Assessment class attributes .................................................................... 54

Table 69 – EquipmentAssessment (Functionality, Quality and Performance) class attribute .... 54

Table 70 – Reliability Performance Assessment class attributes ................................................ 54

Table 71 – Energy Consumption Performance Assessment class attributes .............................. 54

Table 72 – Assessment class attribute ........................................................................................ 56

Table 73 – Process Assessment class attribute ........................................................................... 56

Table 74 – Process Assessment (Functionality, Quality and Performance) class attribute ........ 56

Table 75 – Performance Assessment (Repeatability, Accuracy, ExecutionTime and

EnergyConsumption) class attributes ......................................................................................... 56

12

Glossary

AML AutomationML

CPS Cyber Physical Systems

HMI Human‐Machine Interface

KPI Key Performance Indicator

MSB Manufacturing Service Bus

PPR Product, Process and Resource

SOA Service Oriented Architecture

13

1. Introduction

The aim of this document is to report on the semantic model development within the openMOS project.

The document builds on D3.3 (Assessment of the current semantic model technologies), which

established the modelling technologies and a preliminary version of the model. The models presented in

this document build on the extensive experience from previously developed semantic models in key

projects working on plug‐and‐produce and component‐based automation systems (IDEAS, SelSus, and

OPAK). The open publication of this document and associated models is the first step to generating wider

interest and feedback and establish a community of potential users and technology developers. The

overall objective is to ensure that all best practices and concepts can be brought together and integrated

to prepare an open standard to govern the communication content for plug‐and‐produce components.

These models focus on the project objectives by enabling the creation of high performance plug‐and‐

produce systems that can be rapidly integrated, reconfigured and upgraded without compromising their

operational performance. This is critical for the creation of the semantic model as the model is intended

to be as lean as possible, while ensuring all the necessary information exists at every stage and every

element of the project. This means one requires a view of the expected operation of the system and all

its elements. The elements and expected operation of system are detailed in D3.1 (Open Plug‐and‐

produce Architecture Specification) and D3.9 (Open Plug‐and‐produce Architecture Specification – White

Paper), nevertheless it is important to provide a view into this for better understanding this document.

openMOS aims to deliver a common Manufacturing Service Bus that links all plug‐and‐produce devices

with each other and any higher level operational control, planning, analytics and data management

applications. The openMOS approach will be open for the integration of both existing legacy systems as

well as allow upgrading for future systems. Hence, the openMOS architecture has been designed to

interface with existing industrial control systems and link them to a networked cloud of higher level

applications. As a result, openMOS systems can be deployed using traditional control approaches or

entirely new self‐organising systems approaches. This will allow the rapid deployment of high

performance systems that are seamless integrated within a factory and business environment.

openMOS has identified several key interaction protocols that cover the fundamental communication

requirements of any production system. The expectation is that emerging and future production systems

will follow a Service Oriented Architecture (SOA) to manage the horizontal as well as vertical interactions

between devices. Figure 1 provides a basic overview the typical interactions and associated information

flows that will be supported by the openMOS systems. This provides all the elements and levels for the

system which were used to define the required information for these and formulate the semantic model

that enables their descriptions. Furthermore, this should be considered in across all phases of the

assembly system, Build, Ramp‐up, production and change/ reconfiguration. A more comprehensive

description of the underpinning architecture can be found in D3.1 (Open Plug‐and‐produce Architecture

Specification) and D3.9 (Open Plug‐and‐produce Architecture Specification – White Paper).

In D3.3 (Assessment of the Current Sematic Modelling Technologies) the potential modelling technologies

were assessed to decide on the right approach for the project. Since the model has to be transparent not

only for openMOS but also for other tools, it was decided that once the model should be in the

AutomationML format. The use of AutomationML provides the advantages of having data exchange

focusing on the domain of automation engineering, but also includes the possibility to add other

engineering domains. The data format of this approach is XML schema‐based which makes it ideal for the

information exchange. However, because AutomationML is not a modelling language and it is not enough

to represent and develop the Semantic Model. In fact, the development of the semantic model required

a high level of alignment between the project developments. Therefore, the approach for the modelling

14

effort used a flexible and adjustable way to develop the semantic model, which could easily be adjusted.

UML class diagrams were used modelling and rapid testing in the software tools of the project. This

ensured easy testing and validation of the modelled aspects, before committing them in the final semantic

model. This was also critical for providing the semantic model elements when the exchange of data was

not critical, namely in the cloud tools.

Figure 1 – Overview of openMOS Components and their Interactions

The UML model was only used for internal tools, the openMOS semantic model is detailed in

AutomationML, as this was deemed to be the most suitable solutions for achieving the project objectives,

see details in D3.3. This implies that exchange of data uses this format, and these models can be enhanced

with any AutomationML compliant tools.

This document is organised as follows: section 2 gives an overview of the semantic models and concept

definitions the enables the Plug‐and‐produce functionality, while providing all the elements that are

necessary for the smooth operation of the system throughout its life‐cycle phases; Section 3 describes

how these concepts defined in each of the semantic models has been implemented in AutomationML. An

illustrative example is presented in section 4 to show how this model can be used to represent a simple

assembly product, system and process execution tables, while highlighting the traceability of information

and dependencies/ relationships between various entities and concepts; Section 5 concludes with the

status on the implementation and the use of these semantic models in the other work‐packages to deliver

the overall objective of the openMOS project.

15

2. openMOS Semantic Model Overview

2.1. Introduction

The openMOS semantic model will aggregate all stages of development and operation of assembly

systems. This means the model will enable the capture of changes in the production environment as well

as establishing the basis for the system operation. The model needs to incorporate the product, process

and equipment domains across the different phases of production, while ensuring the capture of all

adjustments and changes. This establishes a complex and interdepend set of requirements, which draw

from all developments in the openMOS project, as the semantic model aims to deliver the underlying

language for all the elements in the project. Figure 2 provides an overview of the main targets of the

semantic model, as well as the phases it will support. This includes the one to one matching view of the

model between the physical and virtual domain. The model was then extended in the virtual domain to

include aspects that are not critical for the system operation, but are important for ramp‐up and system

optimization. This highlights the extendibility of the model, as this is one of the requirements, since it

would not be realistic to an all‐encompassing semantic model within the project. The approach was to

build the core concepts and then enhance these with extensions that catered for the needs of the project,

while underlying the ability to extend this model to other areas.

Figure 2 – Overview of Targets for openMOS Semantic Model

16

The core elements of the semantic model are:

1. The assembly process (skill) semantic model

2. The assembly equipment semantic model

3. Process execution model for the deployment and usage of recipes

4. The assembly product semantic model

The assembly process model is the central concept of the openMOS project as it is present in product,

process and equipment models. The assembling process bridges the gap between the product(s) that

need to be assembled and the manufacturing system that will assemble them. The fundamental notion is

that it is possible to define the required process characteristics based on the product. Additionally, one

can also define the available process capabilities offered by the existing equipment. This means that the

processes can be used as the bridge between the product and the system domains, so long as the

semantics are the same. Additionally, the execution instructions of a capability (skill) can be formalised in

a recipe which is then related to the required process for a product. Figure 3 provides a high‐level view of

these relationships.

Figure 3 – Overview of Relationships between Skill, Skill Requirement and Recipe

The assembly system is composed of several equipment, which can be workstations (composed of

modules, devices) and transport units. These units can realise the assembling processes (known as skills)

through the execution of recipes. This implies that capabilities can only be realised if the recipes required

for given product exist, as defined in the process model. This implies that multiple recipes can be

associated to any given requirement, while the responsibility of establishing the optimised execution for

the system is done by planning and scheduling tools. This means an execution model is needed that

establishes how the system operation is performed.

In openMOS a system is expected to have multiple product variants, thus the model needs to incorporate

mechanisms that enable the system execution to be adjusted during runtime. The execution model

establishes the means for these adjustments, while providing the formalisation of the system current

execution instructions. This is done by providing the explicit relationship between product and recipe,

which will be executed by the system. It is important to highlight that this model does not provide all the

possibilities for execution in the system, but rather is used to maintain the current optimised execution.

The assembly product model allows for the formalisation of products descriptions, including their

assembly process requirements. This model also caters for the creation of generic products, or specific

17

instances of those. This means the system can create execution instructions for generic or specific

products depending on the needs for the system.

openMOS targets also the build and ramp‐up phase, which are intense in system adjustments and

changes. These changes can be physical or logical (process related), therefore it is important to establish

physical parameters which should be incorporated in the equipment model. The logical changes are done

via recipes. It is important to note that recipes need to be validated by an operator before they can be

used by the execution model, as per openMOS project requirements. The capture of all adjustments/

changes in the system is expected to be useful for learning how to improve ramp‐up process. However,

for this information to be meaningful one would require contextualisation. For this, two extra models

were introduced, the observation model and the assessment model. This provides qualitive and

quantitative elements for the diverse system states after adjustments. This in conjunction with execution

data can provide real insights into system behaviour and how to best optimize it.

The adjustment history for a system is important, however would not be relevant for the system

operation. To avoid overloading the system with data, it was decided that these models would only be

incorporated in the cloud. This is the natural placeholder for it as this information could be used also for

other system’s ramp‐up and optimization. This highlights the extendibility of the model, but also details

how it can be used partially to achieve specific objectives. Another example of this is full production

information is not required for the equipment, as they only require the information relevant to them. The

next sections below present the details for these models.

2.2. Assembly Process Semantic Model

This section describes the preliminary details of the semantic model for assembly processes. It covers the

aspects for the creation of assembly processes as skills which are actual capabilities of the devices, the

establishment of the assembly process requirements which are critical for the definition of the product

requirements, and finally on the requirements can be realised by the skills using a recipe. The model also

includes details into the attributes of the classes as well as establishes the necessary relationships

between the concepts.

The preliminary model is defined using UML notation which has been mapped in AutomationML.

Nevertheless, the focus on this document is to provide an overview for which UML is deemed better.

2.2.1. Skill Concepts Definition

The first step in the assembly process semantic model is to understand the concepts and purpose of this

model within the context of openMOS. Therefore, it is important to give an overview of the proposed

concepts and how they influence the different lifecycle stages of an assembly system.

The openMOS project aims the reduction of the initial build and reconfiguration effort using plug‐and‐

produce devices with standardised interfaces and built‐in control capabilities that can be rapidly

connected and dynamically configured to achieve different assembly processes. The plug‐and‐produce

concept goes beyond the mere plug‐ability of hardware modules by modularising the functional

capabilities needed to execute an assembly process. Thus, when a plug‐and‐produce device is plugged

into the system, it comes with its own process capabilities, which are called Skills. The purpose of the

openMOS assembly process (skill) semantic model is to formalise the concept of a skill with all its

characteristics and define how skills are used to configure the process logic of assembly systems.

.

Figure 4 – Overview of Skill Execution Semantic Model

class Execution_SkillsModel

Skill

‐ controlPorts: ControlPort [0..*]‐ description: String‐ id: UniqueID‐ informationPorts: InformationPort [0..*]‐ label: String‐ name: String‐ parameterPorts: ParameterPort [0..*]‐ type: SkillType

AtomicSkill

‐ skillRequirement: SkillRequirement

CompositeSkill

‐ composedOf: SkillRequirement [2..*]

SkillRecipe

‐ description: String‐ executedBySkillControlPort: ControlPort‐ fulfilsRequirements: SkillRequirement [0..*]‐ id: UniqueID‐ kpis: KPIForecast [0..*]‐ name: String‐ parameterSettings: ParameterSetting [0..*]‐ Validity: boolean

SkillRequirement

‐ description: String‐ id: UniqueID‐ name: String‐ precedents: SkillRequirement [0..*]‐ requiresPart: Part‐ type: SkillType

SkillType

‐ description: String‐ id: UniqueID‐ name: String‐ superType: SkillType‐ Decision: boolean

Parameter

‐ defaultValue: String‐ description: String‐ id: UniqueID‐ lowerBound: String‐ name: String‐ subParameters: Parameter [0..*]‐ type: ParameterType‐ unit: String‐ upperBound: String‐ valueType: String

ParameterType

‐ description: String‐ id: UniqueID‐ name: String

ParameterSetting

‐ description: String‐ id: UniqueID‐ name: String‐ parameter: Parameter‐ value: String

KPI

‐ description: String‐ id: UniqueID‐ name: String‐ subKPIs: KPI [0..*]‐ type: KPIType‐ valueType: String

KPIForecast

‐ description: String‐ id: UniqueID‐ kpi: KPI‐ name: String

KPIType


ParameterPort

‐ parameters: Parameter [0..*]

InformationPort

‐ kpis: KPI [0..*]

ControlPort

Port

‐ description: String‐ direction: String‐ id: UniqueID‐ name: String‐ portType: String

Value

‐ id: uniqueID‐ name: string‐ description: string‐ TimeStamp: Date/Time‐ type: enumeration‐ unit: string‐ value: string

super type

isA

isA

0..*

implementedBy1

1implementedBy

0..*

0..*

implementedBy

1

10..*0..*

type1

0..*type

1

isA

0..*

subKPI1

isA

1 parameters

0..*

isA

3..*

controlPorts

0..*

0..*

precedences

1..*

0..*

skillRequirement

1

0..*

type

1

2..*

composedOf 0..*

isA

0..*subParameters

1

1parameterPorts

0..*

0..*

KPISettings

1..*

0..*

parameterSettings

1..*

0..*type

1

0..*

fulfils

1..*

1

KPIs

0..*

19

Skills define the process capabilities offered by the plug‐and‐produce devices to complete the required

assembly process steps. Such skills will be used to select and (re‐)configure a new or reconfigured

assembly system. From a configuration and design point of view, it is necessary to compare the available

skills capabilities with a set of process/ skill requirements, with an underlying common concept called

‘Skill Type’. Therefore, within openMOS project, it is necessary to include Skill and Skill Requirement

concepts.

The concept of the skill is defined in such a way that the product requirements can incorporate optional

process sequences, where selective product needs to follow different routes. For instance, a product may

have to be tested for leaks and the equipment that performs this test can announce either the product

has passed or failed the leak test. In this sense, it may be necessary to differentiate the good and the bad

product, where the bad product may need a corrective action before proceeding any further in the

production. For this reason, the class skill type has been catered to include a Boolean attribute called

decision. This value can be used to choose the optional production flow during runtime.

Additionally, skills have some parameters which can be set either fixed or dynamically adjusted for the

operation of an assembly system. Thus, it is necessary to define which parameter settings a skill should

execute to achieve the desired results. These parameter settings can be defined in the form of Skill Recipe

which prescribes how a Skill Requirement can be achieved by a Skill.

Summarising, skills define the available process capabilities of plug‐and‐produce devices. Skill

Requirements define the characteristics of the required process steps. Skills Recipes define the settings

for a required Skill.

2.2.2. Skill Model Definition

Figure 4 defines the UML diagram for the concepts described in the previous section. The first step for

the definition of the semantic model is to describe the main concept Skill. The Skill class contains a set of

attributes that should be straightforward to understand. These attributes are:

<name>: String

<id>: UniqueID

<description>: String

<label>: String

<type>: SkillType

<controlPorts>: ControlPort

<parameterPorts>: ParameterPort

<informationPorts>: InformationPort

The SkillType class allows a matching between Skill Requirements and Skills and provides the Skill types

that are supported. This allows symbolic matching based on established domain taxonomies without

being cluttered by complex class inheritance. Skills can be either atomic or composite depending on their

level of granularity. Therefore, Skills should be broken down into AtomicSkills or CompositeSkills which

extend the Skill class. The main difference between the two classes is that an AtomicSkill represents the

execution of that skill while a CompositeSkill is composed of a set SkillRequirement which need to be

executed by lower level Atomic or Composite skills.

Skills have a set of parameters and Key Performance Indicators (KPIs) which settings are defined by the

Skills Recipes, through specified ports. The SkillRecipe class has the following attributes:

20

<name>: String

<id>: UniqueID


<kpis>: KPISetting

<fulfilsRequirements>: SkillRequirement

<parameterSettings>: ParameterSetting

<executedBySkillControlPort>: ControlPort

Skill Recipes intends to fulfil certain Skill Requirements. The Skill Requirement concept provides a similar

structure to the Skill concept. A SkillType class enables the automatic mapping between the two concepts.

The details of each of these elements are described in the following section.

2.2.3. Attributes Description

This section provides the detailed attributes for the classes described in the previous section. The attribute

type contained in some of the attributes is a class, thus an explanation is given in a separate table.

Table 1 – Skill class attributes

Attribute Description Constraints Type

controlPorts Set of unique ID’s of control ports which identify specific ControlPort.

Required with reference to valid ControlPort id’s

Set of ControlPort

description Open text description of the skill which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific skill.

RequiredUnique

UniqueID

information Ports

Set of unique ID’s of information ports which identify specific InformationPort.

Required with reference to valid InformationPort id’s

Set of Information Port

label Identification that can be freely defined. This can e.g. define some company specific identification or labelling scheme.

Optional String

name Name which can be chosen for a skill. Required String

parameter Ports

Set of unique ID’s of parameter ports which identify specific ParameterPort.

Required with reference to valid ParameterPort id’s

Set of Parameter Port

type Unique ID of a skill type which identifies a specific skill. This can be linked to a taxonomy of skill types.

Required with reference to a valid Skill Type id

SkillType

Table 2 – AtomicSkill class attributes


skill Requirement

Unique ID of a Skill requirement which identifies a specific Skill requirement.

Required with reference to a valid Skill Requirement id

Skill Requirement

21

Table 3 – CompositeSkill class attributes


composedOf Set of unique ID’s of Skill requirements which identify specific Skill requirements.

Required with reference to valid id’s

Set of Skill Requirement

Table 4 – SkillType class attributes


description Open text description of the skill type which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific skill type.

RequiredUnique

UniqueID

name Name which can be chosen for a skill type. Required String

superType Super type of the given skill which is the hierarchical higher‐level skill type that precedes the current skill.

Optional SkillType

Decision The decisional output on executing a skill (e.g. leak test skill should provide an output whether the product has passed the leak test or not, which can be represented as a Boolean output).

Required boolean

Table 5 – SkillRecipe class attributes


description Open text description of the skill recipe which can also be used for documentation purposes.

Optional String

executedBy SkillControl Port

Unique ID of a ControlPort which identifies a specific Skill.

Required with reference to a valid ID

ControlPort

fulfils Requirements

Set of unique ID’s of Skill requirements which identify specific Skill requirements.

Optional Set of Skill Requirement

id Globally unique identification for each specific skill recipe.

Required

Unique

UniqueID

kpis Set of unique ID’s of KPI setting which identify specific KPI settings.

Required with reference to valid KPISetting id’s

Set of KPI Setting

22

name Name which can be chosen for a skill recipe.

Required String

parameter Settings

Set of unique ID’s of parameter setting which identify specific parameter settings.

Required with reference to valid ID’s

Set of Parameter Setting

Table 6 – SkillRequirement class attributes


description Open text description of the skill requirement which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific skill requirement.

RequiredUnique

UniqueID

name Name which can be chosen for a skill requirement.

Required String

precedents Set of unique ID’s of Skill Requirements which identify specific Skill Requirements that are precedents of the current one.


requiresPart Unique ID of a Part which identifies a specific product part.

Optional Part

type Unique ID of a skill type which identifies a specific skill requirement. This can be linked to a taxonomy of skill types.

Required with reference to a valid Skill Type ID

SkillType

Table 7 – Parameter class attributes


defaultValue Default value which can be defined for the parameter.

Optional String

description Open text description of the parameter which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific parameter.

RequiredUnique

UniqueID

lowerBound Minimum value allowed for the given parameter.

Required String

name Name which can be chosen for a parameter.

Required String

type Unique ID of a parameter type which identifies a specific parameter. This can be linked to a taxonomy of parameter types.

Required with reference to a valid Parameter Type id

Parameter Type

unit The unit in which the corresponding values are measured.

Optional String

upperBound Maximum value allowed for the given parameter.

Required String

23

valueType Definition of the value type e.g. Integer, Float, String, etc.

Required String

Table 8 – ParameterType class attributes


description Open text description of the parameter type which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific parameter type.

RequiredUnique

UniqueID

name Name which can be chosen for a parameter type.

Required String

Table 9 – ParameterSetting class attributes


description Open text description of the parameter setting which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific parameter setting.

RequiredUnique

UniqueID

name Name which can be chosen for a parameter setting.

Required String

parameter Unique ID of a parameter which identifies a specific parameter.

Required with reference to a valid Parameter id

Parameter

value Value which the parameter has or which should be set for the parameter.

Required String

Table 10 – KPIType class attributes


description Open text description of the KPI type which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific KPI type.

RequiredUnique

UniqueID

name Name which can be chosen for a KPI type. Required String

24

Table 11 – KPI class attributes


description Open text description of the KPI which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific KPI.

RequiredUnique

UniqueID

name Name which can be chosen for a KPI. Required String

subKPIs Set of unique ID’s of KPI which identify specific KPI’s.

Optional Set of KPI

type Unique ID of a KPI type which identifies aspecific KPI. This can be linked to a taxonomy of KPI types.

Required with reference to a valid KPIType ID

KPIType

valueType Definition of the value type e.g. Integer, Boolean, Float, String, etc.

Required String

Table 12 – KPIForecast class attributes


description Open text description of the KPI setting which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific KPI setting.

RequiredUnique

Unique ID

kpi Unique ID of a KPI which identifies a specific KPI.

Required with reference to a valid KPI ID

KPI

name Name which can be chosen for a KPI setting. Required String

value Value which the KPI has or which should be set for the KPI.

Required String

Table 13 – InformationPort class attributes


kpis Set of unique ID’s of KPI which identify specific KPI’s.

Required with reference to valid KPI ID’s

Set of KPI

25

Table 14 – Port class attributes


description Open text description of the port which can also be used for documentation purposes.

Optional String

direction Definition of the Port direction, e.g. male, female, etc.

Optional String

id Globally unique identification for each specific Port.

RequiredUnique

UniqueID

name Name which can be chosen for a Port. Required String

portType Definition of the Port type. Optional String

Table 15 – ParameterPort class attributes


parameters Set of unique ID’s of parameters which identify specific parameters.

Required with reference to valid Parameter ID’s

Set of Parameter

Table 16 – ControlPort class attributes


empty In the status of the model, the attributes for this class will be inherited.

2.3. Assembly Equipment Semantic Model

This section describes the preliminary details of the semantic model for assembly equipment. It covers

the aspects of defining a piece of equipment, the establishment of different type of equipment, the

definition of a sub‐assembly unit (which can be workstation or transport) and how it relates to the skill

execution model previously described. The model also includes details of the main classes, their attributes

as well as their relationships.

2.3.1. Equipment Concept Definition

This section addresses the need for a clear classification and organisation of equipment module related

concepts. The organisation and role of equipment modules in the systems in which they are deployed

requires a clear description. Before the specific aspects of this classification can be addressed, it is

important to clearly define some equipment relevant terms.

In the English language the word “assembly” is used two‐fold; there is no clear distinction between the

physical result of an assembling activity, being an assembled product and the actual assembling process

itself. They are both called assembly.

This is also reflected in the equipment domain where a system that carries out an assembling process is

called an assembly system.

The openMOS project is adopting a process oriented approach to the modularisation of manufacturing

resources used for the purpose of assembling products. Therefore, it is advantageous to be able to

26

distinguish between process related aspects and product related aspects. Therefore, the following

definitions are being proposed:

1. Assembly ‐ An assembly is a product related collection of physical interlinked objects that results

from an ordered process of putting its constituent components together.

2. Subassembly ‐ A subassembly is an assembly with the intention to be used as a physical

interlinked object inside another assembly. Subassemblies are usually used to structure the order

in which a product is being assembled.

3. Component ‐ Components are the objects that make up an assembly from the view point of an

assembling system. They can either be individual monolithic machined parts or complex

subassemblies of their own that come from a source outside the assembling system in question.

4. Assembling ‐ Assembling is (are) the (collection of) process related activity (activities) of creating

an assembly or subassembly.

Following the definitions above and recognising the need for process‐based structuring of the

manufacturing systems that facilitate the assembling of components into (sub)assemblies leads to:

5. Assembling Equipment ‐ Assembling Equipment is all the equipment that can be used to carry

out or enable the process of assembling components into (sub)assemblies.

6. Assembling Systems ‐ Assembling Systems are systems that can carry out one or more complete

assembling step, necessary for assembling components into (sub)assemblies.

The openMOS philosophy is being drawn around assembling systems, constituted of modular, pluggable,

reconfigurable and interchangeable building blocks so called equipment modules.

The classification and structuring of assembling systems has a number of different objectives that should

be reflected in the equipment module definition. These objectives include:

Allow the hierarchical organisation of assembling systems to reduce complexity

Permit a clear link between the product organisation and the assembling system organisation

Enable process oriented modularisation of assembling systems at different levels of system/

equipment complexity

Permit the recognition and representation of different types of assembling system structures e.g.

lines, cells, workstations, etc.

Allow the definition of emplacements at different levels of system/ equipment complexity

2.3.2. Equipment Model Definition


the definition of the semantic model is to describe the Equipment class, which contains a set of attributes

that should be straightforward to understand. These attributes are:

<name>: String

<id>: UniqueID


<manufacturer>: String

<skills>: Skill

<ports>: PhysicalPort

The PhysicalPort class allows a matching between Equipment. The PhysicalPort class inherits from Port

class which has the following attributes:

27

<name>: String

<id>: UniqueID


<portType>: String

<direction>: String

Equipment can be a Subsystem (Workstation or Transport) or a Module. A Workstation can be composed

of several Modules. Each subsystem has a TaskExecutionTable to execute the deployed recipes. The

details of each of these elements are described in the following section.

Figure 5 – Assembly Equipment Semantic Model



type contained in some of the attributes is a class, thus an explanation is provided in a separate table.

Table 17 – Equipment class attributes


description Open text description of the equipment which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific equipment.

RequiredUnique

UniqueID

manufacturer Open text to describe the manufacturer of each equipment.

Optional String

class EquipmentModel

Execution_SkillsModel::Skill


Equipment

‐ description: String‐ id: UniqueID‐ manufacturer: String‐ name: String‐ ports: PhysicalPort [0..*]‐ skills: Skill [1..*]

PhysicalPort

Workstation

Module

Transport

SubSystem

‐ composedOf: Module [0..*]‐ taskExecutionTable: TaskExecutionTable(TET)

ProcessExecution::TaskExecutionTable(TET)

‐ id: UniqueID‐ name: string

Execution_SkillsModel::Port

‐ description: String‐ direction: String‐ id: UniqueID‐ name: String‐ portType: String

EquipmentStateChange

‐ TimeStamp: Date/Time‐ type: string

The type is mainly associated to the operational modes such as; Build, Ramp‐up, Production, Reconfiguration/Change. It is also important to note that when the equipment is on the 'production mode' itcan either be in an 'Idle' or 'Active' state.

10..*

1

ports

0..* 1

hasSkills

1..*

1..*

1

isA isA

isA

isAisA

11

28

name Name which can be chosen for anequipment.

Required String

ports Set of unique ID’s of PhysicalPort which identifies specific physical ports.

Optional Set of Physical Port

skills Set of unique ID’s of Skill which identifies specific Skills.

Required Set of Skill

Table 18 – SubSystem class attributes


composedOf Set of unique ID’s of Module which identifies specific Modules.

Optional Set of Module

task Execution Table

Unique ID of a task execution table which identifies a specific existing table.

Required Task Execution Table

Table 19 – Workstation class attributes


empty In the current status of the model, the attributes for this class will be inherited.

Table 20 – Transport class attributes



Table 21 – Module class attributes



Table 22 – PhysicalPort class attributes



29

2.4. Process Execution Model for Deployment and Usage of Recipes

This section describes the preliminary details of the semantic model for the deployment and usage of

recipes. The use of the recipe concept enables the preapproval and deployment of a procedure that

establishes how skills can be executed. This means the skill execution instructions can be present with

and without MES, ensuring the constant operation of the system. Therefore, this section covers the

aspects for the creation of recipes, definition of Task Execution tables, specification of Task Execution

assignments, relationship to recipes execution, and relation to product and product instances classes. The

model also includes details into the attributes of the classes as well as establishes the necessary

relationships between the concepts.

Figure 6 – Process Execution Semantic Model

2.4.1. Recipes Concept Definition

The recipe concept enables the execution of the skills to fulfil a certain skill requirement. This means that

the process of matching the skill requirements, which will be defined by the product, to the skills, which

are defined by the equipment, will result in the creation of a skill recipe. However, it has been decided in

the openMOS architecture document D3.1 “Open Plug‐and‐produce Architecture Specification” that

recipes cannot be automatically generated and made available for execution without human validation.

The process for deploying recipes needs to be in place as the planning for new products will result in the

creation of new recipes that can be used in the system after validation. Also these will serve as the basis

for improvements by the optimisation methods. These optimisation methods will update the execution

tables which in turn will contain the relations to the recipes. The Task Execution tables will contain Task

Execution assignments, which will allow the execution of recipes. This model and further concept are

described in the next section.

class ProcessExecution

TaskExecutionTable(TET)


ProductModel::Product

‐ description: String‐ hasParts: Part [0..*]‐ id: UniqueID‐ name: String‐ workflow: SkillRequirement [0..*]

ProductModel::ProductInstance

‐ hasPartInstances: PartInstance [0..*]‐ id: UniqueID‐ productID: Product

Execution_SkillsModel::SkillRecipe


TaskExecutionLine

‐ id: UniqueID‐ listOfPossibleRecipeOverrites: SkillRecipe[0..*]‐ name: string‐ nextRecipeToExecute: SkillRecipe‐ product: Product‐ recipe: SkillRecipe

Execution_SkillsModel::SkillRequirement


1..*

1

0..*

precedences

1..*

0..*

product

1

1..* 1

0..*

fulfils

1..*

1..*

1

1

1

1..* 1

30

2.4.2. Process Execution Model Definition

All the Subsystems will have a Task Execution table, which will have one or more Task Execution lines for

executing various Recipes, as described in Figure 6. There are Task Execution Assignment entries for

Products and Task Execution Assignment entries for Product Instances, because the openMOS project

supports the execution of products that belong to the same type and also allows customized executions

for specific product variants and instances. For instance, a car company may be producing a car model A,

where the process flow will remain the same for that model; but the customization can be allowed in

terms of paint, accessories and fittings for the other variants within this model or for client specific

product instances.



type contained in some of the attributes is a class, thus an explanation is in a separate table.

Table 23 – TaskExecutionTable class attributes


name Name which can be chosen for the task execution table.

Required string

id Globally unique identification for each specific task execution table.

RequiredUnique

Unique ID

Table 24 – TaskExecutionLine class attributes


Product Flag that represents if the specific task execution assignment is active.

Required boolean

id Globally unique identification for each specific task execution assignment.

Required Unique

Unique ID

recipe Unique ID of a SkillRecipe which identifies a specific existing recipe.

Required SkillRecipe

nextRecipeToExecute Unique ID of a SkillRecipe which identifies a specific existing recipe that is to be executed next according to the product’s work flow requirements.

Required SkillRecipe

listOfPossibleRecipeOverwrites Unique ID of a Skill Recipe which identifies a specific existing recipe that can be overwritten

Required List of SkillRecipes

31

to be executed next. This is only valid for recipes that have a positive value (Boolean 0/1) for the decision attribute.

Table 25 – ProductInstanceProcessExecutionAssignment class attributes


product InstanceIDs

Set of unique ID’s of ProductInstance which identifies specific product instances.

Required with reference to valid ProductInstance ID’s

Set of ProductInstance

2.5. Assembly Product Semantic Model

This section describes the preliminary details of the semantic model for assembly products. It covers the

aspects for the creation of assembly products, division of parts in components and subassemblies,

specification of particular instances of these classes for a particular product definition, and finally the

relationship with the requirements. The model also includes details into the attributes of the classes as

well as establishes the necessary relationships between the concepts.

The preliminary model has been defined using UML notations which have been mapped in

AutomationML. Nevertheless, the focus on this document is to provide an overview for which UML is

deemed better.

2.5.1. Product Concept Definition

The assembly product semantic model formalises all the product related aspects of the assembly domain.

In openMOS, the customer for an assembly system defines the characteristics (skill requirements) of the

product or set of products that need to be assembled by the system. These are generally a mixture of

existing component characteristics and required behaviour of the finished assembly, which is defined by

the interrelationships between the components. The openMOS assembly systems only cater for a limited

set of product characteristics, which target what can be achieved with the available set of equipment

modules.

The matching of required product characteristics against the achievable ones takes place during the

configuration or reconfiguration of an assembly system. Once the required process characteristics have

been defined, then it is possible to determine whether the required product characteristics can be

achieved with an openMOS assembly system.

The final comparison and validation of the skill requirements of the product against the existing

capabilities can only truly take place once the real physical assembly system is actually operational. It is

only possible to compare predicted product characteristics during the intermediate development stages.

The automatic generation of new recipes is outside the scope of the project and will be done manually

here to validate the overall manufacturing operation systems approach. Nevertheless, the concept has

been defined to support automatic recipe generation.

The skill requirements define the characteristics of physical entities for the purpose of their assembly and

can be used to dynamically plan and re‐plan production schedules. The main difference between the

characteristics of an existing product component and the requirements for one is that the requirements

can express several alternative substructures and are related to only one delivery method. The

requirements can be mapped to recipes, which are used to execute the skills to deliver the product.

32

Figure 7 – Assembly Product Semantic Model

2.5.2. Product Model Definition


the definition of the semantic model is to describe the Product class, which contains a set of attributes


<name>: String

<id>: UniqueID


<hasParts>: Part

<workflow>: SkillRequirement

Each product has a set of skill requirements which will allow a matching with the Skill and Equipment

semantics models. The details of each of these elements are described in the following section.




class ProductModel



Product


SubAssembly

‐ hasParts: Part [0..*]‐ workflow: SkillRequirement [1..*]

Component

ProductInstance

‐ hasPartInstances: PartInstance [0..*]‐ id: UniqueID‐ productID: Product

ComponentInstance

‐ componentID: Component

SubAssemblyInstance

‐ hasPartInstances: PartInstance [0..*]‐ subAssemblyID: SubAssembly

Part


PartInstance

‐ id: UniqueID‐ partID: Part

isA

0..*

component

1

isA

1

0..*

1

0..*

0..*

precedences

1..*

0..*

product

1

1..*

1

0..*

part

1

0..*1..*

1

1..*

0..*

subAssembly

1

isA

0..*

requiresPart

1..*0..*

1..*

isA

33

Table 26 – Product class attributes


description Open text description of the Product which can also be used for documentation purposes.

Optional String

hasParts Set of unique ID’s of Part which identifies specific parts.

Optional Set of Part

id Globally unique identification for each specific Product.

RequiredUnique

UniqueID

name Name which can be chosen for a Product. Required String

workflow Set of unique ID’s of Skill Requirement which identifies specific skill requirements.


Table 27 – Part class attributes


description Open text description of the Part which can also be used for documentation purposes.

Optional String

id Globally unique identification for each specific Part.

RequiredUnique

UniqueID

name Name which can be chosen for a Part. Required String

Table 28 – SubAssembly class attributes


hasParts Set of unique ID’s of Part which identifies specific parts.

Optional Set of Part

workflow Set of unique ID’s of Skill Requirement which identifies specific skill requirements.

Required Set of Skill Requirement

Table 29 – Component class attributes


empty In the status of the model, the attributes for this class will be inherited.

34

Table 30 – ProductInstance class attributes


hasPart Instances

Set of unique ID’s of PartInstance which identifies specific part instances.

Optional Set of PartInstance

id Globally unique identification for each specific ProductInstance.

RequiredUnique

UniqueID

productID Unique ID of a product which identifies a specific product.

Required with reference to a valid Product id

Product

Table 31 – PartInstance class attributes


id Globally unique identification for each specific PartInstance.

RequiredUnique

UniqueID

partID Unique ID of a part which identifies a specific part.

Required with reference to a valid Part id

Part

Table 32 – SubAssemblyInstance class attributes


hasPart Instances

Set of unique ID’s of PartInstance which identifies specific part instances.

Optional Set of PartInstance

subAssemblyID Unique ID of a SubAssembly which identifies a specific SubAssembly.

Required with reference to a valid SubAssembly id

SubAssembly

Table 33 – ComponentInstance class attributes


componentID Unique ID of a component which identifies a specific Component.

Required with reference to a valid Component id

Component

Figure 8 – Adjustment Semantic Model

class AdjustmentModel

EquipmentAdjustment

‐ EquipmentID: Equipment‐ adjustmentSettings: PhysicalAdjustmentSetting

ExecutionTableAdjustment

‐ ExecutationTableID: TaskExecutionTable(TET)

RecipeAdjustment

‐ RecipeID: SkillRecipe

SkillAdjustment

‐ SkillID: Skill

Adjustment

‐ AdjustmentID: uniqueID‐ name: string‐ description: string‐ TimeStamp: Date/Time

ObservationModels::Observation

‐ id: uniqueID‐ name: string‐ description: string‐ TimeStamp: Date/Time



EquipmentModel::Equipment

‐ equipmentId: UniqueID‐ name: String‐ description: String‐ manufacturer: String‐ skills: Skill [1..*]‐ ports: PhysicalPort [0..*]‐ adjustmentParameters: PhysicalAdjustmentParameter





For all observations, the user comments made by a human observer via the HMI will be recorded under the attribute description.

0..*

1

0..*

1

0..*

1

1

hasSkills

1..*

executedby

0..*1

0..*

1

36

2.6. Adjustment Semantic Model

The adjustment semantic model is an initial effort to capture and formalise all the necessary changes or

adjustments that can be made to ensure proper functionality of the assembly equipment and processes.

In openMOS, the adjustments are catered to cover the four main phases of the production systems such

as: build, ramp‐up, production and change phases. Adjustments can either refer to changes made to

physical hardware setups or to virtual software entities such as: skills, recipes and execution tables. The

model has also been fitted to record the user’s observation on an adjustment. The model briefs the details

of the attributes under each class and establishes the necessary relationships and dependencies between

concepts.

This model has been defined using UML notations which has also been included in the AutomationML and

mapped with relevant relationships and dependencies. Nevertheless, the focus on this document is to

provide an overview for which UML is deemed better.

2.6.1. Adjustment Concept Definition

An adjustment can be defined as an action of changing the parameters of a physical hardware or a virtual

software entity (e.g. skill) with the intension to achieve a desired output or functionality. The types of

adjustments that are under the scope of the openMOS project are listed as follows:

Equipment Adjustment: equipment modules such as sensors may need to be calibrated to their

environment to provide appropriate outputs, which is referred to as equipment adjustment.

Changes to the physical hardware setups such as positional adjustment to align with other parts

can also be referred to as equipment adjustments. It is important to note that every equipment

has a physical adjustment parameter, which can have one or more settings depending upon the

range of the adjustment parameter. In this sense, every action that has been carried out to

change the adjustment parameter to a specific adjustment setting can be referred as an

equipment adjustment. Every equipment module may have one or more atomic skills, which can

be collectively represented as a composite skill. In this context, deleting or creating a composite

skill is referred to as equipment adjustment. In some cases, the equipment module may not

deliver its intended functionality due to its age (wear‐out failure) or some random failure which

is beyond recovery, and may need replacement, which is also referred to as an equipment

adjustment.

Skill Adjustment: it is important to note that it is not possible to make changes on the skill itself,

as it is defined by the equipment supplier. The recipe is the instantiation of the skill, which can

have user defined parameter settings. Therefore, creating a new recipe can be referred to as a

skill adjustment.

Recipe Adjustment: during ramp‐up the recipes might need one or more adjustments to achieve

the desired functionality of an equipment. This might include one or more parameter changes,

which should be compatible with its corresponding skill’s parametric range limits. Therefore,

editing and deleting recipes are referred to as recipe adjustments.

Execution Table Adjustment: it is important to note that the task execution table provides the

sequence for the product assembly with a set of manually validated recipes. In this direction, if

an equipment module is unplugged from the system then the task execution lines with the

corresponding recipes should be made unavailable or deleted. In the same way, new task

execution lines should be created on generating newer recipes that has been manually validated.

Therefore, all actions such as editing, adding and deleting task execution lines are referred as

execution table adjustments.

37

2.6.2. Adjustment Model Definition


the definition of the semantic model is to describe the Adjustment class, which contains a set of attributes


<AdjustmentID>: UniqueID

<name>: String


<TimeStamp>: Date/Time

There is an optional facility that each adjustment can have one or more observations, which can be useful

for future adjustments or machine learning purposes. The adjustments in openMOS are currently put into

four main categories, which can be expanded for future case studies and are not included under the

current scope of the project. The details of each of these elements are described in the following section.




Table 34 – Adjustment class attributes


AdjustmentID Globally unique identification for each specific adjustment.

RequiredUnique

UniqueID

name Name which can be chosen for a Product. Required String

description Open text description of the adjustment which can also be used for documentation purposes.

Optional String

TimeStamp Date and time that should be recorded for the specific adjustment.

Required Date/Time

2.6.4. Equipment Adjustment Model Definition


the definition of the semantic model is to describe the Equipment Adjustment class, which contains a set

of attributes that should be straightforward to understand. These attributes are:

<EquipmentID>: Equipment

<adjustmentSettings>: PhysicalAdjustmentSetting

There is an optional facility that each equipment adjustment can have one or more observations,

recorded, which can be used for future optimised adjustments via machine learning recommendations.

The equipment adjustments in openMOS is currently put into five main categories, which can be expanded

for future case studies and does not include under the current scope of the project. The details of each of

these elements are described in the following section.

Figure 9 – Equipment Adjustment Semantic Model

class EquipmentAdjustment



Adjustment

EquipmentAdjustment

‐ EquipmentID: Equipment‐ adjustmentSettings: PhysicalAdjustmentSetting

calibration

‐ calibrationType: string

physicalAdjustment

‐ physicalAdjustmentType: string

EquipmentModel::SubSystem

‐ composedOf: Module [0..*]‐ taskExecutionTable: TaskExecutionTable(TET)

AddNewModule

‐ EquipmentID: Equipment

RemoveModule


ReconfigurationChange

‐ TimeStamp: Date/Time‐ id: uniqueID‐ name: string‐ description: string

EquipmentModel::Module

createCompositeSkill


deleteCompositeSkill




PhysicalAdjustmentParameter

‐ defaultValue: String‐ description: String‐ id: UniqueID‐ lowerBound: String‐ name: String‐ subParameters: PhysicalAdjustmentParameter [0..*]‐ type: ParameterType‐ unit: String‐ upperBound: String‐ valueType: String

ParameterType


PhysicalAdjustmentSetting

‐ id: UniqueID‐ description: String‐ name: String‐ parameter: PhysicalAdjustmentParameter‐ value: String

EquipmentReplacement

‐ ReplacingEquipmentId: equipmentId‐ NewEquipmentID: equipmentId

10..*

isA

isA

isA

isA

0..*1

isA

0..*

1

isA

1

RelatedTo

1

0..*

parameters

1

1

adjustmentSetting

1

0..*

1

0..*

type

1

0..*

subParameters

1

0..*

1

1

1

isA

1..*

implementedBy

1

isA

isA

39




Table 35 – EquipmentAdjustment class attributes


EquipmentID Globally unique identification for each specific equipment adjustment.

Required Unique

Equipment

adjustmentSettings The setting chosen for the current action of adjustment.

Required PhysicalAdjustmentSetting

Table 36 – PhysicalAdjustmentSetting class attributes


id Globally unique identification for each specific physical adjustment.

Required Unique

UniqueID

name Name which can be chosen for the adjustment setting.

Required String

description Open text description of the Product which can also be used for documentation purposes.

optional String


Required Unique

String

value The value of the parameter or a desired value that should be set for the parameter.

Required String

Table 37 – PhysicalAdjustmentParameter class attributes


id Globally unique identification for each physical adjustment parameter.

Required Unique

UniqueID

name Name which can be chosen for the adjustment parameter.

Required String

description Open text description of the adjustment parameter which can also be used for documentation purposes.

optional String


Required Unique

String

subParameters Unique ID of a parameter which identifies a specific parameter.

Required Unique

UniqueID

40

value The value of the parameter or a desired value that should be set for the parameter.

Required string

type Unique ID of a parameter type which identifies a specific parameter. This can be linked to a taxonomy of parameter types.

Required Unique

ParameterType

defaultValue The default value of the parameter or a constant value that should be set for the parameter.

Optional String

lowerBound The lowest possible value for the parameter. Required String

upperBound The highest possible value for the parameter. Required String

unit The unit in which the values of the parameter can be measured.

Required String

Table 38 – ParameterType class attributes


id Globally unique identification for each equipment adjustment parameter type.

Required UniqueID

name Name which can be chosen for the equipment adjustment parameter.

optional String

description Open text description of the equipment adjustment parameter which can also be used for documentation purposes.

optional String

Table 39 – Calibration class attribute


calibrationType The type of calibration action that the equipment module needs.

Required String

Table 40 – PhysicalAdjustment class attribute


physicalAdjustmentType The type of physical adjustment that the equipment module needs.

Required String

Table 41 – CreateCompositeSkill class attribute


skillRequirement

Set of unique ID’s of skill requirements which together represents the composite skill.

Required set of skill requirements

41

Table 42 – DeleteCompositeSkill class attribute


skillRequirement Set of unique ID’s of skill requirements which together represents the composite skill.

Required UniqueID

Table 43 – EquipmentReplacement class attributes


ReplacingEquipmentId Unique ID’s of the equipment module that is being replaced.

Required equipmentId

NewEquipmentID Unique ID’s of the new equipment module.


Table 44 – ReconfigurationChange class attributes


id Globally unique identification for each specific reconfiguration/ change.

Required UniqueID

name Name which can be chosen for the current reconfiguration action.

Optional String

description Open text description of the reconfiguration/ change which can also be used for documentation purposes.

Optional String

TimeStamp Date and time that should be recorded for the specific adjustment.

Required Date/Time

Table 45 – RemoveModule class attribute


EquipmentID Unique ID of the equipment module that is being removed.


Table 46 – AddNewModule class attribute


EquipmentID Unique ID of the equipment module that is being added to the system.


42

2.6.6. Skill Adjustment Model Definition


the definition of the semantic model is to describe the Skill Adjustment class, which contains one attribute

that should be straightforward to understand. This attribute is:

<SkillID>: skill

There is an optional facility that each skill adjustment can have one or more observations recorded, which

can be useful for creating new recipes via machine learning. This can be of recommendations with

parameter settings and KPI values for the operator to create new recipes. The operator can either make

use of the recommendations or use his or her own expertise to create new recipes. The recommendations

of this type are not included under the current scope of the project. The details of each of these elements

are described in the following section.

Figure 10 – Skill Adjustment Semantic Model




Table 47 – SkillAdjustment class attribute


SkillID unique ID of the equipment skill that is being adjusted

Required skill

class SkillAdjustment



Adjustment

SkillAdjustment

‐ SkillID: Skill

createNewRecipe

‐ RecipeID: SkillRecipe‐ name: string‐ description: string‐ associatedParameterSettings: ParameterSetting[0..*]‐ associatedKPIForecast: KPIForecast[0..*]‐ associatedSkillRequirements: SkillRequirement‐ associatedControlPorts: ControlPort[0..*]







Execution_SkillsModel::ParameterSetting


Execution_SkillsModel::KPIForecast


Execution_SkillsModel::Value


Port

Execution_SkillsModel::ControlPort

1..*

1

executedby

isA

1..*

1

0..*

1

isA

0..*

precedences

1..*

1

RelatedTo

1

0..*

fulfils

1..*

1..*

1

1..*1

0..*

1

43

Table 48 – CreateNewRecipe class attributes


RecipeID Unique ID of the recipe that is being created.

Required skill recipe

name Name which can be chosen for the new recipe that is being created.

Optional String

description Open text description of the recipe which can also be used for documentation purposes.

Optional String

Associated Parameter Settings

Set of parameter settings that represents the recipe that is being created.

Required Set of Parameter Settings

associatedKPI Set of KPI’s that represents the recipe that is being created.

Required Set of KPI Forecast

associated SkillRequirements

Set of unique skill requirements that represents the recipe that is being created.

Optional Skill Requirement

associated ControlPorts

Set of control ports that represents the recipe that is being created.

Required Set of Control Port

2.6.8. Recipe Adjustment Model Definition


the definition of the semantic model is to describe the Recipe Adjustment class, which contains an

attribute that should be straightforward to understand. This attribute is:

<RecipeID>: skill recipe

There is an optional facility that each recipe adjustment can have one or more observations recorded,

which can be useful for future recipe adjustments via machine learning techniques. The recipe

adjustments in openMOS is currently put into two main categories, which can be expanded for future case

studies and does not include under the current scope of the project. The details of each of these elements

are described in the following section.



type contained in some of the attributes is a class, thus an explanation is in a separate table.Table 49 –

RecipeAdjustment class attributes


RecipeID Unique ID of the recipe that is being adjusted. Required skill recipe

Table 50 – EditRecipe class attributes


recipeId Unique ID of the recipe that is being adjusted. Required UniqueID

44

associatedKPIs Set of KPI’s that represents the recipe that is being adjusted.

Required Set of KPI Forecast

associated Parameter Settings

Set of parameter settings that represents the recipe that is being adjusted.

Required Set of Parameter Setting

Table 51 – DeleteRecipe class attribute


RecipeID Unique ID of the equipment skill that is to be deleted


Figure 11 – Recipe Adjustment Semantic Model

2.6.10. Execution Table Adjustment Model Definition


the definition of the semantic model is to describe the Task Execution Table Adjustment class, which

contains a set of attributes that should be straightforward to understand. These attributes are:

<taskExecutionTableId>: UniqueID

There is an optional facility that each task execution table adjustment can have one or more observations

recorded, which can be useful for future adjustments via machine learning and the optimisation of

production schedules. The task execution table adjustments in openMOS is currently put into three main

class RecipeAdjustment



EditRecipe

‐ associatedKPIs: KPIForecast [0..*]‐ associatedParameterSettings: ParameterSetting [0..*]

DeleteRecipe

Adjustment

RecipeAdjustment

‐ RecipeID: SkillRecipe



Execution_SkillsModel::ParameterSetting


Execution_SkillsModel::KPIForecast


Execution_SkillsModel::Value


0..*

1

0..*

KPISettings

1..*

1

RelatedTo

1

1

RelatedTo1

0..*

1

0..*

parameterSettings

1..*

0..*

0..*

isA

0..*

0..*

isA

isA

45

categories, which can be expanded for future case studies and does not include under the current scope

of the project. The details of each of these elements are described in the following section.




Table 52 –ExecutionTable Adjustment class attributes


Execution TableID

Unique ID of the task execution table that is being adjusted.

Required Task Execution Table

Table 53 – AddNewLine class attributes


lineID Unique ID of the task execution line that is to be added to the task execution table.

Required UniqueID

ProductID Unique ID of the product. Required Product

RecipeID Unique ID of the recipe that is required to execute the specific skill requirement of the product.


Table 54 – DeleteLine class attributes


lineID Unique ID of the task execution line that is to be deleted from the task execution table.

Required UniqueID

ProductID Unique ID of the product. Required product

RecipeID Unique ID of the recipe that is required to execute the specific skill requirement of the product.


Table 55 – EditLine class attributes


RecipeID Unique ID of the equipment skill that is beingadjusted.


ProductID Unique ID of the product. Required Product

RecipeId Unique ID of the recipe that is required to execute the specific skill requirement of the product.


NextRecipe ToExecute

Unique ID of the recipe that is to be executed next in the sequence of the product assembly steps.

optional skill recipe

46

ListOfPossible RecipeChoices

Unique ID of the recipes that can be an alternative for executing the specific skill requirement of the product.

optional Set of skill recipes

Figure 12 – Execution Table Adjustment Semantic Model

class ExecutionTableAdjustment



AddNewLine(TET)

‐ lineID: uniqueID‐ ProductID: Product‐ RecipeID: SkillRecipe

DeleteLine(TET)

‐ lineID: uniqueID‐ ProductID: Product‐ RecipeID: SkillRecipe

EditLine

‐ lineID: uniqueID‐ ProductID: Product‐ RecipeID: SkillRecipe‐ NextRecipeToExecute: SkillRecipe‐ ListOfPossibleRecipeChoices: SkillRecipe[0..*]



Adjustment

ExecutionTableAdjustment

‐ ExecutationTableID: TaskExecutionTable(TET)

ProductModel::Product




1

RelatedTo1

0..*

1

0..*

1

1

RelatedTo1

1

RelatedTo

1

1

RelatedTo

1

isA

isA

1

RelatedTo

1

isA

47

2.7. Observation Semantic Model

The observation semantic model is an initial effort to capture and formalise all the comments or

observations made by the user towards any equipment, processes, adjustments, assessments, etc. In

openMOS, observations are catered to cover the four main phases of the production systems such as:

build, ramp‐up, production and change phases. The model briefs the details of the attributes under each

class and establishes the necessary relationships and dependencies between concepts.




2.7.1. Observation Concept Definition

An observation can be defined as a user defined record (comment or notes) towards functionality, quality

and performance of the equipment or the process. This record helps the user as a guide to undertake

future adjustments and assessments. In openMOS, observations are also used for machine learning

purposes to generate recommendations for future adjustments. The types of observations that are under

the scope of the openMOS project are listed as follows:

Equipment Observation: the functionality of an equipment module can be determined based on

a few parameters such as voltage, current, pressure, temperature, flow, force, etc. There can be

several reasons for an equipment not being able to deliver its expected functionality, for instance

it may not power up, or a pneumatic device may lack pressure due to a leak in its valve, which

could be recorded as an observation in‐terms of the equipment functionality. Today most

commonly used condition monitoring sensors are mainly based on vibration, noise and

temperature readings, which helps to forecast an upcoming failure. Therefore, the operational

quality of an equipment can be determined based on a few observables that it exhibits such as:

the noise, temperature and vibration. In openMOS, the performance of an equipment module is

mostly inferred from a few observables such as: energy consumption and operational speed.

Process Observation: in openMOS, the assembly processes are executed by the recipes.

Therefore, the process functionality, quality and performance are directly related to each

individual recipe. The recipe’s functionality can be observed directly from its parameter settings,

which may or may not be appropriate to fulfil a specific task, operation or action. The quality of

a recipe execution can be determined by quantifying the damages, spillages and other

characteristics associated with handling the product during the assembly process steps. In

openMOS, the performance of a recipe execution can be estimated via its KPI values such as:

duration (execution time) and energy consumption.

2.7.2. Equipment Observation Model Definition


the definition of the semantic model is to describe the observation class, which contains a set of attributes


<Id>: UniqueID

<name>: String



48

The equipment observation in openMOS is currently put into three main categories, which can be

expanded for future case studies and does not include under the current scope of the project. The details

of each of these elements are described in the following section.

Figure 13 – Equipment Observation Semantic Model

class EquipmentObservation



Observation


Noise

‐ Unit: string‐ Value: float

Vibration


EquipmentFunctionality


EquipmentQuality


EquipmentPerformance


Temperature


EnergyConsumption


Pressure


An equipment may not be functioning as expected due to several reasons, for instance the equipment may not power‐up, or even over‐heating, or lacking the pressure for some pneumatic devices etc,.

An equipment under operation might have some observable for instance, the vibration exhibited by the equipment might be the measure of its operational quality.

The performance of anequipment will be mostly related to its operational speed, energy consumption etc.,

OperationalSpeed


Voltage


Current


Flow

‐ unit: string‐ Value: float

Force


isA

isA

isA

isA

isA

isA

isA

isA

isA

isA

0..*

1

isA

isA

isA

49




Table 56 – Observation class attributes


id Unique ID of the observation that is to be recorded.

Required UniqueID

name Name which can be chosen for the observation that is to be recorded.

Optional String

description Open text description of the observation which can also be used for documentation purposes.

Optional String

TimeStamp Date and time that should be recorded for the current observation.

Required Date/Time

Table 57 – Equipment Observation (Functionality, Quality and Performance) class attributes


EquipmentID Unique ID of the equipment module for which the current observation is being made.

Required equipment

Table 58 – Equipment Observables (Temperature, Pressure, Voltage, Current, Flow, Force, Noise, Vibration, EnergyConsumption and OperationalSpeed) class attributes


Unit The unit in which the current observation can be measured.

Required String

Value The value of the current observation. Required Float

2.7.4. Process Observation Model Definition


the definition of the semantic model is to describe the observation class, which contains a set of attributes


<id>: UniqueID

<name>: String



The process observation in openMOS is currently put into three main categories, which can be expanded



Figure 14 – Process Observation Semantic Model

class ProcessObservation





Observation


Recipefunctionality

‐ RecipeID: SkillRecipe‐ associatedParameterSettings: ParameterSetting[0..*]

RecipeQuality

‐ RecipeID: SkillRecipe‐ ProductID: ProductInstance[0..*]

ProductWastage(Damage)

‐ Quantity: int

RecipePerformance

‐ RecipeID: SkillRecipe‐ KPI: KPI[0..*]

Duration(ExecutionTime)

‐ value: sec

EnergyConsumption

‐ value: Watts

ProductWastage(Spilage)

‐ Quantitiy: int

Force


Speed


Torque


The skill recipe is always executed by a base skill and in this sense, any observation made can be recorded towards a corresponding recipe.

The recipe's functionality can be observed alongside of its parameter settings, which may be lacking to fulfill a specific task, operation or action.

The quality of the recipe execution can be observed alongside of its corresponding product (instances) handling and the fulfillment of a specific 'skill requirement'

The performance of the skill recipe can be observed via its KPI values

Voltage


Current


Pressure


Temperature


isAisA

isA isA

isA

0..*

1

isAisA

1

isA isAisA isA

executedby

isA

isAisA

51




Table 59 – Observation class attributes


id Unique ID of the observation that is to be recorded.

Required UniqueID

name Name which can be chosen for the observation that is to be recorded.

Optional String

description Open text description of the observation which can also be used for documentation purposes.

Optional String

TimeStamp Date and time that should be recorded for the current observation.

Required Date/Time

Table 60 – Process Functionality Observation class attributes


RecipeID Unique ID of the recipe for which the current observation is being made.


associated Parameter Settings

Set of parameter settings that represents the recipe for which the current observation is being made.

Required Set of Parameter Settings

Table 61 – Process Quality Observation class attributes




ProductID Unique ID of the product. Required product instance

Table 62 – Process Performance Observation class attributes




Associated KPIs Set of KPI that represents the recipe for which the current observation is being made.

Required Set of KPI

52

Table 63 – Process Functionality Observables (Temperature, Pressure, Voltage, Current, Torque and Force) Class Attributes


Unit The unit in which the current observation can be measured.

Required String

Value The value of the current observation. Required Float

Table 64 – Process Quality Observables (Product Damage, Spillage) class attributes


unit The unit in which the current observation can be measured.

Required String

Quantity The quantity of the product damages and wastages.

Required Float

Table 65 – Process Performance Observables (ExecutionTime and EnergyConsumption) class attributes


unit The unit in which the current observation can be measured

Required String

value The value of the current observation Required Float

2.8. Assessment Semantic Model

The assessment semantic model is an initial effort to capture and formalise all the results when assessing

production equipment and processes. In openMOS, assessments are catered to cover the four main

phases of the production systems such as: build, ramp‐up, production and change phases. The model has

been built in way that the user can record an observation for every assessment. The model briefs the

details of the attributes under each class and establishes the necessary relationships and dependencies

between concepts.




2.8.1. Assessment Concept Definition

Assessment can be defined an action carried out to evaluate the functionality, quality and performance

of production equipment and processes. The combination of the assessment and the observation

together gives a better understanding on the current state of the equipment module, and the

deterioration or improvements made from its previous state. Similarly, the results of assessments can also

be used for future adjustments and assessments. In openMOS, the basic assumption is that the user who

carries out the assessment is a domain expert, and based on his or her knowledge and experience (s)he

provides a score for each and every assessment. The user should record his/her assessment scores in the

HMI (Human‐Machine Interface) device by selecting the appropriate equipment or recipe. The types of

assessments that are under the scope of the openMOS project are listed as follows:

53

Equipment Assessment: the functionality and the quality of an equipment module are manually

assessed by the user by providing an appropriate ranking or score. The results of such

assessments are recorded through HMI devices, where the operator selects the specific

equipment module to rank its functionality, quality and performance. In openMOS, the

performance of an equipment module is assessed based on its reliability and energy

consumption.

Process Assessment: the functionality of the processes is manually assessed by the user by

providing an appropriate ranking or score. The results of such assessments are recorded through

HMI devices, where the operator selects the specific equipment module to rank its functionality,

quality and performance. In openMOS, the quality of a process is assessed based on its

repeatability and accuracy. Similarly, the performance of a process is assessed based on its KPI’s

such as duration (execution time) and energy consumption.

Figure 15 – Equipment Assessment Sematic Model

2.8.2. Equipment Assessment Model Definition


the definition of the semantic model is to describe the Assessment class, which contains a set of attributes


iId>: UniqueID

<name>: String



class EquipmentAssessment

EquipmentAssessment

Functionality(Equipment)

‐ SliderRanking: string

EquipmentAssessment

Quality(Equipment)


EquipmentAssessment

Performance(Equipment)


EnergyConsumption


Reliability

‐ MTBF: int‐ MTTR: int





The ranking will be based on the comments chosen by the operator as follows; Very Bad, Bad, Good, Very Good,Excellent

Assessment

‐ id: uniqueID‐ description: string‐ TimeStamp: Date/Time

isA

0..*1

isAisA

isA

isA

0..*

1

54

The process equipment assessment in openMOS is currently put into three main categories, which can be

expanded for future case studies and does not include under the current scope of the project. The details

of each of these elements are described in the following section.


This section provides the detailed attributes for the classes described in the previous section.

Table 66 – Assessment class attribute


id Unique ID of the assessment that is to be conducted.

Required UniqueID

name Name which can be chosen for the assessment that is to be conducted.

Optional String

description Open text description of the assessment which can also be used for documentation purposes.

Optional String

TimeStamp Date and time that should be recorded for the current assessment.

Required Date/Time

Table 67 – Equipment Assessment class attributes


EquipmentId Unique ID of the equipment module that is to be assessed.

Required UniqueID

Table 68 – EquipmentAssessment (Functionality, Quality and Performance) class attribute


SliderRanking The rank the user provides on assessing the equipment module.

Required String

Table 69 – Reliability Performance Assessment class attributes


MTBF The mean time between failures by which the performance of the equipment module is assessed.

Required int

MTTR The mean time to repair by which the performance of the equipment module is being assessed.

Required int

Table 70 – Energy Consumption Performance Assessment class attributes


Unit The unit in which the current assessment isbeing measured.

Required String

Value The value of the current assessment. Required Float

55

2.8.4. Process Assessment Model Definition


the definition of the semantic model is to describe the Assessment class, which contains a set of attributes


<Id>: UniqueID

<name>: String



The process assessment in openMOS is currently put into three main categories, which can be expanded



Figure 16 – Process Assessment Semantic Model

class ProcessAssessment

ProcessAssessment

Functionality(Process)


ProcessAssessment

Quality(Process)


ProcessAssessment

Performance(Process)

‐ SliderRanking: int



ExecutionTime




Repeatability


Accuracy


EnergyConsumption


Assessment

‐ id: uniqueID‐ description: string‐ TimeStamp: Date/Time

isA

isA

0..*

1

isA

isA

isA isA isA

0..*1

56




Table 71 – Assessment class attribute


id Unique ID of the assessment that is to be conducted.

Required UniqueID

name Name which can be chosen for the assessment that is to be conducted.

Optional String

description Open text description of the assessment which can also be used for documentation purposes.

Optional String

timeStamp Date and time that should be recorded for the current assessment.

Required Date/Time

Table 72 – Process Assessment class attribute


RecipeId unique ID of the recipe that is to be assessed Required UniqueID

Table 73 – Process Assessment (Functionality, Quality and Performance) class attribute


SliderRanking The rank the user provides on assessing the recipe.

Required String

Table 74 – Performance Assessment (Repeatability, Accuracy, ExecutionTime and EnergyConsumption) class attributes


Unit The unit in which the current assessment is being measured.

Required String

Value The value of the current assessment. Required Float

57

3. AutomationML Model

The self‐description provides all the physical and functional specifications of an equipment module for

the creation of a virtual entity, which will be a digital replica of that equipment module. In terms of ‘Plug‐

and‐produce’ devices, they should have embedded information about their process capabilities (Skills),

data that it gathers during the execution of the processes, and other information relevant to its

maintenance and diagnostics details. This is critical for Cyber Physical Systems (CPS), since these systems

would require an exact virtualization of actual physical entities to deliver their vision. In this direction,

AutomationML (AML) is viewed as the prime candidate to aggregate all the information of a physical entity

(electrical, mechanical, geometry, etc.) in a coherent structure that can be easily interpreted across

multiple engineering domains and tools.

An AML file can be an aggregation of several self‐descriptions of equipment modules, which can be used

to represent a hierarchical system or sub‐system. The information stored in this AML file can be used to

provide an overview of the same system in the cloud (cyber‐side), which precisely can display a list of

functional capabilities (‘skills’) that a workstation or an assembly cell can perform. This correlation

between the cyber and the physical sides can help the user to virtually design, simulate and evaluate

several management strategies. Therefore, the cyber representation of a physical system can help to

emulate via monitoring, event forecasting and optimisation based on the current and past data archives.

This needs to support the system integration and exchange of information throughout the several phases

of assembly system development such as: design, build, ramp‐up, production and change

(reconfiguration) phases.

Figure 17 – Overview of Self‐Description and Integrating System Information

58

One of the significant challenges in this respect is to formalise the structure of the self‐description concept

in way that it is compliant with existing sematic models targeting CPS. Another major challenge lies in the

aggregation of self‐descriptions, which can be of varying levels of system topology. It is important to note

that the self‐description includes the process capabilities of the equipment modules, but it does not

provide the information on how to execute these capabilities to realise a product. This will require several

links between the ‘Skill Requirements’ of the product and the actual execution information from the

equipment module’s ‘Skill Recipes’. Figure 17 provides an overview of the challenges with the integration

and mapping of information across the system. The self‐description files require relationships between

the Product, Process and Resource (PPR) domains as well as information related to equipment granularity.

3.1. Overview of AutomationML Libraries

The AutomationML language is a solution for data exchange focusing on the domain of automation

engineering [1]. AutomationML uses an XML schema‐based data format designed for the vendor

independent exchange of plant engineering information. An AutomationML file is basically divided into

four main parts:

Role Class Library, where the roles/types are defined;

Interface Class Library, where interfaces to link elements are defined;

System Unit Class Library, where user‐defined classes are set;

Instance Hierarchy, where instances of System Unit Classes are created.

Figure 18 – AutomationML Editor

In Figure 18 the default layout of the AutomationML Editor is presented with the specified numbering.

Figure 18 shows the four different tabbed windows. The tabbed windows are Instance Hierarchy, System

Unit Class Library, Role Class Library and Interface Class Library as described above.

59

To describe any manufacturing system, one needs to start by defining the Role Class Lib required for the

assembly system, interfaces required for linking the elements, define the System Unit Class and finally

create the instances. Figure 19 shows the flow of how to describe the system in AutomationML.

This section will focus on explaining Role Class Library, Interface Class Library and System Unit Class

Library. The Instance Hierarchy will be explained in the next section with an illustrative example.

As can be seen in Figure 20, there are two important role classes that define an openMOS system: the

AutomationMLBaseRoleClassLib, that comes from the default AutomationML file, and the

openMOSRoleClassLib, that is being defined specifically for the openMOS project.

There are also two interface classes: the AutomationMLInterfaceClassLib, defining default interface

connectors, and the openMOSInterfaceClassLib that defines specific connectors in the context of the

openMOS project.

In the System Unit Class Library, there is only one important System Unit class named

openMOSSystemUnitClassLib, where the basic classes from the UML model are mapped. Other classes

should be defined before instantiating a system, because it is important to define templates like modules

or workstations in the case that one needs to use more than one device.

Figure 19 – Flow of how to describe an AutomationML System

In the following sections, each specific part will be described. The detailed AutomationML file with the

current model of the system will be attached to this deliverable document, which should be useful to

follow through reading this chapter.

3.2. Role Class Library

The Role Class Library comprises role classes collected within role class libraries. A role class describes an

abstract functionality without defining the underlying technical implementation, thus, it has to be seen as

60

an indicator for the semantics of an object. This can be for example the role classes MechanicalPart and

Device indicating system structure semantics or LogisticalDevice and PhysicalDevice representing

communication system semantics [1].

AutomationML defines a set of basic role classes represented in Figure 20. There is the

AutomationMLBaseRoleClassLib with fundamental role classes defined in Part 1 of the AutomationML

standard [2].

Figure 20 – openMOS AutomationML file

Each AutomationML user can define new role classes following its use cases and needs for data exchange,

as defined in openMOS project. AutomationML only defines some rules for role class definition.

Each role class shall have a unique name within the role tree of a role class library. Thereby, it can be

uniquely referenced by this hierarchy path. In addition, each role class has to be derived directly or

indirectly from AutomationMLBaseRole by using the RefBaseClassPath attribute [1].

Each role class may have attributes and interfaces (explained in the next subsection). These attributes and

interfaces shall enable an importer of an engineering tool to interpret and process incoming information

correctly.

For example, the AutomationMLBaseRoleClassLib defines the role class Port, with its direction and

cardinality attributes, and openMOS project defines specific types of ports, as expressed in Figure 21. For

instance, PhysicalPort, ControlPort, among others. These user defined role classes inherit from the

AutomationML pre‐defined Port role class its attributes and interfaces. The same principle applies to the

other openMOS defined role classes.

In order to do a match between the AutomationML model and the UML model described above, one can

understand that this Port role class is related to the Port class defined in the Skill UML model. On the other

hand, the openMOS defined role classes for Parameter Port, Control Port and Information Port are related

to the ParameterPort, ControlPort and InformationPort classes respectively defined in the UML model.

61

Another port role class to take into account is the Physical Port which will match the PhysicalPort class in

the Equipment UML model. This physical port can have different sub‐roles as Equipment Port (divided

into Transport Port or Floor Port), Component Port, Fixture Port and Tool Port (Figure 22).

Figure 21 – AutomationML Base Role Class Library

Parameters are facets that can be divided into Atomic Parameter or Composite Parameter. Examples for

the first are Distance Parameter and Force Parameter. An example for a Composite Parameter is the

Position Parameter, which can be composed by x, y, z attributes. Along the evolution of the project, it is

normal that other parameters are defined.

The same principle is assumed for KPI’s. At this stage, ExecutionTimeKPI and EnergyUsageKPI are defined,

but others can be introduced along the project to map different needs.

Looking at the Equipment UML model and the Equipment Role class it is easy to understand the mapping.

A SubSystem can be either a Workstation or a Transport and then it is possible Modules, Frames, amongst

others. Each SubSystem has a TaskExecutionTable, which will have TaskExecutionAssignments, both

concepts are also mapped into the Role Class Library defined in the AutomationML.

62

Figure 22 – openMOS Role Class Library

63

Figure 23 – Skill Role Class

64

Regarding the Product UML model, the Product class maps directly with the Product role class described

in the AutomationMLBaseRoleClassLib (Figure 22). On the other hand, as defined in the UML model, a

Part can be a SubAssembly or a Component.

Finally, the Skills role class is obviously related to the Skill class in the Skill UML model. In the context of

openMOS, a Skill can be one of five types: action, operation, task, workflow, delivery method. A lot of

Action Skills, Operation Skills and Task Skills are already defined for the openMOS project, as illustrated

in Figure 23. The user should use the most well‐defined skill type that fits his needs, but others can be

defined along the project, similarly to other concepts.

3.3. Interface Class Library

The second modelling library defined in AutomationML is the Interface Class Library. An interface class

describes an abstract relation an element can have to other elements or to information not covered within

the CAEX based model [1].

AutomationML defines a set of basic interfaces represented in Figure 24. There are the

AutomationMLInterfaceClassLib with fundamental interfaces defined in Part 1 of the AutomationML

standard and the CommunicationInterfaceClassLib defined in the Part 5.

Figure 24 – Interface Class Library

65

Each AutomationML user can define new interface classes following its use cases and needs for data

exchange. AutomationML only defines some rules for interface class definition:

Each interface class shall have a unique name within the interface class tree of an interface class

library. Thereby, it can be uniquely referenced by this hierarchy path.

In addition, each interface class has to be derived directly or indirectly from

AutomationMLBaseInterface by using the RefBaseClassPath attribute.

Each interface class may have attributes. These attributes have to be used and filled with values

in each occurrence of an instance of the interface class.

3.3.1. Product Interfaces

Liaison Connector: the product to be assembled may contain one or more components that need

to be assembled to get one whole product or its sub‐assembly. In this sense, each of the

components will have one or more liaison connectors that allow them to be connected or

assembled with other components.

Precedence Connector: the product work flow requirements may have one or more assembly

tasks, which usually encapsulates several processes and actions. These operations should be

carried out according to their precedence requirements that come along with the work flow

requirements. The precedence connector is used to represent these sequences using a

directional connector. All the AML interfaces come with an ‘A’ and ‘B’ side connections, where

the ‘A’ represents the previous operation and the ‘B’ represents the current or selected

operation.

3.3.2. Process Interfaces

Requirement Connector: the ‘skill recipe’ fulfils ‘skill requirements’ and in this sense, the

requirement connector is used to express this mapping. In general, there is no need for a specific

direction for this connection, but in this work, for consistency purposes all the illustrations will

be directed from ‘skill recipe’ to ‘skill requirements’.

Event Connector: the execution of the ‘skills’ are always event‐based and in this sense, the event

connector will be a directional connector that is used to express the sequence of skill executions.

The scope of this work is limited to the design stage of the assembly systems and therefore, this

connector will not be used.

3.3.3. Resource Interfaces

Port Connector: all the assembly equipment will have one or more physical ports to establish

physical interfaces with other modules. The definition of ‘port’ includes its type, and therefore,

this connector is a non‐directional connector that is used to express the interface between two

types (e.g. male & female) of ports that belongs to two different equipment modules.

Material Flow Connector: in real time process execution, there is always a constant flow of

materials between workstations, which can be represented with a help of a directional

connector. This can also be helpful to trace the status of the product between workstations.

Communication Ports: the control elements of equipment modules may have one or more

communication ports. The scope of this work does not include the control commotions and

therefore, this interface will not be used in this work.

66

3.3.4. PPR Interfaces

PPR Connector: the main aim of AML is to provide complete information mapping across the

manufacturing domain. In this sense, each of the products should be linked to one or more ‘skill

recipes’ that are selected to complete its assembly tasks. The ‘skill recipe’ will be linked to an

equipment’s ‘skill’ via the reference base path attribute of AML. This is simply because the ‘skill

recipes’ are the instances of equipment ‘skills’. The equipment modules that are selected to fulfil

a product’s assembly should also be linked to that product.

3.4. System Unit Class Library

The third modelling library defined in AutomationML is the System Unit Class Library. System Unit Classes

can be considered as reusable system components or as templates for system modelling depending on

the point of view.

Usually they reflect either a vendor dependent library of components or devices or a set of templates

used within an engineering tool to structure discipline dependent model information.

Within the AutomationML standard there is no basic AutomationML System Unit Classes Library defined.

Thus, the definition of System Unit Classes libraries is up to the user of AutomationML. AutomationML

only defines some rules for System Unit Classes definition.

Each System Unit Class shall have a unique name similar to role classes and interface classes. It shall have

at least one role class assigned to it giving the System Unit class a semantic by using the

SupportedRoleClass sub‐element.

Each System Unit Class may have sub‐objects of the type InternalElement, attributes, and interfaces

representing the structure of the modelled class of objects, its properties, and its possible associations. In

addition, each System Unit Classes may be derived from another System Unit class by using the

RefBaseClassPath attribute. In this case it inherits all supported role classes, sub‐elements, interfaces, and

attributes from the parent element.

All modelling concepts may have attributes. Attributes are seen as properties which can be assigned to

role classes, interface classes, System Unit classes, and internal elements.

AutomationML defines some rules for attribute definition. Each attribute shall have a unique name within

its parent element. It may have a DataType and a Unit attribute and sub‐elements for description, default

value, value, and semantic referencing.

Figure 25 and Figure 26 describe the System Unit Classes defined for the openMOS project. From both

figures it is easy to understand the mapping with the Role Classes described above and consequent

relation with the UML model.

Parameters can be Atomic Parameters or Composite Parameters. Ports can be PhysicalPort, ControlPort,

ParameterPort, InformationPort or ProductFlowPort, as already described in the UML model. Equipment

can be SubSystem, Module or AssemblySystem. Part can be Assembly or Component. Skill can be

AtomicSkill or CompositeSkill. Requirement can be EquipmentRequirement, PartRequirement or

SkillRequirement.

67

Figure 25 – openMOS System Unit Class Library (1)

68

Figure 26 – openMOS System Unit Class Library (2)

69

3.5. Instance Hierarchy

The fourth and last modelling library defined in AutomationML is the Instance Hierarchy. It is the most

important part of an AutomationML file, as with its integrated hierarchy of InternalElements, it represents

the actual engineering data to be modelled by CAEX following an object oriented and hierarchical

structure [1].

The key pillar for the representation of actual engineering data is the InternalElement. It is the

representation of an object in the production system to be modelled. Depending on the level of

abstraction it can represent physical components like the complete plant, functional component as

machines and turntables, a device as a drive or a controller, or just a mechanical part as a conveyer belt

or a wire. Also, it can represent logical components like a PLC program, a product description, or an order.

InternalElements in the Instance Hierarchy are generally user defined. They can contain attributes and

interface instances derived from interface classes of any interface class library. They can reference a

System Unit class from an arbitrary System Unit class library by using the RefBaseSystemUnitPath

attribute. This reference will identify the corresponding System Unit class as the parent class the

InternalElement is derived from and, thereby, name the System Unit class as template for the

InternalElement. This will lead to the fact that the InternalElement shall have the same substructure,

interfaces, and attributes as defined in the System Unit class. In addition, the InternalElement shall

reference at least one (but possible more than one) role class from an arbitrary role class library.

Therefore, the RoleRequirements and the SupportedRoleClass sub‐objects shall be applied. The

referenced role class will define the semantics of the InternalElement. The structure an InternalElement

is depicted in Figure 27.

Figure 27 – Simplified Structure of an InstanceHierarchy [2]

An instance of a System Unit class can be simply created by drag‐and‐drop of the object from the

SystemUnitClassLib to the InstanceHierarchy and select Create Instance from the dialog box. Then, one

should define the role, by drag‐and‐drop from the RoleClassLib. Specific values for the attributes can then

be specified if necessary.

3.5.1. Instantiation of Assembly Equipment

70

Equipment modules are the basic building blocks of the assembly system. As previously mentioned, the

equipment module can be instantiated either from the openMOS System Unit class library or from the

case specific predefined equipment class provided by the equipment supplier or the vendor who is

currently using them. Instantiation is carried out by a simple drag‐and‐drop functionality into the instance

hierarchy. It is important to note that, when instantiating a System Unit class from scratch, appropriate

role classes and interface classes should be assigned to the specific instance. The process gets a little

easier when instantiating a vendor supplied role class for specific equipment modules. For a hierarchical

system, it is necessary to create instances (e.g. equipment modules) under an instance (e.g. assembly

system), which is considered to encapsulate the other in the system view point.

Figure 28 – Overview of a simple Instantiation of an Equipment

Figure 28 provides an overview of a simple instantiation of an equipment module under the instance

assembly system, which provides the hierarchy for a basic assembly system. It is also important to note

that an instance can have one or more role class assignments, but only one role class can be assigned as

a role requirement. This assignment should describe the best intension of that specific instance. It is also

possible to create a System Unit class that represents the hierarchy of a sub‐system that encapsulates one

or more equipment modules. Figure 29 shows an illustration of creating a System Unit class called ‘Virtual

Gluing Station’, which has instances of ‘Robot’, ‘Gripper’ and ‘Dispenser’ Classes. The instantiation of the

System Unit class ‘Virtual Gluing Station’ into the instance hierarchy provides all its inheritance.

71

Figure 29 – Overview of Instantiating a Sub‐System

3.5.2. Instantiation of Recipes for Assembly Equipment

As mentioned earlier, the recipe is an instantiation of a skill, and there can be one or more recipe

instantiations from a skill that exists in the System Unit class library. The instantiation is done by a simple

drag‐and‐drop functionality into the desired equipment destination. Since the instantiation is a manual

process, it is necessary to make sure that the desired parameter settings and KPI forecasts are entered

manually in the appropriate placeholders in the attributes tab. The recipe parameters can be found under

the parameter port, and similarly, the KPI’s can be found under the information port as shown in Figure

30.

Figure 30 – Overview of Recipe Instantiation

72

3.5.3. Instantiation of Execution Tables for Sub‐Systems

The task execution table holds the details regarding the list of products and their relevant processes that

are to be executed in a specific sub‐system. It is important to note that the recipes represent the

processes, and a product’s skill requirement can be fulfilled by one or more recipes. This means that it is

possible that there can be more than one alternative for executing a product’s skill requirement in that

specific sub‐system. The instantiation of the execution table can be done by a simple drag‐and‐drop

functionality into the desired sub‐system. The user should manually instantiate as many number of lines

that are required to iterate all the product’s skill requirements and recipes for the specific sub‐system. It

is important to note that each of the columns in the task execution line should have a mirror image of the

respective products and the corresponding recipes. Also, only a decisional skill recipe will have entries for

the column ‐ ‘list of possible recipe choices’ in the task execution lines as shown in Figure 31.

Figure 31 – Overview of Execution Table Instantiation

3.5.4. Establishing Interface Relationships for Instances

After completing the process of instantiating the appropriate System Unit classes, it is necessary to

establish the necessary relationships and dependencies between the concepts, which is one of the main

intensions of using AML. This is done by linking the appropriate interface ports, which may be a directional

link such as the precedence relationships between the product’s skill requirements. The physical

connection is one of the more logical connections that can be done after completing the instantiation

process. This can be achieved by connecting the male port (physical port) of an equipment module with

the female port (physical port) of another equipment or vice versa. It is important to note that all the

physical connections are one to one connections. The precedence relationships between the skill

requirements is also an important link that needs to be established to ensure the sequential flow of

assembly processes. This is done by connecting the A‐side precedence link of a skill requirement to the B‐

side of its preceding skill requirement as shown in Figure 32. As mentioned earlier, the recipes fulfil the

skill requirements, which is one of the most important relationships that needs to be mapped into the

AML file. In this sense, each of the products should be linked to one or more ‘skill recipes’ of the

equipment modules that are selected to complete its assembly tasks. This is achieved by connecting the

requirement port connector links between the skill requirement and the recipe. The ‘skill recipe’ will be

linked to an equipment’s ‘skill’ via the reference base path attribute of AML. This is simply because of the

reason that the ‘skill recipes’ are the instances of equipment ‘skills’. The equipment module that is used

73

to fulfil a product’s skill requirement should be linked via the product connector. The link between

equipment that executes the skill recipe should be established via the resource connector as shown in

Figure 33.

Figure 32 – Overview of Precedence Connection in AML

Figure 33 – Overview of Establishing PPR Relationships in AML

74

4. Illustrative Example

4.1. Overview

The illustrative example is based on the MASMEC demonstrator setup D6.1 (specification of IDEAS system

adaptation for openMOS), which represents a closed loop production line as shown in Figure 34. The

setup consists of several stations such as: a manual loading station, two twin leak test stations, a manual

unloading station, a gluing station and a shaker station. These stations are linked with each other by

means of transport systems namely: Transport1, Transport2, Transport3, Transport4 and Transport5.

Each of these transport systems is made of one or more conveyors and junction modules. The conveyors

are used for linear transport and junctions are used to choose the path between any of the two conveyors

ahead. The product used for the illustration purposes is like a container which needs to be tested and

assured that it is leak proof. The product enters the production line through the manual loading station

and exits via the manual unloading station. The product can be tested for leaks either at Leak‐Testing

Station1 or at Leak‐Testing Station2 depending on the demand or product volume. In this sense, Junction1

will mainly be used to route the product between the two leak testing stations. If the product passes the

leak test, Transport2 and Transport3 will route the product to the manual unloading station to exit the

production line. If the product fails the leak test, Transport2 and Transport3 will route the product to the

Gluing Station, where the leak spots will be sealed via a special gluing operation. Subsequently, Transport4

routes the product to the Shaker Station, where the product will be handled to dehydrate the glue.

Afterwards by means of Transport5, the product re‐enters the production line and follows the same loop

until the product passes the leak test.

Figure 34 – Overview of the MASMEC Production System

4.2. Product’s Assembly Requirements

The product’s assembly requirements include a list of skill requirements that follows a specific sequence

(precedence) starting from the entry and until the product exits the production line. The skill execution

model is designed in such way that the assembly product requirements can accommodate optional

75

sequences based on the output result of the decisional skill. Here, the leak test skill requirement is a

decisional skill, which on the execution side can provide a Boolean value as an output result. Therefore,

the product’s assembly requirements are designed in such way that it can accommodate the possible

operational sequences, in the event of either failing or passing the leak test. Likewise, the possible

sequences after the leak test requirement is highlighted in two different colours (red and green) as shown

in Figure 35. The requirement sequences highlighted in red colour indicates the operations that are to be

followed if the product fails the leak test, while the green colour represents the sequences of the product

passing the leak test. Also, the requirements highlighted in red colour follows a loop, which ensures that

the product will not exit the production line without passing the leak test as shown in Figure 35.

4.3. Assembly Equipment Specification and Skills Representation

The main aim of using AML for equipment module description is to provide a standardised platform, and

to hold all the engineering information in a single file. This makes it easier for other stakeholders involved

in the project to interpret and understand the complex information that are integrated into a single file.

Additionally, one of the main aims of this work is to deliver agile systems without compromising system

performance. The basic enabling feature towards this end is the Plug‐and‐produce capability of the

devices, which may have embedded information about their process capabilities (Skills), data that it

gathers during the execution of the processes, and other information relevant to its maintenance and

diagnostics details. In simple terms, when a device is plugged into the system, it needs to provide

information to other devices or tools which are present in the system. This means that the device needs

to have a mechanism to broadcast its description, process capabilities and control features. The self‐

description file should include all this information in a clear and transparent format that facilitates the

dynamic and easy interpretation of information. This needs to support the system integration and

exchange of information throughout the several phases of assembly system development such as build,

ramp‐up, production and change (reconfiguration) phases.

The concept ‘Skill’ is categorised into ‘Atomic Skill’ and ‘Composite Skill’. For instance, ‘Pick and Place’ is

a composite skill encapsulating three atomic skills, which can be defined as: ‘hold’, ‘move’ and ‘release’.

For simplification, any skill which cannot be broken down is classified as atomic. Figure 35 shows all the

sub‐systems that the MASMEC system comprises of, and the corresponding skills that belongs to each of

those sub‐systems. For easy identification the atomic and composite skills are colour‐coded in Figure 35

as dark green and light green respectively. Similarly, the recipes corresponding to specific skills are

represented in orange colour. It is also important to note that the recipes are generated in such a way

that they hold the details regarding the skill requirement that they fulfil and the skill that executes it. In

this sense, the skill recipes can be mapped with the product’s skill requirements as shown in Figure 35.

4.4. Assembly Process Specification

The formalised model developed within openMOS enables ‘plug‐and‐produce’ via the analysis of the

relationships between the core concepts, such as ‘Skill’, ‘Skill Requirement’ and ‘Skill Recipe’, with an

underlying common concept of ‘Skill Type’. The next step details the base for system operation by defining

how the ‘Skill’ can executed to fulfil a ‘Skill Requirement’.

Figure 35 – Overview of Mapping Product Requirements with the Assembly Equipment’s Recipes

77

The ‘Skill Requirements’ enable the formalisation of the product, or other equipment’s, needs and

business objectives. Both of these concepts need to share a common ‘Skill Type’ if automatic matching

between them is expected. The creation of ‘Skill Recipe’ establishes the traceability between these two

concepts, and formalises the necessary parameters for the execution of ‘Skills’. This is particularly

important in real systems, as these tend to be tweaked in the ramp‐up stage, until the system is setup for

production.

In AML, the Skill Recipe is an instantiation of a Skill with specific ‘Parameter Settings’ that can fulfil one or

more ‘Skill Requirements’. The ‘Composite Skill’ concept provides the means to deal with varying degrees

of process granularity. The proposed model takes advantage of the already defined ‘Skill Requirement’ to

establish higher level compositions, which can be fulfilled by lower level ‘Skill Recipes’. It is important to

note that there can be multiple Skill Requirements for each Skill Recipe. Figure 36 illustrates how the

product’s requirements are matched with an appropriate ‘Skill Recipe’ that has a specific ‘Parameter

Setting’, and how the Skill Requirements of the composite skills are fulfilled by other ‘Atomic Recipes’.

And finally, the ‘Skill’ executes the ‘Skill Recipe’ when the appropriate ‘Control Port’ is triggered by the

arrival of the product to the specific workstation.

The illustration provided for this case is a gluing application, where the gluing workstation (sub‐system)

consists of a robot, gripper and a glue dispenser as shown in Figure 36. The robot has two skills: one is an

atomic and the other is a composite skill for simple and complex handling tasks. The simple atomic skill

for handling has four recipes with different parameter settings. Similarly, the composite handling skill has

two recipes with two skill requirements each. These skill requirements are fulfilled by the robot’s atomic

handling recipes that is similar to the concept as described in the previous paragraph. The gripper has two

atomic skills and recipes for enabling pick and drop functionalities respectively. The dispenser has a simple

atomic skill and recipe for glue dispensing. Since the gluing workstation is a collective representation of

all the above individual equipment modules, it is good to take the opportunity of defining composite skills

that can have recipes with appropriate settings that can fulfil higher level product’s skill requirements.

Here, the gluing station has two composite skills such as: frame gluing and raster gluing, and each of them

includes five skill requirements. This skill requirements are fulfilled by the recipes that belongs to the

robot, gripper and dispenser as shown in Figure 36.

4.5. Execution Tables for Sub‐Systems

The task execution table holds the information related to the list of products and their relevant processes

that are to be executed in a specific sub‐system. It is important to note that the recipes represent the

processes that can fulfil specific product’s skill requirements. This means that there can be more than one

recipe that can fulfil a product’s skill requirement. It is important to note that, the execution tables can

only include recipes that are validated by the operator before the actual process execution.

Figure 36 – Overview of Mapping the Skill Requirements of the Composite Skills

79

The openMOS system is designed in such a way that the production schedule (execution tables) can be

optimised by the openMOS cloud services based on the present status of the physical system. In this way,

whenever there is a change (physical/ logical) in the system, the cloud platform analyses the status of the

available resources and provides an optimised production schedule. If the cloud environment gets

unavailable, then it means that the cloud‐based services such as: the assembly process optimisation and

other historical records are being temporarily unavailable.

It is also important to note that the openMOS system is designed in such a way that the system will

continue to operate even without the support of the cloud environment. The AML’s requirement

connectors highlight the link between the list of possible recipes that can fulfil a product’s skill

requirement. This means that the Manufacturing Service Bus (MSB) can find alternative recipes to fulfil

the product’s skill requirements. It is also important to note that the openMOS system continues to

operate even without the cloud services, but there is no guarantee that the production schedules are

optimal.

In the current illustrative example, once the product is launched into the MSB, all the possible recipe

choices for fulling the product’s requirements can be realised via the AML interfaces (Requirements

Connector ‐ PPR). It is also important to note that at any instance of time there can be only one recipe

selected to fulfil each skill requirement. This has been implied in Figure 37 by colour coding the chosen

recipes in green colour. Subsequently, the MSB will execute the assembly processes according to the task

execution table specifications that is available under each sub‐system in a sequential order as shown in

Figure 37.

If an equipment module or a sub‐system is unplugged from the system, then all the corresponding recipes

that belong to this equipment get unavailable as well. In this case, as mentioned earlier, the MSB can

realise that an equipment has been unplugged, and an alternative equipment that has a similar recipe can

be used to fulfil the same skill requirement. This is implied by updating the task execution tables for all

the sub‐systems, whenever the system undergoes a change. It is important to note that if the openMOS

cloud services are available, then the MSB will inform the cloud regarding the latest changes and

subsequently, the cloud can provide an optimal production schedule that best fits the current state of the

system.

Figure 37 – Overview of Product Deployment and the Usage of Task Execution Tables

81

5. Conclusion

This document builds on the deliverable D3.3 (Assessment of the current Semantic Model Technologies),

which provided the assessment for semantic technologies, as well as on the preliminary working model

for the openMOS project.

In this deliverable the preliminary model was tweaked and finalised to include all the necessary elements

required for the operation of the openMOS tools. This meant changes in the core elements as well as full

enhancements which cater for the specificities of some tasks. The resulting models provide the necessary

definitions for the architectural constructs that enable the plug‐and‐produce in a structured manner. This

includes the definition of production facilities (equipment), processes and the corresponding information

models. Collectively these models establish the mechanisms for collecting useful information from the

hardware infrastructure developed in WP2 and ensure that the information can be used across the system

via the open plug‐and‐produce Manufacturing Service Bus.

In addition, this document describes the use of AutomationML as the standard used for semantic

encapsulation of information that governs the communication content for plug‐and‐produce

components. This includes the detailed description of the implementation of the semantic models in

AutomationML. The use of AutomationML supports the system integration and exchange of information

throughout the several phases of assembly system development such as design, build, ramp‐up,

production and change (reconfiguration) phases. Critically, the use of AutomationML also provides the

ability for the model to be used and extended by other multiple engineering tools, as this is a key

characteristic of AutomationML.

For clarity, this document also provides an illustrative example, using the MASMEC demonstration case

D6.1 (specification of IDEAS system adaptation for openMOS), with detailed information of mapping

between the concepts and dependencies that are described in the semantic models.

Finally, it is important to note that the semantic models are already being used by the project partners to

develop, deliver and demonstrate various project objectives. Nevertheless, this is a model that is expected

to be enhanced continuously to cater for other challenges in this domain.

6. References

[1] AutomationML e. V., “Whitepaper AutomationML Part 1 – AutomationML Architecture State : May 2012,” no. May, pp. 1–80, 2012.

[2] D. N. Schmidt, “AutomationML in a Nutshell,” no. November, pp. 1–46, 2015.

Documents

Deliverable: D3 - openMOSAddress Wolfson School of Mechanical and Manufacturing Engineering ... The elements and expected operation of system are detailed in D3.1 (Open Plug‐and‐