Use Cases for a CIP Companion Specification for OPC UA ... · Festo, Honeywell, Prosoft, Rockwell...

Use Cases for a CIP Companion Specification for OPC UA Frank Latino, Steven Roby, Ken Hopwood, Paul Brooks Festo, Honeywell, Prosoft, Rockwell Automation March 4, 2020

Abstract

2

The Common Industrial Cloud Interface (CiCi) SIG has determined that a key element of an overall solution is an OPC UA companion specification for CIP devices. To ensure that a CIP/OPC UA companion specification meets the requirements of both ODVA members, and of users of CIP technologies the CiCi SIG is now refining those requirements This paper explores the user stories and use cases against which that OPC UA companion specification shall be developed. It recaps the work done in the CiCi SIG and benchmarks it against the Device Integration model best practices inside OPC Foundation. It will take advantage of some of the recent lessons learned within OPC Foundation that are being addressed in their Harmonization Working Group and will propose a harmonization model that will allow CIP Technologies to integrate seamlessly with the latest OPC UA specifications

Technical Track 2020 Industry Conference & 20th Annual Meeting www.odva.org © 2020 ODVA, Inc. All rights reserved.

Conclusions

3

There is a compelling case for generation of an OPC UA companion specification for CIP to OPC UA Gateways, based on the assumptions: •  the cloud interface will use an OPC UA information model •  the cloud interface will use OPC UA transport mechanisms (MQTT, AMQP or HTTPS) •  the cloud interface will use OPC UA defined cybersecurity roles, authentication and

encryption Because: •  almost all of the functionality missing from CIP is available already in UA •  it is a far simpler task to enhance and integrate CIP using a companion specification, than

creating a competing approach from scratch. •  functionality which is missing from OPC UA is typically device centric functionality long-

standing in CIP specifications and ODVA core competency.


Recap – The 2017 Architecture

4 Technical Track 2020 Industry Conference & 20th Annual Meeting www.odva.org © 2020 ODVA, Inc. All rights reserved.

An updated reference architecture


Device 2

CIP Gateway (Field)

Analytics

Data Storage

On Premise

Public Cloud

CIP Interface Cloud Interface

Applications

Messag e Routing

CIP Network

...

Device 1

Device n

CiCi Scope

Security & Identity

Stream Processing

Device 2

Non-‐CIP Gateway (Field)

Non-‐CIP Interface

Cloud Interface

Non-‐CIP Network

...

Device 1

Device n

Device 2

Mixed Gateway (Field)

Non-‐CIPInterface

Cloud Interface

Mixed Networks

...

Device 1

Device n

CIPInterface

The old industrial automation value chain


The new industrial automation value chain


Meet the data scientist

8

Rarely engaged before operation of a plant •  May change Responsible for •  ongoing optimization of plant operations •  analysis of root causes of plant inefficiency. Harvest large datasets from plant floor operations Use statistical analysis and artificial intelligence tools •  identify previously unrecognized linkages and variances

in data values. •  work with subject matter experts to eliminate the sources

of these variants. Data Scientists will always prefer technologies which: •  Present information at source with context •  Require no other actors to extract that data from the plant •  Enable storage and analysis of that data using

commercial cloud technologies


Meet the Security Officer

9

No direct stake in production operations or technologies. Responsible for ensuring: •  no unauthorized access to production operations

•  outside hacker, •  inside bad actor •  former employee

• propagation of viruses (worms, malware, ransomware etc.) is restricted • reasonable measures are taken to ensure resilience against these threats.

They are responsible for the management of proprietary data entering and leaving facilities .


This Photo by Unknown Author is licensed under CC BY-‐SA-‐NC

The Security officer will typically assume that any cyber-‐security mechanisms will be breached and is also responsible for minimizing reputaConal damage when this occurs

We know the Controls Engineer

10

And the: •  Business Manager •  Drive Technician •  Engineering Director •  HMI Engineer •  Instrument Technician •  Maintenance Support •  Maintenance Technician •  Network Engineer •  Plant Manager •  Process Engineer •  Process Operator •  Product Developer •  System Commissioner


Optimizing Production Processes Our First Story


The Plant Manager and their Data Scientist Plant Manager wants to •  Optimize Production! Data Scientist needs to •  discover my assets •  and their associated devices •  useful data for analysis, •  query for the data they may contain. To this end it will be important to have a mechanism that will •  discover devices on the network (CIP) •  pull information on the data available •  form an information model to present to the

cloud.

The Device Vendor’s Business Manager and Data Scientist

13

As a Product Developer, I want to •  expose only data that are useful for optimizing the specialized asset •  Simplify experience for customers and plant operators. As a Business Manager at a Device Vendor, I want to •  enable my Data Scientist to be able to access •  some data from my assets, •  so specialists working at the Device Vendor can •  make recommendations that •  result in operational improvements


The Plant Manager and Security Officer

14

