matrikon e-book dec 2018 beeond ...€¦ · © 2018 matrikon inc. & beeond, inc all rights...

© 2018 Matrikon Inc. & Beeond, Inc All Rights Reserved

Matrikon www.MatrikonFLEX.com

Beeond Incorporated www.Beeond.netE-Book Dec 2018

http://www.matrikonflex.com/http://www.beeond.net/


Why Switch and How to Do It

Table of Contents

Backgrounder 03

OPC UA versus Classic OPC 08

Introduction 09

Platforms & Scalability 10

Communications Transport 11

Information Modeling 12

Security 13

Integration Experience 14

End User Adoption 15

Vendor Adoption 20

Resources & Help 23

About Matrikon 26

About Beeond 27

About the Authors

OPC UA vs. Classic OPC

The provides easy to understand bite sized overviews on key OPC UA topics.

In this edition: Find out where Classic OPC came from, why OPC UA was needed, and how you can mix and match both technologies using the right tools and methodologies.

© 2018 Matrikon Inc. & Beeond, Inc All Rights Reserved 3

BackgrounderShop Floor Data Connectivity


Why Switch and How to Do ItOPC UA vs. Classic OPC

Shop Floor Data Connectivity Evolution

OPCUnifiedArchitecture

Approximately15 yearsafter OPCcameto be, industry experts from OPC

Foundationworkinggroupscrafted the next generationcommunicationand

interoperabilitystandardaptlynamedOPCUnifiedArchitecture(OPCUA).

Combiningthe lessonslearnedfrom the classicOPCstandardandsometruly

visionaryforesightasto what control automationwould neednot just in the

present but in the future, OPCUA was designedas a open, secure,OS

agnostic,and extendablestandardthat couldadaptassecurity,connectivity,

anddatamodelingrequirementschangedovertime.

Thevalueof this approachwassoonprovenwhenthe IoTerasprungto life a

few years later and OPC UA was quickly identified as the key data

interoperability standard robust and secure enough to be used as the

foundationfor IndustrialIoTapplications.

Interconnectivity difficult & expensive due to many proprietary and incompatible 3rd party protocols.

ClassicOPC

In the early to mid-1990s, control automationvendorsand end-usersgot together to

definea better wayto sharesupervisorycontrol data throughoutthe plant level. They

createda revolutionarynew open standardcalledOLEfor ProcessControl (OPC)and

formedthe OPCFoundationto manageit. ThomasBurkewasthe first president.

Basedon Microsoft OLE(Object Linkingand Embedding)technologybuilt into all

Windowsversions,OPCwaseasyfor vendorsto adopt sincethe transportmechanism

came with MicrosoftWindows the dominantOSusedin industryat the time.

Within a few yearsOPCbecamethe globalde factostandardfor standards-basedopen

dataconnectivity. However,tyingOPCto a specificOStechnologyhadits drawbacksas

IT an OTrealizedwhen inherent securityvulnerabilitiesand other connectivityissues

surfacedin the OS.

OPC UA EraClassic OPC EraProprietary Era



Data Connectivity in the Industrial IoT Era

It hard to argue againstthe vision of IIoT and Industrie 4.0. The

challengeis how to make the vision a reality. There are billions of

dollarsof installedlegacysystemsand there are manystakeholdersin

anenterprise,eachwith differentviewpointsandrequirements.

Digital BusinessTransformationthrough IIoT technologiesenables

businessesto operatemoreefficientlyandeffectivelythroughfriction-

lesscommunicationsthroughoutthe organizationandsupplychain. As

DigitalBusinessTransformationinitiativestakehold they mustaddress

Business/Financial, Usage, Functional and Implementation

requirementsasdefinedbelow.

Business/Financial Executive management is looking at the financial health of the business and what to see business value and ROI for any investment.

Usage New devices and systems must be securely registered and accessed by business users

