Plug-and-Produce based on Standardized Industrie 4.0 Asset Admin Shells

AUTOMATION 2017, JUNE 28TH, 2017

Plug-and-Produce based on Standardized Industrie 4.0 Asset Admin Shells

Dr.-Ing. Heiko Koziolek, Senior Principal Scientist, ABB Corporate Research, Ladenburg, DE

Plattform Industrie 4.0 Application Scenario

Adaptable Factory and Plug&Produce Vision

Found newModule!

“[…]

A new network-enabled field device, for example a drive with a new version of firmware, is hooked up to the production line.

The new device must be provided automatically with network connectivity and be made known to all online subsystems.

The participating systems must correspondingly be updated.

[…]“

Using Asset Administration Shells?

Plug&Produce for Industrie 4.0 Components

December 15, 2017 Slide 3

Asset Admin Shells for Plug & Produce

Problem Statement


How shall the information in an AAS be structured?

What properties are required for Plug&Produce devices?

What services are required for Plug&Produce devices?

Which technologies can support the scenario?

Which standards enable vendor-neutral Plug&Produce?

Where are standardization gaps?

Open Questions

Simple Example: Temperature Transmitter

Related Work


Selected Industry Initiatives:

FDI (Field Device Integration)

FDT/DTM, FDT/OPC UA

NAMUR Module Type Packages (for Package Units)

Selected Academic Works:

Krüning & Epple (2013): Exploration agent for PROFINET IO Devices

Reinhard et al. (2015): Unified PnP architecture for field devices

Jasperneite et al. (2015): PnP in Smart Factory OWL

Smart Factory DFKI

Plattform I40 Demonstrator

1) Plug & Produce Use Case Specification

2) Asset Admininstration Shell Model

3) Interactions based on the Model for Plug & Produce

4) Technology Mapping OPC UA Device Interface

5) Technology Mapping MQTT

6) Prototypical Implementation

7) Used Industry Standards and potential Standardization Gaps

Agenda


Using IEC 62559-2 Use Case Template

Plug & Produce Use Case Spec


uc Plug and Produce for Field Dev ices (Use Case View)

System Boundary

Integrate Dev ice

1. Connect dev ice

physically

2. Discov er dev ice

3. Establish basic

communication4. Assess capabilities

5. Configure dev ice

6. Integrate dev ice

into production

Dev ice

Management

Serv er

Intelligent Field

Dev ice

Controller

Commissioning

Engineer

Plant Operator

Validation Authority Authentication

Serv er

Network Configuration

Serv ice

Process Control

System HMI

Process

Engineering Tool

«precedes»«include»

«include»

«include»«include»

«include»

«precedes»

«precedes»«precedes»

«include»

«precedes»

«invokes»«invokes»

Actors

Grouping Group Description

Actor Name see Actor List

Actor Type see Actor List

Actor Description see Actor List

Further information specific to this Use Case

Device Management Server

Application This application detects newly connected devices, assesses their capabilities, configures the devices, and sets them into an operational mode. Example: FDI Server.

IEC 62769-3 (FDI), IEC 62541 (OPC UA), IEC 62453 (FDT)

Intelligent Field Device

Device A field device can be an actuator or sensor. It is equipped with standardized communication capabilities and a self-description.

IEC 62541 (OPC UA), eCl@ss, NAMUR NE 131

Controller Device A controller can execute control algorithms based on sensor inputs and passes actions to actuators. It is equipped with standardized communication capabilities and a self-description.

IEC 62541 (OPC UA)

Network Configuration Service

Service The network configuration service provides IP addresses, network masks, gateway information and naming services for its clients.

RFC 2131 (DHCP), IEC 62541-12 (OPC UA Discovery)

Validation Authority

Service Verifies the validity of a digital certi ficate. X.509, RFC 5280 (Public Key Infrastructure)

Authentication Service

Service A central database that can verify user tokens provided by clients. It may also tell servers what access rights the user has. The authentication service depends on the user identity token. It could be a certificate authority, a Kerberos ticket granting service, a WS-Trust Server or a proprietary database of some sort.

IEC 62541-4 (OPC UA)

