Re: [foxboro] OPC again...
- From: Corey R Clingo <corey.clingo@xxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Thu, 3 May 2007 09:50:07 -0500
I would probably favor some sort of tunneling myself, either
MAtrikon-style, or using locating the AIM OPC server on the machine with
the client and using AIM*API to traverse the network between that box and
the I/A as Alex suggested.
I'll have to read that document you mention. Since the UA flavor uses
SOAP/XML, there's probably more protocol overhead than even with DCOM, but
the counter-argument is that machines and networks have gotten faster and
can handle it (sounds like MS and Vista...). But I really know little
about OPC UA.
I still can't get past the feeling, though, that all this is overkill for
most of the live data-transfer applications I use (historical data/A&E is
another topic, but then "real-time" performance is not such an issue
there). My gut tells me that something like Modbus/TCP or Ethernet/IP
would probably do the job in 99% of cases. The extra features of the OPC
flavors might be more beneficial in a MES/enterprise data integration
environment, but for an APC, or foreign device integration, I'll take a
simple protocol like a Modbus or CIP any day.
A side note, and something I think about but don't dwell on because I
don't think there is much I can do about it, is application-layer
security. I doubt any vendor does a whole lot of security auditing or
testing on the software that is used to implement clients and servers for
these protocols, and those programs often run with root/admin privileges,
making the host machine (i.e., your DCS) potentially vulnerable to remote
exploits. Since simple protocols are easier to implement properly, and
open protocols make it at least posssible for someone to implement an
application-layer firewall, I would think simple, open protocols (like
Modbus/TCP and Ethernet/IP) would eventually help lead to better security.
Corey Clingo
BASF Corporation
<tom.vandewater@xxxxxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
05/02/2007 01:54 PM
Please respond to
foxboro@xxxxxxxxxxxxx
To
<foxboro@xxxxxxxxxxxxx>
cc
Subject
Re: [foxboro] OPC again...
I've heard people talk about the tunneler. To my understanding
it uses TCP/IP to pipe from one machine to another instead of DCOM in a
similar manner as Modbus TCP. I would feel a lot better about that than
using DCOM. The old OPC DA,(Data Access),OPC HDA,(Historical Data
Access),and OPC A&E (Alarms and Events), used COM/DCOM for its transport
mechanism and it has been a good idea gone bad because of DCOM.
There were several reasons that motivated the OPC Foundation to
develop the new OPC UA, (Unified Architecture) and the limitations and
problems associated with COM/DCOM were significant drivers for change.
OPC UA based on Web Services/Service Oriented Architecture may alleviate
a lot of these issues. The best article I've read to gain a better
understanding of UA and its features and intent was written by
Stefan-Helmut Leitner and Wolfgang Mahnke of the ABB Corporate Research
Center in Germany. The link to the document, listed below will be
broken and you will have to copy and paste it into your browser to make
it work:
http://pi.informatik.uni-siegen.de/stt/26_4/01_Fachgruppenberichte/ORA20
06/07_leitner-final.pdf
Abstract: OPC Unified Architecture (OPC UA) is the new standard of the
OPC Foundation providing interoperability in process automation and
beyond. By defining abstract services, OPC UA provides a
service-oriented architecture (SOA) for industrial applications - from
factory floor devices to enterprise applications. OPC UA integrates the
different flavors of the former OPC specifications into a unified
address space accessible with a single set of services. This paper gives
an overview of the architecture of OPC UA, its address space model and
its services. It discusses the necessary security mechanisms needed to
allow secure access over the internet. Finally, migration strategies to
OPC UA applications are introduced.=20
Cheers,
Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY USA
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
