Free OPC-UA server

surferb

Lifetime Supporting Member
Join Date
Jun 2007
Location
DC area
Posts
1,777
I've had to hold my tongue about this for quite awhile now, but it's finally official! The Ignition Platform (evolution of FactorySQL and FactoryPMI) includes a free OPC UA server (module). Watch as the capabilities and features continue to grow.

The Gateway (web server) has a built in "quick client" that's pretty slick. In Internet Explorer/Firefox you can browse the memory space of your PLCs, write values, have it automatically update, etc. This works from any computer on the network, even from home via a VPN, etc. It should satisfy a lot of situations where you've been forced to use Excel with DDE just to read/write simple values to your PLCs - and more. Of course, when used with the Vision module (Formerly FactoryPMI), you can create as extensive an HMI/SCADA/MES application as you want or the SQL Bridge Module (Formerly FactorySQL) you can do historian/batching/transactaional/recipe/downtime type applications as before.

As of now, there are drivers for all Allen Bradley Ethernet PLCS. I've played with beta versions of Modbus, Automation direct, and Siemens...I'll provide an update as to what's actually supported. More will come with time.

The platform runs on pure Java so it's 100% supported on Linux, Windows, etc. Also, the platfrom is modular, so as API documentation and example code is released, savy users will be able to create their own modules and drivers.

There's a lot more info on the new Inductive Automation web site.
 
Last edited:
Finally we get to talk about this. I, however did not know about the free surprises that came with the Ignition launch. Nathan and myself have been involved with Ignition for a while now, and oh man is it nice. I have a plant running 40000 active tags with 20 or so concurrent users, and now that Ignition is out, it is getting converted.

Most of my testing has been on the Linux side of the fence, where as I believe Nathan focused primarily on Windows. All of my production servers run Linux where possible, and because Ignition runs very well in Linux, now I can shift all my machines to this platform. Im not saying its the right choice for Company A, but thats your decision. Either way, I will gladly try to give anyone a hand with test driving the new platform.
 
The Gateway (web server) has a built in "quick client" that's pretty slick. In Internet Explorer/Firefox you can browse the memory space of your PLCs, write values, have it automatically update, etc.
Some kind of security against unwanted access must be implemented. No ?

As of now, there are drivers for all Allen Bradley Ethernet PLCS. I've played with beta versions of Modbus, Automation direct, and Siemens...
Can you shed some more details ?
I have looked on your website, but am not sure I understand.
Does the OPC UA server act as a gateway between a regular OPC DA Server and OPC UA ?
Or does the OPC UA Server connect OPC UA clients to your database ?
Or ?
With is meant by "drivers" for AB, Modbus, AD, Siemens ?
 
Absolutely! You have to have admin access to the Gateway to use the quick client. The OPC-UA spec uses strong security between client and server.

However, someone correct me if I'm wrong, most Ethernet enabled PLCs do not support any real security when it comes to register reads/writes. This free version of Ignition does not introduce vulnerabilities, but is an effective tool for the casual attacker. They won't need to "hack" your gateway...they can simply install their own and connect to your PLCs directly. This is true with any OPC server or industrial software. It is becoming increasingly important to secure your PLCs by other means - for example, your users don't need to be on the PLC network to access them. Just like with PCs, security by obscurity is becoming weaker and weaker with time. No IT guy would ever consider putting his enterprise SAN (storage area network) on the users network, even though it speaks TCP/IP and users ultimately need access to the data. They have to go through a mapped network drive, via a file share on a server that is connected to the SAN. Hopefully the point is clear.
Some kind of security against unwanted access must be implemented. No ?

The OPC UA server connects to devices directly and shares information with OPC UA clients (Ignition acts as both in some cases). The drivers are specific to this OPC UA server to communicate with different types of PLCs. To my understanding, all the major vendors are developing OPC-UA client and server products. OPC-DA (the current spec) is a clunker that is difficult to use and impossible to secure in many configurations, due to it's legacy Microsoft DCOM basis. Ignition will work with "legacy" OPC servers via a "COM Module".

The immediate benefit of the Free OPC Server is through the use of the Quick Client, trial Ignition software, or registered ignition software. As time goes on, you will be able to purchase HMI OPC-UA clients and save money by using the free Ignition software instead of purchasing the server from the vendor. Also, as example code and APIs become more available, people/groups/projects can write their own applications that only have to leverage OPC calls (simple reads/writes/etc) to interact with PLCs instead of having to worry about all the details involved in driver writing.

Can you shed some more details ?
I have looked on your website, but am not sure I understand.
Does the OPC UA server act as a gateway between a regular OPC DA Server and OPC UA ?
Or does the OPC UA Server connect OPC UA clients to your database ?
Or ?
With is meant by "drivers" for AB, Modbus, AD, Siemens ?
 
Last edited:
I agree with that current PLCs and OPC DA doesnt have any true security layer. But you have to know OPC, so that protects against the casual noob messing things up.
Opening up for that anyone can just load a webbrowser and then access the PLCs data changes this. Having to login is good, but I would like to have a more controlled security like you have in most HMIs. Like certain data is accessible only to certain users.

Anyway, it all sounds very interesting.
 
By default the quick client is only accessible to "admin" group. You wouldn't just install it and leave permissions wide open for anyone. That would be professionally irresponsible.

