I have a very general inquiry relating to OPC, as I am just beginning on a project that requires OPC driver development. First off, is there a difference between an OPC driver and an OPC server? I have seen people use the terms interchangeably.. We have three microturbines, none of which have OPC drivers/servers. In addition, the PLC's are in-house creations, with RS-232 connections for a PC. We are using OperateIT, a SCADA/HMI software package from ABB. It supports OPC DA v2.0, A&E v1.0 and HDA v1.0. We would like to monitor/control the turbines remotely, as well as monitor for alarms. Where do I begin? Do I need to create three seperate OPC servers for each of the turbines, each defining DA, A&E, and HDA interfaces? Or do I need to just create one server, with the information collected from each of the respective drivers, and then relayed to the SCADA/HMI software? Can anyone make recommendations on a toolkit to be used for driver/server development? Is the development time significant? Thanks for any and all information!

 

Hello, remarks enclosed. Frank ----- Original Message ----- > FROM: Dennis Healy <[email protected]> > I have a very general inquiry relating to OPC, as I am just beginning on a > project that requires OPC driver development. > > First off, is there a difference between an OPC > driver and an OPC server? I have seen people use the terms > interchangeably.. Probably they differentiate between OutProc-Server, i.e. executable and InProc-Server, i.e. DLL. They both provide access to the same functionality, but differ in implementation and use. > We have three microturbines, none of which have OPC drivers/servers. In > addition, the PLC's are in-house creations, with RS-232 connections for > a PC. We are using OperateIT, a SCADA/HMI software package from ABB. It > supports OPC DA v2.0, A&E v1.0 and HDA v1.0. We would like to > monitor/control the turbines remotely, as well as monitor for alarms. > > Where do I begin? Do I need to create three seperate OPC servers for each > of the turbines, each defining DA, A&E, and HDA interfaces? Or do > I need to just create one server, with the information collected from each > of the respective drivers, and then relayed to the SCADA/HMI > software? How do they turbines/PLC communicate with a PC? Are there any bus systems or serial lines? Normally it is sufficeint to write one server for all the equipment. Data Access, Alarms and Events and Historical Data Access are different specifications that define different APIs. Data Access to read and write real-time data (snapshot) Alarms and Events to structure, monitor and achnowledge events and alarms Historical Data Access to access/alter historical data. Decide first what kind of application you need. > Can anyone make recommendations on a toolkit to be used for driver/server > development? Is the development time significant? Development time is significant. Toolkits are available. Have a look at the opc foundation web site (www.opcfoundation.org) To be honest, I would recommend our (Softing) toolkit. If you need more information, do not hesitate, contact me directly. Regards, Frank Iwanitz

 

OPC is a set of interfaces defined as MS COM interfaces. An OPC server is a piece of software that implements these interfaces and also hooks them to something "real" like a serial RS232 protocol. OPC servers are sometimes called OPC drivers in accordance with the "old" times when you had proprietary drivers for each protocol to each HMI/SCADA product. OPC can be seen as an abstraction layer on top of any data source whether this source is a database or a protocol stack. What exactly are you trying to do? Do you already have a RS232 connection from the PLC's to the HMI/SCADA? In that case I think that the HMI/SCADA can act as an OPC server and provide any OPC client with data. Or are you trying to develop an OPC layer between the HMI/SCADA and the RS232 link to the PLC's? In that case there are several OPC toolkits on the market. I have tested one from Softing GmbH and it is a good one. The rest of the OPC server is up to your own design descisions. You can easily let the OPC server access more than one RS232 port and i.e have more than one PLC connected via the OPC server or have one instance of the OPC server per RS232 port. It's your design descisions. Although I think it's a better design to let one OPC server be able to handle multiple I/O ports.

 

