Our EtherNet/IP Scanner is adaptable to lots of different platforms, processors and RTOS environments. It can do both Explicit and I/O messaging and pretty much support an unlimited number of slave devices. We’ve built it to both be easy to integrate and flexible. I think that we’ve done a pretty good job at that.

That software fulfills a need for those customers that for whatever reason won’t or can’t use a Logix PLC in their automation application. ControlLogix and CompactLogix are excellent control platforms but sometimes they just aren’t right for some applications. I don’t often enter into discussions with customers about their platforms but I know that many of them want to tightly integrate databases, decision systems or other analytical software with their control and just can’t do it with a PLC platform.

If they have a university background or hate Microsoft they will use Linux. Linux is one of the most popular platforms for these sorts of supervisory – hard control solutions. Other times they will use one of the Windows platforms (CE is also popular) or an MQX or a QNX. We don’t care. We have adaptations for all the major RTOS platforms.

The problem always comes in when they tell me they really like Point I/O. That’s good because I’m also a fan. If Point I/O had a Facebook page I’d do a Like and be a Friend to it. I hardly understand those terms but I got a bit of insight watching my 10 year old granddaughter updating her FB page yesterday. God knows what’s on that. (Maybe I should find out)

The 1734 Point I/O modules are really nice. I’ve always liked them. Lots of cool features. You can mount them in different ways. You can insert and remove them under power. You can organize them in whatever configuration makes sense. The wiring system is removable. And they support lots of networks; all the ones you’d expect plus Profibus DP.

And they look good too. If GQ ever does a cover on I/O modules the 1734 family might make it.

OK, I can hear you guys saying “Enough Already. What’s the point?”

Ah Yes, the point. The point is that I kind of cringe when I get that question. It’s not that I don’t want to answer it, it’s just that the answer is difficult to easily convey to the questioner.

AB built these modules with a very highly integrated interface to the PLC. As with a lot of AB products they work very well together in a system consisting of all AB products. In a homogeneous system like that a PLC “knows” a lot about those modules. Information that our software just doesn’t know. It makes them easier to integrate into a PLC but makes it more difficult for us to integrate into a Linux EtherNet/IP Scanner application.

Here are some of the issues we have to deal with.

·         The I/O assemblies vary with what specific I/O modules are installed. Gathering the input and output assembly instance numbers and sizes is a real pain. Right now we don’t know a good way to do this other than connect the module to a PLC and reverse engineer that data.

·         Each Point I/O module may have unique configuration data, which if required by the end user, must be sent with the forward open message. This can be hundreds of bytes of cryptic data. Again there isn’t much documentation on the contents of that configuration data.

·         Some point I/O modules support rack optimized I/O while others support both rack optimized and Direct Connect. In rack optimized the Scanner connects to the entire rack as one device. In Direct Connect, it can connect to each module individually. There is usually different configuration for each of these methods

There is a document that covers a lot of this information:
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1734-um016_-en-p.pdf

But even with this document there is a lot of labor involved for our EtherNet/IP Scanner to support these modules. It’s not impossible but certainly not as easy as supporting off-the-shelf I/O for other I/O platforms.

I get a number of questions every week about moving ASCII data. Moving ASCII data in and out of PLCs. Moving it across protocols; everything from J1939 to Modbus, EtherNet/IP and Profinet IO.

There is no trick to it. You just have to understand a few basics to get it done right. Here is a primer on moving ASCII to EtherNet/IP, ASCII to Profinet IO, ASCII to Modbus and all the rest:

1.       Electrical Issues – First, get your wiring right. Look at how your data is coming in (or going out). Is it RS232 or is it RS485? RS232 is point to point and is usually 12 VDC. There’s a Transmit Pin, a Receive Pin and a Ground. RS485 is Multidrop. It’s differential. 5 Volts. Only two wires are needed. Since, you are moving ASCII data and there is no way to arbitrate messages, you will only want to have one device on the link. Two ASCII devices transmitting at the same time means nothing comes through.