Functional Systems and devices must interoperate in and across the fine functional domains of: Control, Operations, Information, Applications and Business

Implementation IT must implement and support system architectures, interfaces, protocols cost effectively.

5

AboutTheIndustrialInternetConsortiumThe Industrial Internet Consortiumwas founded in March 2014 tobring together the organizationsand technologies necessarytoaccelerate the growth of the Industrial Internet by identifying,assemblingand promotingbestpractices. Membershipincludessmalland largetechnologyinnovators,verticalmarket leaders,researchers,universitiesandgovernmentorganizations. (www.iiconsortium.org)

AboutPlattformIndustrie4.0Plattform Industrie 4.0 is the central network to advance digitaltransformation in production in Germany. In close cooperationwithpolitics, industry, science,associationsand trade unions, over 300playersfrom more than 150 organizationsare activelyinvolvedin theplatform. Theplatform is one of the largestinternationaland nationalnetworks and supports German companies especiallysmall- andmedium-sizedcompanies in implementingIndustrie4.0, particularlyby providing practical examplesof Industrie 4.0 to companiesanddeploying them on site. In addition, it provides decisive impulsesthrough concreterecommendationsfor action, as well as informationon meansof support and test environments. Numerousexamplesofinternationalcooperationby the platform underscoreits strongrole inthe internationaldiscussionson Industrie4.0. (www.plattform-i40.de)

OPCUnifiedArchitecture(UA)MeetsConnectivityStandardsCriteria

The IndustrialInternetConsortiumand PlattformIndustrie4.0 are two key organizationsthat have

definedthe requirementsfor nextgenerationmanufacturingsystemsandarchitectures. Theyhave

evaluated the key connectivity standards available today and both have declared that the

OPCUnifiedArchitectureStandardmeetstheir requirements.



Key Industry Consortia Join Forces

IIRA& RAMIArchitectureModels

The Industrial Internet Consortium( ) and Plattform Industrie 4.0

(I4.0) haveindependentlydevelopedreferencearchitecturemodelsfor

the industrial internet. The IIC has defined the Industrial Internet

ReferenceArchitecture (IIRA),and I4.0 has defined the Reference

ArchitectureModelfor Industrie4.0 (RAMI),respectively.

Naturally,questionshavebeenaskedabouthow thesetwo approaches

relateto oneanother. In 2015, representativesfrom both organizations

met to explorethe potentialalignmentof their two architectureefforts

andto understandthe technicalissuesfrom both perspectives.

Courtesy of Industrial Internet Consortium / Platform Industrie 4.0

On February6, 2018, the IICand I4.0 announcedthe publicationof a

joint whitepaper ArchitectureAlignmentand Interoperability which

detailsthe mappingand alignmentbetweenthe two leadingindustrial

internet of things (IIoT)referencearchitecturemodels,the Industrial

Internet ReferenceArchitecture(IIRA)and the ReferenceArchitecture

Model for Industrie4.0 (RAMI4.0), publishedby the two organizations

respectively.

6

Industrial Internet Reference Architecture

(IIRA)

Reference Architecture Model Industrie 4.0

(RAMI)

Source: Industrial Internet Consortium IIRA Source: Platform Industrie4.0 RAMI

https://www.iiconsortium.org/pdf/JTG2_Whitepaper_final_20171205.pdf



OPC UA: A Core Connectivity Standard

IndustrialInternetConnectivityFramework(IICF)

The IIC / I4.0 ArchitectureAlignmentand Interoperabilitywhite paper

definesanIndustrialInternetConnectivityFramework(IICF). TheIICF

IIoT connectivitywith a new IIoT stack model, definesan

open connectivityreferencearchitecture,and helpspractitionersto

categorize,evaluateand determinethe suitability of a connectivity

technologyfor the IIoTsystemat hand.

Theconnectivitychallengesin IIoT systemsincludemeetingdiverse

requirements, supporting many transports and connecting an

