What does the Internet of Things mean to people who make things?
We’ve heard a lot about the Internet of Things (IoT), centering on big business and big data. But what kinds of "things" do we want to do in manufacturing automation?
And what does it take to implement IoT? What about the standards, vision, connectivity, integration, and processes necessary to meet the specific requirements of IoT in industrial automation? Answering the first question will provide reasons to invest in the second question.
Whether you call it Industrie 4.0 or IoT, in manufacturing, it’s really all about connecting machines-to each other, to expert systems, to management execution systems-to get more actionable information using intelligent devices at lower levels of the system architecture (push-buttons, servo drive auto-compensation, energy monitors, vision cameras, accelerometers, and E-stop buttons) than ever before (see Figure 1).
IoT: Things to do
IoT is much more than extending industrial networks to the device level architecture. It’s even more than distributing safety, motion, machine-to-machine intelligence, automated maintenance resources, and enterprise connectivity to heretofore inaccessible manufacturing intelligence. From resource management to intelligent machine devices to predictive maintenance, IoT offers plenty of things to do to make manufacturing automation even more robust.
Secure remote connectivity
IoT promises connectivity for diagnostics, recipe management, collaborative engineering, and all kinds of data acquisition, from OEE to serialization. IoT will provide access to data we can’t get now because we haven’t deployed the sensors to get it and IT hasn’t allowed it.
Yet, in large part, the sensors exist today. They just haven’t been cost justified before. Therefore, they aren’t in RFQs yet. A common rationale has been, "Why spend an extra $100 on a smart sensor that is going to get hit by a fork truck?"
The big security breakthrough in 2014 has been the growth of secure virtual private network (VPN) servers and cloud services to address IT’s concerns. The trend in 2015 will be to seamlessly integrate the secure server into the control software suite.
Perhaps the biggest shift in mind-set for industrial automation users is moving from hardwired safety PLCs and relays to networked safety. It just plain scares people to move from tightening down copper wires with a screwdriver to consulting a software display. Yet, we get on fly-by-wire airliners without a second thought. We take driverless shuttle trains to the airport terminal. We don’t think about it because we can’t see it, but even the car we drive to the terminal depends on networked devices, such as anti-lock brakes, airbags, and cruise control.
Networked safety holds perhaps the greatest potential for improving productivity, along with functionality that prevents workers from attempting to circumvent safety systems. Networked safety has many advantages, including installed cost, testing, and diagnostic capabilities.
The concept is simple. Keep control and line power on while ensuring that operating speeds, torques, directions, and positions can cause no harm. Implementation is in keeping with traditional safety implementations, comparing the primary control system status with a checksum on an independent controller.
But instead of E-stops dropping out all power, networked safety calls for continued operation in safe mode. Safe-mode operation is intended to prevent an operator from being tempted to defeat a door interlock to clear a jam, or to operate with machine guarding removed to save steps. Instead, nip rolls can’t turn in an unsafe direction. A robot arm can’t push hard enough, fast enough, or far enough to put a maintenance worker at risk.
Where does IoT come in? Safety is networked over deterministic industrial Ethernet, and every state change, every instance of operation in safe mode, is logged and can be transferred to management via the Internet. The interlock or light curtain can communicate the nature of the breach, time, and interval to help management analyze root cause.
Of the networked safety functions, safe motion is the most powerful. Using intelligence and software embedded into servo/inverter drives with hardware, such as safety encoders, it is possible for networked safety to maintain operation of production lines, printing presses, robots, and more in safe mode. This intelligence provides not just the now-familiar safe torque off information, but safe limited torque, safe limited speed, safe position, safe limited acceleration, and much more.
Now, the machines on a line can continue to run in safe mode when in the past an E-stop or a controlled shutdown would be initiated to clear a jam, make a repair, or replenish materials. The productivity potential is enormous.
Speaking of E-stops, the E-stop button no longer needs to be hardwired. Yes, E-stop buttons are now available on the Ethernet network and integral to the control panel. Enough said.
Key to predictive maintenance is monitoring based on actual machine conditions, not just cycles or hours. And key to monitoring machine conditions are mechanical disturbances. Use of networked sensors, such as accelerometers, can detect frequencies of bearings, shafts, couplings, and other mechanical devices indicating a trend toward failure that can be interpreted and analyzed to schedule preemptive maintenance (see Figure 2).
The more critical the process, the better the cost justification. But the failure of even a simple device can have a catastrophic result in a process.
Frequency analysis can also lead to identification of root cause before a device is damaged beyond recognition. If conditions such as lubrication, spalling, or corrosion can be documented, preventive maintenance measures can be taken.
Think energy monitoring-and not just electrical power but water, steam, compressed air and vacuum, natural gas, temperature-and you will recognize the immense potential for improving sustainability.
Bring these monitoring activities into individual machines and down to process units-not just branch circuits or incoming power meters-and the data become much more actionable. Why does one shrink tunnel or one shift use more energy than another? What is the optimum line speed to balance energy costs with throughput?
Pushing more intelligence down to the device level isn’t just about communicating in the IoT. It’s about inherently improving performance while removing the need for human intervention. Leading-edge servo drives are a good example.
Autocompensation within the drive lets it respond to anomalies, predictively smoothing out disturbances without a technician fine-tuning the drive. No need to bring up the oscilloscope function; no need to plug in a laptop.
The same holds true for replacing an older component with one that has a newer firmware version. In the past, this has required manually resetting the new component, which often required software loaded on a PC. Now it’s automatic, requiring no intervention on the part of the user.
Onboard intelligence and Ethernet communications between a controller and device today means that the controller can query the new component and automatically downgrade its firmware to the version in use.
This means no need for a technician, no maintenance software, no need to upgrade a software license, no faults showing up, and importantly, no preconfigured spares gathering dust on a shelf.
Intelligent I/O slices
Another example of pushing intelligence down to the device level is having I/O slices with onboard field programmable gate arrays that allow a direct response between devices and the I/O slice, bypassing the backplane, the PLC CPU, and the system scan time. The result is a response time as short as 1 microsec.
Does this unheard-of speed serve a practical purpose? Think of firing a glue gun on a case packer more accurately, high speed registration mark sensing, or shrinking the distance between sensor and reject station on a flow wrapper.
The I/O slices are programmed in the IEC 61131-3 languages, in the same project as the rest of the machine. They just execute down at the slice level.
It’s not uncommon to see machine mounted, integrated motor/drives today, communicating over Ethernet and providing onboard I/O. This concept has been extended to machine mounted, distributed, sealed drives operating conventional motors to meet higher torque and speed requirements (see Figure 3). Meanwhile, small drives, such as steppers used for format changes, are taking the form of IP67-rated distributed I/O blocks.
Even the lowly push-button is now a network node. Instead of old-fashioned, hardwired, dedicated push-buttons, push-buttons now plug into the same industrial Ethernet cable as the I/O. They are multifunctional and programmable, with multicolored LEDs indicating their modes and removable legends making them easy to customize. And they are available with E-stop buttons and IP65 sealing.
Typical applications include conveyor modules, where long runs of wire get expensive and complicated.
This kind of onboard intelligence, combined with inexpensive solid-state memory, leads to another big cost saver that can make machines more efficient. The benefits of using animation and video to walk operators and technicians through work instructions are well documented.
Why not tie those animations into the fault codes in the control system, and walk the operator through first-echelon troubleshooting? Using virtual network computing (VNC) and Wi-Fi, the animations can run on the operator’s smartphone or tablet and they can walk around the whole line if necessary, connected to their interactive troubleshooting aid (see Figure 4).
This is known as autonomous maintenance. It means that a maintenance technician may not be required to bring the machine back on line because less experienced operators can handle problems on their own, and that language and literacy barriers can be overcome.
Of course, if the problem cannot be resolved, the controller will text the maintenance tech on call, advise him or her of what’s been done already, and even identify a faulty part and submit a purchase order for a new one. And the fault will also be documented and communicated back to management, the machine builder, and the component supplier.
– See additional information on Industrie 4.0 and industrial IoT as well IoT standards on the next page.
Industrie 4.0 vs. industrial IoT: Take a unified approach
I recall a trusted German colleague telling me a few years ago that Industrie 4.0 would be a big deal. I scoffed, to be honest, at the obviously promotional messaging. My initial reaction to IoT was the same.
After all, we’ve had the ability to put smart photoelectric sensors on conveyors for decades. Nobody wanted to pay $100 extra for them. But, when the conveyor jammed up, it was okay to waste time walking the line, using human eyeballs to determine the cause of the stoppage.
Today, that smart sensor allows you to pinpoint the problem from the line controller, from the state model on any HMI on the line (PackML, a.k.a. ISA TR88.00.02 helps here, too). Your tech brings the replacement part with him or her, and readjusts or changes out the sensor in a matter of minutes.
It’s the same scenario for Industrie 4.0 and industrial IoT. The difference is mind-set.
Germany has a deserved reputation for engineering, applied technology, and advanced machinery. It’s the basis of the country’s export economy, its economic engine that is trying to drag the rest of the EU out of persistent recession, and a lot of national pride. So it’s understandable that Germany would seize on the potential of IoT and focus on industrial applications.
In Germany, and throughout Europe, technologists tend to sell technology to other technologists. That is, as opposed to the U.S., where technologists need to convince financial managers focused on quarterly results that increased investment in technology is required to keep competitive and generate organic growth. I believe this is why IoT proponents in the U.S. tend to emphasize big data instead of the connected machine. They are selling IT solutions to chief financial officers.
Does this mean that 4.0 has a better chance of actually happening in factory automation than industrial IoT? I’ve become convinced that European industry collectively believes in the vision of the connected machine. So perhaps machine builders and technology providers that also believe should target the European market first.
In Europe, call it 4.0, and when the technology becomes established, next approach the overseas subsidiaries of your European customers. There, call the technology whatever they call it in those markets. Don’t let your organization be caught up in the debate between 4.0 and industrial IoT-they’re the same "thing"-an Ethernet/Internet-based strategy for connecting machinery to deliver more effective operations than previously possible.
Let’s make sure they use the same standards.
Standards for industrial IoT
The following paragraphs explain the standards necessary for the success of IoT, and why.
Ethernet to Internet
Fundamental to IoT is the continuity of TCP/IP, HTTP, FTP, and other universally accepted Internet communications standards across Ethernet-based industrial networks to intranets and the Internet. Today, even a low-cost controller is expected to provide a Web server and one or more Ethernet connections.
ISA/IEC-62443 (ISA 99) provides a comprehensive overview of cybersecurity measures for industrial control systems. This is a complex topic requiring subject matter experts. Suffice to say that just as IT has security standards, so does automation.
Secure VPN servers and hosted cloud services are now widely available. Emerging now are secure services catering to the specific needs of industrial automation. Secure VPN capabilities are also being built into automation software suites. Large users and integrators with extensive IT resources can apply their own solutions across these interfaces. Machine builders and users can source software-as-a-service solutions without investing in additional IT infrastructure.
Services are available from third parties, control suppliers themselves, and machine builders and integrators. Secure services include turnkey remote data acquisition, monitoring, data storage, reporting, and diagnostics.
The bottom line is simple: Security concerns—exemplified from Stuxnet to Sony—are real, but the countermeasures are out there.
Virtual network computing epitomizes the IoT. VNC is an open-source sharing system that allows remote access to an IoT-enabled controller without the vendor’s software suite. No licenses and no dedicated communications software or hardware are required. All you need is the controller’s IP address.
Open networked safety
Without standards, IoT will fail. IoT can’t tolerate closed systems because it’s about connecting everything. And contrary to popular belief, networked safety does have an international standard. The openSAFETY protocol stack is an implementation of the openSAFETY specification according to IEC 61784-3-13 and is licensed free of charge.
Also, openSAFETY has been tested and proven to run on the application layers of the major industrial networks: Profinet, EtherNet/IP, Modbus TCP, SERCOS III, EtherCAT, and POWERLINK. However, it will be up to control users to specify openSAFETY from their suppliers.
Proprietary safety protocols (those limited to the networks for which they were originally designed) don’t support IoT because they limit connectivity. They may also effectively limit third-party access to develop master rather than only slave interfaces. To be open, safety must allow any automation supplier to develop compliant controllers and devices.
Better known as OMAC PackML, this standard describes a state model, modes, and tag naming conventions originally intended to communicate with packaging lines typically comprising machinery from many different suppliers using different control platforms.
Developed by the Organization for Machine Automation and Control (OMAC), PackML has been demonstrated to pertain equally well to any discrete control scheme. OMAC has specifically taken this standard through the ISA (International Society of Automation) review process to become an ISA Technical Report, ISA TR88.00.02. OMAC next will initiate the International Electrotechnical Commission (IEC) review process.
TR88 is a key standard for machine programming, as well as machine-to-machine and management data acquisition.
OPC UA (IEC 62541) stands for OPC Unified Architecture, developed by the OPC Foundation to replace the original OPC (OLE for process control, OLE standing for object linking and embedding, a Microsoft-centric interface based on COM).
OPC UA is based on Web services and is platform independent. Cooperation is underway between PLCopen (representing IEC 61131-3) and OPC Foundation to map OPC UA to the popular control programing standard. It is anticipated that the OMAC initiative, ISA TR88.00.02 (PackML) will follow.
This is both a game changer and a necessity for industrial IoT practitioners. Compared with the proprietary data acquisition tools provided by the PLC suppliers and limited to their products, OPC UA is a true international standard. OPC communications fit the need for data handling between Ethernet and the Internet, and between factory and management systems.
John Kowal is director of business development at B&R Industrial Automation Corp., Roswell, Ga.
B&R Industrial Automation is a CSIA member as of 2/26/2015
– See other articles from the supplement below.