Process Engineering Tool

Application The application provides configuration data for a plant, which may include specific configuration parameters for field devices.

IEC 62424 (AutomationML), NAMUR NE 150, Whitepaper “AutomationML and eCl@ss Integration”, VDMA-Einheitsblatt 66415

Process Control System HMI

System Hardware/Software system that visualizes operator screens to supervise an industrial process.

Commissioning Engineer

Human Responsible for the installation and commissioning of an automation system.

Plant Operator Human Supervises the operation of an industrial plant via the Process Control System HMI.

http://www.plattform-i40.de/I40/Redaktion/EN/Downloads/Publikation/Industrie-40-%20Plug-and-Produce.html

Industry 4.0 goals:

Industrial assets become „Industry 4.0 Components“ that provide data and services via standardized interfaces

An Asset Administration Shell exposed data and services to other Industry 4.0 components

To implement a Plug-and-Produce scenario with „Industry 4.0 Components“ a formal specification for AAS is required. Such a specification does not exist by now.

The following specification is only one possibility for such a specification.It defines the AAS conservatively around existing standardsand introduces as few new concepts as needed.

Some concepts in the following AAS model (e.g., references) are not required for Plug-and-Produce, but may be needed for other usecases.

Considerations

Asset Administration Shell Modeling


UML Model

Asset Adminstration Shell


class I4.0 Component and System

I4.0 System

I4.0 Component

DIN 40912

Automation Asset Class

Service System Participant

Asset Administration Shell

Asset +represents

0..1 0..*

1..*

0..*

1..*

0..*

0..*

1..*

class AdminShell


«DIN 91345»

Asset

Administration

Shell

«IEC62832»

Collection of Data

Elements

Collection of

Serv ices

«IEC62832»

Header

«IEC62832»

Body

«IEC62832»

Data Element Serv ice

«IEC62832»

View

View

Specification

Serv ice

Specification

Property

Specification

IEC62541-4

MQTT, DDS, CoAP, ...IEC 62382

IEC 81345eCl@ss

IEC61987

STEP

«IEC62832»

Reference

references

1

0..*

0..*

0..*

0..*

1

1

0..*

references

1

0..*

1..*

0..*

0..*

uses

0..*

0..*

0..* 0..*

0..*

0..*

references

1

1..*

0..* 0..*

UML Model

Asset Adminstration Shell Examples


object PnP Asset Admin Shells

Dev ice Management

Serv er AAS :Asset

Administration Shell

:Communication Serv ices

+ Connect() :int

+ GetRequiredSecurity() :int

+ DiscoverHost() :int

:Body

Intelligent Field Dev ice AAS :Asset


:Body

NAMUR Core Parameters :

Collection of Properties

- ProcessValue :string

- ProcessUnit :string

- UpperRangeValue :float

- LowerRangeValue :float

eclass 27-20-02-06

Temperature transmitter :

Collection of Properties

- Height :float

- MaxMeasurementError

- Lenght :float

Controller AAS :Asset


:Information

Serv ices

+ Browse() :int

+ Read() :int

+ Subscribe() :int

+ Write() :int


+ Connect() :int


:Reference

:Body


+ Connect() :int


+ DiscoverHost() :int

74 eCl@ss

properties

in total

24 NAMUR core

parameters in

total

UML Model

Interaction of Asset Adminstration Shells (Example)


sd Plug and Produce for Field Dev ices (Dynamic View)2

Device Management

Server AAS :Asset


Controller AAS :Asset


Intell igent Field Device AAS :


Process Engineering

Tool AAS :Asset

Adminstration Shell

Process Control System

AAS : Asset


loop loop

loop

loop

Overwrite default

parameters with desired

configuration.

May require human

approval.

Controller is

continuously looking for

new sensors to integrate.

Operator in the Process

Control Systems gets

notifies about the new

sensor and gets a list of

its properties.

Automatic subscription

to a default value.

The Device

Management Server

is continuously

looking for new

devices to integrate.

e.g., read all standardized

properties found

opt

1.0 SendConfig(ConfigData)

1.1

DiscoverHost()

1.2

DiscoverHost()

