Welcome to the OPC TAC Blog! 

Tags:

First things first.  Let’s answer some questions I’m sure many people have.

What is the OPC TAC?   In June 2007 the OPC Foundation formed the Technical Advisory Council (TAC) to guide, monitor and approve the technical deliverables of OPC-UA.   Its main purpose is to advise the OPC Foundation management on current and future technical matters and in general, guides the technical direction of the Foundation.

Who is the OPC TAC?  The Technical Advisory Council is comprised of OPC community members who hold technical leadership positions, have years of software development and architecture experience or are technical visionaries responsible for deploying OPC and industrial automation applications in their enterprises. The third-party organizations currently involved in the Council are ABB, Emerson Process Management, Fieldbus Foundation, Honeywell Process Solutions, Iconics, International Electrotechnical Commission (IEC), Invensys Process Solutions, Kepware, Matrikon, OSIsoft, Rockwell Automation, SAP, Siemens Energy & Automation, SISCO, WBF, Wonderware and Yokogawa.

Why is there an OPC TAC?  In addition to the obvious advisory role, members of the Council are responsible for championing and evangelizing OPC internally and externally to ensure timely and complete adoption.   The members also define technical Working Group Charters, approve for final release all output of the Technical Working Groups and serve in leadership roles as required.   OPC has a vast implementation base, and the functionality, quality and delivery of OPC and OPC UA products directly affects them.   The OPC Foundation has created the TAC from a variety of stakeholders to be a part of the process and ensure its success.

What is the TAC Blog, Who writes it and Why is it here?   The vision of this blog is to be a source of information on what is happening with the OPC Foundation, the progress of the various OPC UA initiatives and most importantly as a two-way method of communication to you, the OPC community.  Yours truly, Eric Murphy, along with all the other members of the TAC will be posting here.   The TAC acts as the representatives of all OPC members, to ensure OPC UA meets the high quality demands and needs of the end-users.  This blog is one way for you the members to make your voice heard.   

If you follow this blog, you’re sure to hear from us, and I hope to hear from you.

Stay tuned.

 
Posted by Eric Murphy on 21-Mar-08
2 Comments  |  | Bookmark this post with:        
 

Comments


OPC vs Modbus commented on Wednesday, 26-Mar-2008
I work for Fluor and am currently helping to write a specification for a petrochemical plant. We would like to use OPC instead of Modbus. I am having to write a white paper on the advantages of using OPC. Besides time stamping and the disadvantage that Modbus is a master/slave protocol. It prevents peer to peer communication and does not allow report by exception, are there any other advantages for OPC?

OPC advantages commented on Wednesday, 26-Mar-2008
It's hard to really hit the key advantages of one protocol over another without having the full picture of where and how it is being used. What applications need to connect, environment, number of points, update rates, etc. But in the general case, you've already hit on the main points OPC has over Modbus: Timestamp/Quality information, Client-Server architecture and Subcriptions. Some other points to consider: From a usability point of view, OPC provides browsing of the address space and more descriptive item IDs (tags/registers). From a protocol point of view, OPC does not have the network node limitations that exist in Modbus (which require splitting Modbus networks or using gateways or repeaters). OPC also supports more data types, deals with data type conversion and is better at handling string data. From a system architecture point of view, it deals better with event based and historical data. OPC is easier to integrate with control/business level applications, since adoption is so prevalent at these levels. OPC is also more extensible since there are so many COTS products that add redundancy, reliability, data buffering and guaranteed data delivery to any OPC architecture. For any system, you need to decide what the key concerns and functionality you need, and determine which connectivity option gives you the best fit now and in the future.
Name:
URL:
Email:
Comments:

CAPTCHA Image Validation