overwhelmingarrayof from smalldevicesto huge,intelligent

networksof complexsubsystems.

The number of core data standardswas kept as small a possibleto

minimize complexity and addressesnot only manufacturingbut all

possiblemarketsincludinghealthcare,transportationandothers.

At right, the red highlightedtechnologies,show that OPCUA supports

the levels of the technology framework. Critical Criterial for the

frameworkincluded:

7

Industrial Internet Connectivity Framework (IICF)

Source: IIC/I4.0 Architecture Alignment and Interoperability White Paper.

Syntactic Interoperability SecurePerformantScalableReliable

ResilientOpen StandardInternational AdoptionVendor AgnosticSDKs Available

(Open Source + Commercial)

Transport

Link

Framework

Distributed Data Interoperability

and Management

Physical

Network

TSN/Ethernet(802.1,802.3)

WirelessPAN

(802.15)

WirelessLAN

(802.11 Wi-Fi)

Wireless2G/3G/LTE

3GPP)

WirelessWide Area(802.16)

DDS oneM2MWeb

Services OPC UA

Energy & Utilities Healthcare Manufacturing Transportation

Telecommunication Origin Manufacturing Origin

DDSI-RTPS CoAP MQTT HTTP OPC UA Bin

TCPUDPTCP

Internet Protocol (IP)

https://www.iiconsortium.org/pdf/JTG2_Whitepaper_final_20171205.pdf


OPC UA vs Classic OPCWhat are the differences & Why Switch?



OPC UA versus Classic OPC

InformationModeling

How is data / information defined? How robust is the information

model. Doesit allowsfor vendor abstraction? Theability to define a

vendor independent information model would allows for universal

applicationcommunicationsandinteroperability.

Security

Cybercrimewasoneof the top newsstoriesin 2017with the estimated

global cost set to reach $6T annually by 2021, according to

CybersecurityVentures. Themanufacturingsector is at the top of the

list of most frequentlyhacked,secondonly to healthcare. Much of the

current industrialinfrastructurewasinstalled,10 to 20 yearsago,when

data security was much less of an issue and the focus was on

performanceandsafety. ThenextgenerationFrameworkmustprovide

a high level of security to protect againstsabotage,espionageand

compromisinga IT integrity.

IntegrationExperience

An optimum CommunicationsFrameworkmust addressthe primary

End User requirement to significantly reduce or eliminate system

integration complexity,cost and maintenance. The Frameworkmust

allow for: a) vendorsto differentiate their applications,b) applications

from different vendorsto easilyinteroperatewith minimaleffort, and

c) deploymentof applicationsthroughout the entire enterprise,from

sensorto cloudandthroughoutthe supplychain.

9

System Integration & Maintenance

Despite its strengths, the classicOPCstandard falls short of what is

expected from modern control automation systemsand the way they

interact with the rest of the enterprise. Key issuesaround shop floor

integration,ITpolicycompliance,reliability,datacontextpreservation,and

other issuesareall keybusinessdriversfor movingto OPCUA.

Thissectionlooksat keycriteria usedto comparewhat the differenceare

betweenclassicOPCandOPCUAtechnologies.

Platforms& Scalability

Platforms& Scalabilitydiscussesthe requirementssurroundingthe needto

deploy data connectivityon a broad range of computingplatforms and

operatingsystems. Thisis crucialfor a standardthat must be equallyat

homerunningon a sensoraswellasa cloudbasedapplication.

CommunicationTransports

Thereare manytransportsto chooseform for movingdata betweentwo

points. Some examplesare TCP/IP,MQTT, HTTPS,and UDP. These

protocols are in wide use and each well adapted for use in specific

scenarios. A datainteroperabilitystandardneedsto be ableto utilizethese

transportsasneeded. It must alsoprovidea wayfor new transportsto be

addedin the future astechnologiesevolve.



Computing PlatformsEmbedded (ARM Processors)Personal Computers / ServersBare Metal

