1. OPC Today and in the Future
Tom Burke - President and Executive Director, OPC Foundation
Jim Luth, Technical Director, OPC Foundation

2. OPC : Past, Present, & Future
Thomas Burke, OPC Foundation President

3. OPC Foundation International Industry Standard Organization
400+ Member Companies / 40+ end-users Members
2500+ Total Companies Build OPC Products = Products
The vision of OPC is to be the Foundation for interOperability
for moving information vertically from the factory floor through the enterprise of multi-vendor systems (with stops in between…)
For moving information horizontally between devices on different industrial networks from different vendors;
Not just data but information…….
Reliable, Secure Integration is not an Option
Collaboration is key to pulling multiple “open” standards into unified open platform architecture….

4. hours min secs 1 sec msec sec
The Plant : a Complex Environment with many opportunities for standards for interoperability
Plant
Servers
Other
Computing
Devices
hours
PLANT INFORMATION NETWORK - Ethernet
Personal Computer
Network Manager
min
Archive
Replay Module
Area Servers
Plant
Network
Modules
Control Stations
Additional
CN Modules
Application
Module
History
Module
secs
Fiber Optics
CONTROL NETWORK
Network
Gateway
Network
Gateway
PLC
Gateway
1 sec
Subnetwork Gateway
Network
Interface
Module
Control Network
Extenders
Other Data
Hiway Boxes
PLC
Other
Subsystems
msec
Multifunction
Controller
Logic Manager
Process
Manager
Subnetwork
Extended
Controller
Basic
Controller
CONTROL NETWORK
Advanced
Process
Manager
Before we discuss Microsoft’s offering for the Manufacturing Industry I would like to review with you a typical IT infrastructure of a Manufacturing company.
In the 1970’s, the central theme of information systems was hardware, and the result was almost always a hierarchical system centered on the company mainframe for commercial systems and perhaps manufacturing planning, with separate design, engineering and shop floor solutions.
By the 1980’s, information systems for manufacturing had become more focused on applications, with numerous applications economically available for tasks ranging from process control and manufacturing planning to product design. PC networks and UNIX based systems appeared in large numbers. ‘Open Systems’ promised easy integration and access to data as well as vendor independence. If a new application needed a new Operating System, then, so ,long as enough ‘Open System’ standards were supported, the new Operating System could fit into the enterprise’s Information Technology (IT) architecture.
The result of this is a variety of different systems on different hardware platforms difficult to interface and sometimes impossible to integrate. Each Operating System needs its own specialist. Even dialects of UNIX each need their own specialist
Another common factor is that these systems are not only complex and expensive to support they are also very difficult to change. Meeting the requirements (in terms of IT infrastructure) for BPR projects has become a nightmare for many IT departments adding additional cost and complexity.
Advanced
Multifunction
Controller
LocalProcessors
sec
Transmitters
Smartine
Transmitters
Asynchronous Processing
Multiple Interfaces
Mission Critical
How To Manage Changes?
Complex Information Flows
Multi-vendor
Proprietary

5. The Inter-Enterprise Nightmare
Best-of-breed solutions
Many different vendors
Custom made solutions
Proprietary technologies
Point-to-point Integration
Limited real-time information
Risking future success
Complex business environment
Maintenance nightmare
Multiple dependencies
Multiple standards
Manufacturer
Plants
Suppliers
OPC started in 1995 providing a simple interface allowing the device driver problem to be solved. This slide reflects that the same problem now exist for interenterprise information communication. OPC is well positioned to solve the fundamental problem of moving data and information across the corporate firewalls via the new OPC unified architecture. The slide conveys the existing problem of the spaghetti nightmare of hundreds of millions of interfaces being currently required for interenterprise communication
Customer value is lost

