Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Netduino and OPC

Started by testermax, Aug 07 2011 06:41 PM

Please log in to reply

12 replies to this topic

#1 testermax

New Member

Members
2 posts

Posted 07 August 2011 - 06:41 PM

Hello! Im new to the netduino platform, (and also fairly new to C#) but I must say that this little thing is FANTASTIC! It fun to program microcontrollers with C#. I have a question about communication between this Netduino + and a PLC. Is it possible to run an OPC server on the Netduino, which other PLCs or OPC clients can communicate with? Have anyone of you made one? I think that if there were a good, standardized interface between the two platform, it could be quite beneficial.

Back to top

#2 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 07 August 2011 - 09:31 PM

Hello testermax,

welcome to the Netduino forums!

An OPC server is usually a gateway between some device that supports a proprietary communication protocol (e.g., a PLC), and client applications on a Windows network. Any client that supports the OPC protocol can then access measurements from the device, send setpoints to the device, and receive alarms from the device. As an industry standard, at least these basic elements of OPC have been very successful.

OPC is based on Microsoft's older Component Object Model, therefore a computer that supports an OPC server (i.e., a COM server) needs COM support, or rather its network-version DCOM (Distributed COM). This is quite out of the question for a Netduino. You'd better stick to an embedded Windows computer if you want to use the original OPC protocol.

There is the newer OPC UA specification, which does not rely on DCOM but on Web services technologies such as SOAP. However, this is a far more ambitious specification than the original OPC. It goes all the way to modeling automation systems, and one add-on specification is currently being created for PLC interfacing. Even though the specification is somewhat modular, I wouldn't expect an implementation for even the smallest possible subset to be feasible for a Netduino. From the perspective of OPC UA, a "small" embedded computer is orders of magnitude more powerful than a Netduino.

For some companies, OPC UA was too much, so they created what is now called OPC .NET 3.0. It is basically a .NET oriented version with the original scope of OPC. However, it requires the Windows Communication Foundation (WCF), so is probably out of reach as well.

Just to put things in perspective: a Netduino Plus is too resource-limited to run SSL.

However, if you don't mind unencrypted communication (which most people in industrial automation are somewhat allergic to), you could use some plain vanilla REST server with HTTP instead of OPC. This is perfectly within reach of a Netduino Plus. IMHO, in many cases it is the better architectural approach anyway, due to its platform independence, scalability to (relatively) small embedded devices, and natural integration with the world-wide web.

Best regards

Cuno

Back to top

#3 RandyA

New Member

Members
3 posts

Posted 11 August 2011 - 04:30 PM

Your device is pretty cool. I would like to add a few clarifications about OPC UA:

Even though the specification is somewhat modular, I wouldn't expect an implementation for even the smallest possible subset to be feasible for a Netduino. From the perspective of OPC UA, a "small" embedded computer is orders of magnitude more powerful than a Netduino.

OPC UA runs on this:
http://embeddedlabs....rvermodule.html

For some companies, OPC UA was too much, so they created what is now called OPC .NET 3.0. It is basically a .NET oriented version with the original scope of OPC. However, it requires the Windows Communication Foundation (WCF), so is probably out of reach as well.

The .NET SDK uses .NET 3.5. WCF is not required for the binary protocol.

However, if you don't mind unencrypted communication (which most people in industrial automation are somewhat allergic to), you could use some plain vanilla REST server with HTTP instead of OPC.

OPC UA has REST + UA Binary option now. No SOAP, No XML, No Security. Runs in Silverlight.

I would be happy to work with you or anyone who is interested in getting OPC UA to run on your board.

Randy Armstrong
OPC Foundation

Back to top

#4 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 11 August 2011 - 06:18 PM

Very interesting! Looks like OPC UA has improved a lot in the last two years. When I last looked at the spec, it said very little about the Low End Embedded Device Profile, and REST wasn't mentioned. Great to see that more lightweight solutions with OPC UA have become possible. Can you share a bit more information on a minimal implementation today? Maybe you can give a rough indication of how much Flash and how much RAM would be needed on an ARM7, assuming support for at least the data access profile? Is REST possible for all OPC UA functionality, including data access and alarms & conditions (and through firewalls/NATs)? Thanks for the infos! Cuno

Back to top

#5 RandyA

New Member

Members
3 posts

Posted 12 August 2011 - 12:45 AM

There are companies selling DA-only implementations that run in 64KB of RAM. I will have to check on the ROM footprint but I assume it is the same order of magnitude. They use the UA TCP protocol rather than REST. All UA features are available via the REST-like option (it is HTTP POST with binary bodies). You can use XML bodies but I am assuming that XML on small devices is not desireable. The NAT firewall traversal is part of the architecture but assumes you have port forwarding enabled if a server is behind a NAT firewall.

Back to top

#6 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 12 August 2011 - 09:49 AM

There are companies selling DA-only implementations that run in 64KB of RAM.
I will have to check on the ROM footprint but I assume it is the same order of magnitude.

The new Netduino Plus beta firmware has 38KB of RAM available for the application. Not quite enough to put aside 64KB for another protocol stack, unfortunately.

Of course, if you eliminate the .NET Micro Framework entirely, then such a protocol stack might well fit on a Netduino Plus. Could be a very interesting project to run an OPC server on the bare metal, with little or no operating system!

As for the REST question, I have downloaded the current version of the OPC UA specifications, and will take a look at the new HTTP features. I hope that HTTP GET is also supported. At least for data access, so that the Web's caching magic works.

You can use XML bodies but I am assuming that XML on small devices is not desireable.

Yes, I would indeed avoid XML on a small device. Even if some efficient binary encoding were used, you still need an XML parser. Unless you only produce XML, never consume it.

The NAT firewall traversal is part of the architecture but assumes you have port forwarding enabled if a server is behind a NAT firewall.

During the Getting Started with the Internet of Things project, the most unpleasant experience for me was that I learned to not rely on port forwarding for its target audience of makers. I got so unambiguous feedback (thanks, Corey :-) in this respect that I rewrote much of the book and used another approach to solve the firewall/NAT issue.

For professional automation projects, this was obvious much earlier. If you ask an IT administrator to open an incoming port, to make your devices accessible as servers over the Internet, he will often just say "no" without further discussion. Sometimes, we think ourselves lucky if the network admin is even willing to only open an outgoing port with a predefined list of IP addresses (whitelist), to which the device may open a connection as a client. You cannot assume VPNs either, especially for small devices like the Netduino for which there simply are no VPN clients.

What this means is that an Internet-oriented automation architecture fundamentally cannot assume that incoming ports are available. Simply cannot.

That's why we had to find another solution for the firewall issue, but that's probably a bit out of scope here. It is definitely possible to solve the problem for OPC UA as well though.

Best regards

Cuno

Back to top

#7 Mario Vernari

Advanced Member

Members
1768 posts

LocationVenezia, Italia

Posted 12 August 2011 - 10:39 AM

Pardon me for the question, but a small device like Netduino wouldn't be more feasible to *act* as a PLC, instead *serving* a PLC? Usually it needs a PC to aggregate (and elaborate) the data coming from 1+ PLC, so...how could a Netduino fits the needs of a even small SCADA? Thank you all. Cheers

Biggest fault of Netduino? It runs by electricity.

Back to top

#8 RandyA

New Member

Members
3 posts

Posted 12 August 2011 - 11:26 AM

The new Netduino Plus beta firmware has 38KB of RAM available for the application. Not quite enough to put aside 64KB for another protocol stack, unfortunately.

Ok. A lot of IA applications have higher price points and can afford more RAM. It may make more sense to have a UA server that can be a gateway for a network of these devices that be on the device itself.

As for the REST question, I have downloaded the current version of the OPC UA specifications, and will take a look at the new HTTP features. I hope that HTTP GET is also supported. At least for data access, so that the Web's caching magic works.

You need to get V1.02 which is not posted yet. Members can find drafts here (Part 6):

http://lists.opcfoun...5-2F2FC9333917}

Yes, I would indeed avoid XML on a small device. Even if some efficient binary encoding were used, you still need an XML parser. Unless you only produce XML, never consume it.

Why would you need an XML parser?

What this means is that an Internet-oriented automation architecture fundamentally cannot assume that incoming ports are available. Simply cannot.

If there is a business case for external communication then the IT must open ports to something. Whether it is some gateway or the device itself is TBD.

Back to top

#9 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 12 August 2011 - 01:13 PM

Why would you need an XML parser?

If I use a binary encoding for my XML documents, e.g., Efficient XML Interchange (EXI), I win by reducing the amount of data I send around. But on the device, I still need some kind of parser for this format. Since it has a shorter input "text" to process, it may be faster than a normal XML parser, but it is still not a trivial program.

If XML on the device is really important for some reason, though, one can certainly use such an approach. But if I have the choice, I personally prefer to use an efficient non-XML binary protocol, as you do with OPC UA on these low-end devices that you pointed out.

If there is a business case for external communication then the IT must open ports to something. Whether it is some gateway or the device itself is TBD.

If you mean allowing outgoing connections to something, absolutely. This is usually possible. Sometimes by default, then people don't even need any cooperation from IT administration. The client devices simply connect out to some server on the Internet. No problem here.

In our experience, this is far less straightforward in practice for incoming connections, i.e., for devices as servers. But maybe we address different use cases and different types of customers. For example, assume company X sells devices to thousands of customers around the world: to large companies, small companies, government organizations, maybe even consumers. Now X wants to offer a remote monitoring service to its customers, e.g., to detect possible malfunctions of devices before they actually occur, in order to reduce costly downtimes of the device. The devices of many customers are connected to X through mobile phone networks, using different network operators in different countries.

Then X would not only have to convince (and maybe help) its customers to open up incoming ports in all their networks, it would also have to negotiate with all the involved mobile phone operators to allow opening connections to devices on the networks. On nearly all mobile networks, a phone (or a Netduino with a GSM modem) can connect "out" to the Internet, but no one can connect "in" from the Internet to a phone or Netduino that's on the mobile network. Neither X nor its customers have control over the network operators' firewalls and NATs. Some of the mobile operators sell separate subnets where they allow incoming connections, but these can be prohibitively expensive.

As far as I can tell, these hassles are simply too much for the companies of type X that I have met. Moreover, such services are innovations with which X necessarily has little or no prior experience, and so the business cases are less clear-cut than in more traditional settings like plant monitoring within a single company.

Wouldn't it be wonderful to use an approach where companies and their IT departments don't have to worry about opening potential security holes in their networks? And where makers are not required to find out whether it is possible to enable port forwarding on their home routers, and how to do it?

Anyway, as for OPC on Netduino, you really answered the original question:

It may make more sense to have a UA server that can be a gateway for a network of these devices that be on the device itself.

Thanks for your inputs here - it is great to meet OPC guys on this kind of forum!

Cuno

Back to top

#10 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 12 August 2011 - 01:43 PM

Pardon me for the question, but a small device like Netduino wouldn't be more feasible to *act* as a PLC, instead *serving* a PLC?
Usually it needs a PC to aggregate (and elaborate) the data coming from 1+ PLC, so...how could a Netduino fits the needs of a even small SCADA?
Thank you all.
Cheers

Yes!

In an ideal world, it would be possible (and cost nothing) to connect every PLC and Netduino etc. directly to the Internet, and a SCADA system that fetches measurements from all these devices over the Internet (well, if the data is not time- or safety-critical). Then the PLCs and Netduinos and SCADA systems would have to support some common standard, let's say OPC UA.

In reality, it makes more sense to have a PC or the like as aggregator for several devices, as you said. If this aggregator is powerful enough, it could translate between the OPC UA standard protocols and the PLC's/Netduino's proprietary formats. (Especially if these formats were designed to facilitate the translation.) Such a gateway scenario is the original OPC standard's primary use case. Because of COM, it required a Windows PC. With OPC UA, this restriction doesn't exist anymore. But as Randy pointed out, a Netduino is not necessarily a good choice for such a gateway.

Best regards

Cuno

Back to top

#11 SiggyTheViking

New Member

Members
3 posts

Posted 23 August 2011 - 02:33 PM

Yes!

In an ideal world, it would be possible (and cost nothing) to connect every PLC and Netduino etc. directly to the Internet, and a SCADA system that fetches measurements from all these devices over the Internet (well, if the data is not time- or safety-critical). Then the PLCs and Netduinos and SCADA systems would have to support some common standard, let's say OPC UA.

In reality, it makes more sense to have a PC or the like as aggregator for several devices, as you said. If this aggregator is powerful enough, it could translate between the OPC UA standard protocols and the PLC's/Netduino's proprietary formats. (Especially if these formats were designed to facilitate the translation.) Such a gateway scenario is the original OPC standard's primary use case. Because of COM, it required a Windows PC. With OPC UA, this restriction doesn't exist anymore. But as Randy pointed out, a Netduino is not necessarily a good choice for such a gateway.

Best regards

Cuno

So let me see here. We could have a machine that talks to various devices using a protocol they understand, and then presents it in a normalized protocol to a machine that records and aggregates all this I/O. Maybe we could call them an I/O server and a Historian. That would be some wonderful software. We could call it, um, Wonderware. Ja, that's it. AHHHHHHHHHHHHH!!! It hurts!!! It's too late for me. Turn back while you still can!

Yes, indeed, we have a common task to achieve, and an industry with a handful of players, all solving the problem with the same broad strokes, but subtly different details. It is time for me to look back into OPC UA again (it's been a couple of years for me, too), since I tire of working in a Babble of Wonderware, Modicon, and Allen-Bradley (with a few others too weird to mention.)

Oh, and to be vaguely on topic, I am meandering toward using my N+ as the PLC for my ranch (open the gate, monitor starts and stops of the well, etc.) I have this new wheel I'm working on, I think I'll call it Supervisory Control and Data Acquisition, or maybe something like that ;-)

Cheers,

Siggy

Back to top

#12 fileark

Member

Members
12 posts

LocationNM

Posted 10 July 2012 - 07:12 PM

My opinion is that there is definitely a time and place for everything including OPC devices. No one said you had to be traveling out side of your LAN. If you must go outside of the LAN remind your IT department that they exist so that the company can do business and make money. IT should be responsible for coming up with the solutions on how to make it work and not simply say "NO".

A Netduino could serve as a data concentrator bringing in IO and serial data from other devices then talk OPC directly to a PC. This may not be possible now but the next version will surely have more power and RAM.

Wouldn't it be wonderful to use an approach where companies and their IT departments don't have to worry about opening potential security holes in their networks? And where makers are not required to find out whether it is possible to enable port forwarding on their home routers, and how to do it?

Please help me understand, are there other more secure ways to communicate to a netduino through a firewall that does not entail opening a port? Does opening a port to communicate with a Netduino using OPC pose more of a security risk than opening a different port to communicate with the Netduino in any other way?