2.       Termination – Once you are wired let’s understand how the receiver is going to find the end of the message. Is it fixed length? Is it terminated by a Carriage Return, Line Feed or even a “?” or “$”? In fact, you need to understand how that works in both directions.

3.       Byte Ordering – Most PLCs are going to store your ASCII data in PLC locations that are 16 bits or 2 bytes long. That means that two of your ASCII characters are stored in each PLC location. When the PLC moves that data to an HMI or database or someplace else, the byte order might be wrong. “123456” can come out as “214365”.

If you are going to use one of our ASCII gateways that move ASCII gateways over networks to networked devices like a Siemens PLC (Profibus or Profinet IO) or Rockwell PLC (EtherNet/IP or DeviceNet) or something else, maybe using Modbus, there are other considerations.

For example, if a PLC is sending labels to a printer over an Ethernet link, how does the gateway know that the PLC has a new label to print? It might want to print the same label a second time.

The same applies in the reverse direction. If your system allows duplicate barcodes, how does the gateway tell the PLC that this is new ASCII data?

Remember that in all these networks (EtherNet/IP, Profinet IO, DeviceNet and everything else), data is flowing constantly. A PLC that writes a label to a printer out as I/O data is going to send that same label every 10msec. A gateway device that is sending a barcode to a PLC as I/O data is going to send that barcode to the PLC every 10 or 20msec. There has to be some way to recognize new data.

RTA has implemented a simple handshaking protocol for sending and receiving ASCII data over EtherNet/IP, Profinet IO, DeviceNet, Profibus and Modbus networks. Using a control bit, status bit and sequence number, each side of the network can know exactly if it is looking at new data or data that it has already processed. Since our communications manuals and our applications notes for exact instructions on using the handshaking protocol.

Moving ASCII data between serial devices and networked devices is not difficult. There is just a bit more complexity that you have to manage.

Good Luck,

John

2012 is done over and gone. Lots and lots of people are making resolutions. Resolutions to lose weight, to be more patient, to spend more time with the kids…etc. There’s probably a hundred million different resolutions that have been made in the last few days.

I have kind of a unique take on the end of 2012 and the beginning of 2013. I’ve been reading a book called The 50^th Law. It’s the story of the rapper 50 Cent and it is exceptionally compelling. 50 Cent never knew his father. His mother was murdered when he was 8 years old. He grew up on the streets and decided that the only people he knew with money were the dealers so he set out to get his own piece of the action on the streets.

Well, 50 Cent is no dummy. He quickly realized that life expectancy of a dealer was about 21. And a good portion of those that survived went to prison and returned despondent and broken. Later 50 Cent realized that the music industry was no different than the drug trade. There’s always someone using you for their benefit. 50 Cent decided to be his own man; owned by no one – drug dealer or music executive.

Then it happened. A gunman reaches into his car and pumps nine bullets into 50 Cent. Nine bullets from point blank range but he survives. It made him realize how short and tenuous life is. From then on 50 Cent lived fearlessly for what was there to fear? He knew death was coming for him. If not today, then tomorrow or the next day. It was the one implacable enemy that he couldn’t defeat.

 And that leads me to the most unique question anyone will ask of you as we start 2013. What would you do this year, in 2013, if you knew that it was your last one on earth? What if you knew that December 31, 2013, 12:59:59pm you will take your last breath?

Of course, there’s a lot of the stuff we’d all do. We’d have a lot of the same reactions. We’d tell all our close family and friends how much we love them. We hug a lot. We’d get up early and watch the sun come up. We’d stay up late drinking wine and laughing with our best friends. We’d walk shoelessly through the grass and get soaked in a summer rain.

That’s all natural and very human. But what would you accomplish with those final 365 days? Isn’t there something you’d want to do that you’ve been putting off? Something you’re afraid to start?