6. InterOperability InterOperability Performance Connectivity ...
A standard object model and set of interfaces for applications and servers
Performance
Before OPC:
With OPC:
Custom interfaces
Client and Server write to a standard
costly
inefficient
risky
reduce cost
protect investment
more choices
increase productivity
Connectivity
Application X
...
DCS
Controller
PLC
Application Y
Display
Application
Trend
Application
I put the slide in just a reemphasized the points of the previous slide more from an educational point of view, and is not intended to have to be part of the presentation in the keynote.
Before OPC: Custom Interfaces
COSTLY
INEFFICIENT
RISKY
With OPC: Client and Server write to a Standard
REDUCE COST
PROTECT INVESTMENT
MORE CHOICES
INCREASE PRODUCTIVITY
Before OPC
No standard for interfacing with devices / tools / applications
Vendors must each develop their own proprietary servers.
With OPC
Provides a standard interface for applications to communicate & exchange data & objects
Vendors develop to one standard OPC interface
OPC
OPC
PLC
DCS
Controller

7. OPC Data Access Architecture
Software App
provides
a linkage between
OPC Client(s)
and devices
MES and/or HMI Applications
(OPC Client)
OPC Server
PLC
OPC Client access to CIP (and other network) data is provided through OPC server functionality running in a PC today
PLC
Proprietary Messaging
OPC Data Access

8. OPC Market Acceptance OPC $ Time Dramatic Market Acceptance & Growth
Clear business benefits & risk mitigation
Many vertical industry applications
Source: Inside the Tornado by Geoffrey A. Moore, HarperBusiness, 1995 pages 14 & 19
Innovators Early Adopters Early Majority Late Majority Laggards
Technology Visionaries Pragmatists Conservatives Skeptics Enthusiasts
Chasm $
Time
Technology Life Cycle Curve
OPC
OPC UA

9. OPC – Functional Areas

10. Today’s Integration Challenges
Numerous incompatible protocols
Complex configuration and maintenance
Islands of automation
Rigid infrastructure
Vulnerability to system and network failures
Security

11. Numerous Incompatible Protocols
DDE
RS-232
HART
Lonworks
UNICODE
802.3
ProfiBus
V.35
Interbus
CC-Link
Bluetooth
DNS
IPsec
DeviceNet
RS-485
TCP
OAGIS
CAN
Kerberos
ControlNet
CORBA
RS-422
DHCP
netDDE
BAPI
EBCDIC
HTTP
SNMP
802.11
SOAP
DeviceLogix
FIPIO
ANSI
FieldBus
COM
IPX
USB
With so many protocols and standards--some of which work together, some which do not, and all of which need to be configured properly--you can literally lose sight of the manufacturing process
CANopen
AS-I
Industrial Ethernet
RS-423
.NET Remoting
DCOM
OPC-HDA
OPC-A&E
ARP
XML
OLE
Firewire
WMI
IPv6
Modbus
802.1x
IPv4
UDP
OPC-DA
FDI
RARP
J1939
ICMP
Ethernet
FTP

12. Numerous Incompatible Tiers
Section/Area
material
dispatch
performance
measurement
SCADA
quality
systems
production
planning
process history
controllers
area
Enterprise
ERP
CRM
SCP
SCE
PLM
R&D
Facility/Plant
time
attendance
and
maintenance
management
resource
product
genealogy
WIP
tracking
PDM
production
planning
Cell
cell controllers
HMI
DCS
operator interfaces
Equipment
sensors
transmitters
valves
networks
field NC
machines
robots
Station
continuous controllers
batch controllers
NC controllers
discrete controllers
process
monitoring
Viewed another way, the plant’s information architecture explodes into multiple tiers, each of which has its own class of devices, its own class of applications, and its own way of representing, storing, and communicating data.

13. OPC Unified Architecture Motivation
.NET
new
Communication
architecture
DCOM
retires
Internet
OPC-UA
Better
Integration
(DA, HDA, AE)
More Areas of
Application
(MES, ERP)
Storyboard #0 – OPC UA: Why we started it (Slide 1 of 2)
The Unified Architecture is the next generation of technology. We need to make clear that the current OPC is great but we still thought we start with a completely new technology. How can we sell this? We do not want users to stop buying products until UA.
We also need a statement about compatibility.
Allow existing servers to be plugged into UA.
Keep established terminology and functionality
Roadmap!
Service
Oriented