As a Plant Manager, I want to •  only expose data that will not disrupt the operation of my assets •  so that unnecessary downtime can be avoided. As a Security Officer, I want to •  guarantee that only authorized connections can be made •  only authorized devices can be discovered •  and authorized data can be read.


The takeaways

15

Native protocols of the devices in these use cases are not important to achieving the desired outcomes. In most operations, there are mixtures of vendors and protocols in use. What is important is enabling these actors to have access to data contained in their assets. The “shape” or context of the data is also very important to the value of the data. More context makes it easier to provide valuable insights. Data scientists use different tools that are aligned with cloud technologies,

largely due to the significant amounts of data storage and process power required. Technologies are evolving to be able to take advantage of computing power on the “edge.”


OPC UA Thin Slice and Companion Specifications


Evolving CiCi Charter – The Thin Slice

Thin Slice Functional Requirements

18

The premise of the CiCi working group is that Cloud vendors have “preferred gateways” that can be used by a “User” application to send data to/from cloud. Therefore the task of ODVA is to provide an <interface> that “User” applications could use with the following functions: •  Browsing / Discovery of CIP devices on the local subnet •  Provide Identity Object information from discovered CIP devices •  Provide Connected/Not-Connected status of any valid CIP device address •  Return an EDS file from the device, if it exists •  Return values of parameters that are defined in an EDS file •  Return values for parameters or assemblies as defined in a Device Profile


The Role of OPC UA

19

Focus on Vertical Integration Consumer is Compute and Software applications Designed to support •  on-prem and •  in-cloud applications Firewall friendly Devices at the Edge


OPC UA Device Model

20

the consumer of information used in devices is unlikely to have detailed knowledge of the field level protocols used in the interaction between controller and device. In April 2019, the Foundation published specification Part 100: Device Information Model to provide the harmonized interface called for to create the north side interface


Complementing EtherNet/IP with OPC UA


Capability Actor Story CIP OPC UA

Discovery from Cloud Data ScienCst 5.1 (✔) (✔) Human readable informa=on model in device

Data ScienCst 5.1 ✔

Discovery in plant Data ScienCst 5.1, 5.7, 5.8 (✔) (✔) Role based security Product Developer

Business Manager

5.1, 5.5 ✔

Gateway Func=on Process Engineer Controls Engineer

5.1, 5.2, 5.13, 5.14 (✔)

Common seman=c presenta=on of devices using varying protocols

Data ScienCst Controls Engineer

5.1, 5.2, 5.3, 5.4, 5.7, 5.8, 5.9, 5.14

(✔) (✔)

Device Level implementa=on Business Manager 5.2 ✔




Contextualiza=on Business Manager 5.2, 5.14 ✔ Granular Data Privacy Business Manager 5.2 ✔ Cloud supplier independence Business Manager 5.2, 5.14 ✔ Vendor specific informa=on model Business Manager 5.2 ✔ ✔ Firewall friendly Networks Engineer 5.2, 5.14 ✔ Data reads changeable in run-‐=me Data ScienCst 5.3, 5.7, 5.14 ✔ ✔ Cloud supplier pre-‐integra=on Data ScienCst 5.4 ✔ Automa=c model genera=on Data ScienCst 5.4, 5.14 Single in-‐plant security management Plant Manager 5.5, 5.14 End-‐end security Security Officer 5.5 (✔) No=fica=ons Maintenance

Technician 5.5, 5.12, 5.13 ✔




Asset Management Plant Owner Maintenance Technician

5.6, 5.13, 5.14 (✔)

Rich Iden=ty Maintenance Technician Security Officer

5.6 (✔) (✔)

Consistent Diagnos=c Model Maintenance Technician Plant Operator

5.9 (✔)

Common presenta=on of =me Maintenance Technician

5.9 ✔




Unified Alarming Maintenance Technician Plant Operator

5.9, 5.12, 5.13 ✔

IT Centric Security Plant Manager Security Officer

5.10, 5.11

IT Integrated Security Policy Management Plant Manager Security Officer

5.11, 5.14 (✔) (✔)

Security Audit Plant Manager Security Officer

5.11, 5.14 ✔

Automated Replacement of Devices Maintenance Technician

5.13 ✔

Conclusions

25

There is a compelling case for generation of an OPC UA companion specification for CIP to OPC UA Gateways, based on the assumptions: •  the cloud interface will use an OPC UA information model •  the cloud interface will use OPC UA transport mechanisms (MQTT, AMQP or HTTPS) •  the cloud interface will use OPC UA defined cybersecurity roles, authentication and

encryption Because: •  almost all of the functionality missing from CIP is available already in UA •  it is a far simpler task to enhance and integrate CIP using a companion specification, than

creating a competing approach from scratch. •  functionality which is missing from OPC UA is typically device centric functionality long-

standing in CIP specifications and ODVA core competency.


Date post:	17-Mar-2020
Category:	Documents
Upload:	others
View:	12 times
Download:	4 times

Use Cases for a CIP Companion Specification for OPC UA ... · Festo, Honeywell, Prosoft, Rockwell...

Documents