BACnet Data Representation

BA-data copyTo understand a standard what you have to do is to focus on the data representation. How a protocol represents data is key to its functionality. Once you understand the data representation, then it’s simply a matter of figuring out how that data is moved from Point A to Point B over whatever physical layer it uses.

In BACnet, the basic construct to organize data is an Object. An Object is really key to the operation of BACnet. Objects contain the physical data – temperatures, counts, rates and everything else captured by our automated devices. Groups of Objects represent the devices themselves. A flow meter can be represented by a group of Analog Input Objects and some Binary Objects. Objects are really at the center of BACnet technology.

BACnet has eighteen different objects in its specification. That list includes the most common objects, objects you’ll find in most BACnet devices: the Analog Input Object, the Analog Output Object, the Binary Input Object, the Binary Output Object and the Binary Value Object. It also includes some objects you might never run into in an entire career, like the Notification Class Object and the Loop Object.

Every BACnet Object is composed of a set of properties. The properties of an Object describe the Object to the network. BACnet properties include items like identification strings, configuration information, status values and diagnostic status. It is only through an Object’s properties that an Object is monitored and controlled.

Properties are very valuable to BACnet users. They provide information called meta-data. Meta-data defines and explains a data point. For example, you may have a temperature value of 25. Without meta-data, you won’t know if the refrigeration system is properly cold (25 Fahrenheit) or if the building roof is really hot (25 Celsius). Properties (meta-data) help to explain the characteristics of a value, what we call “present value” in BACnet.

Properties can tell you things like the scale, where the sensor is located, what kind of sensor is being used, or what kind of device is doing the measuring. Properties can be either Read only or Read-Write. The BACnet specification details what level of access an external device has to a BACnet property.

Properties are either required or optional. Required properties are properties that must be included in the Object. Network queries to the Object can always find and read those properties in an Object because, be definition, they have to be present. Optional properties are properties that CAN be included in the Object. It’s the choice of the device vendor to include or exclude an optional property.

Three properties, Object-identifier, Object-name, and Object-type are required to be present in every BACnet Object. Every Object must have these three objects plus any other Objects that are required for that Object’s Object-type. The type of Object and the type of device in which that Object resides determine which properties are required.

An Analog Input Object, for example, has the three objects required of every BACnet object, five other …

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 …