Situation

Over the last few years, there has been an ever-growing demand for connectivity and interoperability between the different factory automation solutions and business applications. Solutions to this demand are twofold: for one thing there are the evolutions in the fieldbus camp, for another migration towards Ethernet is followed with Argus' eyes. Even the fieldbus evolutions are tending towards Ethernet, e.g. OPC DX (OLE for Process Control Data Exchange). This will come as no surprise as Ethernet is the de facto standard today for corporate enterprise systems. With Ethernet, combined with standards like OPC (OLE for Process Control), legacy systems can be reused.

[an error occurred while processing this directive]

One of the values of OPC is that it provides a common interface for communicating with diverse process control devices, regardless of the controlling software or protocols used in the process. Before OPC was developed, application developers had to create specific communications drivers for each control system with which they wanted to connect. With OPC, application vendors no longer need separate drivers for each new processor or protocol. Instead, the manufacturers create a single optimised OPC driver for their product.

Current State

Although the efforts of OPC are definitely a step into the right direction, today's solution does not bring universal happiness either. It is true that more and more manufacturers are supplying an OPC server for their products, but what about communication between these OPC servers, and what about security, internet accessibility, data safety to name some of today's questions.

OPC uses COM (Component Object Model) and DCOM (Distributed COM) as core technology for their software interface. This is where the first problem arises: when you want to use an OPC server located on a machine different from yours, you must configure the DCOM security. DCOM security, albeit a very good security model, simply does not work in the real world. Judging by the considerable amount of questions on newsgroups, many installers experience this as a problem, on Windows 95 and Windows 98 machines in particular as they have a security infrastructure different from Windows NT/2000/XP. As a result, DCOM security is often disabled which leads to severe security risks. It gets even more challenging to use an OPC server over internet.

[an error occurred while processing this directive]Another point of thought is the assurance that no data gets lost. For tracking and other monitoring software it is essential that all data is received by the application, but what if you experience bad connections or even got disconnected? Wouldn't it be nice if the data got buffered and then sent when the connection is re-established? How can we automatically try to reconnect?

Evolution

Previous paragraph indicates that there is still some work to do! Although many efforts are made towards interoperability and connectivity, the technology still doesn't meet all the needs.

Where OPC offers us an unambiguous interface to communicate with different automation protocols, it does not satisfy the need for remote communication over intra- or internet. While in some cases it is possible to create a remote connection with DCOM, it is an obsolete technology that has been improved several times by Microsoft. Successors in this technology have already been available for several years: MTS, COM+, SOAP...

Keeping in mind that DCOM is an obsolete technology, and that better solutions are available, it is time to take the next step in evolution!

What is really necessary to cope with the current needs for remote communication with OPC servers? How do other technologies create this kind of real-time communication?

There are many implementations of real time communication over intra- or internet, and most of them use the same technology. Let's take Windows Media Player (WMP) as an example, which is able to play live audio streams from the internet.

The real time audio provided by the central server on the internet can be compared with the data from the OPC server. What do they have more than we have? Communication!

Communication

Although there are efforts in this direction, it takes more than that to have a reliable, secure communication.

The ideal scenario would be one where current automation software does not have to be updated to use remote communication, one where there is no need for a new protocol or standard…

A central server can make an audio stream available for remote use. It accepts any incoming connection (if it can be authenticated), and provides it with the data it possesses. A similar way of thinking can be used for OPC. A server can accept any incoming connection, and if authenticated, provide it with the functionalities of an OPC server located on the same computer.

 

Figure 1: Server

What about the client computer? Windows Media Player translates the data to an audio signal. Similar, an OPC Server is required on the client computer. Once connected to the server, this OPC server on the client computer can act exactly as the original one. Data requested from that OPC server is transmitted to the central server, which in turn will request that data from the original OPC server. The result is transmitted back to the client, and this client will report the result as if it was the original OPC server.

Figure 2: Remote OPC Server

The interaction between the original and the remote OPC server can be described with the term 'synchronic'. All changes requested to the remote OPC server are transmitted to the original OPC server, so it changes to the same state. On the other side, if the original OPC server changes (e.g. events); these changes are transmitted to the remote OPC server which in turn changes its state to remain synchronic to the original.

Although this is the basic idea for the communication, it is not adequate for real use yet. What about security? What about data safety? How can a communication application comply with these needs?

Security

This term encloses encryption, authentication and authorization.

Encryption changes all data that leaves the computer into an unreadable stream of data. 128 bit encryption can guarantee us that even the fastest computers, with the best hacking tools need way to much time to decrypt one single piece of data.

Authentication can be done by the classic username/password together with a strong key. So even if anyone discovers the username and password of a valid user, he will not be granted permission to the server because he cannot deliver that strong key to the server.

The third step towards security is to assign rights to a user (authorization). Is a user allowed to connect to a specific OPC server? Can he write data to that server, or can he only read it?

Although this can guarantee us that only authorized users can connect and use OPC servers, this does not meet the needs for a safe communication application. Hackers use several techniques to undermine the correct operation of a server. This is why a server needs to be protected against brute force attacks, etc. The system must detect and log the number of failed attempts with a given username and password, and lock out the account under attack or even ignore connection attempts from IP addresses that causes the security leaks.

Data Assurance

Built-in systems must assure that all the data reaches its destination. Within an intranet, this will not be that problematic, but internet connections are not that reliable. While the communication application cannot guarantee that the connection to the client is reliable, it can guarantee that the data transmission is. Buffers can store data during temporal connection failures and remote OPC servers can have automatic reconnection logic.

Observation

It is necessary for the user (or administrator of the server) that he is informed of the functioning of the communication application. Were there any hacking attempts, connection failures, what is the amount of data that was transmitted from and to this application, are there connections which are sending to much data to the server?

Synchronic!

Synchronic is a product of I-Systems.be that implements this communication technology for OPC.

With Synchronic you don't have to worry anymore about remote use of OPC servers. The application will guide you to the correct configuration, and will hide all complexities for you.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]