1.3 Get IP Address()

1.4

Announce()1.5

Announce()

1.6 Check Identity()

1.7 Get Required Security()

1.8 Connect()

1.9 Read(Default Parameters)

1.10 Merge(ConfigData,

DefaultParameters)

1.11 GetApproval()

1.12 Write(Device Parameters)

1.13 Check Identity()

1.14 Get Required Security()

1.15 Connect()

1.16 Browse()

1.17 Read(Properties)

1.18 Write(Properties)

1.19 Subscribe(Temperature Value)

1.20 Publish(Temperature Value)

1.21 Publish(Termperature Value)

Technology Mapping: AAS <-> OPC UA Device Interface (IEC 62541-100)


Device Type (from IEC 62541-100) Comments

Header ↔ Object (ParameterSet) Functional Group Type "Identification"

Data Element (ManufacturerId) ↔ Variable(ManufacturerId) Only example in IEC62541-100

Data Element (ModelId) ↔ Variable(ModelId) Only example in IEC62541-100

Data Element (SerialNumber) ↔ Variable(SerialNumber) Only example in IEC62541-100

Data Element (<ProfileId>) ↔ Variable(<ProfileId>) Only example in IEC62541-100

Data Element (SecurityClass) X Could be mapped to a Parameter

Body X No corresponding element in IEC 62541-100

Collection of Data Elements (Device Parameters) ↔ Object (ParameterSet)

Data Element (<ParameterIdentifier>) ↔ Variable (<ParameterIdentifier>) A number of parameters can be specified here

Collection of Data Elements (Device Properties) X No corresponding element in IEC 62541-100

Data Element (SerialNumber) ↔ Variable (SerialNumber)

Data Element (RevisionCounter) ↔ Variable (RevisionCounter)

Data Element (Manufacturer) ↔ Variable (Manufacturer)

Data Element (Model) ↔ Variable (Model)

Data Element (DeviceManual) ↔ Variable (DeviceManual)

Data Element (DeviceRevision) ↔ Variable (DeviceRevision)

Data Element (SoftwareRevision) ↔ Variable (SoftwareRevision)

Data Element (HardwareRevision) ↔ Variable (HardwareRevision)

Data Element (DeviceClass) ↔ Variable (DeviceClass)

Data Element (DeviceHealth) ↔ Variable (DeviceHealth)

Collection of Data Elements (Device Support Information) X No corresponding element in IEC 62541-100

Data Element (DeviceTypeImage) ↔ Object (DeviceTypeImage)

Data Element (Documentation) ↔ Object (Documentation)

Data Element (ProtocolSupport) ↔ Object (ProtocolSupport)

Data Element (ImageSet) ↔ Object (ImageSet)

Collection of Services ↔ Method Set

Service (<MethodIdentifier>) ↔ Method (<MethodIdentifier>) A number of methods can be specified here

Service (Lock) ↔ Lock Locking specifies additional services

View (<GroupIdentifier>) ↔ FunctionalGroupType (<GroupIdentifier>)

View (Identification) ↔ Identification

Reference X No corresponding element in IEC 62541-100

AAS

Good match between generic AAS model and OPC UA DI concepts.

Technology Mapping: AAS <-> MQTT


MQTT Comments

Header ↔ /aas Id/header

Data Element ↔ /aas Id/header/Data Element Id

Body ↔ /aas Id/body

Collection of Data Elements ↔ /aas Id/body/Collection of Data Elements Id

Data Element ↔ /aas Id/body/Collection of Data Elements Id/Data Element Id

Collection of Services X

Service ↔ Custom HTTP service (GET/PUT)

View X Use topic filters to emulate or define

new topic referencing other topics

Reference ↔ /aas Id/body/references/

AAS

MQTT mapping is feasible and would require additional HTTP services.

Applying the AAS Model and OPC UA

Plug-and-Produce Prototypical Implementation


sd PnP for Field Dev ices (Dynamic / OPC UA)

FDI :

OPC UA

Server

FDI :

OPC UA

Client

FDI :Local

Discovery

Server

TT :

OPC UA

Server

CTRL :

OPC UA

Server