I bet you’d face a lot fears. Why not? What would you have to lose? Time’s quickly running out anyways. Maybe you’d bungee jump. Maybe it’s giving a talk in front of your church group or colleagues at work. Or maybe it’s something like flying in a helicopter.

That’s mine. I’m deathly afraid of helicopters. THERE’S NO WINGS on the damn things. I also afraid to skydive, to fly an airplane and, in some situations, to just be myself [could be some people that might not like me]. And there is a personal situation I’m afraid to resolve. Lots of fears. I’d conquer them all if I knew I had only 365 days to live.

What about you? More than likely you have more than 365 days. But it’s NOT certain. Not at all certain. I’d point to my friends Jeff (43 yrs old) and Bob (37). Both of them figured they had decades.

So what are you going to do today, this month and this year? Why not face one of your fears. Pick just one thing you’d accomplish if you knew you had just 365 days to live and get it done.

Do It – Live Fearlessly – there’s not much time left.

If you know me I’m always on the lookout for new products. I wish I could tell you that I get premonitions in bed or in the shower. That’d be really cool. I’d love to be one of those guys that has to keep a pen and notepad next to the bed so I could wake up and write down that ten million dollar idea.

Unfortunately, that’s not the case. Usually, it’s you guys that call me up and berate me with “How do I do this…” or “Why doesn’t someone make it possible to do….” That’s the usual way.

And that’s exactly what happened to me a number of years ago with our EtherNet/IP Tag Client software. This software is very simple. It just moves Tag data between a PLC and an embedded device. You can read a bunch of tags or write a bunch of tags whenever you want. It, of course works with ControlLogix and CompactLogix but it also supports PLC5E, SLC 5/05 and Micrologix PLCs. With those legacy PLCs, you use the old file notation (N7:200) [For simplicity I am going to just say Tag when I mean Tag or File.]

That software was always a pretty good product for us. Lots and lots of embedded developers incorporated it into their product. It can do a transaction every 10-20msecs. That means the source device could load up a structure with a bunch of tags to read and then 10-20msecs later get the values of all those tags. That’s not terrific but it’s adequate for a lot of applications. We have alternate schemes for those of you that need responses down in the 1 or 5msec range.

The big problem with this software was the limited buffer sizes of the PLC. At 512 bytes you just couldn’t get a lot of tags in there. The way the protocol works is that we actually send the ASCII string names of those ASCII tags in the message to the PLC. So if you wanted to read 50 tags out of a CompactLogix PLC, you could only do it if the sum total of all those ASCII characters was less than 512 bytes. That was pretty limiting for a lot of folks. Especially on writes because in addition to the ASCII characters for the names of the tags to write you also had to have space for the data.

It kind of sucked and I didn’t have a great way around it.

Until now!

Just this week we released a new version of our EtherNet/IP Tag Client software that uses a fragmentation feature in the ControlLogix and CompactLogix PLCs. That new feature adds two new service codes; Read Tag Fragmented and Write Tag Fragmented. These service codes allow us to exchange very large Tag Arrays and UDTs (User Defined Types) between a PLC and your embedded device.

With these new services we now have the capability to transfer 65,535 array elements between your device and a Logix PLC. That’s independent of data type. You can transfer 65K Floats, 65K Ints or 65K Sints. It doesn’t matter. If you are using an array of UDTs, you can transfer 65K array elements of your UDT. That’s a lot of data. A lot more than we could ever transfer previously.

The best thing about this is that from your application this is all seamless. You just pass the array name to us and the Tag Client interface handles all the fragmentation for you. You just process the buffer with your data.

If you’d like to use this facility please contact me about getting a software upgrade.

John

I have a weird relationship with Profibus. I like a bunch of things about it but I’m not fond of other things.

Profibus is more and more important. It used to be that Profibus was only found in Europe where Siemens was dominant. DeviceNet was in the US, Profibus in Europe.

Well, that’s over now. Siemens has made huge strides in the US. So much so that it’s not hard to find manufacturing sites in the US that have standardized on Profibus IO.  Rockwell even had a module created so that their ControlLogix PLC platform could use Profibus (and Profinet IO) IO though its kind of a “hands off” module as they directed one of their close partners to make it and sell it.