14. OPC Unified Architecture
Web Services / XML
Easy Configuration and Maintenance
Increased Visibility
Broader Scope
Reliability
Security
Performance
Platform Neutrality
Legacy Products Plug Right In…

15. OPC Unified Architecture Base
Integration of DA, A&E, Commands, Complex Data, and Object Types
Designed for Federation
abstract data/ information from the plant floor, through information models, and up to enterprise systems
Information Modeling
development and deployment of standard information models to address industry domains specifics
Complex Data
OPC Standard & Domain & vendor specific…..
Storyboard Topics to Address with Posters
Storyboard #1 – OPC UA Architecture
This storyboard describes the technical architecture of an OPC server, highlighting the integration of DA, A&E, Commands, Complex Data, and Object Typing.
Storyboard #2 – Server Chaining
This storyboard describes how OPC UA servers can be designed to abstract information from the plant floor, through information models, and up to enterprise systems. Aggregation of servers will be highlighted.
Storyboard #3 – Information Models
This storyboard will emphasize the application of OPC UA to specific industry domains. It will encourage the development and deployment of standard information models so that interoperability will start to happen at the information level rather than at the bit level.
Storyboard #4 – Complex Data
This storyboard will supplement Storyboard #1 with examples of how complex data can greatly expand the data accessible from a server. Examples to include alarm objects and trend objects.
Storyboard #5 - Commands
This storyboard will supplement Storyboard #1 with examples of how commands can suppport the invocation of specific operations, such as calibrations.
Storyboard #6 – Enterprise Integration
This storyboard will emphasize the exchange of well-known objects (perhaps standardized) through the OPC UA standard messaging system.
Storyboard #7 – Robustness
This storyboard will describe how OPC overcomes the inherent problems associated with failed communications and failed clients and servers. Sequence numbers, keep-alives, resyncing, and support for redundancy will be highlighted.
Storyboard #8 – Companion Standards
This storyboard will describe the process by which industry groups can define how OPC UA can be used in a standard manner to access their data. Standard procedures for the development and registration of companion standards with the OPC Foundation will be highlighted.

16. OPC Unified Architecture Base
Security
Collaboration, Development & Reference
Enterprise Integration
OPC UA standard messaging system
Robustness / Reliability Designed & Built in….
NO Failures
Sequence numbers, keep-alives, resyncing, and support for redundancy
Commands
Companion Standards
industry groups define what OPC Unified Architecture “transports”
Storyboard Topics to Address with Posters
Storyboard #1 – OPC UA Architecture
This storyboard describes the technical architecture of an OPC server, highlighting the integration of DA, A&E, Commands, Complex Data, and Object Typing.
Storyboard #2 – Server Chaining
This storyboard describes how OPC UA servers can be designed to abstract information from the plant floor, through information models, and up to enterprise systems. Aggregation of servers will be highlighted.
Storyboard #3 – Information Models
This storyboard will emphasize the application of OPC UA to specific industry domains. It will encourage the development and deployment of standard information models so that interoperability will start to happen at the information level rather than at the bit level.
Storyboard #4 – Complex Data
This storyboard will supplement Storyboard #1 with examples of how complex data can greatly expand the data accessible from a server. Examples to include alarm objects and trend objects.
Storyboard #5 - Commands
This storyboard will supplement Storyboard #1 with examples of how commands can suppport the invocation of specific operations, such as calibrations.
Storyboard #6 – Enterprise Integration
This storyboard will emphasize the exchange of well-known objects (perhaps standardized) through the OPC UA standard messaging system.
Storyboard #7 – Robustness
This storyboard will describe how OPC overcomes the inherent problems associated with failed communications and failed clients and servers. Sequence numbers, keep-alives, resyncing, and support for redundancy will be highlighted.
Storyboard #8 – Companion Standards
This storyboard will describe the process by which industry groups can define how OPC UA can be used in a standard manner to access their data. Standard procedures for the development and registration of companion standards with the OPC Foundation will be highlighted.

