OPC AE is acronym of OPC Alarms and Events. It is a set of interfaces that handle real time access to alarms and events occurred in the automation industry. This is achieved by exposing alarms and events to the control process level with respect to OPC standard format.
The OPC Alarms and Events specification follows similar basics as Data Access and Historical Data Access specifications. The type of manipulated data differs from an OPC specification to another. In fact, unlike OPC DA specification that addresses real-time data and OPC HDA that addresses historical data, OPC AE manipulates alarms and events data.
The main goal of OPC AE specification is to define and provide a common communication interface for transferring real-time alarms and events data in the process control environment
A typical architecture of the OPC AE communication is as follows:
First an OPC AE Server is installed on the production level acting as a supervisor for a given manufacturer’s device in respect with OPC standard that defines the I/O operations. Therefore, all information retrieved from the device by the OPC Server via its specific API will be exposed as OPC alarms format.
Then and to allow access and acknowledgment of these alarms, one or many OPC AE Clients are installed anywhere in the manufacturer’s local network. An OPC AE Client will have the possibility to subscribe for all or for a filtered set of alarms notification and to acknowledged alarms.
Follow and to better explain the fundamentals of the OPC AE standard, I will try to answer to the most important questions that may include the following:
1. What is the purpose of the OPC AE specification?
The purpose of the OPC AE specification is to define interfaces used to notify the automation process control level by the areas of the process that require immediate attention. Therefore, it provides an industry standard that will enable communication of different components related to different providers in an heterogeneous environment.
The OPC AE specification is intended to increase the alarming solutions capabilities by the plug-n-play environment feature.
The OPC AE specification define a series of interfaces that provide the functionalities required by an OPC AE Client to be notified by the occurrence of an alarms and events and the services to query the OPC AE servers capabilities.
2. What is the difference between alarms and events?
An alarm is an abnormal condition.
An event is a detectable occurrence.
Therefore, the alarm and event meanings are not totally separate and can be related. They are not limited to safety limits of equipment, event detection or abnormal situations.
3. What is a condition?
A condition is a named state of the OPC AE Server. It can include multiple sub-conditions. Thus, a condition can be single state, or multi-state.
3.1 What is a multi-state condition?
A multi-state condition is one whose state encompasses multiple "ranges" or sub-states that are of interest
3.2 What is a single state condition?
A single state condition has only one sub-state of interest; and thus has only one sub-condition associated with it.
Condition definitions are server specific. It can be a Boolean expression or a text string message indicating an abnormal situation.
4. What is a sub-condition?
A sub-condition is a state of a condition. To better understand this, let us assume that we have a condition name C1 with this Boolean expression: 100 < CV < 1000. For this condition we can define multiple sub-conditions in order to get more information about the value generating the alarm. So we can have SB1 (100 < CV < 500) and SB2 (500 < CV < 1000)
5. What are the different types of alarms and events?
The OPC AE specifications define 3 types of events: Simple, Tracking and Condition.
6. How are event sources organized inside the OPC AE Server?
Event sources are organized as Area space and Event space.
7. What are the different operations that can be performed by an OPC AE Client?
The OPC AE Specification defines interfaces and methods to allow the OPC AE Client to:
- Query the configuration supported by the OPC AE Server including the type of event, the conditions names and sub-conditions names
- Subscribe to specified events. Thus, it can receive notifications of their occurrences.
8. How can the OPC AE Client filter on the events of interest?
This subscription is in fact characterized by a Filter. A Filter is a structure containing criteria for selecting events of interest to the client. To receive all events, the OPC Client can pass a null Filter as inputs.
Events may be selected using the following criteria: Type of event, Event categories, severity, Process areas and Event sources
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
mardi 23 janvier 2007
jeudi 18 janvier 2007
OPC Historical Data Access Specification: The industrial standard to share historian content on a transparent way
In the automation industry, data can be organized in three categories: real-time data, historical data and alarms.
Thus, OPC Foundation published its first industry OPC standard: OPC DA that handles the real-time data. In a second step, and to satisfy the strong need of the industrials of a standard manner to manage the historian retrieved from the process control level in a transparent way, the OPC Foundation released the second specification called OPC HDA. Its main goal is to provide a standard communication for the historical data between the software application and any specific system and/or industrial equipment.
The OPC HDA specification is then represented as a set of interfaces that handle historical data stored in archiving systems such as databases for analysis purposes.
A typical architecture of the OPC HDA communication is as follows:
The OPC HDA Server retrieves historian data from plant historian or any historian database.
Using OPC HDA, any OPC HDA Client can read either raw or processed data within a time range.
Besides reads, it can, depending on OPC HDA Server updates capabilities, insert into the historian database or deletes data at a given timestamp or through a time period.
It can also replace existing values in the historian. This can be useful in case data was updated by mistake.
Compared to OPC DA, OPC HDA standard is simpler because:
- It requires less OPC interfaces’ implementation: just 2 interfaces
- It is based on one type of object "OPCServer". There is no "OPCGroup" notion. In fact, items are manipulated at the server level without the scope of any container!
Although the simplicity of the OPC HDA specification, it is rich with fundamental concepts such as historical data processing (interpolation, average, maximum, etc) within time ranges that accommodate the best the industrial’s requirements.
In the following, I will try to clarify some points in the form of
Questions:
1. What are the possible data sources from which an OPC HDA Server can retrieve historian data? Is it possible to collect historical data from an OPC DA Server?
2. What are the types of OPC HDA Servers defined by the specification?
3. What are the minimum required functionalities that it is expected to offer a basic OPC HDA Server?
4. What are the possible read modes that can provide an OPC HDA Server?
5. What is the meaning of the parameter "Max Returned values"?
6. What do we mean by "processed data"?
7. What are the possible update operations that may offer an OPC HDA Server?
8. How can we know what the OPC Server supports as update functionalities?
9. Besides reads and updates, does OPC HDA standard offer other types of exchanging data between OPC client and OPC server?
10. Does HDA standard support asynchronous calls?
And responses:
1. What are the possible data sources from which an OPC HDA Server can retrieve historian data? Is it possible to collect historical data from an OPC DA Server?
With respect to the OPC HDA specification, data sources of historian data are not specified. It is up to the OPC HDA Server to define one or more data sources including:
any proprietary historian server (example PI and InFoPlus.21 systems), databases and an OPC DA Server. In fact, imagine you have an existing OPC DA Server and you want to expose history from the collected real time data. In such case, you can add an OPC HDA layer to the same server. Therefore, you will have an OPC DA/HDA Server that manipulates both real time and historical data.
2. What are the types of OPC HDA Servers defined by the specification?
We can distinguish two types of Historian Servers:
- Simple Trend data servers: these servers just offer simple raw data reads and some optional interfaces.
- Complex data compression and analysis servers: these servers provide reading of both raw and aggregated data, historian updates and other functionalities such as playback and annotations.
3. What are the minimum required functionalities that it is expected to offer a basic OPC HDA Server?
To build a basic OPC HDA Server, you need to implement IOPCHDA_Server and IOPCHDA_SyncRead interfaces. These interfaces define methods to get information about the OPC Server and to perform synchronous read raw data operation.
4. What are the possible read modes that can provide an OPC HDA Server?
We can distinguish the following read modes:
- Read raw data: allows reading raw data, for one or more HDA items, within a time range.
- Read at time data: allows reading data, for one or more HDA items, at a specified timestamp.
- Read processed (or aggregated) data: allows to read computed data by using analysis functions such as maximum and average, for one or more HDA items, within a time range.
- Read modified data: allows reading modified data, for one or more HDA items, within a time range.
- Playback: to get continual updates on the historical data
- Annotations: used to read and/or insert annotations relation to the HDA items in the history database.
5. What is the meaning of the parameter "Max Return values"?
Some OPC Servers could not manage a huge number of historian data values within a given time range. They have a significant server characteristic called "max returned value"; this parameter is useful in read calls in which the number of requested values to be read is specified. Then, if "max returned values" differs to 0, the total number of read values cannot bypass this limit anyway. If it is equal to 0, OPC Client can retrieve all the historical data during a specific time range without any restriction.
6. What do we mean by "processed data"?
Besides reading data as it is archived in the historian, an OPC HDA Server may provide summary data which is computed using a variety of analysis functions.
For example:
Using OPC HDA, it is possible to calculate hourly maximum data value during the last year in an efficient way.
7. What are the possible update operations that may offer an OPC HDA Server?
Standard OPC update capabilities are: insert, insert/replace, replace, delete at time and delete raw. But, it is up to the OPC Server to support a set of them (this set can be empty).
8. How can we know what the OPC Server supports as update functionalities?
OPC specification offers a method called "querycapabilities" to request for OPC Server update capabilities.
9. Besides reads and updates, does OPC HDA standard offer other types of exchanging data between OPC client and OPC server?
In addition to reads and updates, an OPC HDA Server can provide:
- reading of annotations for a given list of HDAA items for a specified time period
- playback functionality to allow reading receiving continual updates on the historical data
10. Does HDA standard support asynchronous calls?
Obviously, OPC HDA standard supports asynchronous calls for both reads and updates. HDA asynchronous concept is the same as in OPC DA
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
Thus, OPC Foundation published its first industry OPC standard: OPC DA that handles the real-time data. In a second step, and to satisfy the strong need of the industrials of a standard manner to manage the historian retrieved from the process control level in a transparent way, the OPC Foundation released the second specification called OPC HDA. Its main goal is to provide a standard communication for the historical data between the software application and any specific system and/or industrial equipment.
The OPC HDA specification is then represented as a set of interfaces that handle historical data stored in archiving systems such as databases for analysis purposes.
A typical architecture of the OPC HDA communication is as follows:
The OPC HDA Server retrieves historian data from plant historian or any historian database.
Using OPC HDA, any OPC HDA Client can read either raw or processed data within a time range.
Besides reads, it can, depending on OPC HDA Server updates capabilities, insert into the historian database or deletes data at a given timestamp or through a time period.
It can also replace existing values in the historian. This can be useful in case data was updated by mistake.
Compared to OPC DA, OPC HDA standard is simpler because:
- It requires less OPC interfaces’ implementation: just 2 interfaces
- It is based on one type of object "OPCServer". There is no "OPCGroup" notion. In fact, items are manipulated at the server level without the scope of any container!
Although the simplicity of the OPC HDA specification, it is rich with fundamental concepts such as historical data processing (interpolation, average, maximum, etc) within time ranges that accommodate the best the industrial’s requirements.
In the following, I will try to clarify some points in the form of
Questions:
1. What are the possible data sources from which an OPC HDA Server can retrieve historian data? Is it possible to collect historical data from an OPC DA Server?
2. What are the types of OPC HDA Servers defined by the specification?
3. What are the minimum required functionalities that it is expected to offer a basic OPC HDA Server?
4. What are the possible read modes that can provide an OPC HDA Server?
5. What is the meaning of the parameter "Max Returned values"?
6. What do we mean by "processed data"?
7. What are the possible update operations that may offer an OPC HDA Server?
8. How can we know what the OPC Server supports as update functionalities?
9. Besides reads and updates, does OPC HDA standard offer other types of exchanging data between OPC client and OPC server?
10. Does HDA standard support asynchronous calls?
And responses:
1. What are the possible data sources from which an OPC HDA Server can retrieve historian data? Is it possible to collect historical data from an OPC DA Server?
With respect to the OPC HDA specification, data sources of historian data are not specified. It is up to the OPC HDA Server to define one or more data sources including:
any proprietary historian server (example PI and InFoPlus.21 systems), databases and an OPC DA Server. In fact, imagine you have an existing OPC DA Server and you want to expose history from the collected real time data. In such case, you can add an OPC HDA layer to the same server. Therefore, you will have an OPC DA/HDA Server that manipulates both real time and historical data.
2. What are the types of OPC HDA Servers defined by the specification?
We can distinguish two types of Historian Servers:
- Simple Trend data servers: these servers just offer simple raw data reads and some optional interfaces.
- Complex data compression and analysis servers: these servers provide reading of both raw and aggregated data, historian updates and other functionalities such as playback and annotations.
3. What are the minimum required functionalities that it is expected to offer a basic OPC HDA Server?
To build a basic OPC HDA Server, you need to implement IOPCHDA_Server and IOPCHDA_SyncRead interfaces. These interfaces define methods to get information about the OPC Server and to perform synchronous read raw data operation.
4. What are the possible read modes that can provide an OPC HDA Server?
We can distinguish the following read modes:
- Read raw data: allows reading raw data, for one or more HDA items, within a time range.
- Read at time data: allows reading data, for one or more HDA items, at a specified timestamp.
- Read processed (or aggregated) data: allows to read computed data by using analysis functions such as maximum and average, for one or more HDA items, within a time range.
- Read modified data: allows reading modified data, for one or more HDA items, within a time range.
- Playback: to get continual updates on the historical data
- Annotations: used to read and/or insert annotations relation to the HDA items in the history database.
5. What is the meaning of the parameter "Max Return values"?
Some OPC Servers could not manage a huge number of historian data values within a given time range. They have a significant server characteristic called "max returned value"; this parameter is useful in read calls in which the number of requested values to be read is specified. Then, if "max returned values" differs to 0, the total number of read values cannot bypass this limit anyway. If it is equal to 0, OPC Client can retrieve all the historical data during a specific time range without any restriction.
6. What do we mean by "processed data"?
Besides reading data as it is archived in the historian, an OPC HDA Server may provide summary data which is computed using a variety of analysis functions.
For example:
Using OPC HDA, it is possible to calculate hourly maximum data value during the last year in an efficient way.
7. What are the possible update operations that may offer an OPC HDA Server?
Standard OPC update capabilities are: insert, insert/replace, replace, delete at time and delete raw. But, it is up to the OPC Server to support a set of them (this set can be empty).
8. How can we know what the OPC Server supports as update functionalities?
OPC specification offers a method called "querycapabilities" to request for OPC Server update capabilities.
9. Besides reads and updates, does OPC HDA standard offer other types of exchanging data between OPC client and OPC server?
In addition to reads and updates, an OPC HDA Server can provide:
- reading of annotations for a given list of HDAA items for a specified time period
- playback functionality to allow reading receiving continual updates on the historical data
10. Does HDA standard support asynchronous calls?
Obviously, OPC HDA standard supports asynchronous calls for both reads and updates. HDA asynchronous concept is the same as in OPC DA
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
dimanche 14 janvier 2007
OPC Data Access Specification: Handling real-time data according to the OPC Standard
OPC DA is acronym of OPC Data Access. This is the first specification published by OPC Foundation. It represents the most important one. Released versions include 1.0a, 2.05 and 3.0. But, the most used version is 2.05.
OPC DA is a set of interfaces that handle real time data by making available for read and/or write device’s information according to OPC standard format.
A typical architecture of the OPC DA communication is as follows: First an OPC DA Server is installed on the production level acting as a supervisor for a given manufacturer’s device in respect with OPC standard that defines I/O operations. Therefore, all information retrieved from the device via its specific API by the OPC Server will be exposed as OPC data. Then and to allow access and manipulation of this data, one or many OPC DA Clients are installed anywhere in the manufacturer’s local network. An OPC DA Client will have the possibility to perform read/write operations from/to the OPC Server.
Above is just a brief presentation of OPC DA standard. I guess you have a lot of questions that may include the following:
1. What is the type of information exposed by the OPC DA Server?
2. How can an OPC Server allow data access to any OPC Client?
3. Does an OPC Client have the possibility to get the current value of a tag without adding an OPC group?
4. What are the different operations that can be performed by an OPC Client?
5. What are the different read modes offered by an OPC Server?
6. Are updates made by an OPC Client available for other clients?
7. How can we customize the rate at which an OPC Client receives last values?
8. What is the difference between synchronous and asynchronous modes?
9. In which case we need to use asynchronous mode?
10. Is it possible to communicate OPC Server and OPC Client installed on different machines in the LAN?
In the following, I tried to answer briefly to all these questions:
1. What is the type of information exposed by the OPC DA Server?
An OPC DA Server is designed to collect and control real time data from any device. It makes retrieved data available to any OPC DA Client that complies with the same OPC specification supported by the OPC Server.
2. How can an OPC Server allow data access to any OPC Client?
The OPC Server retrieves the useful information (data points) from a given device by using its API calls. Then, these data points are represented, at the OPC Server level, as tags and may be gathered in branches. That’s called server address space.
Thus, a tag is simply a logical representation of a real data point in the device. Tag names are unique.
Go back to the OPC Client, firs of all, it connects to the OPC Server
and then gets a reference to requested tags to perform requested processing. That’s what we call DA item. Thus, a DA item is reference to a tag in the server address space available by:
- firstly adding a group that present a logical collection of the tags added by the OPC Client on the OPC Server side
- secondly adding an item to this group
3. Does an OPC Client have the possibility to get the current value of a tag without adding an OPC group?
No in the old specifications (1.0 and 2.0), but it became possible in the new one (3.0). The OPC DA specification offers an interface that allows the OPC Client to read the current value and other properties of any tag in the server address space. Available tag’s properties are defined by the OPC Server including:
- access rights
- engineering unit information
4. What are the different operations that can be performed by an OPC Client?
An OPC Client can:
- Retrieve information about the OPC server status
- Browse the server address space and read tags’ properties
- Read current items values
- Write new value to an added item
5. What are the different read modes offered by an OPC Server?
The OPC DA specification offers two (2) read modes:
- Read on demand: the OPC Client requests for reading data synchronously or synchronously
- Data changes: In this case, the OPC Client is informed of new data values by the PC Server whenever changes occur
6. Are updates made by an OPC Client available for other clients?
The OPC Server maintains a client session per connection. Every client session has its own groups and items. But write requests sent by an OPC Client are executed on real data points accessible as items. That’s why other connected OPC Clients are informed with these changes in case they added the same tags.
7. How can we customize the rate at which an OPC Client receives last values?
Items are gathered in groups to share common aspects such as read mode, write mode and the rate or frequency at which the OPC Client receives data values change. This frequency is the update rate of the group. It is expressed in milliseconds.
Example, you add an OPC group with an update rate of 1000 ms to receive data changes every 1 second.
8. What is the difference between synchronous and asynchronous modes?
In synchronous mode (read or write), the OPC Client sends the request and waits for the response to resume its processing. A synchronous call is blocking.
Whereas, in asynchronous mode, we distinguish two types of operations: call and callback.
The call is the request to send to OPC Server where all requested inputs are specified.
The callback is the response sent by the OPC Server at the appropriate moment.
In this case, the call is not blocking and the OPC Client can send its request without being dependant of the immediate response of the server.
9. In which case we need to use asynchronous mode?
In case of frequent data values change, it is recommended to use asynchronous mode to avoid blocking the OPC Client application.
10. Is it possible to communicate OPC Server and OPC Client installed on different machines in the LAN?
OPC standard is based on COM/DCOM technology. Therefore, the OPC solution can be deployed in a distributed environment.
In such case, OPC Server and OPC Client installed on different machines communicate through DCOM.
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
OPC DA is a set of interfaces that handle real time data by making available for read and/or write device’s information according to OPC standard format.
A typical architecture of the OPC DA communication is as follows: First an OPC DA Server is installed on the production level acting as a supervisor for a given manufacturer’s device in respect with OPC standard that defines I/O operations. Therefore, all information retrieved from the device via its specific API by the OPC Server will be exposed as OPC data. Then and to allow access and manipulation of this data, one or many OPC DA Clients are installed anywhere in the manufacturer’s local network. An OPC DA Client will have the possibility to perform read/write operations from/to the OPC Server.
Above is just a brief presentation of OPC DA standard. I guess you have a lot of questions that may include the following:
1. What is the type of information exposed by the OPC DA Server?
2. How can an OPC Server allow data access to any OPC Client?
3. Does an OPC Client have the possibility to get the current value of a tag without adding an OPC group?
4. What are the different operations that can be performed by an OPC Client?
5. What are the different read modes offered by an OPC Server?
6. Are updates made by an OPC Client available for other clients?
7. How can we customize the rate at which an OPC Client receives last values?
8. What is the difference between synchronous and asynchronous modes?
9. In which case we need to use asynchronous mode?
10. Is it possible to communicate OPC Server and OPC Client installed on different machines in the LAN?
In the following, I tried to answer briefly to all these questions:
1. What is the type of information exposed by the OPC DA Server?
An OPC DA Server is designed to collect and control real time data from any device. It makes retrieved data available to any OPC DA Client that complies with the same OPC specification supported by the OPC Server.
2. How can an OPC Server allow data access to any OPC Client?
The OPC Server retrieves the useful information (data points) from a given device by using its API calls. Then, these data points are represented, at the OPC Server level, as tags and may be gathered in branches. That’s called server address space.
Thus, a tag is simply a logical representation of a real data point in the device. Tag names are unique.
Go back to the OPC Client, firs of all, it connects to the OPC Server
and then gets a reference to requested tags to perform requested processing. That’s what we call DA item. Thus, a DA item is reference to a tag in the server address space available by:
- firstly adding a group that present a logical collection of the tags added by the OPC Client on the OPC Server side
- secondly adding an item to this group
3. Does an OPC Client have the possibility to get the current value of a tag without adding an OPC group?
No in the old specifications (1.0 and 2.0), but it became possible in the new one (3.0). The OPC DA specification offers an interface that allows the OPC Client to read the current value and other properties of any tag in the server address space. Available tag’s properties are defined by the OPC Server including:
- access rights
- engineering unit information
4. What are the different operations that can be performed by an OPC Client?
An OPC Client can:
- Retrieve information about the OPC server status
- Browse the server address space and read tags’ properties
- Read current items values
- Write new value to an added item
5. What are the different read modes offered by an OPC Server?
The OPC DA specification offers two (2) read modes:
- Read on demand: the OPC Client requests for reading data synchronously or synchronously
- Data changes: In this case, the OPC Client is informed of new data values by the PC Server whenever changes occur
6. Are updates made by an OPC Client available for other clients?
The OPC Server maintains a client session per connection. Every client session has its own groups and items. But write requests sent by an OPC Client are executed on real data points accessible as items. That’s why other connected OPC Clients are informed with these changes in case they added the same tags.
7. How can we customize the rate at which an OPC Client receives last values?
Items are gathered in groups to share common aspects such as read mode, write mode and the rate or frequency at which the OPC Client receives data values change. This frequency is the update rate of the group. It is expressed in milliseconds.
Example, you add an OPC group with an update rate of 1000 ms to receive data changes every 1 second.
8. What is the difference between synchronous and asynchronous modes?
In synchronous mode (read or write), the OPC Client sends the request and waits for the response to resume its processing. A synchronous call is blocking.
Whereas, in asynchronous mode, we distinguish two types of operations: call and callback.
The call is the request to send to OPC Server where all requested inputs are specified.
The callback is the response sent by the OPC Server at the appropriate moment.
In this case, the call is not blocking and the OPC Client can send its request without being dependant of the immediate response of the server.
9. In which case we need to use asynchronous mode?
In case of frequent data values change, it is recommended to use asynchronous mode to avoid blocking the OPC Client application.
10. Is it possible to communicate OPC Server and OPC Client installed on different machines in the LAN?
OPC standard is based on COM/DCOM technology. Therefore, the OPC solution can be deployed in a distributed environment.
In such case, OPC Server and OPC Client installed on different machines communicate through DCOM.
If you have questions not shown in the list above, please do not hesitate to send them to my email: hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
mercredi 10 janvier 2007
OPC Fundamentals
OLE is the acronym of Object Linking and Embedding. It is a technology provided by Microsoft offering the possibility to share information between applications and to provide a way to drive an application from another one.
Using such technology, it will be possible to improve the application functionalities based on the ones provided by another application.
DDE is the acronym of Dynamic Data Exchange. It is a Microsoft technology for exchanging information between two Windows applications according to a client/server model.
COM is the acronym of Component Object Model; based on a binary standard. It provides a way to ensure the interoperability between different processes without paying attention to the used development languages.
COM comes as an extension of the OLE technology. As a part of the operating system, it aims to provide a built-in standard component used to develop servers that offer various services to clients’ applications.
Using such technology, the software development will be more simple and more open, knowing that it is possible to consume existing services exposed by third-party COM servers.
With all these advantages, COM presents drawbacks. Among them, we can introduce the limitation of COM deployment on a Windows platform.
DCOM is the acronym of Distributed COM. It is a standard developed by Microsoft as an extension of the COM technology to offer the possibility to share data between different objects through the network.
OPC is the acronym of Ole for Process Control. It is a standard of interfaces based on COM/DCOM technology. This standard aims to provide interoperability in communication between software applications that supervise industrials equipments.
A typical OPC architecture is based on two components: an OPC server to handle communication with the equipments and an OPC client to read/write data from/to OPC server (from/to the equipment).
OPC Server is a software application that drives bi-directional communication with the equipment such as PLC, a database (DB) or any data source and expose collected data to the OPC Client.
OPC Client is a software application used to access (for reading and/or writing) information provided by the OPC Server through the OPC standard.
If you need additional definition or clarification, please do not hesitate to contact me at hassen.kouki@gmail.com.
Using such technology, it will be possible to improve the application functionalities based on the ones provided by another application.
DDE is the acronym of Dynamic Data Exchange. It is a Microsoft technology for exchanging information between two Windows applications according to a client/server model.
COM is the acronym of Component Object Model; based on a binary standard. It provides a way to ensure the interoperability between different processes without paying attention to the used development languages.
COM comes as an extension of the OLE technology. As a part of the operating system, it aims to provide a built-in standard component used to develop servers that offer various services to clients’ applications.
Using such technology, the software development will be more simple and more open, knowing that it is possible to consume existing services exposed by third-party COM servers.
With all these advantages, COM presents drawbacks. Among them, we can introduce the limitation of COM deployment on a Windows platform.
DCOM is the acronym of Distributed COM. It is a standard developed by Microsoft as an extension of the COM technology to offer the possibility to share data between different objects through the network.
OPC is the acronym of Ole for Process Control. It is a standard of interfaces based on COM/DCOM technology. This standard aims to provide interoperability in communication between software applications that supervise industrials equipments.
A typical OPC architecture is based on two components: an OPC server to handle communication with the equipments and an OPC client to read/write data from/to OPC server (from/to the equipment).
OPC Server is a software application that drives bi-directional communication with the equipment such as PLC, a database (DB) or any data source and expose collected data to the OPC Client.
OPC Client is a software application used to access (for reading and/or writing) information provided by the OPC Server through the OPC standard.
If you need additional definition or clarification, please do not hesitate to contact me at hassen.kouki@gmail.com.
What is OPC?
OPC is the acronym of OLE for Process Control. To better understand the meaning of OPC, let us first start by describing the problem before the creation of OPC, then we present the solution coming with it.
Assume that, in an industrial devices’ manufacturer, there are three different equipments (E1, E2, and E3) communicating respectively to three different providers (P1, P2 and P3), and we need to display exchanged real time data between these equipments in form of trends. The solution was to develop a specific module per provider; each one ensures communication with the correspondent equipment using the API of the provider related. Then, these modules are integrated to compose the final solution. Therefore, we developed as many modules as providers.
But what about this issue: How much we may investigate time and money to reuse this solution to support a different provider?
From here the industrials’ need emerged for the standardization of the way to read and write data to their devices. It is OPC!!
Now I will try to respond to the following questions. What is OPC? Who is the OPC creator? How did OPC resolve the issue described above?
OPC is a set of interfaces based on the COM/DCOM technology developed by Microsoft that provides interoperability between software applications and industrial equipments. OPC is based on a client/server architecture that allows one application to consume the services exposed by another one. A typical OPC solution is based on two components: on one hand, an OPC server to ensure communication with the device to get and/or to set data and on the other one, an OPC Client to access data made available by the server through its exposed interfaces.
OPC is defined by the OPC Foundation organization (www.opcfoundation.org) that has the responsibility to create and maintain the different OPC specifications (for more information about OPC Foundation, you can refer to the following link: http://www.opcfoundation.org/Default.aspx/01_about/01_history.asp?MID=AboutOPC)
Now, to respond to the last question about how did OPC resolve the issue described above? and according to the above description, using OPC, the industrial devices’ manufacturer could write three OPC servers applications that collect data respectively from P1, P2 and P3 and one and only one OPC Client application that communicates with the server applications to access and expose data as trends.
If you need additional information or you have any question, please do not hesitate to contact me at hassen.kouki@gmail.com. I would be more than happy to answer your requests.
Assume that, in an industrial devices’ manufacturer, there are three different equipments (E1, E2, and E3) communicating respectively to three different providers (P1, P2 and P3), and we need to display exchanged real time data between these equipments in form of trends. The solution was to develop a specific module per provider; each one ensures communication with the correspondent equipment using the API of the provider related. Then, these modules are integrated to compose the final solution. Therefore, we developed as many modules as providers.
But what about this issue: How much we may investigate time and money to reuse this solution to support a different provider?
From here the industrials’ need emerged for the standardization of the way to read and write data to their devices. It is OPC!!
Now I will try to respond to the following questions. What is OPC? Who is the OPC creator? How did OPC resolve the issue described above?
OPC is a set of interfaces based on the COM/DCOM technology developed by Microsoft that provides interoperability between software applications and industrial equipments. OPC is based on a client/server architecture that allows one application to consume the services exposed by another one. A typical OPC solution is based on two components: on one hand, an OPC server to ensure communication with the device to get and/or to set data and on the other one, an OPC Client to access data made available by the server through its exposed interfaces.
OPC is defined by the OPC Foundation organization (www.opcfoundation.org) that has the responsibility to create and maintain the different OPC specifications (for more information about OPC Foundation, you can refer to the following link: http://www.opcfoundation.org/Default.aspx/01_about/01_history.asp?MID=AboutOPC)
Now, to respond to the last question about how did OPC resolve the issue described above? and according to the above description, using OPC, the industrial devices’ manufacturer could write three OPC servers applications that collect data respectively from P1, P2 and P3 and one and only one OPC Client application that communicates with the server applications to access and expose data as trends.
If you need additional information or you have any question, please do not hesitate to contact me at hassen.kouki@gmail.com. I would be more than happy to answer your requests.
This is my first BLOG
This is my first BLOG entry. My name is Hassen KOUKI. I’m a Senior Software Developer for Secure and Real-Time Industrial Solutions based on OPC (OLE for Process Control) standard. During my experience, I have developed OPC solutions including clients, servers, gateways and toolkits in most programming languages and environments. In fact, I have programming skills in C/C++, MFC, VB, C#, Java, JNIWrapper, ASP, and ASP.NET. In addition to that, I’m used to work with relational databases such as Oracle and SQL Server and some interesting systems including G2 Expert system, ICONICS, PI and InfoPlus.21 systems.
Regarding this weblog, its goal is to provide help for users and developers using the OPC (OLE for Process Control) standard. This industrial standard of interface is designed to allow communication between different providers in transparent way.
This weblog will contain a background about the OPC standard and its related specifications, the COM/DCOM technology, a presentation of some useful OPC tools as well us some OPC tutorials.
Thanks for your attention in my work and I hope that it will help you.
If you need additional information and if you have any question, please do not hesitate to contact me. I would be more than happy to answer your requests. Please contact me at (00216) 23456445 or via email to hassen.kouki@gmail.com
Regarding this weblog, its goal is to provide help for users and developers using the OPC (OLE for Process Control) standard. This industrial standard of interface is designed to allow communication between different providers in transparent way.
This weblog will contain a background about the OPC standard and its related specifications, the COM/DCOM technology, a presentation of some useful OPC tools as well us some OPC tutorials.
Thanks for your attention in my work and I hope that it will help you.
If you need additional information and if you have any question, please do not hesitate to contact me. I would be more than happy to answer your requests. Please contact me at (00216) 23456445 or via email to hassen.kouki@gmail.com
Inscription à :
Articles (Atom)