Profibus had two huge advantages over DeviceNet. One is speed and the second is data size.

The speed is what I really like about Profibus. 12Meg. That’s really fast. Faster than most people need but generally automation engineers believe that when possible, it’s always best to go faster. I remember that a guy who had four injection molding machines that dropped a part every 27 seconds told me he was getting 100Gig Ethernet for communications with those machines. With a part dropping every 27 seconds I was thinking that 300 baud serial would do just fine.

Speed has its downside though and that’s cost. It costs more to go that fast. A special ASIC with the communications infrastructure on it (MAC – Media Access) and special transceivers, cabling and connectors. All that makes Profibus devices significantly costlier than DeviceNet devices. DeviceNet can actual be really done on the cheap. The controller chips are pretty cheap and you can use real inexpensive connectors if you are doing a device that operates off of CAN power.

That’s about the only time that DeviceNet has an advantage. Network powered devices that move a few bits from a device to the controller. Simple devices like proximity sensors, photoeyes and such will always be more cost effective on DeviceNet than Profibus. And usually with mechanical devices, the speed Profibus advantage isn’t that important since the mechanicals don’t move all that fast.

But when you get to more complex devices like drives, scales and the like, Profibus is clearly a better solution. These devices are more costly to begin with, have more data to transfer and sometimes can use the higher speed.

The data size advantage over DeviceNet is significant. Profibus has a frame size of 244 bytes. That’s monstrous compared to 8 bytes frames in CAN. Yes – DeviceNet has fragmentation but that eats up so much bandwidth it is hardly useable.

One of the things I dislike about Profibus is the data representation. All Profibus devices look like a rack of I/O to the controller. That means that a device is a series of slots, each slot with a module in it and all sorts of different size modules.

That’s easy for simple devices like I/O devices. You can simply decide that the first slot has a module that is a 16 Discrete Input device. The second is 8 bit of Discrete Output and so on. If you have Analog in/outs too, you could setup the device using four slots and four modules.

But how do you do a Scale? What is the structure for that? What is the structure for a barcode reader. This data representation doesn’t easily fit those devices. It gets kind of awkward.

We have a lot of DeviceNet gateways in our gateway product list. This month we will be adding a bunch of Profibus gateways; Profibus ASCII, Profibus to Modbus TCP, Profibus to Modbus RTU and more. I hope you will take a look at them.

About ten years ago I got myself in a world of trouble. Big Trouble. I sent out a newsletter with the title “DeviceNet is Dead”. Basically I said that Ethernet would dominate the factory floor in the future. Valid point but the tile was extremely incendiary.

And arrows from the world over rained down on me. Rockwell was pissed. DeviceNet Vendors were pissed. Some proposed throwing me out of the ODVA. Eaton Cutler Hammer called to complain.

One of the marketing flunkies over there called to complain that their customers were calling them and wondering if DeviceNet was obsolete and what the plan was to move to Ethernet. He kept repeating how many customers were calling and the burden they were under having to “talk to their customers” about the future and their future product plans. The irony of this was completely lost on him.

My response was that I didn’t care. The fact that they had to talk to customers was not going to make me lose sleep at night. Between their customers calling and the starvation in sub-Sahara Africa I wasn’t much concerned about them.

So, it’s ten years later. Where do we stand with DeviceNet, and for that matter, Profibus DP. Are they dead? Is everything going to Ethernet?

I have to tell you that the future for these technologies is not all that clear to me. I can make the case either way.

I do know that processors are getting more sophisticated and have built-in Ethernet functionality. The low level processors that are usually used with DeviceNet and Profibus are becoming more rare and gradually being phased out. So the technology trends seem to indicate a move to Ethernet.

