OPC Security specification is defined by OPC Foundation to protect sensitive information from unauthorized access.
The main goal of this entry is to introduce the basic security concepts as well as describing how the security is implemented on both OPC Server and OPC Client levels to ensure secure communication.
1. What means «Authentication»?
It’s the process of controlling the eligibility of a user to access an object.
2. What means «Authorization»?
It’s the process of determining what types of activities are permitted to a given user.
3. What is the relationship between «Authentication» and «Authorization»?
We introduce the authorization in the context of authentication. In fact, once the user is authenticated, he may be authorized to different types of access or activities.
4. What is the goal of the OPC Security specification?
This specification focuses on the client identification that consists in the exchange of trusted credentials to be used by the OPC Server for access authorization decisions. It does not address which objects to be secured. It leaves this matter to the OPC Server implementers.
5. What are the possible OPC Server security levels?
There are three security levels that can be implemented by an OPC Server:
- Disabled Security: No security is applied in this case. Launch and Access permissions to the OPC Server are given to everyone (for client to server communication), and Access permissions for clients are set to everyone (for server to client communication).
No control of the access to any vendor specific secured object is applied by the OPC Server.
In this case, an OPC Client without any security implementation can connect to the OPC Server.
- DCOM Security: Only NT DCOM security is applied in this case. Launch and Access permissions to the OPC Server are limited to selected clients, as are the Access permissions for client applications.
No access control of any vendor specific secured object is applied by the OPC Server.
In this case, an OPC Client without any security implementation can connect to the OPC Server.
- OPC Security: In this case, the OPC Server provides a control of the access to vendor specific security objects that are exposed by the OPC Server. An OPC Server may implement OPC Security in addition to DCOM Security, or implement OPC Security alone.
In this case, and according to the security model implemented by the OPC Server:
- For the NT credential security model, an OPC Client without any security implementation can connect to the OPC Server.
- For the private credential security model, an OPC Client without any security implementation can connect to the OPC Server but will receive access denied when trying to access to any secured objects.
6. What are the possible security modes that can be implemented by an OPC Server?
The principal security mode that should be implemented by an OPC Server is the NT security (handled by IOPCSecurityNT interface) mode where the security is based on the access authorization of the NT Access Token associated with the client application. This approach allows security to be transparent to client applications and ensure the portability of the client applications (There is no special action in the OPC Server side).
However there are some situations where this mode cannot be used such as:
- The machine hosting the OPC Server does not support an NT operating system such Windows CE and UNIX
- The machine hosting the OPC Client does not support the NT Access Token
- The machines hosting the OPC Server and the OPC Client are outside the context of an NT Domain.
To address such situations, the OPC Server can implement the private credential security mode (handled by the IOPCSecurityPrivate interface).
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 20 février 2007
jeudi 8 février 2007
OPC Miscellaneous
After I briefly overviewed the most known OPC specifications, I would like to give you an idea about important OPC miscellaneous that will be frequently used in the coming blogs.
What are the OPC Servers types?
There are two types of OPC Servers: in-process and out-process servers.
In-process servers are written in form of a Dynamic Link Library (DLL) loaded in the OPC Client’s process space.
Thus, each OPC Client application manages its own Server instance.
Whereas, out-process servers are standalone applications. Therefore, an out-process server is written in form of an executable. It can be launched by any OPC Client locally or remotely. In multiple OPC connections, all OPC Clients connect to the same instance of the OPC Server’s application. This allows OPC Server application to share data between all its OPC Clients.
In-process servers are better than out-process servers in term of speed and performance.
How OPC components communicate locally and remotely?
OPC components can communicate on the same machine through LPC (Local Procedure Call).
They can also communicate on distributed computers using RPC (Remote Procedure Call).
How can the OPC Server be launched?
An OPC Server can be launched as an executable or run on background as Windows service.
Like any service, the OPC Server’s service can be managed (start, stop, pause) from the Service Control Manager (SCM).
What do you mean by DCOMCNFG?
Microsoft offers a Windows built-in tool called DCOMCNFG used to define DCOM settings for COM applications.
You can launch it by typing dcomcnfg on Start | Run.
DCOMCNFG window is mainly composed of the following tabs:
- Default Properties: to enable/disable DCOM and set the default communication properties for DCOM (authentication level and impersonation level). The authentication level specifies if the authentication of the caller is requested. If it is the case, you have to set the permission to honor (authentication only at the connection step, at every call, etc).
The impersonation level specifies whether the applications can determine who is calling them; and in which manner the identity of the caller is used.
- Default COM Security: to set permissions for the users that can access COM applications and those who can launch them.
- Default Protocols: to order by priority the network protocol to be used by DCOM. "Connection-oriented TCP/IP" is the default setting.
Using DCOMCNFG, you can either set a general configuration to be applied to all COM applications installed on the local machine or define custom configuration for a specific application.
In Windows XP, DCOMCNFG window layout differs a little bit from Windows 2000.
You need just to:
- Double-click "Components services"
- Expand Computers node. You will get the "My Computer" node.
- From the contextual menu, click "Properties" to get a window for general configuration
If you want to define specific settings, double-click on "My Computer" node and expand the "DCOM config" entry. Then, you select the application you are interested in and click on the contextual menu "Properties".
What is an AppID?
DCOMCNFG lists only applications that have an AppID. It is a GUID that uniquely identifies the application executable.
AppIDs are stored in the Registry under the HKEY_CLASSES_ROOT\AppID key.
Each application’s AppID entry groups all settings for distributed COM objects hosted by the application executable. We can enumerate these settings: AccessPermission, AuthenticationLevel and LaunchPermission.
What is a CLSID? ProgID?
A CLSID is a 128 bit number that uniquely identify a software component. There are 218 possible unique values. This large number makes the probability to find two equal CLSIDs very small.
CLSIDs are generated by the Microsoft’ useful tool called GUIDGEN.exe (based on the COM call CoCreateGuid).
Back to OPC standard, every OPC Server should have its own CLSID.
So that any OPC Client can identify the OPC Server to which it wants to connect.
But, this identifier is quite difficult to manipulate and remember for more than one OPC Server. To make things easier, an OPC Server is rather identified by a human readable name of string type called ProgID. Generally, the ProgID format is as follows:...
What are callbacks?
In asynchronous communication, the OPC Client does not receive the final results when receiving the request result (success/failure). The request is processed in two steps: call and callback. For example: Read request
- Firstly, the OPC Server returns a preliminary error codes and no values (call).
- Secondly, the OPC Server sends a callback to the OPC Client with the requested values in case of success.
Giving this scenario, the OPC Server and OPC Client roles are reversed. In fact, the OPC Server behaves as a COM client and the OPC Client as a COM object.
This is very important to understand because we should take it in our account when configuring DCOM. Any bad DCOM configuration may cause a problem of not receiving data changes at the OPC Client side.
What is OPCENUM?
OPCENUM is the OPC Server Browser. It is a COM object (Server) that offers interfaces for browsing local and remote OPC Servers. OPC Foundation published until now versions 1.1 and 1.2.
OPCENUM can run as an executable or a Windows Service.
Before using it, you should register it.
Apply this command line "opcenum.exe /RegServer" to register OPCENUM as an executable.
Or, this command line "opcenum.exe /Service" to register OPCENUM as a service.
What is Registry?
The Windows Registry is a database that stores all your system information and settings.
This includes all hardware, installations, operating system, users, etc. It also contains all registered OPC Servers (server type: local or in-process, full path, implemented categories and vendor information).
For example, any change made through DCOMCNFG is saved to the Registry.
Thus, the Registry reflects the current configuration of your system.
How can we update the Registry content?
We can update the Registry content in different ways:
- Applying a *.reg file, you will be prompted to confirm changes
- Programmatically: by using the Windows 32-Bit Registry API: it contains functions starting with RegXXX
- From the Registry window: type regedit (Start | Run) and manipulate Registry entries graphically
How can we modify the Registry access privileges?
Assume you are logged with an Administrator account.
You can define the permissions for the Registry by using the tool Regedt32.
To run it, click Start | Run and type Regedt32.
Windows XP integrated this utility into Regedit.exe.
Can we access the Registry of a remote machine? How?
It is possible if you have the privileges to access the remote Registry.
Launch the Registry Editor through:
Run => regedit => File => Connect Network Registry…
If you need additional definition or clarification, please do not hesitate to contact me at hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
What are the OPC Servers types?
There are two types of OPC Servers: in-process and out-process servers.
In-process servers are written in form of a Dynamic Link Library (DLL) loaded in the OPC Client’s process space.
Thus, each OPC Client application manages its own Server instance.
Whereas, out-process servers are standalone applications. Therefore, an out-process server is written in form of an executable. It can be launched by any OPC Client locally or remotely. In multiple OPC connections, all OPC Clients connect to the same instance of the OPC Server’s application. This allows OPC Server application to share data between all its OPC Clients.
In-process servers are better than out-process servers in term of speed and performance.
How OPC components communicate locally and remotely?
OPC components can communicate on the same machine through LPC (Local Procedure Call).
They can also communicate on distributed computers using RPC (Remote Procedure Call).
How can the OPC Server be launched?
An OPC Server can be launched as an executable or run on background as Windows service.
Like any service, the OPC Server’s service can be managed (start, stop, pause) from the Service Control Manager (SCM).
What do you mean by DCOMCNFG?
Microsoft offers a Windows built-in tool called DCOMCNFG used to define DCOM settings for COM applications.
You can launch it by typing dcomcnfg on Start | Run.
DCOMCNFG window is mainly composed of the following tabs:
- Default Properties: to enable/disable DCOM and set the default communication properties for DCOM (authentication level and impersonation level). The authentication level specifies if the authentication of the caller is requested. If it is the case, you have to set the permission to honor (authentication only at the connection step, at every call, etc).
The impersonation level specifies whether the applications can determine who is calling them; and in which manner the identity of the caller is used.
- Default COM Security: to set permissions for the users that can access COM applications and those who can launch them.
- Default Protocols: to order by priority the network protocol to be used by DCOM. "Connection-oriented TCP/IP" is the default setting.
Using DCOMCNFG, you can either set a general configuration to be applied to all COM applications installed on the local machine or define custom configuration for a specific application.
In Windows XP, DCOMCNFG window layout differs a little bit from Windows 2000.
You need just to:
- Double-click "Components services"
- Expand Computers node. You will get the "My Computer" node.
- From the contextual menu, click "Properties" to get a window for general configuration
If you want to define specific settings, double-click on "My Computer" node and expand the "DCOM config" entry. Then, you select the application you are interested in and click on the contextual menu "Properties".
What is an AppID?
DCOMCNFG lists only applications that have an AppID. It is a GUID that uniquely identifies the application executable.
AppIDs are stored in the Registry under the HKEY_CLASSES_ROOT\AppID key.
Each application’s AppID entry groups all settings for distributed COM objects hosted by the application executable. We can enumerate these settings: AccessPermission, AuthenticationLevel and LaunchPermission.
What is a CLSID? ProgID?
A CLSID is a 128 bit number that uniquely identify a software component. There are 218 possible unique values. This large number makes the probability to find two equal CLSIDs very small.
CLSIDs are generated by the Microsoft’ useful tool called GUIDGEN.exe (based on the COM call CoCreateGuid).
Back to OPC standard, every OPC Server should have its own CLSID.
So that any OPC Client can identify the OPC Server to which it wants to connect.
But, this identifier is quite difficult to manipulate and remember for more than one OPC Server. To make things easier, an OPC Server is rather identified by a human readable name of string type called ProgID. Generally, the ProgID format is as follows:
What are callbacks?
In asynchronous communication, the OPC Client does not receive the final results when receiving the request result (success/failure). The request is processed in two steps: call and callback. For example: Read request
- Firstly, the OPC Server returns a preliminary error codes and no values (call).
- Secondly, the OPC Server sends a callback to the OPC Client with the requested values in case of success.
Giving this scenario, the OPC Server and OPC Client roles are reversed. In fact, the OPC Server behaves as a COM client and the OPC Client as a COM object.
This is very important to understand because we should take it in our account when configuring DCOM. Any bad DCOM configuration may cause a problem of not receiving data changes at the OPC Client side.
What is OPCENUM?
OPCENUM is the OPC Server Browser. It is a COM object (Server) that offers interfaces for browsing local and remote OPC Servers. OPC Foundation published until now versions 1.1 and 1.2.
OPCENUM can run as an executable or a Windows Service.
Before using it, you should register it.
Apply this command line "opcenum.exe /RegServer" to register OPCENUM as an executable.
Or, this command line "opcenum.exe /Service" to register OPCENUM as a service.
What is Registry?
The Windows Registry is a database that stores all your system information and settings.
This includes all hardware, installations, operating system, users, etc. It also contains all registered OPC Servers (server type: local or in-process, full path, implemented categories and vendor information).
For example, any change made through DCOMCNFG is saved to the Registry.
Thus, the Registry reflects the current configuration of your system.
How can we update the Registry content?
We can update the Registry content in different ways:
- Applying a *.reg file, you will be prompted to confirm changes
- Programmatically: by using the Windows 32-Bit Registry API: it contains functions starting with RegXXX
- From the Registry window: type regedit (Start | Run) and manipulate Registry entries graphically
How can we modify the Registry access privileges?
Assume you are logged with an Administrator account.
You can define the permissions for the Registry by using the tool Regedt32.
To run it, click Start | Run and type Regedt32.
Windows XP integrated this utility into Regedit.exe.
Can we access the Registry of a remote machine? How?
It is possible if you have the privileges to access the remote Registry.
Launch the Registry Editor through:
Run => regedit => File => Connect Network Registry…
If you need additional definition or clarification, please do not hesitate to contact me at hassen.kouki@gmail.com. I will be more than happy to answer you within hours.
mardi 6 février 2007
OPC Data eXchange Specification: Enabling horizontally data exchange between OPC based systems
OPC DX is acronym of OPC Data eXchange.
By March 2003, OPC Foundation released the new specification OPC Data eXchange version 1.0.
Unlike OPC DA, HDA and AE standard that were defined to manage a specific sector in the automation world: OPC DA for real time data that represents the current state of connected devices, OPC HAD for historical data stored in archiving systems and OPC AE for alarms and events generated in the industry,
OPC DX does not target a new domain in the industry. It rather constitutes a complimentary standard for the following reasons:
- OPC DX specification is not coming with a new type of data to manage. It is designed for communication with OPC DA servers. Consequently, it manages real time data.
- OPC DX ensures horizontal communication between OPC servers. Whereas other standards specify vertical data transfer from/to OPC Server/OPC Client.
This standard is based on the OPC DA specification with a thin layer acting as an OPC DA Client for specific goals. Imagine you are in a factory where you have a set of equipments that need to exchange their I/O data. Let us focus on two specific equipments belonging to this set. With an OPC architecture, an OPC DA server (DA1) is installed to supervise sensor 1. A second OPC Server (DA2) is installed to supervise sensor 2. If the pressure of sensor 1 exceeds x, then the temperature of sensor 2 should be multiplied by 1.5. Instead of developing a specific gateway to collect the current pressure of sensor 1 and updates the temperature of sensor 2 through DA2 at the appropriate moment,
An OPC DX server can be installed on sensor 2 to collect directly last pressure value from DA1 and updates the temperature of sensor 2 in the most efficient way.
That’s why an OPC DX server is the combination of an OPC DA Server and OPC Client layer.
Giving this architecture, we can distinguish:
- An OPC source server from which data is collect
- An OPC target server that collect the data for its own processing. The target server must be OPC DX.
To allow this horizontal data exchange between OPC servers, following are the general configuration steps to respect:
- DX configuration by using an OPC DX client to define: source servers and DX connections. OPC DX permits data transfer through a logical container of data exchange called DX connection. It defines the source item, the target item and other parameters.
- After that, data transfer is controlled from any OPC DA client connecting to the DX server
Above is just a brief presentation of OPC DX standard. I guess you have a lot of questions that may include the following:
1- How much data transfers it is allowed?
This means how many DX connections can be configured in the OPC DX server. The OPC DX specification defines a DX Server status flag called MaxDxConnections. This flag determines the maximum number of supported DXConnections by the DX server.
2- How OPC DX standardize the data transfer between OPC servers?
OPC DX specification defines a new OPC interface called IOPCConfiguration to manage DX connections and source servers (add, remove, query and update).
DXConnections and source servers’ management is performed by any OPC DX Client.
This step is called DX configuration.
3- Where the DX configuration is stored?
The current DX Server configuration is stored in the server DX DataBase. The DX DataBase can be saved in any media such as XML file.
4- What is the DX DataBase?
In addition to collected DA tags, the OPC DX Server maintains a reserved subtree named “DX” under the root of its address space for DX items. This subtree is called DX DataBase. It contains 3 braches at the top level:
- ServerStatus: provides information about the DX Server status such as DXConnectionCount, MaxDXConnections and SourceServersTypes (the supported DA versions for source servers).
- DXConnectionRoot: contains all configured DX connections
- SourceServers: contains all configured source servers
5- What is the role of the DA Client communicating with the DX Server?
The DA Client can monitor and control the DX Server through runtime attributes of DXConnections such as:
- DXConnectionState
- WriteValue, WriteQuality, WriteTimestamp
- WriteErrorID, WriteErrorDiagnostic
- Etc.
A DXConnection is represented as a read-only OPC DA item.
6- When the data transfer is started?
Once the DX configuration step is performed successfully, the DX Server opens a DXConnection under the following conditions:
- the attribute “SourceServerConnected” of the requested source server is TRUE
- At least one DXConnection among the configured ones whose source server is this server and its SourceItemConnected attribute is TRUE
Under the conditions above, the data exchange is automatically started even though there is no OPC DA/DX client connected to the DX server.
7- What are the types of data transfer defined by OPC DX?
The OPC DX specification does not have any restrictions on this matter. In fact, this can be a simple copy of data, any mathematic operation (sin, cos, arithmetic, etc). OPC DX unifies the way to collect data from source servers; and it is up to the target server to perform any processing on the received data values.
8- What are the OPC DA versions supported by OPC DX?
The supported versions are DA2, DA3 and XML-DA.
Although benefits of OPC DX standard since it enables data exchange between heterogeneous systems from various vendors, this standard was not very welcomed by industrials. Unfortunately, this standard is dying!!
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.
By March 2003, OPC Foundation released the new specification OPC Data eXchange version 1.0.
Unlike OPC DA, HDA and AE standard that were defined to manage a specific sector in the automation world: OPC DA for real time data that represents the current state of connected devices, OPC HAD for historical data stored in archiving systems and OPC AE for alarms and events generated in the industry,
OPC DX does not target a new domain in the industry. It rather constitutes a complimentary standard for the following reasons:
- OPC DX specification is not coming with a new type of data to manage. It is designed for communication with OPC DA servers. Consequently, it manages real time data.
- OPC DX ensures horizontal communication between OPC servers. Whereas other standards specify vertical data transfer from/to OPC Server/OPC Client.
This standard is based on the OPC DA specification with a thin layer acting as an OPC DA Client for specific goals. Imagine you are in a factory where you have a set of equipments that need to exchange their I/O data. Let us focus on two specific equipments belonging to this set. With an OPC architecture, an OPC DA server (DA1) is installed to supervise sensor 1. A second OPC Server (DA2) is installed to supervise sensor 2. If the pressure of sensor 1 exceeds x, then the temperature of sensor 2 should be multiplied by 1.5. Instead of developing a specific gateway to collect the current pressure of sensor 1 and updates the temperature of sensor 2 through DA2 at the appropriate moment,
An OPC DX server can be installed on sensor 2 to collect directly last pressure value from DA1 and updates the temperature of sensor 2 in the most efficient way.
That’s why an OPC DX server is the combination of an OPC DA Server and OPC Client layer.
Giving this architecture, we can distinguish:
- An OPC source server from which data is collect
- An OPC target server that collect the data for its own processing. The target server must be OPC DX.
To allow this horizontal data exchange between OPC servers, following are the general configuration steps to respect:
- DX configuration by using an OPC DX client to define: source servers and DX connections. OPC DX permits data transfer through a logical container of data exchange called DX connection. It defines the source item, the target item and other parameters.
- After that, data transfer is controlled from any OPC DA client connecting to the DX server
Above is just a brief presentation of OPC DX standard. I guess you have a lot of questions that may include the following:
1- How much data transfers it is allowed?
This means how many DX connections can be configured in the OPC DX server. The OPC DX specification defines a DX Server status flag called MaxDxConnections. This flag determines the maximum number of supported DXConnections by the DX server.
2- How OPC DX standardize the data transfer between OPC servers?
OPC DX specification defines a new OPC interface called IOPCConfiguration to manage DX connections and source servers (add, remove, query and update).
DXConnections and source servers’ management is performed by any OPC DX Client.
This step is called DX configuration.
3- Where the DX configuration is stored?
The current DX Server configuration is stored in the server DX DataBase. The DX DataBase can be saved in any media such as XML file.
4- What is the DX DataBase?
In addition to collected DA tags, the OPC DX Server maintains a reserved subtree named “DX” under the root of its address space for DX items. This subtree is called DX DataBase. It contains 3 braches at the top level:
- ServerStatus: provides information about the DX Server status such as DXConnectionCount, MaxDXConnections and SourceServersTypes (the supported DA versions for source servers).
- DXConnectionRoot: contains all configured DX connections
- SourceServers: contains all configured source servers
5- What is the role of the DA Client communicating with the DX Server?
The DA Client can monitor and control the DX Server through runtime attributes of DXConnections such as:
- DXConnectionState
- WriteValue, WriteQuality, WriteTimestamp
- WriteErrorID, WriteErrorDiagnostic
- Etc.
A DXConnection is represented as a read-only OPC DA item.
6- When the data transfer is started?
Once the DX configuration step is performed successfully, the DX Server opens a DXConnection under the following conditions:
- the attribute “SourceServerConnected” of the requested source server is TRUE
- At least one DXConnection among the configured ones whose source server is this server and its SourceItemConnected attribute is TRUE
Under the conditions above, the data exchange is automatically started even though there is no OPC DA/DX client connected to the DX server.
7- What are the types of data transfer defined by OPC DX?
The OPC DX specification does not have any restrictions on this matter. In fact, this can be a simple copy of data, any mathematic operation (sin, cos, arithmetic, etc). OPC DX unifies the way to collect data from source servers; and it is up to the target server to perform any processing on the received data values.
8- What are the OPC DA versions supported by OPC DX?
The supported versions are DA2, DA3 and XML-DA.
Although benefits of OPC DX standard since it enables data exchange between heterogeneous systems from various vendors, this standard was not very welcomed by industrials. Unfortunately, this standard is dying!!
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
OPC Alarms and Events Specification: Handling real-time access to alarms and events in the industry
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.
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.
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)