OPC UA Server Object

UAobjectsThere’s a lot of interest around the globe for OPC UA. One of the drivers is that UA is an extension of the original OPC which I have been calling OPC Classic. I named it after Classic Coke. Though UA isn’t the same throwback after a terrible experiment that Classic Coke was.

The more I learn about UA the more I marvel at its complexity and simplicity. It is both very powerful and at the highest level, very easy to understand. The power comes in the Type System, Object Model, multiple transport layers and ability to wrap other protocols.

For the past several days I have been studying the Server Object. Like everything else in UA there are layers and layers of complexity to it.

The Server Object is, like almost all UA Objects, an instance of a Type Definition. In its case, its Type Definition is the ServerType which is itself, a subtype of the BaseObjectType. All the type definitions for UA are neatly grouped under the root node. From the Root Node in every Server you can follow the reference to the Types Object. From there you can follow the reference to the ObjectTypes Object. And from there to the BaseObjectType which is the parent of the ServerType. A Client can follow references from the Root Node through the Types Object to find the definition of any Object in a UA Server.

The Server object, which is required as part of the Core Server Facet, neatly organizes a lot of information about the Server and makes it easily available to Clients who want to know the capabilities of the Server, its current operational status and any diagnostic information that the Server can provide. Since all Profiles are based on the Core Server Facet, a Client can count on being able to find this information by reading the Attributes and properties of the Server Object. A Client can find the Server Object from the Root Node of the Server by following the reference to the Objects Object and then to the Server Object.

In the Server Object you will find a number of different kinds of references:
ORGANIZES – An Organizes reference serves no purpose other than to establish a relationship from one the source Object to the nodes it organizes. The Root Node, for example, uses Organizes references to relate the base View, Objects and Types Objects to it. The View Node Organizes all references to the currently existing Views in a system. The Server is the destination node for a Organizes reference from the Objects Object.

COMPONENT – A component reference implies a “stronger” relationship between the Source Object and the Destination Object. A Component reference through a hasComponent reference implies that the destination Object is part of the Source Object. The Server Object, for example, has hasComponent references to the ServerCapabilities Object, VendorServerInfo Object and Namespaces Object. Whenever the destination is complex, meaning it is more than just a simple variable, UA requires that a hasComponet …

Data Modeling in Industrial Automation

datamodelingIn lots of ways the Industrial Automation business has been pretty unsophisticated for a very long time. There’s lots of reasons for this. IA uses PLCs and these have been pretty unsophisticated since, well, their creation.

PLCs have always had the identical structure. Get Inputs in, process the logic, set new Outputs…repeat forever. The data types were pretty limited. Binary, Integer and Floating Point and arrays of those items for the most part. Then later on, structures were included and then user defined structures.

Logic wasn’t any better. You had subroutines but software engineering principles that were well-developed and used in higher level languages generally weren’t applied to Ladder Logic development tools. IEC 6-1131 has done a good job improving some of this but ladder is still ladder. The polymorphism and inheritance that you find in a C++ isn’t even whispered about when it comes to ladder.

Another factor that has kept Industrial Automation in the dark ages is that most data is just binary. It’s a sensor input like a photo eye or an actuator output like a gate. The data being processed has relationships to other data but those relationships were pretty much ignored. The fact that the photo eye was part of the folder device on a packaging machine was ignored. It provided little value in the “old” days.

EtherNet/IP and Profinet IO and all the other factory floor protocols haven’t done anything to change the way that we look at factory floor data. It’s still just plain old inputs and outputs. An Ethernet application layer protocol like EtherNet/IP or an application layer protocol like Profinet IO may have some semblance of object based structure but none of that is really present in the communications. It’s still a bunch of inputs in and outputs out.

The techniques that have evolved in the higher level languages used in general computation just haven’t been used on the factory floor. The evolution there was different. From day one, people who built business systems had to think about relationships. They had to consider how one piece of data was related to another piece of data. They had to consider this as they collected it, as they stored it and as they reported it. It was central to all their thinking.

To do this they created all sorts of techniques and technologies for data modeling. In the ‘80s, one of the seminal ideas for data modeling was engineered by G.M. Nijssen. Deemed NIAM, short for “Nijssen’s Information Analysis Methodology,”. Later is was called ORM, or “object role modeling.” This approach shows representations of relationships instead of showing types of entities as a rational table. That’s a lot of gobblygook but it means that ORM shows relationships and constraints.

Today, because of the superb capabilities of OPC UA, we now have the first real ability to model information on the factory floor. In UA, we have a true extensible Type Definition system and a real ability to describe data, device, machines, lines, anything …

Future of the Factory Floor

Factoryfloorfuture

I’m hearing a lot of talk about IT protocols and the factory floor. This stems from the fact that the Factory Floor is slowly becoming IT. It’s much like the continents drifting around the globe over time. Continents form, move together, move apart over thousands of years. Continents of IT and the Factory Floor are now moving together.

It’s going to happen a lot faster than some vendors in factory automation would like. It’s also apparent to me that IT is going to absorb the factory floor and make the Engineers who work on the factory floor part of IT. As that happens, I think vendors will respond by making their products have more IT “friendly” features.

If you look at IT kinds of products they use a lot of XML, SOAP, SNMP and Web Services. Things pretty easily integrate. You can find interfaces available on the network, figure out what they do and connect and use those interfaces pretty easily. There are things like WSDL documents that publicly describe what is available. We all know that it’s a lot harder on the factory floor. We have things like EtherNet/IP, DeviceNet, Profibus DP and PLCs.

What’s this evolution going to look like? Well, certainly it’s clear that PLCs will look a lot more like Servers with built-in routers over the next few years. They’ll support Oracle and Sequel databases, HTML5 Web pages and web services. You’ll probably have the ability to write control code in Java or IEC 6-1131. We won’t lose all the factory floor protocols – those things will still do all the hard work of communicating with I/O.

