19 minute read
PERSPECTIVES
Industrial Sensors Boost Vineyard Data
By David Greenfield
Editor-in-Chief/Director of Content
When most people think of vineyards, thoughts of a lazy, sunny afternoon enjoying select wines tend to come to mind. For the owner and operators, however, the vineyard is but the fi rst step in the production of their beverage. That’s why increasing amounts of industrial automation technology are being applied to wine-producing operations.
Bouchaine Vineyards is one of the latest examples of a vineyard adopting industrial automation technology with its implementation of Cisco Industrial Asset Vision sensors to track data throughout its 100+ acres in the Carneros AVA (American Viticultural Area), which includes parts of Sonoma and Napa counties in California.
Chris Kajani, Bouchaine winemaker and general manager, said, “For hundreds of years, much of grape growing has been based on anecdotal knowledge shared between generations of winegrowers, along with visual cues taken by walking the vineyards. Now this knowledge, which is so central to the traditions of great wines, can be digitized. This automatic accumulation of data with real time dashboards will give us insight across the lifetime of the vineyard. Cisco sensor technology allows us to gather data in real time, bringing us the ability to make site-specifi c grape growing decisions year after year based on our vineyard’s microclimates.”
More specifi cally, Cisco sensors are used to collect temperature, light, humidity, wind, and water over the course of the growing season. According to Cisco, the sensors are advanced enough to track details such as the amount of light hitting individual grapevines within each block, o ering key insights into the tannin development of the grapes. This kind of information enables Bouchaine to refi ne decisions on irrigation, leafi ng, and fruit thinning.
Throughout the 2021 growing season, Bouchaine monitored temperature, light, and humidity of individual vineyard blocks in more detail than they ever had before using Cisco’s sensor technologies.
“The Cisco sensors are helping us preserve one of our most precious resources—water,” Kajani said. “We’re using the data to water only when and where it’s absolutely necessary. The sensor data gives us peace of mind that we’ll see changes in the vineyard when there’s still time to take action.”
Cisco Industrial Asset Vision is an all-in-one product that includes di erent kinds of industrial sensors (for example, temperature, light, humidity), gateways that collect data from the sensors (which come from Cisco with batteries included), and a cloud-based dashboard on which to view the resulting data.
The ruggedized sensors and gateways that comprise Cisco Industrial Asset Vision are designed to withstand temperature swings, rain, and wind. According to Cisco, the gateways can connect sensors spread over a large area, reducing the number of gateways a user will need to buy and maintain.
Speaking to Cisco Industrial Asset Vision’s ease of installation, Kajani said, “Installing the sensors and gateways was as simple as scanning their bar codes. The whole solution was up and running within an hour.”
Based on results gathered during the 2021 growing season, Bouchaine is planning to install more sensors to understand the environment in smaller sections of the vineyard.
A Cisco Industrial Asset Vision sensor in the fi eld at Bouchaine Vineyards.
To watch a video report on this story, visit awgo.to/1290.
Securing MQTT Messages
By David Greenfield
Editor-in-Chief/Director of Content
Akey aspect of MQTT’s (message queueing telemetry transport) architecture involves the use of an intermediary server to collect data, as it changes, from the devices it is connected to. It then publishes those data points to other systems or applications that subscribe to those specific data feeds collected by the server. Because the subscribing systems or applications do not directly connect to the device they are monitoring, some levels of security are inherently supplied by the MQTT messaging structure.
Like any security measure, however, this decoupling of devices and the systems that subscribe to them does not address every potential cybersecurity angle. Beyond the direct disconnect o ered by the server, MQTT infrastructures support several options that use widely adopted internet security methods, such as those used in online banking and recommended by NIST (National Institute of Standards and Technology).
MQTT infrastructure
To understand MQTT’s various security measures, it helps to fi rst understand the building blocks of MQTT’s IIoT (Industrial Internet of Things) infrastructure: • MQTT edge clients – These are remotely distributed devices and/or gateways in the plant or fi eld connected to your process to gather data. • MQTT enterprise clients – This can be any centralized or remote application that needs to subscribe to an MQTT server to receive or send information in the IIoT infrastructure. • MQTT server(s) – These are centralized servers that the edge and enterprise client applications connect with to send and receive data.
Arlen Nipper, president and chief technology o cer at Cirrus Link and co-creator of MQTT, explains that both the MQTT edge and enterprise clients use the same security models. “Each initiate an outbound connection over the TCP/IP network utilizing transport layer security (TLS) with security certifi cate credentials from a certifi cate authority (CA),” he said.
TLS uses a set of public/private security certifi cates where the MQTT clients must establish a connection to the MQTT server that is authenticated by the CA. This is the same level of security used in banking systems today and is considered best practice by NIST.
The network architecture of MQTT topologies requires that MQTT edge clients have all inbound TCP ports over the network disabled, explained Nipper. “This provides a high level of security by preventing potential attackers on the internet/intranet from simply establishing a connection with the edge devices.”
While this confi guration provides solid security, Nipper notes that it can create challenges for accessing the edge client for remote debugging and confi guration. “These challenges can be overcome using a reverse VPN connection,” he said.
Server security
The confi guration of the TLS used with the edge device is also used with the MQTT servers. “MQTT servers utilize further security measures in the form of MQTT level username, password, and an access control list (ACL),” said Nipper. “The ACL limits which devices will be allowed to connect into the MQTT server. The ACL also controls what topics a given username/password pair can publish and subscribe to, providing further security.”
Nipper added that the MQTT servers should be setup in a DMZ and behind a fi rewall that only allows two inbound ports for connection: 8883 and 443.
As the MQTT servers provide the message delivery mechanism in the enterprise services bus, Nipper noted that the MQTT servers “must be 3.1.1 OASIS-compliant.” Cirrus Link supplies an MQTT Distributor and Chariot MQTT Server for this purpose. The company also supplies the Chariot MQTT Server for multiple MQTT server redundancies and a higher number of connected clients for onpremises or cloud-connected applications.
Protection overview
To reiterate the security recommendations made above, Nipper suggests applying the following security measures at the transport
and application levels: • Physical network/VPN for ultimate security; • TLS with certifi cate credentials from CA for all connections; • All inbound ports should be disabled at
MQTT edge clients; • Only two TCP/IP ports (8883 and 443) should be open at the MQTT server; • Use MQTT client username/password at
MQTT servers; and • ACLs should be used to limit MQTT client access to the topic levels they can either publish or subscribe to.
Security layers
Nipper pointed out that network security can be divided into three layers—each of which provide a di erent level of security against cyber-attacks: • The physical layer provides the highest level of security where the network is isolated from any outside connection or is completely encapsulated in a virtual private network (VPN). • The transport layer uses transport layer security (TLS) with security certifi cate credentials from a certifi cate authority (CA) to secure infrastructures that use public networks, where setting up discrete VPNs to each end device is not practical or cost e ective. Firewalls can also be used at the transport layer to close all TCP/IP ports on the remote devices, and only the minimum ports necessary for operation at the central location should be allowed. • The third layer is application security where, within Cirrus Link MQTT Servers, username/password authentication is applied with access control lists (ACL).
“The combination of these layers ensure a robust secure IIoT network,” said Nipper.
XX Ultrasonic Sensors with NEW easy-to-use software. Ideal for level detection & control, mobile equipment, material handling and hoisting applications.
This illustration depicts MQTT edge client connectivity. Source: Cirrus Link
WOW! That was “Simply easy!”
This engineer just set up several ultrasonic sensors for a new machine line. Despite the varying ranges he had to set, he used a single software application. He set the distances. He adjusted gain. He filtered out anomalies. And those settings will remain for future replacement sensors.
Programmable... ...Flexible... ...and SMART!
Pat rom P to Autonom
By David Greenfield
Editor-in-Chief/Director of Content
Looking back through the history of automation, it’s not di cult to see how most advances are extensions of existing technologies. This can be seen at all levels of automation—from the evolution of relays into programmable logic controllers to the enterprise, where the all-encompassing ERP (enterprise resources planning) systems were developed from expansions of material requirements planning (MRP) software over the course of several years.
When you look at autonomous systems, however, the advance can seem so vast that it’s not always as easy to see the origin point in traditional manufacturing systems. This gap can make end users wary of autonomous technologies; but when you trace the development path of autonomous systems, it can make these new technologies less intimidating.
Connecting the dots
At Rockwell Automation Fair 2021, Jordan Reynolds, global director of data science at Kalypso (a Rockwell Automation company), gave a presentation on autonomous systems that helped explain how these advanced neural systems, as they’re applied in industry, can be seen as extensions of the PID (proportional-integral-derivative) closed-loop control systems with which we’re all familiar.
Illustrating the evolution from PID control to autonomous systems, Reynolds explained that the first step is to start with a physical system—an entire plant or a production line— and create a model or digital twin of this system that shows how that system responds to changes to inputs or operational parameters, as well as disturbances.
This model, which sets the stage for autonomy, is created via hybrid modeling. Reynolds said hybrid modeling is developed through two processes: first, there is input from an engineer followed by input from a data scientist who understands AI (artificial intelligence).
“There’s a delta between what an engineer knows and what a data scientist does to derive a model that can learn rather than being programmed,” said Reynolds. He stressed that, to develop an e ective model for autonomous operations, you need the engineer to define basic principles and have the data scientist close out the gaps to ensure the model performs to standards. “This is hybrid modeling,” he said.
Autonomic control
Rockwell Automation is focusing on this area because it views autonomy problems as control problems.
“Feedforward control was one of fi rst predictive applications of control,” said Reynolds. “It expands on feedback control and provides early indications of a state that is yet to come so that it can be addressed proactively. Model predictive control (MPC) is a modern version of feedback control, where you use multivariable models to characterize how a system performs. We use those models to control a system better than we could with PID.”
Reynolds noted that Rockwell Automation acquired Pavilion Technologies in 2007 for its MPC technology.
“MPC is good with highly predictive systems that don’t change that much,” said Reynolds. “But it falls short when recipes or parameters change. The MPC must be updated because it does not adapt on its own. That’s where adaptive control comes in. In adaptive control, the model doesn’t have to be perfect because it can adjust to changes.”
Reinforcement Learning is a newer concept that expands on adaptive control and is an emerging method of AI that has developed along with the abilities provided by cloud computing resources and greater connectivity among plant fl oor systems.
Explaining the connections between PID and autonomous operations with Reinforcement Learning, Reynolds said PID is used to ensure the system complies to the setpoints, whereas MPC determines the setpoints based on the multiple inputs and outputs of the system. Going further, Reinforcement Learning creates an executive function that can strategize.
Reynolds provided a car racing example to help illustrate this concept. MPC keeps the car in the lane, he said, while Reinforcement Learning helps you strategize about how to win the race, e.g., when to change tires, when to take the inside lane, etc.
Deep learning neural networks, like those used in Reinforcement Learning, is where most innovation has come from as industry advances toward greater use of autonomous systems. The problem is that, even though neural networks are highly accurate, they’re not very transparent or explainable. “An engineer can’t easily get an answer as to why decisions are made by the neural network,” Reynolds said.
That’s why Rockwell Automation focuses on deep symbolic regressions to explain how an AI control model works. Reynolds said Rockwell Automation uses this in its FactoryTalk Analytics LogixAI. According to Rockwell Automation, FactoryTalk Analytics LogixAI applies analytics within the controller application to achieve process improvement. It is an add-on module for ControlLogix controllers that streams controller data over the backplane to build predictive models.
Digital Twin Controller (Optimization) PV – process value SP – setpoint CV – controlled variable MV – manipulated variable DV – disturbance variable
Lab Results
Securing Distributed Control Systems
By David Greenfield
Editor-in-Chief/Director of Content
Distributed control systems (DCSs) are commonplace in continuous processing, particularly in the oil and gas and chemical industries where they’re used to control several machines or processes at the same time. This di ers from PLCs (programmable logic controllers), as a PLC is typically used to control just one machine.
This di erence in how DCSs are used to manage multiple machines and processes ups the ante in terms of the impact a security breach of a DCS can have. With this type of vulnerability in mind, Tim Mirth, PlantPAx platform leader at Rockwell Automation, says plant decision-makers exploring DCS-related cybersecurity improvements should be aware of these common DCS cybersecurity challenges:
Open systems. “Open protocol networks are a historical hallmark of distributed control systems and are usually considered a huge benefi t,” said Mirth. “But the additional avenues of risk associated with online, connected control systems may leave producers more vulnerable. The Zone and Conduit model can help mitigate the threat and keep critical assets segmented from most vulnerable areas. Managed fi rewalls are another important part of protecting open systems.
Legacy equipment. Older machines, especially if they have not been updated in many years, are potential entry points for viruses, worms, and hackers. “This is where a risk assessment can expose a vulnerability and develop a strategy to strengthen them,” Mirth said. “In larger plants you may not even know there is still an obsolete operating system on your network.” Mirth noted that if replacement of a legacy device is not possible, some protection can be gained with network segmentation to build in layers of defense.
Evolving workforce. “The people who have access to your plant and systems are an important piece of the overall cybersecurity puzzle,” said Mirth. “Breaches can be caused by innocent mistakes as well as those with nefarious intentions.” To address this, Mirth said to ask yourself: Do you know who manages user accounts and system access for your company? Also, are there any accounts that have remained active and unused for years? Adhering to international standards, such as the ANSI/ISA-62443-3-3 standard, and managing your users as part of a cybersecurity strategy can help mitigate this risk, Mirth added.
Unknown ROI. Too often, companies view cybersecurity as an expense with an unidentifi able ROI (return on investment). Mirth said that, with cybersecurity or any risk mitigation initiative, “it’s less about how much money the company will make and more about what you don’t want to lose. With a proper risk assessment, vulnerabilities, risks, and mitigation strategies can be evaluated and allow producers to answer questions such as: What risk are we willing to accept? What will it cost to make the changes needed to feel comfortable in our risk posture?” Mirth said it may not be as expensive as you think to make changes, and the opportunity cost for not protecting your systems is too great to pass up implementing even some simple measures.
Finally, Mirth pointed out that it is necessary for industrial companies to realize that having an evolving plan will be needed to properly secure your DCS. That’s why it’s important to recognize the criticality of the cybersecurity challenges he cited and to “select a plan that keeps enhanced overall security, fl exibility, and digital transformation in mind and won’t trap you from making the progress you need to run your business.”
This illustration highlights the control connection di erences between a PLC-controlled system (left) and a DCS-controlled system (right). Source: RealPars
If you’re involved in any kind of Internet of Things (IoT), Industry 4.0, or advanced manufacturing initiative in general, a key task will involve extracting data from older equipment. Given that large numbers of automated equipment and devices across industry pre-date any sort of broad, network-centered data aggregation or standardization e orts, this task is not as straightforward as it might seem.
To better understand how manufacturers can more e ectively go about extracting data from older equipment in a meaningful way, we connected with Luke Stephenson, business manager at Enterprise Automation, a control systems integrator, for a recent episode of the “Automation World Gets Your Questions Answered” podcast series (www.awgo.to/1283).
“Everybody knows businesses that use, collect, and observe data in real time are more agile and more e ective when it comes achieving their objectives,” said Stephenson.
But before you head out to collect all the data you can from your equipment, Stephenson said there are many important questions to ask; the first of which should be: What would those equipment data, if they were available to you in real time, enable you to do?
Stephenson said this question is so important because the way in which data is stored, accessed, and gathered can “really change what you're able to do with it.”
O ering an example to show why answering this question is so important to determining your data aggregation approach, Stephenson said: “If you have a factory floor with one hundred machines on it, you don't go after [the data from] all one hundred machines right out of the gate.” He said you should start with one machine to learn which data collection methods work best for you so that you can then scale that approach.
However, if your company is aware of how it could use a particular range or data set from di erent equipment if they could just get that data into a repository, then have that target serve as a baseline from which to determine the best data extraction methods for your equipment and use that to scale up from.
Essentially, the determining point here is whether you know what data you need and for what purpose(s). If you’re uncertain, start with one machine.
Making Legacy Equipment Connections Work
By David Greenfield
Editor-in-Chief/Director of Content
Data format and communication di culties
Explaining why older equipment can be more di cult to extract data from, Stephenson pointed to devices that communicate using “serial communication protocols and protocols that are often considered proprietary. Once you start getting into Ethernet-based communication or even just two-wire or fourwire communication, there are a lot more ways to pick that information up.”
Most legacy devices are not going to have a built-in ability to transmit on sort of modern IoT type of communication protocols or be able to communicate with those types of platforms directly, Stephenson said; so you have to install a translator between the legacy device and the edge-of-network device used to collect the data.
“You want to translate the data from the legacy protocol into a more modern version, such as MQTT, so that you can then use it in di erent ways,” he said.
Stephenson also cautioned users to pay attention to the format used for extracted data. Formats such as JSON (JavaScript Object Notation) will typically be more viable with IoT platforms than files in .csv or .xml formats.
MQTT and the cloud
“MQTT (message queueing telemetry transport) is going to be the most common and most supported data messaging service out there,” said Stephenson.
Essentially, when a system is built for data collection—whether it’s for use with older or more recent equipment—it's most likely going to include the use of edge devices to get equipment data into a format that can be used for di erent purposes and by di erent systems.
“A publish and subscribe message broker, like those used for MQTT, are scalable and built for the future,” said Stephenson. “I can't think of one IoT device that's not capable of communicating via MQTT. And all software systems, whether they’re SCADA (supervisory control and data acquisition), CMMS (computerized maintenance management system), or ERP (enterprise resources planning), can connect to MQTT message brokers. They’re super-e cient, fairly easy to set up, and very scalable. And they’re e ective whether you’re connecting multiple devices in a plant or multiple plants across the country.”
He also stressed the importance of aggregating the data you collect in the cloud.
“This is where the rubber hits the road. Collecting data is all well and good, but making use of the data is really why you invest the time and energy to do it. And today, the cloud is a safe way to do this—even though people sometimes shudder at the term ‘the cloud,’” said Stephenson.
He explained that the cloud is integral to data collection and analysis because once your data is in the cloud or other data repository, there are a host of services and software that can help you with it—whether that's for data visualization through something like Microsoft’s Power BI or Tableau or for specific applications like predictive maintenance.
“These tools go beyond what humans can do in terms of drawing insightful conclusions. It’s also a good way to make the data available to those with credentialed access wherever they may be located. We want to be able to get our data when we need it; and putting it in the cloud does that the best,” Stephenson said.