17. Unified Architecture Evolution
Asset
Management
Production Control
Inventory
Management
Purchasing
HMI
Visualization
SCADA
The
Enterprise
paradigm
The
Automation
paradigm
Production Management
Systems

18. OPC Unified Architecture
Open Standards to Deliver Interoperability
Device to Device and Device to the Enterprise
MIS
Enterprise Integration
(ERP, Asset Management,
Advanced Diagnostics, etc.)
Device Data
APPLICATION
PACKAGES
Configuration
Subsystem Integration P L P L
Device Integration
(FF, Profibus, HART, etc)

19. ERP, SAP … Corporate Enterprise
OPC Provides Industry-Standard interOperability, Productivity & Collaboration
ERP, SAP … Corporate Enterprise
OPC Unified Architecture
Manufacturing, Production and Maintenance
OPC Unified Architecture
Adv.
Control
HMI
MES
SCADA
Batch
OPC
OPC
This is a sense of the picture that shows OPC and all the possible opportunities for OPC XML data access being used for a whole interoperability and connectivity between different applications.
We may have used this slide many many times, but I think that the audience in a message that it conveys merits possible inclusion.
Essentially what you’re talking about is as a wide variety of different applications that have the need for data and information being exchanged between themselves. Is data moves from the lower level devices, up through the various applications . The data gets transformed into information.
A typical example as that a lot of times and HMI application becomes the alarm server for and operates on the data from the factory floor, in transposes the data on via rule processing to determine if the data on from the factory floor represents some sort of alarm condition that needs to be passed out the works changed between different applications.
when alarm information needs to be passed between applications that are distributed and connected via the Internet the best technology to do that is by using XML and web services
OPC
PC-Based Control
OPC
PLC
DCS
Industrial Networks
Data
Acquisition
?? ??

20. OPC Unified Architecture
Jim Luth, OPC Technical Director

21. Based on standards for the Web
OPC-UA Fundamentals
Based on standards for the Web
XML, WSDL, SOAP, WS-*
WS-Policy negotiates protocol and encoding
WS-SecureConversation provides secured sessions
Optimized for the Intranet
OPC Binary encoding over TCP

22. OPC Interface Unification
SOA (Service Oriented Architecture)
Single set of Services
Query, Read, Write, Subscribe…
Named/Typed relationships between nodes.
Alarms & Events
Data Access
Historical Data Access
Commands
Storyboard #1 – OPC UA Architecture (Slide 1 of 3)
This storyboard describes the technical architecture of an OPC server, highlighting the integration of DA, A&E, Commands, Complex Data, and Object Typing.
Additional highlights:
 communication architecture: 3 layers: protocol, proxy/stub, API (.NET)
 fully based on public specifications (WSDL, SOAP, WS*)
o platform independent
o well supported with the next .NET version
 efficient enough to replace DCOM
 scalable
Complex Data
UA Server
The UA Server embodies the functionality of existing OPC Servers using a single set of services

23. Unified Object Model
Storyboard #1 – OPC UA Architecture (Slide 2 of 3)
This storyboard describes the technical architecture of an OPC server, highlighting the integration of DA, A&E, Commands, Complex Data, and Object Typing.
Additional highlights:
 communication architecture: 3 layers: protocol, proxy/stub, API (.NET)
 fully based on public specifications (WSDL, SOAP, WS*)
o platform independent
o well supported with the next .NET version
 efficient enough to replace DCOM
 scalable

24. OPC-UA Address Space Full Mesh – Network Model
Storyboard #3a – Address Space (slide 2 of 5)
Explain additional potentials:
aimed to represent a “System” rather than independent tags
Object classes and instances
Relationships
Meta data
Items, alarms and commands
Full mesh rather than simply hierarchical
Views
Browse and Query
Configuration (AddNode, Import, Export, …)
Full Mesh – Network Model
Unlimited Named/Typed Relationships
“Views” are used to present hierarchies