Operating SystemsWindowsLinuxiOSAndroidNo-OS

ScalabilitySensor to CloudThroughout the Supply Chain

Platforms & Scalability

OPC UA Classic OPC

Computing Platforms

Personal Computers / Servers

Operating Systems

Windows only

Locally discoverable per PCNeed DCOM permissions on remote PCs to check for OPC Servers No global discoveryNeed to search per PC

ScalabilityPC / Windows Platforms only

OPC UA can be Deployed Anywhere

Any Platform & Operating SystemClassic OPC only runs on Windows



Communications Transport

Client-Server:Binary/TCPSupervisory control over LAN

PubSub: MQTT (Sensor-Cloud)Secure access over WANHighly scalable

PubSub: UDP (M2M)Efficient, High speed dataHighly Scalable

Connection RecoverySuitable for unreliable networks

Reverse Connection across firewalls

DCOM based transport onlyDifficulties with unreliable networks Requires 3rd party tool like OPC UA Tunneller to eliminate DCOMWindows Updates often break DCOM settings Not suitable for M2M communicationso Slowo Too expensive to deploy PCs

OPC UA supports various

Communications Transports

Classic OPC relies on Windows

COM/DCOM technology

OPC UA Classic OPC



Information Modeling

Object Oriented Information ModelingData & Commands (Services) Companion specifications provide standardized Information ModelsDynamically updates Information Models as neededMeta data for application independent definition of data

OPC UA Enabled products have:Data structures predefinedUnits, limits, etc. match device configuration

No Information ModelingSimple Items: Name, VTQNo relationship between itemsUsers: employ dot-naming convention to imply structureo Error prone and work intensiveo Easily Outdatedo Low consistency

OPC UA supports comprehensive object

oriented information modeling

Classic OPC only uses a simple dot

naming convention for items.

OPC UA Classic OPC



Security

Passed extensive security tests performed by the German Federal Government (BSI)

Threats Addressed:

DCOM IssuesIntrusion & PropagationSystem Control TakeoverEspionage & Sabotage

Network IssuesError prone and work intensiveEasily OutdatedLow consistency

OPC Server BehaviorTag Browsing: ReconnaissanceTag Reads: Espionage & ReconnaissanceTag Write: Sabotage

OPC UA was designed on best security

practices from the ground up.

Classic OPC primarily relies on outdated

Windows COM/DCOM security.

OPC UA Classic OPC



Integration Experience

Enhance Integration ExperienceSimplified multi-vendor system integrationOPC UA Companion Specifications provide common Information Models for usersInformation Model preserved data context improving analytics & insightsVendors retain unique internal implementationsServers discoverable Locally or Globally via Global Discovery Service (GDS)

Enhanced Shop Floor IntegrationShop-Floor application use OPC UA natively and pre-configured (no PC Setup)Applications call OPC UA Services directly Programming focuses on logic not translation

Shop Floor IntegrationProtocol Drivers needed per componentProgramming needed to facilitate interaction between components & production logicLocally discoverable per PC

Need DCOM permissions on remove PCs to check for OPC ServersNo Global Discovery - Need to Search per PC

OPC UA minimizes integration efforts as it

runs natively in devices and applications.

Classic OPC only runs on Windows, requires

more integration work for non-windows devices.

OPC UA Classic OPC


End User AdoptionMixing and Migrating to OPC UA



OPC UA / IIoT Considerations

Legacy Infrastructure Considerations

Most industrial enterpriseshave automation systemsfrom multiple

vendorsinstalled in their facilities. Customsoftware usingeither the

proprietary or ClassicOPC protocol is used for system

integration and data extraction for monitoring, alarms, history and

reporting. As long as these facilities continue to run in an optimized

mannerwith acceptableadministrationand maintenancecost, it does

not makeeconomicsenseto replacethesesystems.

Asnew and enhancedapplications,hardwareandsoftwaresystemsare

