Custom OEM Solutions

OEMOne of the things that RTA doesn’t promote very much is our ability to do custom OEM solutions. These solutions serve customers with applications scenarios that have proprietary communication protocols, a unique footprint, special I/O requirements or some special logic.
We’ve done a lot of this work over the years. We’ve made custom hardware for all sorts of applications. For many, many years, customers have used our custom OEM hardware in automotive tool changer modules.

Today we mostly do custom configurations and brand labels of our off the shelf gateways. A lot of these are higher volume applications where the customer wants to use the same configuration in every module. In a lot of these cases, we put the customer’s logo on all the web pages and preset most or even all the configuration so that the unit can be easily integrated into the customer’s equipment. For example, in our 460MSBS, Modbus TCP to BACnet gateway, we would preset all the properties that are read from as BACnet device data. We would predefine all the destination Modbus registers for the Modbus side and we might even set the IP addressing. Really, anything is possible.

Unfortunately, there are still a lot of devices with proprietary protocols around. I don’t expect that to change. There are some management types and some engineers that just like having their own communication protocol so that outsiders can’t access their equipment without authorization. That can make some sense if the protocol allows a device to modify safety-related or critical operating parameters and change how the equipment works.

But often that’s not the case. Instead, the company has some software package that accesses their device and does reporting. To preserve the market for their software package, they might use proprietary communications. If they used some open protocol, someone could write a driver and pump the data into Excel, limiting sales of their software package. I know of an inspection company that uses this exact strategy. We’re creating an OEM module for them that provides access to their equipment from Allen-Bradley PLCs, Siemens PLCs and Modbus TCP Client devices.

We’ve done a lot of OEM packages that turn these kinds of proprietary protocols into open protocols. If you ever have a proprietary protocol and need it translated to some open standard, it can be a very simple and easy process or it can be extremely difficult and time consuming. It depends on the number of commands in the proprietary protocol, how much data is supported, how fast it communicates, and what the transport protocol is.

The transport protocols can vary. We’ve seen a lot of RS485 and Ethernet, but also a fair amount of CAN. Controller Area Networking (CAN) is a popular mechanism for easily connecting devices on a local network. It’s fast, with speeds up to 1MBaud, it’s easy to use, and there is little effort for the programmer since all he does is put the data block in the transmit registers. CAN has the additional benefit …

IA, BA, Star Trek

BA-IA_StI always loved the original Star Trek series. The original. Not any of the extensions that followed. I liked the old ones. The ones with the really awful special effects, the terribly done fight scenes and the really racy (for the day) “love” scenes for Captain Kirk. Alright, it wasn’t really love scenes. There was hardly was as much as a kiss, but when I was twelve, what they had was pretty thrilling.

It was good vs. evil. Very simple premise. William Shatner and Leonard Nimoy fighting the Klingons. The Klingons – dastardly enemies. Dirty, conniving, thieving aliens who were always suspicious of Kirk, the Enterprise and the United Federation of Planets (UFP).

Here’s a huge leap. I’m going to compare the United Federation of Planets vs. the Klingons to the Building Automation (BA) and the Industrial Automation (IA) industries (you won’t get that anywhere else). I’ll admit it’s a pretty big stretch, but that’s how my mind works. They’re not at war. They don’t hate each other. But the people working in one industry just don’t understand a lot about the people working in the other industry. Yes, they both do automation, but there are differences. Lots of differences.

For example, speed – BA data is pretty slow. Flow rates, temperatures, cooling or heating initiation, it’s all stuff that can take seconds. Moreover, it’s stuff that no one cares about. If I get the temperature in the cooling tower every one second or every thirty seconds, it really doesn’t matter as the temperature doesn’t move that fast. In IA we have a lot more speed concerns. When you start a production line, it had better start in the next half second, not thirty seconds from now. I remember GM saying that a two second delay starting a line could cost them $2,000,000 a year.

There are other differences too. People tend not to just work on one building but rather work on many different sites. In IA, a control engineer might spend his whole career in one place.