Comments inline. > First off, is there a difference between an OPC > driver and an OPC server? Nope. But some people out there use an OPC server term talking about a bridge between some proprietary data access protocol and an OPC. An OPC Driver, according to that erroneous opinion, is a device/network driver which API meets the OPC Data Access Custom Interface Spec (Server I/F). > We have three microturbines, none of which have OPC drivers/servers. In > addition, the PLC's are in-house creations, with RS-232 connections for > a PC. We are using OperateIT, a SCADA/HMI software package from ABB. It > supports OPC DA v2.0, A&E v1.0 and HDA v1.0. We would like to > monitor/control the turbines remotely, as well as monitor for alarms. > > Where do I begin? Do I need to create three seperate OPC servers for each > of the turbines, each defining DA, A&E, and HDA interfaces? Or do > I need to just create one server, with the information collected from each > of the respective drivers, and then relayed to the SCADA/HMI > software? IMHO the best approach is in creating a single server supporting both DA and A&E interfaces. By such a way you'll be able to store/manage its configuration in a single database/persistent storage. I think it is not so necessary to implement HDA out there because most of datalogging packages and tools support the OPC DA client I/F. > Can anyone make recommendations on a toolkit to be used for driver/server > development? Is the development time significant? You'll find a lot of info over there: http://dialspace.dial.pipex.com/town/estate/on50/index.shtml http://www.intellution.com/opchub/opcsample.asp We use the ICONICS OPC ToolWorX (http://www.iconics.com) for a long time. IMHO it is a very convenient and powerful toolkit. Cordially, Alexander Lokotkov Software Development Dept. Head Fastwel, Inc., Russia

 

For data access you may look at Descartes Omni server for the RS232 lines Ronald

 

Hi Dennis, Please see my comments below. Feel free to contact me directly with any questions or comments. Norm Malloch -----Original Message----- FROM: Dennis Healy <[email protected]> >I have a very general inquiry relating to OPC, as I am just beginning on a >project that requires OPC driver development. >First off, is there a difference between an OPC >driver and an OPC server? I have seen people use the terms >interchangeably.. None. You can think of an OPC server as a driver in the sense that it is application software that communicates with a proprietary system via a protocol stack or API, for example. The main difference is that the interface to the rest of the world is standardized. That is, any OPC client application can connect and use the "driver". Your OPC server implementation could in fact be a "wrapper" for one or more software drivers that you already have. >We have three microturbines, none of which have OPC drivers/servers. In >addition, the PLC's are in-house creations, with RS-232 connections for >a PC. We are using OperateIT, a SCADA/HMI software package from ABB. It >supports OPC DA v2.0, A&E v1.0 and HDA v1.0. We would like to >monitor/control the turbines remotely, as well as monitor for alarms. >Where do I begin? Do I need to create three seperate OPC servers for each >of the turbines, each defining DA, A&E, and HDA interfaces? Or do >I need to just create one server, with the information collected from each >of the respective drivers, and then relayed to the SCADA/HMI >software? This is a generalized statement not knowing what the interface methods are for your microturbine systems and their complexity, but in general, it makes good sense to combine the DA and AE interfaces into a single server. While the data model (continuous data flows for DA and event information for AE) for each interface are different, I would imagine that you would use the same interfacing method to your microturbine systems (maybe an API library?). The rationale for bundling HDA interfaces with DA and AE are less general. It would depend on a number of design issues. Here are two that come to mind. One, are you wrapping a historian product or is the HDA server actual going to be your historian product (i.e. will it collect, accumulate, and aggregate data)? If you are wrapping, then it may make sense to bundle the three interfaces together. If not, then it may make sense to implement the HDA server stand alone. Two, are the historical interfaces to your system integrated with the interfaces that supply real-time data (for DA) and events/alarms (for AE)? If yes, then combining three interfaces into one server makes sense from a technical perspective. Another issue to consider is software maintenance. Each standard will evolve at its own pace. Each time a new version of the standard is released, you have to decide how that affects your product and how you update your customers. >Can anyone make recommendations on a toolkit to be used for driver/server >development? Is the development time significant? Check out the OPC Programmers Connection website for a list of toolkit vendors on the market: http://www.opc.dial.pipex.com/. My company (Northern Dynamic) sells a DLL-based toolkit that you download for free and give it a try. We also have a DLL-based Alarms & Events toolkit, soon to be released.

 

Dennis, No there is not a difference between an OPC server and an OPC driver as far as I'm concerned. I know that I find myself using them interchangeably because my clients tend to use the term OPC driver because before OPC we all talked about "drivers" for talking to our PLCs -- when OPC came along the "driver" code gets wrapped up on the OPC server software application that talks to the PLC/hardware and "serves up" it's data to client applications that want the data - i.e your typical HMI/SCADA application or any application that has the hooks and handles built in to be an OPC "client". So in short, the "client" wants the data and the OPC "server" provides the data by going out using it's driver code to talk the necessary language/protocol that the PLC/hardware needs to use to get said data. Like i said, since in my mind it's safe to use the 2 interchangebly, my thought is "why confuse my client by making him use the same terms i do -- if he wants to say 'opc driver' to mean OPC server then that's oK by me" -- John Weber President Software Toolbox