introduced offering improved functionality, easier integration and

maintenance,and higher and more reliable performance,end users

have started to look for viable upgrade strategiesthat retain their

infrastructureROI.

Mix & Migrate Best Practice

AsvendorsincreasinglyembedOPCUAinto their products,what is the

best practice for blending OPCUA enabled applicationswith legacy

applications?The following pages discussesthe options that are

availableandapproachesthat canbetaken.



Mix & Migrate to OPC UA

Phased Migration from Classic OPC to OPC UA

MixingOPCUAClientsandServersWithClassicOPCCounterparts

AsnewenhancedOPCUAenabledapplicationsanddevicesare introducedinto facilities primarily based on ClassicOPCit becomesnecessarytointegratethe OPCUAandClassicOPCcomponents.

Problem: OPCUA and ClassicOPCapplications cannot communicatedirectlyastheyusedifferent transports.

Solution: BridgingsoftwarelikeMatrikon®OPCUATunneller(UAT)enablesreliable and securecommunicationsbetween classicOPCand OPCUAcomponents. Thisextendsthe usefullife of existingassetswhile enablingyouto start usingnext-generationtechnologytoday.

UAT enableseither OPCUA Serversto communicatewith ClassicOPCClients(Figure1) and OPCUA Clientsto communicatewith ClassicOPCServers(Figure2).

Figure 1: Classic OPC Client & OPC

UA Server CommunicationFigure 2: OPC UA Client & Classic OPC

Server Communication

Theability to mix ClassicOPCand OPCUA componentstoday helpsfuture-

proof yourcontrol infrastructurein preparationfor a time whereonlyOPCUA

isusedat minimaleffort andexpense.

Migrationto OPCUA

Eventually,full migrationto OPCUA simplifiesinfrastructuresas middleware

PCsand bridgingsoftwarelike Matrikon OPCUA Tunnellerwill no longerbe

required. (Figure3).

Figure 3: Migrating fully to OPC UA simplifies your infrastructure and reduces integration and

maintenance costs beside the other advantages OPC UA offers.



Putting OPC UA to Work

There are a multitude of sensors,equipment, devices,and applicationsin a typical plant or

factory. Eachof theseusesdifferent communicationmethodsincludingClassicOPC,proprietary

protocols,Modbus,and others. Whateverthe setup,best practicesfor mixing& migratingto

OPCUAapply. Commonscenariosinclude:

(1) ClassicOPCArchitectures Aspreviouslydiscusseduseof Matrikon®OPCUA is

recommendedto improvethe classicOPCinfrastructuresecurityandto enablemixingin of OPC

UAcomponents.

(2) NativeProprietaryProtocols- To connectto proprietaryprotocol basedcomponents,OPC

middlewareis used to enable other systemsto openly communicatewith them. Matrikon®

IndustrialDataGatewayis an exampleof a data appliancethat provides3rd Partyconnectivity

andMatrikonOPCUATunnellerpreloaded.

18

(3) NativeOpenProtocols Thereare manyOPCUAGatewaysavailablefor the numerous

Open Protocols that are in use today, such as Modbus, FactoryTalk,Fieldbus,etc.

Ex. Matrikon®OPCUAModbusGatewaywhich, translatesbetweenModbusand OPCUA

without the needfor a PC.

(4) Devices Whenequipmentor deviceshaveno communicationscapabilitiesthen

customOPCUAgatewayscanbe developedto interfaceto new sensorsappliedto these

Darkdevices.

(5) OPCUA EnabledDevices Asmore and more vendorsOPCUA enabletheir products

then EndUsersadoptionis simplified. Therecommendationis for EndUsersto encourage

their strategicvendorsto OPCUAenabletheir productsto matchtheir adoptiontimetable.

(1) (2) (3) (4) (5)

matrikon e-book dec 2018 beeond ...€¦ · © 2018 matrikon inc. & beeond, inc all rights...

Documents