CTRL :

OPC UA

Client

CTRL :Local

Discovery

Server

:Validation

Authority

:Authentication

Service

PCS :

OPC UA

Server

:DHCP

Server

ref2. Discov ery

ref3. Basic Communication

ref4. Capability Assessment

ref5. Configuration

ref6. Integration

ref1. Physical Connection

sd Capability Assessment

FDI :OPC UA

Client

TT :OPC UA

Server

opt dev ice ID known

Require

conventions

The ID in the device header

refers to a certain device type

(e.g., eCl@ss 27-20-02-06

Temperature Transmitter). In this

case it is assumed that the FDI

node knows this type and can

start configuring the device.

Afterwards, the capabilities

of the temperature

transmitter are known to

the FDI node.

1.0 Browse(AAS Header)

1.1 Read(AAS Header)

1.2 :AAS Header

1.3 check device ID()

1.4 Browse(Device Parameters)

1.5 :Node

1.6 Call(ReadDeviceParameters)

1.7 :Device Parameters

Device: ABB TTH 300 Temperature Transmitter, preconfigured with tag name

Device AAS: OPC UA Server (Prosys OPC UA Java SDK), hosted on Raspberry Pi single-board computer

Device Management AAS: self-coded mock-up

Applying the AAS Model and OPC UA



deployment PnP for Field Dev ices (Static Component / OPC UA)

FDI Node

Ethernet

DHCP Serv erFDI Node AAS: Asset


«executionEnviro...

Raspberry Pi

TT AAS: Asset

Admiinistration

Shell

«execut...

Termparture

Transmitter

ABB TTH300

GPIO

Standards & Evaluation



Standard / Norm Purpose Evaluation

IEC 62541 (OPC UA) Basic communication services, informationmodels

Much more powerful than required forsimple PnP scenario

RFC 2131 (DHCP) Retrieval of IP address for basic connectivity Requires DHCP server administration

RFC 6762 (mDNS) Automatic discovery of OPC UA Server after physical connection

OK for local networks

IEC 62769-3 (FDI) Standardized device model, backwardcompatbility to existing EDDs

Useful structure, aligned with OPC UA, interoperable

IEC 61360, eCl@ss Procurement and engineering data tosupport comissioning

Supports device replacement well, canbe used in cross-vendor scenarios

IEC 62714 (AutomationML) XML format for engineering data Generic container for engineering

NAMUR NE 131 Device core parameters for commissioning(i.e., for sensors)

Useful subset for PnP, but onlyavailable for sensors so far

NAMUR NE 150 Data structure for engineering data Useful to match pre-config data

Plug-and-Produce based on Standardized Industrie 4.0 Asset Admin Shells

Summary + Next Steps


Summary:

• Defined use case specification for PnP (IEC62559-2)

• Created detailed conceptual AAS Model in UML

• Mapped AAS Model to different technologies (OPC UA, MQTT)

• Prototypically implemented PnP Scenario

Potential Next Steps:

• Map Profibus PA Profile to IEC CDD for more comprehensive standardized device descriptions and configuration

• Analyze integration of more complex sensors, actuators and controllers for PnP

• Create an open repository for certified device descriptions (-> FieldCom Group)

• Assess PnP potential for Modular Automation

Found newModule!

class AdminShell


«DIN 91345»

Asset

Administration

Shell

«IEC62832»

Collection of Data

Elements

Collection of

Serv ices

«IEC62832»

Header

«IEC62832»

Body

«IEC62832»

Data Element Serv ice

«IEC62832»

View

View

Specification

Serv ice

Specification

Property

Specification

IEC62541-4

MQTT, DDS, CoAP, ...IEC 62382

IEC 81345eCl@ss

IEC61987

STEP

«IEC62832»

Reference

references

1

0..*

0..*

0..*

0..*

1

1

0..*

references

1

0..*

1..*

0..*

0..*

uses

0..*

0..*

0..* 0..*

0..*

0..*

references

1

1..*

0..* 0..*


http://www.plattform-i40.de/I40/Redaktion/EN/Downloads/Publikation/Industrie-40-%20Plug-and-Produce.html