I thought about this today because we’ve really made some cool new products at RTA to link BA and IA together. For the first time, there are BACnet gateways that function as BACnet IP Clients and BACnet MS/TP Masters.

What’s that mean?

There are a lot of possibilities. For example, it means that a PLC for the first time can access a BACnet IP Server device or a BACnet MS/TP Slave device as an EtherNet/IP Adapter. Our gateway can make up to 32 BACnet devices act like EtherNet/IP Adapters.

This is a pretty significant. There are a lot of times when PLCs need to access building kind of control devices and RTA is providing those integrators with a great way to do that. I’ll look forward to getting your feedback on this exciting addition to our product line. Just don’t comment on the silliness of the analogy to Captain Kirk and the Klingons. Do you think the Enterprise had BACnet? John…

Grid Security

gridsecurityI’m worried. No, not about my weight. I’m doing as well at that as I am with getting younger. And just to be clear, I’M NOT GETTING YOUNGER.

What worries me is what happened to Sony pictures recently. In case you missed it, they were brutally and ruthlessly attacked by what I (and many others) believe was the government of North Korea in retribution for the Sony movie The Interview.

In the movie, Seth Rogen and James Franco are recruited by the CIA to assassinate North Korean dictator Kim Jong-un. The two have a hit TV show, and Kim Jong-un is a huge fan. To enhance their journalistic credentials, they get an interview with him, at which point the CIA intervenes and tries to recruit Rogen and Franco to assassinate the Beloved Leader. As they are totally incompetent and inept, the plan is doomed from the beginning, and it falls apart with hilarious consequences.

Kim Jong-un was not amused. Though he denies it, it is pretty apparent that the North Korean state’s cyber army was directed to attack Sony. Sony has released few details, but this event is thought to be the most destructive attack yet on a US company. It is likely that the attack knocked much of Sony’s network off line with malware that wipes the drives of PCs. A lot of Sony’s intellectual property, including unreleased movies, is thought to have been stolen during the attack. Apparently, the cyber attackers had free rein inside Sony’s network. Sony likely will never release the complete details of what they lost (if they ever really know).

This reminds me of the attack on the PG&E Metcalf substation in April of 2013. Not much was made of that attack as destructive as it was, since the Boston Marathon bombing occurred the day before. This attack was well organized, well planned and well executed. Communications cables were cut and a large number of rounds from high-powered rifles were fired at the generator in an apparent attempt to make it explode.

The electrical substation was disabled for nearly a month, with repairs costing several million dollars. It could have been much worse. There are only one or two suppliers of massive generators like this in the world, the largest of them in South Korea. Making one is not an overnight endeavor. Replacing a group of them, disabled in a coordinated attack, would be impossible.

Luckily, the Metcalf attack occurred in the middle of the night when power demand was low, and the utility was able to reroute electrical power. FERC (Federal Energy Regulatory Commission) chairman Jon Wellinghoff called the attack the most significant incident of domestic terrorism against the electrical grid ever. No one was ever arrested. The case remains unsolved.

Security of our country’s infrastructure and our production facilities is going to become increasingly important in the years ahead. I predict that some major manufacturer or plant will be targeted for cyber destruction in the near future. I hope such an attack …

EtherNet/IP Variations

EIPvarI have a lot of customers that want EtherNet/IP. But just like buying anything else, it’s just not that easy.
Just last week I did something that almost no one does anymore. I bought a camera. That’s right: I bought a device designed specifically to take pictures. Still pictures and movie pictures.

And like any other complex buy, it wasn’t as simple as it seemed at first. There are lots of different types of cameras for lots of different purposes. There are cameras for photographing wildlife, cameras for underwater shots, and cameras that you can strap to your head for who knows what reason (the last thing I want is a camera strapped to my head).

EtherNet/IP is something complex, possibly even more complex than a camera. There are a few different kinds of EtherNet/IP and you have to decide what is going to work best in your application.