25. Subscription Update Features
Robustness
Subscription Update Features
Keep-alive (heartbeat) messages
Allows clients to detect a failed server or channel
Sequence Numbers in each update message
Allows client re-sync to obtain missed messages
Decouples callback channel from notification mechanism, allowing callback channel to be reset without loss of data
Redundancy Features
Designed for easy (optional) redundancy of both Clients and Servers
e.g. re-sync request can be sent to a backup server
Storyboard #7 – Robustness
This storyboard will describe how OPC overcomes the inherent problems associated with failed communications and failed clients and servers. Sequence numbers, keep-alives, resyncing, and support for redundancy will be highlighted.

26. UA Servers require authentication and authorization.
Security
UA Clients present credentials to UA Servers (x509 certs on both sides).
UA Servers require authentication and authorization.
Access control can be fine-grained down to the property level.
Optional message signing and encryption.
Storyboard #10 – Security (1 of 2 )

27. Communication Layering
.NET (WCF) Version
Portable C/C++ Version
Java Version
Tool or Language Dependent (e.g. .NET)
Scalable Platform Independent Messaging Model
Storyboard #1 – OPC UA Architecture (Slide 3 of 3)
This storyboard describes the technical architecture of an OPC server, highlighting the integration of DA, A&E, Commands, Complex Data, and Object Typing.
Additional highlights:
 communication architecture: 3 layers: protocol, proxy/stub, API (.NET)
 fully based on public specifications (WSDL, SOAP, WS*)
o platform independent
o well supported with the next .NET version
 efficient enough to replace DCOM
 scalable
Business Model, Adaptable to
Platform Independent Messaging Models (e.g. WSDL)

28. Specification Layering
Vendor Information Models
Information Model Specifications
IEC, ISA, MIMOSA … DA
A&E
HDA
CMDs
OPC Information Model
OPC UA Base Services
All Necessary Services
Storyboard #8 – Companion Standards
This storyboard will describe the process by which industry groups can define how OPC UA can be used in a standard manner to access their data. Standard procedures for the development and registration of companion standards with the OPC Foundation will be highlighted.
Clients written to just the base can still discover and access all data from the derived layers!

29. Scalability
OPC UA “Server Profiles” defined to allow servers with different capability levels
Client can discover server profile
Profiles and wrappers defined for migrating existing servers to UA
More capable profiles also defined
Storyboard #9 – Evolution/migration of servers

30. Server Diagnostics Standard “Server” node defined in address space
Standard diagnostic data items defined for the server, such as “SubscriptionCount”
Server specific diagnostics can be added, with semantics defined by object type definitions
Storyboard #11 – Diagnostics in the address space

31. UA Server Chaining
UA Client
UA Client
Enterprise Semantics
“Aggregating” UA Servers extract and process data from lower level “Device” UA Servers. Data is recast using different information models appropriate for the clients at the higher level.
“Aggregating” UA Servers extract and process data from lower level “Device” UA Servers. Data is recast using different information models appropriate for the clients at the higher level.
Enterprise Network
UA Server
UA Client
UA Client
Operations Network
Process Semantics
UA Server
UA Server
UA Client
UA Client
Plant Floor Network
Storyboard #2 – Server Chaining
This storyboard describes how OPC UA servers can be designed to abstract information from the plant floor, through information models, and up to enterprise systems. Aggregation of servers will be highlighted.
Device Semantics
UA Server
UA Server

32. OPC Address Space Today
Storyboard #3a – Address Space (slide 1 of 5)
Explain additional potentials:
aimed to represent a “System” rather than independent tags
Object classes and instances
Relationships
Meta data
Items, alarms and commands
Full mesh rather than simply hierarchical
Views
Browse and Query
Configuration (AddNode, Import, Export, …)
Pure Hierarchy
Parent/Child Relationships Only