The configuration trends also point to Ethernet. Having web-based configuration, monitoring, diagnostics and the rest is important. And you can’t do that as well on DeviceNet. End users like the ability to access a web page for a sensor from their smartphone to check on device status.

Is there any advantage to the Profibus and DeviceNet networks? Well, comfort. People have been using these for a long time. They provide good, near deterministic response. They are actually very good for the kinds of applications where they are used.

The only disadvantage of Ethernet is the star architectures you have to use. Buying lots of big switches is not attractive. But with the increasing deployment of devices with built in Ethernet switches, all that goes away.

So what will happen when the next line that is built? Sensor bus network like DeviceNet or Profibus? Or some Ethernet? I’d guess Ethernet. Ethernet is so pervasive. It has almost no disadvantages other than the switch issue and integrators and end users are just as comfortable with it as they are with DeviceNet and Profibus.

So, my announcement that DeviceNet is Dead was a little premature. Ten years later, it might still be but the fat lady is starting to warm up. I won’t expect to see much new DeviceNet and Profibus when I write an update to this blog ten years from now.

PRINTER COMMUNICATIONS

One of the most prevalent applications for our products is connecting printers to controllers. As you certainly know there are all kinds of printers and applications. And a lot of them don’t even print anything in the traditional sense. Some of them are really engravers and embossers.  Others use various techniques for encoding information physically on a product.

Let’s talk about the kinds of ways that these printers are driven and how you can connect them to your controllers.

Let’s start with physical connections. There are two basic ways to connect a printer to a controller; serially or over Ethernet [I’m going to skip parallel printers because if you’ve decided to use a parallel printer, your beyond hope]. Serial is the traditional approach. And 90% of the time, those printers will use RS232 as the electrical standard. But RS232 always presents some problems. It’s limited to 50 feet so you have to keep your printer close to the controller and it’s not very noise immune. That can be a real problem in a lot of factories.

But if the printer supports Ethernet, and a lot of them do, the distance and noise issue go away. You can put the printer anywhere you have an Ethernet switch. And noise won’t be a problem if you’re sending data over Ethernet.

But no matter what kind of physical layer you use, you still have to process the printer data, the characters that are printed and any controller characters that it sends.

