SEPTEMBER 2019
Inside: Control system connectivity p4 SCADA & IIoT p10 Edge, fog & cloud p14
Cover image courtesy: Opto 22
Supplement to Periodicals Publication
| AT11-14USA |
A revolution in linear transport systems: XTS NEXTSTEP The XTS advantage circulatory movement flexible modular system individually movable movers
User benefits reduced machine footprint software-based changeovers improved machine flexibility increased throughput shorter time to market
www.beckhoff.us/xts Manufacturers around the world need to offer increasingly customized products – with machines that deliver reduced footprint and improved productivity. Available now in the U.S., the eXtended Transport System (XTS) from Beckhoff answers these machine design challenges and more. In combination with PC- and EtherCAT-based control technology, the XTS features a high level of design freedom for machine builders to develop game-changing concepts for product transport, handling and assembly. A stainless steel hygienic XTS version is ideal for use in the pharmaceutical and food industries. Take your next step in machine design with XTS: total freedom of installation position compact design integrates directly into machinery freely selectable track geometries few mechanical parts and system components
See XTS live! Lower South Hall, Booth 6149
SEPTEMBER 2019
IIoT technologies can be seen as an alternative to the traditional automation triangle comprising control, execution and enterprise levels.
EDITORIAL
3 Welcome to the video age FEATURES
4 Control system connectivity update Digitalization, IIoT and Industry 4.0 implementations need communication hubs, a role well-suited to PLCs and HMIs
4
10 Leverage SCADA data in maintenance workflows Know what you need before investing in IIoT
14 Expert advice given on edge, fog and cloud All three may come into play in a single installation
10
16 Industrial controller cybersecurity best practices Protecting industrial automation systems is easier when controllers offer built-in cybersecurity features
16
Cover image courtesy: Opto 22
www.controleng.com/IIoT
IIoT For Engineers
SEPTEMBER 2019
| 1
PRODUCTIVITY AND BEST PRACTICES: EDITOR’S COLUMN Kevin Parker Senior Contributing Editor
Welcome to the video age
I
world. Other features included audience polling, private chat t was over a good dinner in an Italian restauand participation of a webinar attendee as a presenter. rant in downtown Charleston, S.C., that this editor first found out videos could be in a magazine. What’s called Video in Print has been around since Video in webinar 2008 but is no doubt more commercially viable today Use of screen sharing and video in webinars is growing than when first introduced. fast as platforms advance and users grow more comfortWhat we’re talking about is full-motion video on an LCD able. Both have played a big role in editorial and custom screen that is paper thin, requires no Internet or electricity, webinars lately produced for IIoT for Engineers, or as it is and delivers good resolution and sound quality. sometimes referred to at CFE Media, IIoT4e. Does the technology point the way forward for magaThis September issue of IIoT4e includes a brief readzines? No one would dispute the power of the Internet to out of answers to attendee questions that we didn’t deliver (and deconstruct) information. have time to get to during the quesNevertheless, some say the Internet can’t tion & answer segment of the “edge, deliver the experience of paging through fog and cloud” webinar originally a luxury magazine. Don’t look for it broadcast June 20. The presenter crew What if every page anytime soon, but what if every page in a for that webinar was especially sharp. magazine was video capable? That would The archive version of this webinar in a magazine was be a world fueled by science fiction. and others in the IIoT/Cloud webinar series are available on the Control video capable? Engineering website. The thing about some things Another, more recent webinar in the Sticking to the media side of things, series was “Introduction to machine webinars and podcasts are proving more learning” broadcast August 15th. We’re happy to say popular than ever, despite the relative difficulty for users we had a good size audience for the program because in indexing the information for future use. In 2019, CFE that means we’ll be doing more webinars on the same or Media & Technology, publisher of Control Engineering, similar topics. Plant Engineering and IIoT for Engineers will produce Contributors to and readers of IIoT4e are skeptical more than 80 webinars on industrial technology topics. when they hear the words “artificial intelligence.” MaWikipedia says webinar history began in the 1980s, if you chine learning, on the other hand, though it is sometimes count real-time text messaging apps, including web chats classified as a kind of AI, is really the application of staand instant messaging. In 1995, PictureTel announced the tistical methods, enhanced by computational power and launch of the LiveShare Plus software. The app allowed screen sharing, providing users with remote access to a com- available for use in real-time process control. Returning to the topic of video, on the other hand, puter, as well as file transfer and text messaging. although it’s not the end of the world as we know it, it The first public web conferences became available in does seem a shame that certain habits of thought associMay 1996 due to the efforts of Microsoft, which launched ated with print are being abandoned. It was in the age of NetMeeting. It was an inbuilt component of the web browser Internet Explorer 3.0. NetMeeting allowed users to Texas Instruments calculators that an engineer was heard admiring someone’s ability to quickly add a column of communicate and exchange data in real time. figures on paper. Today, engineers don’t perform calculaThe first webinar software, PlaceWare, became available tions. They evaluate inputs and outputs. Finally, someone the same year. It was developed by Xerox PARC. The app recently mentioned young engineers who struggle to allowed one or several users to make a presentation that interpret 2-D drawings. IIoT could be attended by thousands of visitors from all over the
‘
’
www.controleng.com/IIoT
Industrial Internet of Things
SEPTEMBER 2019
| 3
CONTROL & COMMUNICATIONS
Control system connectivity update Digitalization, IIoT and Industry 4.0 implementations need communication hubs, a role well-suited to PLCs and HMIs
By Don Pham and Linda Htay
M
any industrial plants and facilities are in the midst of executing asset digitalization projects by incorporating industrial Internet of things (IIoT) elements and implementing other Industry 4.0 initiatives. A key enabler for these efforts is connectivity between field devices, such as sensors and instruments, and higher-level computing platforms. Connectivity is usually via company intranets and the Internet. Field devices typically use operations technology (OT) communication protocols and traditional wired signals, while intranets and the Internet use IT protocols. A bridge between OT and IT is therefore required in the form of a communication hub, a role wellsuited to newer programmable logic controllers (PLCs) and human machine interfaces (HMIs). Let’s look at how PLCs and HMIs can be used to make connections from OT field devices to company intranets and the Internet, as well as examples illustrating these types of applications.
Controller connectivity PLCs must connect to a wide variety of field devices and other components to perform traditional control and monitoring tasks. Discrete devices providing inputs to PLCs include limit
4
|
SEPTEMBER 2019
IIoT For Engineers
FIGURE 1: Newer PLCs support a multitude of communication protocols for connecting to plant-floor field devices via OT protocols, and to upper level computing systems via IT protocols. All figures courtesy: IDEC
switches, position switches, photoelectric sensors and other components indicating on-off status. Discrete PLC outputs provide on/off commands to motors, on/off valves and other on/off equipment. Analog devices providing inputs to PLCs include analyzers, instruments, RTDs/thermocouples and other components with varying inputs. Analog PLC outputs drive variable frequency drives, control valves and other equipment operating over a range of speeds or positions, typically scaled as zero to 100%. These traditional discrete and analog connections are common to most every type of PLC application, with digital communication links
added in many instances. Instead of installing a bundle of wires and cables from a variable frequency drive to a PLC, a single digital communication cable can be used to exchange information. A group of drives can often be linked to a PLC via some type of Ethernet-based network, such as Modbus TCP, further reducing required wiring and cabling. Smart instruments and analyzers generate many data points, and for this reason are also commonly linked to a PLC via a network. Less common methods of communication, but critical in some applications, are serial via RS232C/RS485 networks. Many older field devices, such as weigh scales, may only offer this type of digital communication link. Bluetooth and other forms of wireless connectivity are provided by some PLCs for networking to compatible devices. Specialized industries and applications such as building automation often require support for the BACnet/ IP communication protocol, a feature found in many newer PLCs (Figure 1). J1939 is another specialized protocol, typically used for connections to inplant vehicles such as forklifts. PLCs use these methods of communication to gather data for monitoring and control, and this data can also be manipulated and stored. SD memory ports and mini-B USB ports www.controleng.com/IIoT
FIGURE 2: Up to four communication protocols, including leading IT protocols such as Modbus TCP/IP and FTP, can be used simultaneously with high performance HMIs.
are often provided for expanded data storage, and data stored there or in PLC memory can be exchanged with higher level computing platforms via company intranets and the Internet, both typically via Ethernet. A PLC work wells as a communication hub for applications where only a single controller is used to concentrate many field devices, but applications with multiple PLCs and other controllers are often better served by an HMI.
HMI hubs HMIs typically don’t connect directly to field devices, but instead exchange data with these devices via an intermediate PLC or some other type of controller. For applications with a small amount of I/O, an HMI with realtime control capabilities can be used to provide a space-saving all-in-one automation solution. An HMI is often required to communicate with many different controllers simultaneously, requiring support for a multitude of protocols (Figure 2). Some of the most common types of controllers connected to HMIs via digital data links include PLCs, variable frequency drives and weighing systems. Modern HMIs typically provide support for over 100 serial and networkwww.controleng.com/IIoT
FIGURE 3: Forklifts and other industrial vehicles typically used in production plants and facilities often provide support for the J1939 protocol, allowing data exchange with PLCs supporting the same protocol.
ing industrial protocols, such as BACnet/IP, Modbus RTU Master/Slave and Modbus TCP/IP. Users should look for an HMI capable of supporting multiple protocols simultaneously as this allows ongoing data exchange with many sources and systems. Not only can an HMI connect to many different sources of data, it can also provide onboard data storage, as well as additional storage via devices plugged into its USB and SD memory card ports. All this stored data can be formatted for exchange with asset management systems, enterprise resources planning systems and other higherlevel computing platforms. These communications are typically via Ethernet for real-time data exchange. For periodic transfers of accumulated data, file transfer protocol (FTP) functionality enables copying or moving files between local memory, external memory devices or cloud-
based files, databases or data storage platforms. FTP provides a convenient and effective remote file transfer method, and is supported by most upper level computing platforms, as well as by some newer HMIs.
Monitoring mobile assets Many plants and facilities use forklifts, trucks and other industrial vehicles to move personnel, equipment, raw materials and supplies from one location to another (Figure 3). These industrial vehicle assets naturally come with their own automated systems to monitor and control operation. These systems typically provide support for the J1939 protocol, as do some PLCs. In a typical application, a PLC can be added directly to a vehicle and communicate with its vehicles local control systems via the J1939 protocol. In these instances, it’s often helpful to use a combination PLC/HMI unit so the driver can view operational IIoT For Engineers
SEPTEMBER 2019
| 5
CONTROL & COMMUNICATIONS
solution is a substantial improvement as compared to proprietary building management systems, which typically lack flexibility and features. As with other applications, the HMI or PLC can interface subsystems up to higher-level computing platforms, such as a building’s asset management system, usually via an Ethernet connection.
Final words
FIGURE 4: The controllers for filtration, cooling and other packaged systems usually provide support for the BACnet/IP protocol, offering a convenient means for digital communication with HMIs and PLCs.
status details and receive messages. Interlocks and other programming can be added so only certain types of critical information are displayed while the vehicle is in motion, such as a warning to reduce speed, with other information only accessible while the vehicle is stationary. The PLC/HMI unit can be connected to an asset management system for data exchange via either a wired or a wireless link. In another type of application, a vehicle would be manually connected to a PLC via J1939 communications at the end of a shift. This would allow the vehicle to transmit its operational status such as mileage, battery life and other operating parameters to the PLC. The PLC would in turn send this information to an asset management system, usually via an Ethernet link. If wireless communications are added between a vehicle and a PLC, data can be sent via the J1939 protocol while the vehicle is mobile, adding another level of functionality.
6
|
SEPTEMBER 2019
IIoT For Engineers
BACnet for buildings Commercial and industrial buildings and facilities typically contain a large number of packaged units such as HVAC, air purification, water softener, boiler, chiller, cooling and filtration systems (Figure 4). Each of these units usually has its own local control system, with all the units normally connected to a central control and monitoring system. Connections from these units to the central system can be hardwired, but this only provides limited data exchange and requires extensive wiring and cabling. A much better approach is to exchange data digitally using BACnet/IP, a protocol supported by most every building automation packaged unit, and by many HMIs and PLCs. This allows an HMI, a PLC or both to be used for monitoring and control, and for coordination among multiple packaged units. Integrating various systems with this type of
PLCs and HMIs with the right connectivity and communication features are an excellent fit for linking field devices and equipment to higher level computing systems, providing double duty in addition to their regular monitoring and control roles. When used in this fashion, no new communication hardware or software needs to be purchased, installed and integrated, reducing costs and complexity. Don Pham is a senior product marketing manager at IDEC Corp., with more than fifteen years of detailed experience with industrial automation products including PLCs, HMI touchscreens, machine safety and sensors. He is responsible for product positioning and marketing strategies for these products and works with a research and development team to identify and add features that customers and OEMs are looking for. Don is proficient in several industrial programming languages. IIoT Linda Htay is a product marketing specialist at IDEC Corp., responsible for touchscreens and display products. She has experience working with automation and industrial products such as HMIs, PLCs and more. Linda holds a BS degree in electrical engineering from San Jose State University. www.controleng.com/IIoT
MOVE SECURELY INTO THE CLOUD
ITY R U EC
S
WAGO Cloud
Amazon Web Services Other Cloud Services
-IN T L I BU
Microsoft Azure IBM BLUEMIX
Direct Field to Cloud Connection with the PFC Series Controllers • • •
•
IIoT-ready with Sparkplug, native MQTT and TLS encryption Built-in VPN and Firewall for increased network security Run Docker Containers in parallel with PLC logic
Interface with existing controls via onboard fieldbus gateways
www.wago.us/IIoT
Control Engineering IIoT Supp.indd 1
4/25/19 10:40 AM
Committed to providing continuing education to engineering professionals.
Whether enrolled students
Our course catalog is RCEP
After finishing each course,
need a refresher course on a
Accredited, as well as certified
participants will receive a
particular topic or need to know
by the American Institute of
certificate of completion. Each
more about the latest engineering
Architects (AIA) for continuing
course will educate and test
industry issues, CFE Edu offers
education. AIA CES credits
participant knowledge via a
courses that touch on a wide
(learning unit hours) are earned
mix of reading, video clips, and
variety of topics.
for each course upon completion.
interactive elements.
Want to drive your career forward with CFE Edu? View the course catalog at:
cfeEdu.cfemedia.com cfeEDU_house ad_halfHZ.indd 1
4/29/2019 12:58:55 PM
ADVERTISEMENT
The digital process unit Solutions help refiners achieve efficient asset monitoring and effective unit optimization
O
il & gas industry players stay competitive by making incremental improvements to existing assets. For example, high-speed data networks, cloud-based systems, and data-compilation tools today monitor and optimize operating assets. Axens combines these with advanced modeling to improve process safety, operational excellence and costs.
Connect’In™ Direct data transfer link provides secure access, with automatic transfer and direct access to unit data allowing faster, proactive technical assistance for unit engineers. Process unit monitoring requires teams comprised of unit engineers, catalyst supplier technical service engineers, and corporate subject matter experts to optimize unit performance proactively. Within the first three years of client implementation, Connect’In™ has been deployed to more than two dozen units worldwide. Integration of Connect’In™ for multiple units within the same refinery has improved technical support by centralizing client process data and facilitating discussions with unit engineers. A major US refiner implemented Connect’In™ across several refineries in order to perform benchmarking analysis and performance reviews. The Connect’In™ platform uses real-time data calculations and trend comparisons to alert both the unit and Axens engineers of issues as they happen. Predictive models evaluate future catalytic performance and estimate cycle length based on unit operation. Connect’In™ also includes a model-based process heater monitoring tool based on expertise from Axens’ subsidiary, Heurtey-Petrochem.
Fast and secure data transfer Unit monitoring requires filtering and analyzing large quantities of process data. Cloud-based data collection improves current unit monitoring by modifying and sharing process data with those who need it, decreasing time between the initial transfer and analysis.
8
|
SEPTEMBER 2019
IIoT For Engineers
Data visualization The Connect’In™ Dashboard summarizes the entire unit through customizable performance indicators highlighting any immediate product-quality threats. High-priority KPIs are included, allowing drill down into progressively more detailed data. Alerts can be configured to compare current operation with a recommended operating range, reducing reaction time to opportunities for improvement.
Advanced process control As product specifications become increasingly stringent, APC is a low cost and continuously operating solution to maximize profitability. Rigorous model-based inferences control economically or environmentally critical product values. A model internal to the controller provides adjustment vectors for controllers. The economic benefit of using APC is seen in a gasoline desulfurization unit. The client struggled to maintain a product specification of 20 wppm sulfur, often averaging 17 wppm. Over-treatment caused octane loss with high hydrogen and utilities consumption. Axens’ APC solution combined extensive process knowledge, intensive operational expertise, and proprietary models. The refiner saw a tighter average product sulfur of 20 wppm with an improvement in octane retention, hydrogen consumption, utilities consumption, and even catalyst cycle length. Unit profitability increased by five to six million dollars per year.
Final words Axens’ range of customized software solutions combine with proprietary high-fidelity models to improve unit safety and operational excellence. Its digital suite offers complete and cost-effective solutions to any refinery aiming to proactively improve the operation and performances of current assets. Nevin Whalley, David de Gruyl, Matthew Hutchinson Axens North America
OIL REFINING
PETROCHEMICALS
GASES
ALTERNATIVES & RENEWABLES
WATER
POWERING SMARTER WAYS
In a fast changing world shaped by increasing complexity and connectivity, Axens Group, building on the commitment and the diversity of its teams, fosters innovation and collaboration to create added value for its clients.
Catalysts & Adsorbents and Process Licensing activities, including the modular units business.
Furnace business including waste heat recovery units.
Auditing, consulting and digital applications activities.
RELIABILITY IN THE INDUSTRIAL ENTERPRISE
Leverage SCADA data in maintenance workflows Know what you need before investing in IIoT By Michael Watson
S
upervisory control and data acquisition (SCADA) systems are an excellent tool for managing operations and resources. However, many SCADA systems were deployed before condition-based maintenance technologies were available commercially. As a result, maintenance investments and planning were focused on increasing the effectiveness of calendar -based preventive maintenance.
While this has helped teams track costs, it also has resulted in bloated maintenance calendars. As much as 70% of calendar-based efforts may be unnecessary, having no impact on long-term asset performance. Issuing work orders based on asset condition represents the single largest opportunity for maintenance teams to improve operations. Many strategies for transitioning to condition-based maintenance leverage the Industrial Internet of Things (IIoT). However, organizations should first take advantage of existing operations’ data sources before investing in IIoTenabled sensors or software. Capitalizing on the billions of data points already being generated by SCADA and automation systems augments maintenance records front-line workers use daily.
Leverage the trove
To harness the power of IIoT technologies, SCADA data must be merged with information from computerized maintenance management software (CMMS) and enterprise asset management (EAM) solutions. All images courtesy: Fluke Corp.
10
|
SEPTEMBER 2019
IIoT For Engineers
Over the past 20 years, maintenance and operations managers used systems that often didn’t speak to each other, whether clipboardbased data collection, Excel-based repositories, third-party software or some other solution. This stovepiped data could have been leveraged by other teams to decrease maintenance spend. Data from SCADA systems is an untapped gold mine of a facility’s inner workings. The systems gather data that can mirror asset health, including the following:
n n n n n
Cycle counts Gas detection Runtime hours Valve status Electrical readings.
Maintenance and reliability (M&R) teams could save as much as $16,000 per year maintaining a single pump if monthly planned maintenance were swapped out for a condition-based program. Downstream, there may be a flowmeter uploading data to a SCADA system. The pressure readings or runtime hours from the flowmeter can be useful in maintaining the pump. Scheduled routes completely overlook the power of operations automation data. Session-based metrics used by maintenance teams provide asset status “snapshots” rather than continuous conditional data. Other operational information, such as irregular fuel consumption or pressure readings, streamed to SCADA systems, could be used by maintenance teams to determine current asset status and performance. After equipment experiences downtime, retrospective failure mode and effects analysis (FMEA) provides maintenance teams with SCADA information. After-the-fact reporting completely misses the opportunity to optimize maintenance strategies and cut unnecessary costs by integrating automation databases with maintenance data. www.controleng.com/IIoT
This “operations-maintenance gap” shortens equipment lifespan and produces higher operation costs. Bridging the gap allows plant managers to rein in maintenance costs, transforming team efforts into a business engine that drives value back to a company’s bottom line. “A consolidated data platform allows you to see data in one place,” said Stephen Gerrard, vice president, Fluke Digital Systems.“Some solutions only record one kind of data. Decision makers don’t want to put in multiple solutions that they then have to try to coordinate and orchestrate.”
Advanced connectivity software and hardware solutions enable teams to plan maintenance based on asset status, rather than arbitrary calendars. CMMS users can monitor SCADA data streams to detect changes in asset status.
The connectivity bridge To harness the power of IIoT technologies, SCADA data must be merged with information from computerized maintenance management software (CMMS) and enterprise asset management (EAM) solutions. “Consolidating data is a key fundamental requirement, and it’s where a lot of companies struggle,” Gerrard said. “In a recent industry inquiry, the analysts identified consolidated data as being the real barrier to practical IIoT adoption.” Advanced connectivity software and hardware solutions enable teams to plan maintenance based on asset status, rather than arbitrary calendars. CMMS users can monitor SCADA data streams to detect changes in asset status. IIoTintegrated software can trigger work orders within the CMMS when assets exceed user-defined thresholds. “Software should combine operational technology data from systems such as PLCs and SCADA, or other sources familiar to operations departments, with data from enterprise asset management systems maintenance teams typically use,” Gerrard continued. “Before connected soluwww.controleng.com/IIoT
tions came along, there was no way for the maintenance team to view operational data that might help them in decision making.” Highly automated operations, such as aerospace or automotive manufacturing, have cut response time to equipment outages by as much as 70% simply by routing alarms to front-line maintenance professionals. Some even achieved a full return on investment within six months through a combination of cost savings and increased efficiency. In one instance, a major aerospace engine manufacturer caught an emerging fault on a critical motor with IIoT-enabled vibration sensors. This gave them three months to plan an effective replacement and avoid unplanned downtime. As reported by the facilities and maintenance professional at the aerospace company, their IIoT-enhanced condition-based maintenance program saved operations from a critical asset failure.
framework” that unites all industrial data. By connecting people, data and systems, operations and maintenance teams will have the information they require to get the job done at their fingertips and regardless of location. A major pharmaceutical and health products company used connective solutions to schedule preventive maintenance on actual runtime, as recorded by their automation system. The results were astounding. On average, preventive maintenance was reduced by 30% and mean time to repair was reduced by 20% through earlier notification of potential faults. All of this translated to almost a 50% increase in asset availability. The best solutions also connect data to mobile devices – such as mobile phones, tablets and PC/Mac computers – enabling maintenance teams to optimize scheduling and planned downtime. Software also should provide real-time alarms to technicians to ensure urgent problems are rectified quickly.
Success in real time
Where you are now
The future isn’t just about IIoT devices but a “connected reliability
Using asset condition to plan maintenance tasks, rather than an IIoT For Engineers
SEPTEMBER 2019
| 11
RELIABILITY IN THE INDUSTRIAL ENTERPRISE
Using asset condition to plan maintenance tasks, rather than an arbitrary calendar, can improve productivity and save money.
arbitrary calendar, moves teams along the path to predictive maintenance (PdM) and prescriptive maintenance (RxM). However, the road ahead can’t be discerned if it isn’t known where the maintenance program currently stands. Some important questions to ask are:
GEng-CE 2017-06_TRGuide_MediaShowcase2x4_MII.indd5/17/2017 1 2:23:54 PM
n What are current operational workflows? n Which practices are working, and which are not? n Which IIoT solutions will have the biggest impact on operations? One reason IIoT solution implementations fail is that organizations don’t understand where they are along the PdM or RxM path, let alone what to do with all the new data coming from connected devices. Once it’s understood, there is a way forward to connected reliability. Transitioning from siloed systems to a connected reliability program may be a daunting undertaking for industrial organizations. However, you don’t have to implement solutions in the dark or on your own. Maintenance technology companies can help organizations from planning to practice. “Get some advice. There are solutions out there now, ours included,” Gerrard said. “There are companies that provide connected reliability assessments to help you with a road map and to identify the next logical step that will provide the biggest return on investment for the company.”IIoT
Michael Watson CMRP, CRL, is a product application specialist for Fluke Corp.
12
|
SEPTEMBER 2019
IIoT For Engineers
New look. New feel. Same GREAT information.
NEW PRODUCTS FOR ENGINEERS
Search Products And Discover New Innovations In Your Industry The New Products for Engineers Database is a platform that provides an opportunity for engineering and technical professionals to access the latest NEW product information for the manufacturing, commercial construction, and manufacturing control industries.
An enhanced search process allows
users to search by category or keywords and narrow their search by filtering on manufacturer, industry, or release date.
Users can browse CFE Media’s various award programs and vote for their favorite products.
Users can provide comments and rate products to share their product experiences with other users.
Product profiles can easily be printed to PDF within the browser.
Users can choose to subscribe to
product alerts on a category or manufacturer, and will receive an email as matching products are added to the database.
When viewing a product, a user can
view contact information on the manufacturer and request additional information on a product.
www.controleng.com/NP4E
INDUSTRIAL COMPUTING INFRASTRUCTURE
Expert advice given on edge, fog and cloud All three often seen in a single installation
I
n the parlance of industrial automation, “the edge” has emerged as a term of considerable currency. The edge is found where the action is, at or near the industrial process. On June 26, IIoT for Engineers aired a webinar on the evolving nature of Industrial Internet of Things (IIoT) elements and how users are applying the edge, fog and cloud in their Industrial operations. To relieve bandwidth constraints or inherent latencies, and to improve system security and reliability, computational resources – from gateways to multi-purpose devices to computers – are being stationed at the edge. These computational resources located at the edge can filter or process data so that only what’s needed is transmitted between production control or enterprise systems and the cloud. During the webinar, attendees submitted their questions to the speaker/panelists. Some of the most interesting questions, with the panelists’ replies, are found below. Answers were provided by Charles (Chuck) C. Byers, associate CTO, Industrial Internet Consortium (IIC), a CFE Media content partner; Ed Kuzemchak, CTO and director of IoT, Software Design Solutions Inc.; and Steve Hilton, cofounder and president, MachNation. The webinar in its entirety can be viewed on the Control Engineering website.
14
|
SEPTEMBER 2019
IIoT For Engineers
CFE Media: Please discuss some specific differences between edge, fog and cloud. Are edge and fog the same? Charles C. Byers: Edge and fog are very similar technologies. Edge is often a single (or few) layers serving gateway functions for a limited set of IoT applications, while fog tends to be more hierarchal and supports multiple tenants. Fog tends to have slightly stronger security and orchestration. Edge is a more common term in the industry, so the Industrial Internet Consortium (IIC) is migrating to using edge for the superset of edge and fog. Steve Hilton: We generally use the phrase “distributed architecture” to capture the concept that data ingestion and process can happen at different points in the IoT architecture. Ed Kuzemchak: Some practitioners use ‘edge’ to describe the actual sensors and ‘fog’ to denote one layer of processing above that. But that distinction is getting less clear, so I support the IIC’s move to using edge for both. CFE: What are the most important IIoT-related protocols? CB: There are lots. Certainly, IP at the network layer is predominant. At the Transport layer, TCP, UDP, HTTP, CoAP, MQTT and OPC-UA are common. There are also frameworks
like web services, OPC-UA, OneM2M and DDS used to interconnect system components. CFE: Are users actually implementing edge, fog and cloud applications? CB: Yes. There are many working edge systems in multiple vertical markets. Edge computing is already in volume deployment in smart grids, smart cities, intelligent transportation systems, healthcare, manufacturing, consumer and many other applications. SH: In fact, we find it uncommon that an IIoT solution is only cloud or only edge. Most deployments make some use of both edge and cloud. This gives enterprises the benefit of flexible deployments and cost efficiencies. EK: Many legacy industrial control systems had some kind of edge/fog/ cloud architecture even before IoT was named. Classic machine-to-machine (M2M) systems are being recast as IIoT systems to take advantage of the common protocols and interoperability that Chuck mentioned above. CFE: In the IIC architecture, what is the difference between security and privacy? How does that matter to a edge/fog device design? CB: There are differences. Security is often about preventing bad actors from taking unauthorized actions to influence the behavior of an IIoT system. This means unauthorized users must be prevented from seeing www.controleng.com/IIoT
internal states or controlling system configurations. It is highly concerned with making systems as hacker-proof as we can. Privacy is more about the data flowing in networks than the networks themselves. Privacy SW prevents data in motion or data at rest in IIoT systems from being read by unauthorized parties. This is especially important to conform to government privacy regulations like GDPR or HIPAA. SH: For MachNation, security is primarily a technology-related issue. Privacy is an issue that is created by individual, societal, and governmental expectations that can be solved by technology and other factors. EK: The application domain may determine that privacy is not a requirement in their system, but it is unlikely that any system can make the claim that security is not a requirement. CFE: With edge and fog can we reduce our dependence on the cloud in the future? CB: Partially. As more critical compute, networking and storage functions move closer to the edge, we may be less reliant on cloud capacity, performance or reliability to provide them. Certain operations may be much more efficient or cheaper if run at the edge. However, we will never eliminate the role of the cloud from IIoT networks. There will always be a need for a highly scalable, elastic, overarching compute and storage infrastructure to perform the highest level of IIoT tasks. SH: Enterprises should always start the IIoT discussion by determining their business-related goals requirements. From the business goals, an enterprise can determine it’s IIoT architecture and technology requirements. By following this approach, www.controleng.com/IIoT
we ensure that the right technology – whether edge, fog, or cloud – is used to meet the ultimate business goal. EK: It is all in the tradeoff of where the best place to do the processing lies, regarding gathering the necessary data, having the compute power available, and utilizing the results. CFE: Since there is so much software-related complexity in edge and fog, are a lot of homegrown applications being developed by users?
Charles C. Byers
Steve Hilton
that provide the greatest development challenge. Most IIoT solutions are deployed in brownfield environments. As such, most enterprises require some fairly extensive southbound and northbound integrations. EK: At Software Design Solutions, we see a lot of custom applications being built, but using the standard communications protocols, message brokers, and data analytics packages. But bringing them together to solve a specific need often requires a custom design.
CFE: what is the posCB: Yes, end users of sibility of utilizing the edge systems often are sinoatrial node found the best experts on the in the human body systems they are controlthat creates the body’s ling. This gives them the electricity, for tie-in to best perspectives on the the IIoT network? data, control algorithms, CB: As a signal source, and procedures needed Ed Kuzemchak it is already in use. A deto control the system. vice called an Implantable CardiovertHowever, end users may not be as er Defibrillator (ICD) monitors the SA skilled on software development node and other electrical activity in processes, or the edge-cloud infrathe heart (sensing), and can provide structures, so it often makes sense to collaborate with specialized IIoT a pacemaker pulse or a larger shock (actuation) if abnormal rhythms are programming help. detected. Sophisticated ICDs connect SH: In most cases, the ultimate IIoT application is either home-grown or to your cell phone and thence to the Internet for continuous control and developed by a services company for monitoring. the enterprise. While there are IloT platform vendors that supply sample In terms of energy harvesting, the raw energy available from heart IIoT applications, it is fairly uncomelectrical activity is pretty small, and mon that enterprises will use those applications as-is. Keep in mind that I think many safer alternatives exist to harvest energy from within the application development is not necesbody. Systems also can take advansarily the most complex part of IIoT platform implementation. Often it tage of mechanical motions, pressure is the integrations to legacy systems changes and respiration. IIoT IIoT For Engineers
SEPTEMBER 2019
| 15
CYBERSECURITY
Industrial controller cybersecurity best practices Protecting industrial automation systems is easier when controllers offer built-in cybersecurity features
By Benson Hougland
S
ecurity issues impact all types of digital systems. Intrusions or breaches constitute a nuisance at the least but also can compromise data or trigger unauthorized actions. Resulting problems for end users vary depending on their organization
and systems. For industrial automation users, cyberattacks can lead to ruined product, damaged equipment and safety hazards. The potential cost of poor cybersecurity is clear. As industrial operations technology (OT) systems evolve and cyberattackers adapt, security requirements change. Greater integration of OT systems with IT systems and
Internet connectivity create more exposure to cyberattacks. Integrating security provisions into automation system designs – and continued vigilance – are key to defending against these types of threats. As Bruce Schneier, a noted cryptographer and computer security professional, wrote in 2000, “Security is a process, not a product.”
FIGURE 1: Industrial controller security is best implemented with multiple network interfaces that do not route traffic between them, protecting the local trusted network from external untrusted access. All images courtesy: Opto 22
16
|
SEPTEMBER 2019
IIoT For Engineers
www.controleng.com/IIoT
To address security’s complex, changing nature, users must understand security risks, the digital environment and the available security tools. Security experts recognize several elements of system security, including physical security, network security and policies and procedures. The ultimate security of your industrial automation system depends on the user, but let’s look at network security features built into certain automation products, along with best practices for setting up a secure system network.
Security basics Devices and practices for industrial automation have evolved over many decades, resulting in a wide spectrum of available products. Of interest here are applications where designers would typically deploy individual controllers, even if many of those controllers may be used in parallel as peers. Products used in this space are digital controllers capable of being networked via Ethernet and include: n Smart relays n Programmable logic controllers (PLCs) n Programmable automation controllers (PACs) n Industrial personal computers (IPCs) n Edge programmable industrial controllers (EPICs). The first three products are deeply rooted in the origins of industrial automation. Conceived prior to the proliferation of PCs and before cybersecurity even existed, many early generations of these products remain in service today. While the latest iterations are updated with www.controleng.com/IIoT
current computing and networking technology, these products are generally limited to offering a dedicated computing environment tailored for industrial control. In contrast, an IPC is simply a robust version of a PC, which end users can outfit with various control software and communication elements to achieve industrial control. The last product, an EPIC, is a newer generation of industrial controller, packaged like a PLC and offering similar real-time control functionality, but with many PC-like features and IT-friendly communication advantages added. Enabling digital communications for all these products is essential not only for configuration and maintenance, but also for incorporating complementary products like humanmachine interfaces (HMIs) and other intelligent devices. Best practices for proper network security design of industrial controllers requires careful consideration of the following areas: n n n n
FIGURE 2: This example firewall configuration opens only specific ports for OT protocols, and only on the local trusted network (“eth0” in this case), denying all connections from the untrusted network (“eth1”). The groov EPIC controller can be accessed only via ports 80 and 443 (while port 80 is open, any inbound traffic is automatically redirected to port 443, which is secure).
Operating systems Network interfaces User access Data communications.
Operating systems Any industrial controller’s operating system (OS) defines the extent of its computing and input/output (I/O) interfacing abilities. PLCs and PACs typically use dedicated or embedded closed-source OSs tailored to the required fast-acting logic solving. IPCs commonly use closed-source OSs also, most often Microsoft Windows. Another OS option is to use a variant of open-source Linux. Some IPCs use Linux, and many EPICs use Linux to take advantage of PC-like capabilities.
FIGURE 3: Granular control of user accounts and the use of complex passwords for authentication are crucial to effective security, because they help repel intruders. IIoT For Engineers
SEPTEMBER 2019
| 17
CYBERSECURITY
Counterintuitively, open-source OSs are often more secure than closed-source versions. The same worldwide high profile that helps a closed-source OS like Windows gain such market acceptance also makes it the target for cyber-attacks. And while the closed-source embedded OSs used for PLCs are relatively obscure, the emergence of Stuxnet almost a decade ago demonstrated that commercially available industrial control platforms are viable targets for cyberattacks. A benefit of open source is its crowd-sourced nature. The large number of developers involved – far more than a traditional closed-source industrial controller manufacturer can employ – allows quick reaction to address vulnerabilities. When open-source OSs are used for industrial applications, they should be custom-built for a specific
device and include only the packages the device requires. This streamlining reduces the ways it can be attacked, also known as reducing the attack vectors or the attack surface. In addition, the purpose-built OS for an industrial controller should be cryptographically signed by the manufacturer. Only vendor-approved OS builds should be accepted by the controller, guaranteeing the build’s origin and precluding unauthorized OS code alteration.
Network interfaces Modern industrial controllers rely heavily on commercial Ethernet, although many specialized industrial fieldbuses remain in use. Ethernet for industrial controllers is provided by physically wired network interfaces. Wi-Fi devices may also provide connectivity. For any networking, it is impor-
FIGURE 4: Some controllers can be configured by OT personnel to establish a secure VPN tunnel, shown here with orange highlighting, for remote connectivity. This is useful on a temporary basis for troubleshooting, or regularly for normal operation.
18
|
SEPTEMBER 2019
IIoT For Engineers
tant to understand the concept of a trusted network as opposed to an untrusted network. A trusted network is usually within a private facility and may be an IT-managed network, where all users with access are known. An untrusted network is any network where those who can access it are unknown, like the Internet. A router is a network device configurable to route traffic between any two networks. Many people are familiar with routers for home use, with these devices handling traffic between the Internet network and devices on the home network. These routers move data between these two networks. Industrial applications, on the other hand, call for controllers with multiple independent network interfaces, so that trusted and untrusted networks can be kept separate. One network interface can be assigned to the local trusted network, and another to the external untrusted network. These interfaces must be non-routable, so that no external attacker can connect to the trusted network from the untrusted network (Figure 1). Another crucial networking concept is a firewall, which provides security by preventing unsolicited traffic from accessing the network, device or host. Typically, local deviceoriginated outbound connections are considered trustworthy and therefore allowed, as are the associated inbound responses. However, other inbound connection attempts from outside are rejected, although the firewall may be configured for certain specific ports to be opened and allow inbound traffic. An industrial controller should have its own firewall and provide the means to configure it. For industrial www.controleng.com/IIoT
FIGURE 5: Outbound, device-originated protocols like MQTT allow controllers to initiate data communication connections securely through a firewall, providing better security by not requiring any inbound ports be opened.
FIGURE 6: Best practice is for controllers to support industry-standard security certificates, just like banking and e-commerce
applications, the trusted network interface will need the ports associated with control logic, I/O connections or other industrial protocols opened. But the untrusted network interface should typically have all ports blocked except for a secure port allowing authenticated users to access the controller over an encrypted connection. Best practice is to open only the ports specifically needed and to block all other ports, and for the untrusted network interface to block all ports by default (Figure 2). Proper network configuration is essential, and it goes hand-in-hand with carefully assigning user access and privileges.
User access A key feature of modern digital computing – whether used on mobile devices, PCs or industrial controllers – is the concept of user accounts with assigned access and www.controleng.com/IIoT
privileges. Typically, an administrator account must be created initially; it has global privileges. This account must be carefully protected by the owner. An industrial controller should not offer a default username or password on any account, but instead should require that the administrator select unique credentials upon account creation. Default credentials can be easily obtained and used by anyone, whereas a unique administrator account better protects the controller from nefarious actors. If administrator credentials are lost, the account should not be recoverable, and instead would require a reset of the controller to factory defaults. The administrator account is used to create user accounts. For an industrial controller, authorized users may be people, but they may also be software services.
sites.
Best practices are to create accounts only for the necessary users, grant them only the essential privileges, assign strong passwords and always require authentication for system use. Careful user account management gives the administrator complete and granular control of who and what can access the system, and therefore of who and what cannot (Figure 3). A common requirement is for offsite users to connect with a controller via the Internet. A secure port that encrypts all data communications and allows only authenticated users to connect can meet this requirement. Another way is with a separate device on the network capable of creating a secure virtual private network (VPN) tunnel to outside clients or servers. However, setting up a VPN IIoT For Engineers
SEPTEMBER 2019
| 19
CYBERSECURITY
can require extensive involvement and coordination with IT personnel. A better option is to select a controller with built-in secure VPN tunnel capabilities, giving OT personnel complete control of VPN connections to securely match their needs (Figure 4). Whether using onboard controller features or site networking devices, best practice for remote connections via any form of untrusted network is to always use a properly configured secure VPN tunnel and to disable it when not needed.
Data communications The whole point of equipping controllers with network interfaces is to provide data communication connections. However, the main thrust of this article has been how to prevent connections, at least from unauthorized entities. Communications on the trusted side of a controller are relatively simple, and as discussed, inbound connections over an untrusted network should go through a VPN or be blocked. So how do you communicate data if a VPN is difficult to set up? For example, how does an OEM get data needed from machines at customer sites for billing or maintenance? The answer is to use outbound, device-originated data communication protocols. One such protocol is MQTT, which uses a publish/subscribe model (Figure 5). As pointed out above, outbound connections are generally allowed through a firewall because they are trusted. The controller is configured to publish data of interest to an external central broker using an outbound connection. Remote users connect and subscribe to the central broker in a similar manner. Because the connection
20
|
SEPTEMBER 2019
IIoT For Engineers
originates from a trusted source, it is allowed through the firewall, and responses are allowed in return, safely permitting two-way data flow. All connections are authenticated and encrypted. Another key feature to look for in an industrial controller is built-in security certificate management. A security certificate basically verifies a machine’s identity to another machine, so an originating machine can be sure it is connecting to the proper destination machine and not an imposter. Certificates can be implemented in various ways and can be generated by the end user or registered through a certificate authority (Figure 6). Industrial controllers should use industrystandard certificate practices, similar to banking and e-commerce sites. Even with these security provisions in place, there are other best practices to consider.
Other best practices So far, we have looked at configuration and best practices for system design. However, there also are procedural best practices for improving security. n Minimum interfaces: The most cyber-secure system is air-gapped and has no interfaces. This isn’t usually practical, but it may be possible if the controller offers an onboard interface. In any case, always remove unnecessary network connections and block unused ports. n Minimum access: Assign users the lowest possible privileges consistent with what they need to see and do, and require them to log out when inactive – especially administrators. This advice extends to all control system elements, including
HMIs, which should be run in readonly kiosk mode whenever possible. n Development versus production: Restrictions are sometimes relaxed for testing and prototyping. Make sure the controller is completely protected after testing and before being placed into production. Some Linux-based controllers allow users to take advantage of secure shell access (SSH) for developing custom applications. Once development is complete, make sure shell access is disabled.
A secure approach The best practices outlined in this article are a solid starting point for embarking on any new industrial automation project, or for revisiting one already in service. Good security must be carefully implemented at many levels and is most effective when security provisions are built into automation products, not bolted on. Built-in security features help you implement security quickly with minimal expense. Every situation is different, and you are most familiar with your applications and network architectures. Built-in network security features for industrial controllers can help you design and maintain a secure system, but ultimately you are responsible for using them wisely in your application and as part of your overall security strategy. IIoT Benson Hougland has 30 years of experience in IT and industrial automation and drives strategy for Opto 22 products that connect the real world to computer networks. He speaks at trade shows and conferences, including IBM Think, ARC Forum and ISA. His 2014 TEDx Talk introduces nontechnical people to the IoT. www.controleng.com/IIoT
IIoT devices run longer on Tadiran batteries.
PROVEN
40 YEAR OPERATING
LIFE
Remote wireless devices connected to the Industrial Internet of Things (IIoT) run on Tadiran bobbin-type LiSOCl2 batteries. Our batteries offer a winning combination: a patented hybrid layer capacitor (HLC) that delivers the high pulses required for two-way wireless communications; the widest temperature range of all; and the lowest self-discharge rate (0.7% per year), enabling our cells to last up to 4 times longer than the competition.
ANNUAL SELF-DISCHARGE TADIRAN
COMPETITORS
0.7%
Up to 3%
Looking to have your remote wireless device complete a 40-year marathon? Then team up with Tadiran batteries that last a lifetime.
* Tadiran LiSOCL2 batteries feature the lowest annual self-discharge rate of any competitive battery, less than 1% per year, enabling these batteries to operate over 40 years depending on device operating usage. However, this is not an expressed or implied warranty, as each application differs in terms of annual energy consumption and/or operating environment.
Tadiran Batteries 2001 Marcus Ave. Suite 125E Lake Success, NY 11042 1-800-537-1368 516-621-4980 www.tadiranbat.com
*