What is the difference between the OPC-Router and Kepserverex? I have seen a solution where both of them were used - Kepserverex connecting to machines and sending data to the OPC-Router which then sends data to IT Applications. Couldn't one of them do both tasks together?
I did compare the features of both products, but couldn't figure out why you would use one or the other - or both together. Both products seem to support data exchange between different protocols and platforms.
The KepServerEX is an OPC Server. Connecting over 150 different kinds of machines and providing their data as OPC UA data for OPC Clients.
The OPC Router is an OPC Client and is a tool for system integration. With the OPC Router it is possible to transfer data between systems whenever the data is needed (triggered). So the OPC Router connects systems like SAP, databases, label printers and a lot more and moves data between them. This also includes workflow-like data transfers, like calling a Stored Procedure in a database with a defined set of input parameters and transferring the returned values back to another system (maybe to the PLC over OPC UA => over the KepServerEX). In general you enable systems to interact with each other by the OPC Router. And this is where Industry 4.0 starts.
Greetings from the inray-Team
Related
I am new to OPC UA,
Our requirement is that the OPC UA Client app will do the reads/write data from/to a backend system (which is the system of record) via a OPC UA server. How can we represent the backend system C# objects in an OPC UA Server? So that the data gets directly updated in the backend system rather being on nodes(nodes object), we are more concerned on the duplicate data in both places (OPC UA server and Backed system) and also the data need to be UPTODATE on both the OPCUA server and backend system
I know this is not exactly an answer but maybe it can help you.
Look in the https://github.com/OPCFoundation/UA-.NETStandard-Samples with the Quickstarts and especially AlarmCondition Server. There you see a simple implementation of an "Underlying System".
Maybe this can be of help?
In other words, is it possible for a server or a client to receive partial data before the transmission is finished?
I am sure this information is written somewhere in the extensive documentation of the OPC Foundation, but I think this is essential.
I am using the "atomic" phrase as used for database writes. When a programmer updates a table, the update is always atomic in the sense that it is either done or not done. We rely on the DB software for guaranteeing against the operation being only partially successful.
In the case of a PLC acting as an OPC UA server; when the client writes say 1 KByte data, are we sure that the program running on the PLC, on any instant read a part of this data while it is still being communicated and written? Since we are dealing with a very fast reading entity (the PLC) on the other side of the communication, is it possible that the PLC gets the first 100 bytes before the rest is received?
In the case of a PLC acting as an OPC UA server; when the client writes say 1 KByte data, are we sure that the program running on the PLC, on any instant read a part of this data while it is still being communicated and written?
You can be certain that any server will not be processing any read or write until the request has been fully transmitted by the client. There is no facility in OPC UA for dealing with streaming/partial requests from clients.
That said, how the server handles that 1KB of data it just received as a write is not covered by spec. There is no guarantee that it is written atomically to whatever the backing/underlying datasource may be (in memory, shared memory, a file, another device on the network, etc...).
I do believe that most OPC UA servers built in to PLCs are probably doing the right thing to ensure atomicity but there is nothing in the spec that guarantees it and no way to be sure other than contacting that vendor or consulting documentation.
Beckhoff OPC-UA Server communicates with the Beckhoff PLC through the ADS protocol.
The default Max Size of the consistent data sent with the help of the ads router is 16 kByte although it can be changed if needed.
This is important to understand, because the OPC-UA Server is not part of the PLC runtime environment.
When an OPC-UA client writes a node of an OPC-UA Server, the OPC-UA Server sends this data to the PLC.
In the Twincat development environment you have the option to declare a special attribute for structured types:
{attribute 'OPC.UA.DA.StructuredType' := '1'}
This tells the Beckhoff OPC-UA Server to send the data concerning that specific data structure in a consistent way to the PLC when it receives it from a client.
The Beckhoff OPC-UA documentation states:
"StructuredTypes allow you to read or write structures without interpreting each byte, because the UA Server
returns the information type of each element of the structure. Based on complex functions in modern
OPC UA SDKs, OPC UA Clients can search and interpret this structural information."
Therefor, regarding data consistency, it is also important that your OPC-UA SDK (client) is modern enough to be able to "search and interpret this structural information".
The answer is provided by Flippo & Kevin in the above comments. So this will be a recap for everyone to quickly spot:
OPC UA guarantees atomicity only for simple types (Integer, Double Integer etc)
Longer structures' atomicity depends on the specific manufacturer.
I am expected to design the solution for collecting/processing samples from a PLC device, and working with some control tags of the device. Please, suggest the approach. Sorry for the long question. I will split it to more questions after learning what are the smaller and more reasonable subjects/questions.
The solution for the company is built almost from scratch. There are some PLC devices, and there is a KEPServerEx (without the IoT Gateway). The PLC devices are already used through the third party proprietary software. But there is no "bigger framework" for future. From that point of view, I can introduce a modern design, but the budget is restricted.
From what I have learned so far, it seems that the KEPServerEx is a good choice for accessing PLC devices, but I have no hands-on experience with it. It seems to me that the OPC UA should be the choice over the older OPC (DA). I am also aware of the ladder way of working with PLC.
From what I have learned about "IoT Gateway" (which will not be used) for KEPServerEx, the KepServer can set the sampling frequency at the PLC tag level. And also the frequency of transferring the data can be set by IoT Gateway. The IoT Gateway then uses an internal (memory) buffer for storing the sampled values, and the tuples (tagID, value, quality, timestamp) can be read and passed to third party.
What is not clear to me is, how to do that without the IoT Gateway. I assume that it must be a basic operation. Is the (tagID, value, quality, timestamp) generic for working with PLC through any OPC server? Or is it generic only for KEPServerEx, or is it special for the IoT Gateway (optional) plugin?
I have learned that OPC Foundation added recently the Publih/Subscribe mechanism to the OPC UA. Does it require also newer version of KEPServerEx? Or can it be used with any earlier OPC server?
I am fairly experienced in programming and database things. I also have some technical background in industrial sensors, actuators,... However, I have never worked with digital automation in industry.
Thanks, and have a nice day.
Depending on the PLC you want to communicate with, and the communication network your devices will be transmitting data on, you need to purchase the appropriate driver package so that KEPServerEX can communicate with it.
For example:
If your PLC is an Omron NJ PLC, and it is on an Ethernet network with the server that KEPServerEX is residing on, you will need to use the "Omron NJ Ethernet" driver in the suite package Kepware offers called the "Omron Suite".
Regarding your question about the IoT Gateway:
From what I have learned about "IoT Gateway" (which will not be used) for KEPServerEx, the KepServer can set the sampling frequency at the PLC tag level. And also the frequency of transferring the data can be set by IoT Gateway. The IoT Gateway then uses an internal (memory) buffer for storing the sampled values, and the tuples (tagID, value, quality, timestamp) can be read and passed to third party.
This can be done without the IoT Gateway, by using the appropriate aforementioned driver, and then using another driver package to send the PLC data to wherever you would like (ODBC client, SQL Server database, etc.). It depends on what you want to do with the data you are acquiring.
When you talk to a specific device you need to know the protocol that the device uses and those protocols can vary really much.
Sometimes the manufacturer of a device provides an OPC server that shields you from this or as you mention a 3rd party Connectivity server like KepServerEx or Matrikon can be used presenting an OPC interface for your client to use.
I don't know anything about the KepServerEx or your particular requirements but normally an OPC server has a cache where values are stored from which the client can read from alternatively read directly from the hardware. Subscriptions can be configured similarly e.g. frequency, threshold etc.
The protocol from the OPC sever/3rd party to the device determines the frequency in which you can sample values. E.g. some protocols need the device to be polled for values, some are more elaborate.
If you create an OPC client then you are pretty much free what kind of OPC server you connect to whether it is a 3rd party or an OPC server from the manufacturer and having the client storing values whenever items in a subscription changes is pretty trivial.
If you are familiar with Visual Studio, then AdvancedHMI may be a possible solution. You did not mention any specific PLCs, but AdvancedHMI includes many PLC communication drivers as part of the free package. This gives you the ability to write VB or C# for transferring the values from the PLCs to a database. The drivers are not OPC drivers, but are designed to be much simpler to use and more efficient.
We are looking for a solution for collecting data from different SCADA systems. It seems that OPC UA is a good approach for that. Data collection will be done from a single system to multiple SCADA systems over the internet (https). So, we are planning to develop a OPC UA client that can connect to multiple OPC UA servers. Data will be collected with a given interval. The system should be able to handle if the connection between client and server is lost for a period of time. In that case, I assume we need to get the data by looking into historical data. Hence, we need a server that support HA (Historical Access).
Are there any servers supporting this or do we need to develop our own server implementation?
Or is there a better approach than the one described above?
Any help or hints on this would be appreciated.
How long would you expect the connection to be down for?
While leaning on HA is certainly one way to handle this, I think you'll have a hard time finding any products on the market right now that are actually implementing HA.
Luckily, you can probably deal with this scenario without HA. If you create your subscriptions with a generous lifetime, and create your monitored items with a queue size that, based on the sampling interval, could hold enough data changes to span up to that lifetime, then you upon reconnecting you should receive all of the data changes that happened while the connection between client and server was lost.
If the connection is expected be down for days/weeks/months, then this won't work without support for durable subscriptions, introduced in UA 1.03, but then again you're limited by finding a server that supports durable subscriptions. (Durable subscriptions are basically just a way to make the lifetime of target subscriptions much longer than normally allowed and to instruct the server that they are expected to persist these subscriptions to disk and restore them in the case of e.g. server restart)
How can I interact with a PLC to send and receive data to/from a remote server(PC).
For example a robot that have a PLC and want to interact with a server that placed at near room with a wireless communication.
Data must move all over the time. PLC sending the data to the server and server must sending back the result of computation on the data to PLC.
review : My PLC brand is Delta but its model has not been selected yet .
A common scenario is that the manufacturer provides an OPC server for the PLC. You should check their website once you know the model. Then it is just a matter for you to create an OPC client.
A good way to start is to get a free OPC server simulator like the one from Matrikon. It doesn't need any hardware. OPC is a standard interface (although there are often some minor variations between manufacturers) - if you can get your client to work with the test server you can probably get it to work with the PLC.