Sometimes that’s just straight ASCII with a CR (Carriage Return) and LF (Line Feed) on the end. Those are the easiest ones to deal with. Lots of people just hook those up to the serial port of the controller and blast out the printer data over RS232. But if your printer isn’t near the controller or you don’t have a spare serial port, our 435NBX (http://www.rtaautomation.com/products/435/nbx.html) takes the string data out of the controller, adds the termination characters on the end and sends it serially to the printer. That’s a great tool if you need to remotely locate your printer.

And if the printer is on TCP we have an equivalent tool, the 490NBX (http://www.rtaautomation.com/products/490/TCPControl.html). The 490NBX grabs the printer data in your Controllogix data table and sends it to the printer over standard TCP/IP. On the PLC side it works exactly like the 435NBX.

But what if the printer data is more complicated? Sometimes there are printer control characters involved. Sometimes there are multiple messages. Most of the time the 435NBX and the 490NBX can handle those situations. In a lot of cases, you can embed the printer control characters right in the ASCII string. You’ll have to see your PLC handbook on how to do that.

What those devices can’t handle though is when there has to be a dialog between the printer and the controller. Some printers use their own protocol and have a pretty extensive command set. The controller must send command 55 followed by command 23 and then 49. Each one of these reports back to the controller with a status or some data.

This kind of interaction is handled using our tailoring services. We actually implement that command set in our unit and the unit will do all the interaction with the printer. All you do in the PLC is to kick off the interaction and give us the base data we need to send.

That kind of project is handled on a case by case basis.  Just call our office and we’ll arrange a phone meeting where we can go over all the details.

Happy Printing…

When I gave Drew, our fun and entertainment director, the title of this piece, he had lots of off color remarks about its content. Loose and tight lend themselves to a lot of “interpretation”. It might be fun to go there but we’d have to be drinking brews to have that conversation.

Instead I’d like to talk about difference between “loosely-coupled” systems and “tightly-coupled” systems. I’m sure that these are not new concepts but I think they maybe haven’t been explained in light of the current trend toward the integration of factory floor systems and enterprise systems.

I would argue that factory floor systems should be labeled tightly-coupled. Systems that use Profibus, Profinet IO, DeviceNet, EtherNet/IP or any Modbus version have a very strict architecture. These are really I/O systems much as the ODVA and PI (Profinet International) would have you believe otherwise. [Those folks like to argue that you can extend these protocols all the way up the factory architecture to the enterprise but that’s just not workable.]

Tightly coupled systems have these kinds of characteristics:

1.       A strictly defined communication model where device communication is inflexible and tightly regulated

2.       A strictly defined data model with a limited set of proprietary objects

3.       A requirement for human intervention to change the communication or data model

Tightly coupled systems provide much needed, well-defined functionality in a highly specific domain. Expanding operation to other domains or trying to provide more general operation is difficult. Making more generic data and functionality available requires significant programming resources that result in a very fragile interface. And that’s why tightly coupled systems are wrong for Enterprise communications.

Loosely coupled systems, on the other hand, provide exactly the right kind of interface for enterprise communications. Loosely coupled systems decouple the platform from the data, the data from the data model and provide a much more dynamic mechanism for moving data.

Loosely coupled systems have these kinds of characteristics:

1.       A widely used, standards based transport layer; TCP and HTTP.

2.       An open, platform independent, easy to implement encoding; XML

3.       An extensible operating interface; SOAP

What I’ve described here is web services. Web Services is the backbone of everything we do on the internet. It is extensible, flexible, platform independent – all required for the ever expanding internet.

The challenge is to how to best connect the tightly coupled factory floor architectures with the loosely coupled web services architecture of the Internet. Rockwell has its Factory Talk product line. The ODVA promotes EtherNet/IP. PI promotes Profinet IO. I don’t believe any of these are good solutions.

The solution? I’ve thought a lot about it and I think it’s OPC UA for reasons that I’ve explained in earlier articles.

In the Rockwell Automation world it is common to find applications on Windows or Linux that exchange data with PLCs like ControlLogix and CompactLogix. These applications can be found in all sorts of industries. They typically have some special logic, user interface or a database component that makes it not feasible in an HMI or PLC. Recipe managers are a good example of these types of applications.

In the Rockwell world, this kind of thing is easy to do. It is easy to get a tool, like our EtherNet/IP Tag Client, that can read and write tags in ControlLogix PLC. These tools open a connection to the PLC and read and writes tags whenever needed. Rockwell has made this interface easy to do.

In the Siemens world, it’s not that easy. In fact there are a lot of difficulties. Let’s start with Profinet IO. As you know there are a number of Profinet flavors. There’s CBA, IO and IRT. CBA is virtually obsolete and IRT requires special hardware so let’s take a look at IO.

To have the equivalent functionality that you find in the Rockwell world, you need two things. One, Profinet IO Controller-side software and two a PLC that can be a Profinet IO device. Well, the last time I checked (this changes quickly) there is no IO Controller code that you can get anywhere. No one has it. You can probably get embedded modules from Ixxat, Hilscher and Softing that do Controller side communication but that is awkward. You have to use some other communication mechanism to talk to the embedded module.

What about the S7 PLC? Well, there’s really little help there either. An S7 can not be configured as a Profinet IO device. It just doesn’t work that way. It’s the Controller, not a device.

If you really want to duplicate the functionality that Rockwell has in the Siemens environment you have to use the proprietary S7 code. You can get that from Siemens by special arrangement but it’s not easy. There is also some open source or free software that’s floating around on the Internet.

I’d be wary of that though. If Siemens revs a controller and changes something, it might impact the interface and then what do you do? Hard to know what changed and how to fix it. To which S7s does the change apply? It gets ugly fast. People are doing this now, it’s just a little more precarious.

So, if you have one of these applications  that rides on top of a Rockwell PLC and are thinking about doing the same thing for Siemens – note that it’s a bit harder. Not impossible but harder and more precarious.

DISCLAIMER TIME – I live in the Rockwell world about 80% of the time. Siemens is a huge company with a lot of moving parts. If something has been made available that I don’t know about I’ll update this blog and get that information posted. Let me know!

There’s a discussion I seem to be having about once a week on implementing OPC UA (Unified Architecture). The people on my side of the world, automation, seem to think that UA is just another protocol like DeviceNet, Modbus TCP, EtherNet/IP or Profinet IO. That’s silly but I don’t blame them for thinking that.

In Automation, all those protocols are basically alike. There is a block of Outputs that move from some controller to some end device; a PLC sending speed command to a Drive. There are some Inputs coming from the target device to the controller; a valve block sending valve status bits to the PLC. The specifics vary but all the standard automation protocols have this sort of functionality. I/O moves from here to there at some cyclic rate.

And that’s why all the automation guys want to put OPC UA in that I/O box. They are thinking that it’s just another one of these protocols with a new twist to it.

Just yesterday, Vince, one of our newest engineers asked me about implement UA for a project I just assigned to him. We were discussing it and he says “UA has an Object Model just like DeviceNet”. And I go “Only if you would say a Ruth’s Chris Steak is just like a white castle burger”.

What Vince doesn’t understand is that UA is more of an IT protocol than an automation protocol. Before starting an implementation you have to wrap your mind around the fact that UA exists to move non-control data to some server in a very open, extremely secure and highly organized way. It doesn’t exist to move I/O data to a controller.

The key to understanding this is that UA servers a different but complementary purpose than those automation protocols Vince was thinking about. Once you get past that, you can start to think about implementing OPC UA.

If you’re a device developer implementing a UA stack, Step 1 is identifying the data you want to make available to UA Clients like databases, quality tools, energy management systems and more. If this is a Drive that is connected to a controller over Profinet IO or EtherNet/IP, you don’t want to duplicate all the information that is going to the PLC. Current Drive status (run/stop/faulted) and speed are already over there in that environment and available to process controllers and HMIs.

Instead you probably want to think about the data that a maintenance guy might need (run time, number cycles), the data the plant IT people might want (last time the drive profile changed), the data the group concerned with monitoring energy might need (current KW and KW month-to-date) or the data mechanical guys might want to see (a torque profile). It’s very different way of looking at a plant floor device.

Once you get there, you will need to start thinking about the OPC UA functionality you want to build into your device. Here is a not at all comprehensive OPC UA implementation checklist:

1.       Address Space – How does the data that you defined interrelate? Is there a hierarchy? How much access do you want to give to the user to customize the address space? Can they add or delete nodes or will it be fixed? What Attributes are read only and which ones are writeable?

2.       Views of the address space – will different users have different views of your device? Will the maintenance guy want to access a different subset of information than the energy manager?

3.       What alarms will each of these users require?

4.       What level of security is required? If your device is going to be accessed over the Internet, you will probably need security? Do you need 128 or 256 bit security? Can your hardware support 256 bit security? What security models does your Client support?

5.       What Transport mappings and data encodings should you support? There will be some Clients that will only use .net. If you aren’t using something like embedded windows, you may not be able to talk to those kinds of devices.

6.       What Events will you make available for notification?

7.       What UA Services must be supported? What Services should you support?

8.       Do you want to implement the Historical functionality where the device manages history data? I’d guess that few devices will implement this.

9.       How will your device support device discovery under UA?

10.   Do you want to support Methods? Methods are essentially vendor specific functionality. A calibration process might be a Method?

Once you have all this information, next you need to identify the profile for the device that most closely matches your functionality. And, then check with your client devices to make sure they can support that profile. It’s not for the faint hearted. There’s a reason the trailblazers take the arrows and right now, UA is trailblazing kind of stuff.