What will be different is that these PLC Servers will be easily integrated with the Enterprise. They’ll look to the Enterprise just like any other Enterprise Server. It’s just that there will be a back end to these devices that does factory floor I/O and Control. With the speed and bandwidth of Servers today and the ability to partition the hardware and software it will be easy to use standard Servers as PLCs in the future. In fact, there is no reason to have the physical footprint of the PLCs we have today. A hardened server will do the trick nicely. I expect that Siemens, Rockwell and other PLC manufacturers will probably become software companies in the future at least in regard to the control currently found in their PLC’s.

The key, of course, is going to be security. That’s where OPC UA comes in. I expect UA to be the prime Transport layer for all the Enterprise / PLC communications in the future. It has the ability to support IT transports like Web Services as well as fast binary. With its adaptable, user configurable and powerful security component it makes the most sense as the prime data mover between the factory floor and Enterprise.

I do expect HMIs to disappear also. Everyone will have their own person HMI on them with their own web pages or dashboard that …

Betamax and HMI’s

BetaandHMIsI’m old enough to remember the war between VHS and Betamax. If you don’t remember, these were the first two tape formats for home video recording. Betamax was the Sony standard, while VHS was the standard from JVC. Eventually JVC won the war, even though Betamax was clearly the superior technology. JVC did a really smart thing. They licensed their technology to any and every manufacturer they could find. Those manufacturers all started putting out nearly identical machines that competed with each other. Price became the distinguishing factor, and the manufacturers outdid each other to see who could sell for the lowest price.

Meanwhile, Sony had its very high quality, superior technology Betamax units. The people who bought them bragged about having better quality machines, implying that they were somehow smarter and more prescient than the rest of us. But in the end, we had the last laugh: Sony couldn’t compete with all the low cost VHS manufacturers and Beta died a slow death. Eventually, those arrogant Betamax users had to go out and buy a VHS machine. (Of course, DVR technology then killed VHS.)

We have a similar contest going on that is going to have some impact on the Industrial Automation industry. Since smart phones were introduced, there have been people who saw the smartphone as a “personal HMI.” The idea is that instead of walking up to one of those Rockwell PanelView screens on the side of the machine, you simply pull out your smart phone and look at the data you’re interested in.

There have always been issues with this. One way to do this is to use your cellular provider to access your manufacturing network. That’s not an option that every management team has readily accepted given the security issues with opening up their manufacturing networks to cellular access. People are doing this, but it’s awkward and requires some significant thinking and planning to pull off securely, and that’s what matters most.

Other management teams have just said NO – you can’t use your smartphone to access machine data. I think that’s shortsighted. The new engineers we’re now getting in the automation industry think of their smartphone as their sixth sense. It’s integral to them. As they grow and mature, you can bet that they’ll be pushing for more access.

Well, there is another way to access machine data from a smartphone – or should I say two ways. I am talking about the contest between NFC (Near Field Communications) and Bluetooth LE. With these technologies, the smartphone doesn’t use its cellular communications to access machine data; instead it accesses the machine data whenever it’s in range over one of these short-range technologies.

Near Field Communications (NFC) is a descendant of the RFID (radio-frequency identification) technology we’ve long used on the factory floor. RFID allows a reader to send radio waves to a passive electronic tag for identification, authentication and tracking. NFC is a similar technology that communicates either by a modulated electric field (not …

Stop the Presses

Stop-the-PressesSTOP THE PRESSES! Major advancement in automation technology is upon us…Rockwellis introducing a Micrologix processor with USB.

Can you believe it? Isn’t it everything you and I have been waiting for with “baited” (whatever that is) breath?

Why next week we might hear that apples are coming to market with another shade of red; TVs with digital tuning and cars with radial tires.

I mean, really, I don’t mind USB. I just don’t think it has much place on the factory floor. Let me explain.

1.       It has no legs – 16feet is about it. You have to be really close to the equipment to get connected. Why do I want to walk halfway across my plant to plug my laptop into this processor? Why can’t I access it from my desk.

2.       There are a number of different standards. One side is, of course, the controller side and the other is the adapter. You have to make sure that you’re the end that your customer needs you to be. And there’s a bunch of different standards. USB 1.0, 2.0 and 3.0. Some of them incompatible depending on the implementation. It’s really not as simple as the Marketing guy saying “we need to support USB” and you doing it.

3.       And then there are power considerations. These USB devices will want power and you have to support it. How much? Well, it varies…

Lots of ways to screw up with USB. That’s one of the reasons I don’t like it.

But I understand why they are doing it. PCs don’t have serial ports anymore. In the effort to get the price of a PC to less than a candy bar, they’ve eliminated the serial port and most everything else. I’m sure over the last 5 years they have had a host of customers asking for USB. And now, they’ve “quickly” responded.

TOO LITTLE. TOO LATE.

The trend now is to smart phones, IPADs and a host of other wireless devices. They should have just skipped right past USB and made their controllers work seamlessly with these devices. You can bet that in the bowels of Mayfield Heights they are right now thinking about writing specifications for wireless access to those controllers. [I am sure I’m being a bit unfair here – it takes a long time to get anything done in any huge corporation]

OK, here’s what really frosts my cookies about this. Lots and lots of their customers are going to be confused by this. They’re going to think that RA has just introduced some magic way to access PLCs. That the USB port is the magic bullet for uploading and downloading programs and doing data table read and writes.

Believe me it won’t be. It’s going to be the same as a serial port.

On the serial ports, you need a DF/1 protocol to send PCCC messages. And with those messages you can read or write any data item in the controller.

Now those PCCC messages are going …