33. Data Items and Alarms Today
Storyboard #3a – Address Space (slide 3 of 5)
Explain additional potentials:
aimed to represent a “System” rather than independent tags
Object classes and instances
Relationships
Meta data
Items, alarms and commands
Full mesh rather than simply hierarchical
Views
Browse and Query
Configuration (AddNode, Import, Export, …)

34. UA Coherent Address Space
Storyboard #3a – Address Space (slide 4 of 5)
Explain additional potentials:
aimed to represent a “System” rather than independent tags
Object classes and instances
Relationships
Meta data
Items, alarms and commands
Full mesh rather than simply hierarchical
Views
Browse and Query
Configuration (AddNode, Import, Export, …)

35. UA Coherent Address Space
Storyboard #3a – Address Space (slide 4 of 5)
Explain additional potentials:
aimed to represent a “System” rather than independent tags
Object classes and instances
Relationships
Meta data
Items, alarms and commands
Full mesh rather than simply hierarchical
Views
Browse and Query
Configuration (AddNode, Import, Export, …)
Integrated data and alarms

36. Object Classes and Instances
Top Layer
Relationship
Complex Data
Top
Base Types
Schema
Type
Layer
Instantiation
(between layers)
Subclassing
(Inherit
ance)
Storyboard #3a – Address Space (slide 5 of 5)
Explain additional potentials:
aimed to represent a “System” rather than independent tags
Object classes and instances
Relationships
Meta data
Items, alarms and commands
Full mesh rather than simply hierarchical
Views
Browse and Query
Configuration (AddNode, Import, Export, …)
Data Type
Reference
Standard and
System -
defined
Other relation- ship such as “contained”, “operated by”, “controls”, etc.
Data Type
Definitions
Instance Layer

37. Complex Data Features Tells clients how to parse structured data
Allows use of XML Schemas for describing XML data
Defines OPC Binary data description language that uses XML to describe binary data structures
Allows client to access device specific data descriptions (e.g. Fieldbus Foundation OD)
Storyboard #4 – Complex Data
This storyboard will supplement Storyboard #1 with examples of how complex data can greatly expand the data accessible from a server. Examples to include alarm objects and trend objects.

38. Methods vs. Programs Programs built on top of Methods
Programs represent executable components of objects , e.g.,
DownloadProgram(Name, InitState)
MonitorNetwork (From, Till, Interval)
Execution time may vary from milliseconds to indefinitely.
Asynchronous invocation is non-blocking. Results are returned using notifications.
The client can control the execution.
Storyboard #5 - Commands
This storyboard will supplement Storyboard #1 with examples of how commands can suppport the invocation of specific operations, such as calibrations.
Methods part of UA Base
Synchronous invocation similar to blocking function calls.
AckAlarm()

39. Programs can have State
State Machine
UA defines the basic state machine.
State transitions may cause notifications. 2
Executing
Opening
Sending
Closing 3
Storyboard #5 - Commands
This storyboard will supplement Storyboard #1 with examples of how commands can suppport the invocation of specific operations, such as calibrations.
Sub-states can be defined in particular for the executing state.

40. Scalability
OPC UA “Server Profiles” defined to allow servers with different capability levels
Client can discover server profile
Profiles and wrappers defined for migrating existing servers to UA
More capable profiles also defined
Storyboard #9 – Evolution/migration of servers

41. Server Diagnostics Standard “Server” node defined in address space
Standard diagnostic data items defined for the server, such as “SubscriptionCount”
Server specific diagnostics can be added, with semantics defined by object type definitions
Storyboard #11 – Diagnostics in the address space

42. UA Services Common services support DA, A&E, and HDA operations
Protocol independence
Timeless durability
Integrated with the UA Data Model
Partitioned into Service Sets

43. UA Service Sets Secure Channel Service Set Session Service Set
Open & Close Channel, GetPolicies
Session Service Set
Create, Close, Activate, ImpersonateUser
Node Management Service Set
Add & Delete Objects and References
View Service Set
Browse, BrowseNext