The EtherNet/IP Scanner is our software that opens connections, send outputs to devices, and gets inputs from devices. It is the “PLC side” of an EtherNet/IP network. The Scanner is usually the controller in the system and there is usually just one controller, but there could be more.

The most difficult part of implementing a Scanner is that the Scanner must be configured. It must know what devices to open, what each IP address is, how many bytes of data are being transferred from each device, and how much to send to each device. How you get that data to it is an application decision. You can read the EDS file for the devices, you can use some custom application program, or, in a lot of cases, you can make the device list fixed. A fixed device list is one where the devices are always going to be there and never change. The tools of a Robot, for example, would be an application where the device list would be fixed. Those tools are going to always be there, day in and day out, and never change.

You want to buy an EtherNet/IP Scanner when you need to control a set of devices on an EtherNet/IP network. Typically, your device is going to be the controller, getting inputs, processing logic against those inputs, and setting outputs. If that’s what you want, then you need an EtherNet/IP Scanner.

An EtherNet/IP Scanner opens EtherNet/IP devices. Those devices, on that end of the network, are called Adapters. Adapters are end devices like valves, I/O blocks, drives, scales, meters and everything else you might find in an automation system. An Adapter has one job: connect the virtual I/O that gets transferred back and forth from the Scanner with the real world I/O. An Adapter takes the Outputs from the Scanner and manipulates real world, physical outputs. An Adapter takes real world inputs, digitizes them and sends them back to the Scanner. If no Scanner talks to it, an Adapter just sits there idling away its time (like some folks I know at big companies).

You want …

Windows Embedded vs. Linux

linuxvswindowsI’m an agnostic. I just don’t care.

No, not regarding religious beliefs. I’m talking about what OS and TCP/IP stacks our customers use.

A lot of what we do is getting customers enabled to do Profinet IO, EtherNet/IP, Modbus TCP, DeviceNet and all the rest. The best way to do that is to integrate our software directly into their OS. That means that we have to be able to work with all the top stacks that people might use.

I never encourage these guys one way or the other. The choice of MQX, uCOS, QNX, VxWorks or Nucleus always seems to be a really important personal decision. In the old days, before I knew better, I might question a decision for one or the other. No more. I learned that the choice of an embedded OS is protected by nothing less than the US Constitution and I’d better keep my opinions to myself. It’s kind of like someone’s choice in women. Some only will date short blondes, while others go nuts over a tall redhead. Those guys will claim it’s about features and functions, but I think it’s more personal preference.

Well, the debate’s on again and this time it’s the embedded Linux vs. embedded Windows front. Both camps are digging trenches, stockpiling weapons and training armies. The war simmered for a number of years, never more than a low-level regional conflict while Microsoft went through its troubles. The embedded version of Windows had security issues, resource issues (it was monstrously large) and a bad reputation on the factory floor.

Now, with the emergence of IT on the factory floor, high-speed processors, massive amounts of low-cost flash and RAM and the need to communicate with the Enterprise, vendors are taking another look. A Windows system has a lot to recommend it. Even though it’s always going to pose security risks, there are good reasons for selecting it for your embedded platform. You can make a pretty strong case that development is easier and that you have much more flexibility on the factory floor.

But you can make a good case for Linux too. It’s less of a resource hog, it’s reliable, it’s arguably more secure than Windows, and it’s a lot less expensive. On the downside, there are lots of different variants to select from, there are possibly fewer platforms that will support Linux, and support can be more difficult to obtain.

Recently I’ve seen a pretty good increase in the number of customers that are building EtherNet/IP Windows devices, Profinet IO Windows devices, Windows OPC UA servers and other Ethernet devices on Windows. Several years ago, Microsoft made a pretty big commitment to the factory floor and has steadily improved its offerings. The original CE was pretty much a disaster, but the later versions and XP Embedded are much improved.

So, what am I planning to do? RTA designs, develops and sells automation devices. System Integrators use our Device Converters to move data around the factory floor and around …