The web browser doesn't introduce the vulnerability, it's the means of accessing the installed software. Ignition makes this a little easier, but isn't much different except that it's free. With Rockwell software you install RSLinx, connect to the PLC, then do your thing with RSLogix or RSView. With Ignition you install the software, connect to the PLC, then communicate with it. For a given project, you have lots of options to secure it. Authentication can be performed via a built in system, SQL database, or Active Directory (LDAP source). Communication can be secured with SSL/TLS and OPC-UA specifies all kinds of security features with certificate exchanges, one time keys, etc - everything you trust with secure banking.

At the end of the day it's the PLCs that are weak from a security perspective, not OPC, OPC-UA, vendor X's product, open source projects, etc. They respond to read/write requests without so much as an authenticated session - or even a password. The fact that industrial software has been historically expensive and difficult to use adds nothing to your security posture.

Let me give an example - suppose you have a Wonderware system controlling your process. It may be strong or weak from a security perspective, but if I can plug my laptop into your network in a user area, scan for your PLCs and connect with my own copy of Wonderware, your HMI security setup becomes trivial. The PLC should support pre-shared keys, certificates, Kerberos authentication, or at least ask for a username/password. Since it doesn't, anyone on the network can trivially write values to the PLC, which you know, can often mean dangerous things. PLC programmers are going to have to start becoming more security conscious. This is a good time for hardware vendors to step up to the plate and for consumers to demand it.

I agree with that current PLCs and OPC DA doesnt have any true security layer. But you have to know OPC, so that protects against the casual noob messing things up.
Opening up for that anyone can just load a webbrowser and then access the PLCs data changes this. Having to login is good, but I would like to have a more controlled security like you have in most HMIs. Like certain data is accessible only to certain users.

Anyway, it all sounds very interesting.
 
Last edited:
Nathan, my post wasnt intended as a critique, merely a wish for the functionality.

The webbrowser does not introduce the vulnerability as you say.
But the webbrowser does make the vulnerability more accessible.
You wrote in the initial post that you could browse the PLCs memory and write values. Thats what I jumped on. If there is not sufficient security in the underlying PLC or OPC connection, then it would be nice if the new UPC UA connection can add a layer of security. And it would be nice if it is not merely a "master key" that grants unlimited access, but some kind of "areas" or "zones" where access is granted.

I have exactly the same problem today. In my HMI today there is a system of users and permission rights. However, at the same time, anyone with the right know-how can startup an OPC test client and write any value to any PLC address he desires. I must admit that I have used this myself on a couple of occasions.
 
Jesper - I see where you're coming from. You can use security to block/grant access, but don't get the granular ability to define areas with separate permissions. It's too bad that PLCs don't support protected memory like PCs - or permission systems like file systems. That is certainly something that could be entered as a feature request, although, in truth, I doubt any software vendor would take it seriously unless enough customers demanded it.
 
Nathan, when will the S7 PLCs drivers be ready? Will (or could) they support complex data areas such as udts? I would be all over that. I'm working on a project where OPC just doesn't cut it, and have used a direct connection instead, but would prefer to use a canned solution if it works.
 
I'm not sure how far they got with the S7-300 drivers. As I understand, the S7-200 drivers were more mature. They don't want to release any driver sets that aren't completely tested, but you could probably work with the guys in beta form if you're interested. Would you be able to do any Java work with help on the driver? The platform takes care of a lot that you would otherwise have to write. How much time do you have, and what's your project timeline like?

Nathan, when will the S7 PLCs drivers be ready? Will (or could) they support complex data areas such as udts? I would be all over that. I'm working on a project where OPC just doesn't cut it, and have used a direct connection instead, but would prefer to use a canned solution if it works.
 
The S7-200 is a completely different animal and represents only a small portion of installed Siemens systems. To give you an idea, in twenty years I've worked on only one, and only seen two more in person. As for S7-300s and 400s, I've seen thousands.

I haven't got any free time to work on drivers right now (that's a good thing, I guess), but I can certainly help with setting up a real PLC and programing some test code. I was planning on going to Sacramento for a day or two of design help in February sometime, and I can talk to them about it then.

My project timeline is, like, right now. :) I'll stick with what I've done so far, but I haven't done anything that would preclude switching later on if they get a driver finished and it can duplicate the functionality I need.
 
I know - the S7-300 and 400s would be much better. Sounds like a plan - I wouldn't hold your breath for an unsupported driver. Would Modbus be helpful for your project?
 
No, I'm connecting directly to hundreds of S7-300s and 400s. Modbus isn't in the picture.

It's not that urgent right now. With Ignition I can still use Kepware for the stuff that OPC is good at, and I can do what I'm doing with the other stuff.

But what you said above about being able to browse the memory space of the PLC with IE really peaked my interest. If you can do that, then theoretically you should be able to handle complex data types as well. Hmmm....
 

Similar Topics

Downloaded from the matrikon portal. I wonder, is it a trial or what?:hmmm: Currently im not having access to my plcs so unable to try it...
Replies
1
Views
2,483
Hellow, Anyone knows if there is a free API for the new released OPC UA in firmware 2.0 of the 1500 CPU's ? Thanks in advance, Kind regards, C
Replies
0
Views
1,332
Hi All I have seen multiple questions on this forum about interfacing SQL from OPC Sources (such as PLC), without any good and/or free options...
Replies
16
Views
8,317
I'm collecting input for a free datalogging version of FactorySQL to include .CSV logging. What I need from you is: would it be useful as...
Replies
7
Views
5,628
Dear All, If you developing SCADA / HMI within OPC Server and Visual basic. I would like to suggest my COPC ActiveX control. It can connect to...
Replies
8
Views
9,721
Back
Top Bottom