44. UA Service Sets (2) Query Service Set Attribute Service Set
QueryFirst, QueryNext
Attribute Service Set
Read, Write, ReadHistory, UpdateHistory
Method Service Set
Call
Monitored Item Service Set
Create / Modify / Delete
Subscription Service Set
Create / Modify / Delete, Publish, Republish

45. Putting it all together
Abstract
Services
Type
Descriptions
Object
Model
Data
Model
SOA
Model
OPC UA
DA, HDA,
and A&E
Protocol
Independent
Comms
Model
Platform
Independent
Plant floor
and Internet
Access

46. UA Programmers’ Interface
Designed to provide an abstraction layer between the application developer and the SOAP stack/wire encoding
Defined by UA to match the abstract specification instead of the WSDL
Client
Proxy
Stub
Server
SOAP

47. Interoperability with UAPI
Client Application
UA Programmers’ Interface
WSE 2.0
Indigo
Java
UA TCP
UA Binary
XML
XML
UA Binary
Indigo
Binary
UA Binary
WSE 2.0
Indigo
Java
UA TCP
UA Programmers’ Interface
Server Application

48. UA Programmers’ Interface UA Reference Server Extensibility Interface
The UA SDK (II)
WSE 2.0
Indigo
Java
UA TCP
UA Programmers’ Interface
UA Reference Server
UA Reference Server Extensibility Interface
COM
Wrapper
XML-DA
Wrapper
Native
Vendor
Specific

49. UA –Enable all OPC COM Servers
UA clients can instantly connect to hundreds of existing OPC COM Servers
UA Client
UA Server
Wrapper
COM DA
Server
SOAP over UA
HTTP or TCP

50. UA –Enable all OPC COM Clients
Use the UA Client Proxy to connect existing COM clients to new UA Servers
COM DA
Client
UA Client
Proxy
UA Server
SOAP over UA
HTTP or TCP

51. Disable Remote DCOM
Use the UA proxy and wrapper to replace DCOM as remote communication protocol
COM DA
Client
UA Client
Proxy
UA Server
Wrapper
COM DA
Server
SOAP over UA
HTTP or TCP

52. Disable Remote DCOM
Use the UA proxy and wrapper to replace DCOM as remote communication protocol
COM
Client UA
Proxy UA
Wrapper
COM
Server UA

53. OPC Unified Architecture Roadmap
Architecture Vision
Q4 / 03
Implementation Sub-Committee Formed
Q1 / 05
Phase One Ref. Implementation Q4 / 06
OPC Unified Architecture Milestones
UA Committee Formed
Q1/ 04
Phase One Spec. Release Q2 / 06
Promote Phase One Worldwide
Q4 / 06

54. OPC Unified Architecture Demo
The UA Proxy and Wrapper:
Enhancing the past, Connecting the future

55. Cross Industry Interoperability Strategy
OPC used in process & discrete manufacturing
OPC adopted in the following:
Semiconductor
Plant Maintenance and Production Management
Industrial Ethernet …..
Security
Building Controls
RFID
Retail/ Financial ….
Collaboration with MIMOSA
Collaboration with ISA (S88, S95, S99)
Collaboration with OAGi
Collaboration with IEC
Collaboration with MS MUG & NAMUR
Collaboration with …… (stay tuned)
Markets
Collaboration

56. OPC Vision OPC Domains OPC is the “HOW” for moving “WHAT”
Automation (factory & process)
Building Controls
Security
Semi – Conductor
Financial / Retail
…..
OPC is the “HOW” for moving “WHAT”
OPC Collaboration
Industrial Ethernet, WS - *, IEC, ISA SP95, ISA SP88, ISA SP99, EDDL, OMAC, MS MUG, …

57. Visit the UA ‘home’ page
More Information …
Visit the UA ‘home’ page

58. OPC Success Success is measured by level of adoption
OPC members’ participation
Design, Build, and Deliver Products
Compliance / Interoperability Testing
End-users demand certification
Industry Endorsement
OPC is everywhere!