Posts

Data Sharing Needed for Sustainable Energy

/by

Sustainable energy can be profitable. That, in a nutshell, is the finding of a GreenBiz Research survey presented in the 2019 Corporate Energy & Sustainability Progress Report from Schneider Electric. And an important key to those profits is sharing data.

“Companies agree that sharing data is important, with those that share the most seeing significant benefit,” the report said. This importance of data sharing stands out in the context of the overall report findings, which are broken up into 5 main topics:

  • Funding: Executives that demonstrate ROI (return on investment) and provide strong leadership can overcome perceived obstacles, such as insufficient capital.
  • Data: The challenge is to ensure the quality of collected data, and to share it effectively.
  • Goals: Setting public targets or goals for energy conservation and sustainability drives motivation and success.
  • Energy: Strategic sourcing optimizes usage, yielding significant cost savings in a volatile energy landscape.
  • Technology: Energy efficiency and renewables, based on data-driven technologies, are a leading source of ROI.

Ultimately, for a sustainable energy project to succeed, it must provide a solid return on investment. This report affirms the experience of our customers in wind and solar that the better the quality of their data, and the more they are able to share it, the higher their ROI.

For example, a wind farm doesn’t operate in isolation. In addition to the electrical power it sends to the grid, each wind turbine also sends data for its rotor speed, operating state, power output, and more out to control engineers and automated systems to optimize performance. This data can also be integrated with other data arriving in real time. Weather and climate conditions can be introduced, along with real-time market pricing, to generate live, real-time cost/benefit analyses.

Seeking ways to share data

Sharing data like this takes both cooperation and technology. The various players involved have to agree on what to share and how. Reviewing last year’s survey, the report noted that “respondents indicated that 80% of their companies had energy and sustainability data collection projects underway.” And this year “the research finds that more companies are now seeking the most efficient ways to share the data that has been collected.”

We are pleased to see this growing level of awareness of the need for data sharing. At the same time, we actively encourage executives, managers and engineers who are looking for more efficiency in their data sharing practices to consider our approach. It could be just what they need to boost the ROI of their sustainable energy projects.

Turning IIoT Data into Value: The 5D Architecture

/by

What’s in it for me? Sure, the Industrial IoT is getting a lot of press—it’s been riding high on the Gartner Hype Cycle for years. But now that most people have beheld the vision and survived the deluge of glowing predictions, they are starting to ask some down-to-earth questions. In particular, engineers who have to assemble the pieces and managers who need to justify the costs are asking, “What are we going to get out of it?”

The benefit of the IoT, according to Finbar Gallagher, CEO and Founder of Fraysen Systems, is its ability to turn data into value. To explain how that happens, Gallagher has boiled down every IoT implementation into a common “5D architecture.” In his article, The 5D Architecture – A Standard Architecture for IoT, he says, “IoT systems are complex, very large scale and present many pitfalls for the system architect. Thinking about these systems in terms of the problem to be solved: turning data into value…”

The article breaks down the process of turning data into value through the interaction of five core elements, the 5D of the architecture, which can be summarized as follows:

  1. Data collection
  2. Detecting events based on changes in the data, and analysis
  3. Dispatching (decide and plan) an action based on events
  4. Delivering the action
  5. Developing value, which underlies and unites all of the above

Surrounding, connecting, and acting upon these 5D core elements are four services:

  1. Communication
  2. Presenting information
  3. Storing data and information
  4. Managing the 5 core elements.

Although these services are sometimes considered to be core elements, Gallagher separates them, because he says they do not in themselves create value. Each of these services relies on a person to extract value from them. Ultimately, value is not intrinsic to the data, analysis, plans, or actions either, but rather depends on human interaction to derive it. To make his point, Gallagher quotes a production manager who once said to him, “So if I don’t look at the charts this system presents, the system doesn’t deliver any value, does it?”

Be that as it may, people still need an IIoT system to access their data for extracting value.  And the better it functions, the more value they get. A good IIoT service will provide optimal data collection, event detection, dispatching, and delivery of action through secure and rapid communication, accurate presentation, and fully-integrated storage of data and information. Gallagher suggests some specific criteria, such as:

  • The ability to collect data from a wide range of sources, including legacy PLCs, log files, historians, and devices that may use different protocols.
  • Low latency data communication through direct, real-time connections whenever possible, avoiding high-latency approaches such as having a sender write data to files and requiring the receiver to read them.
  • Consistent event detection: repeatable and verifiable.
  • The ability to provide feedback (with or without human input) so that the system supports the ability to learn and modify action plans.
  • Data communication should be easy to use, resilient, and able to preserve structure. To these we would also add secure by design.
  • Data storage should be flexible, fully integrated, and minimal latency.

Anyone familiar with Skkynet’s approach to Industrial IoT will see that it meets the criteria that Gallagher proposes. On our own, we can’t turn data into value. That depends on you, the user. But we can provide you with easy, quick, and secure access to your data, so that you can make the most of it.

Industrial IoT that Works

/by
Data Communication for Industrial IoT – Conclusion

The Industrial IoT holds a lot of promise for improving productivity and cutting costs for industrial systems.  Yet the IIoT is different from both the consumer IoT and traditional SCADA systems.  In particular, data communications have unique requirements that you need to keep in mind if you are planning to implement an IIoT project that works well.

Re-Thinking Assumptions

Because industrial data communication was developed independently of the Internet, the merging of these two technologies requires a re-thinking of some basic assumptions.  The most secure and reliable approach is to focus on the data, and to allow access to the data only.  Accessing a device means that the device is open to an attack.  Accessing the network leaves the network exposed, even if you use a VPN.  A more secure-by-design approach allows the data source and the data user to make outbound connections to a public or private cloud service that holds only the data.  This keeps all plant firewall ports closed, and provides a secure spot independent of the plant where the data can be accessed by authorized users.

Data Protocol Problems

A number of data communications protocols have been proposed for the IIoT, each with its advantages and drawbacks.  UDP works for VOIP and streaming media, but it lacks the accuracy and completeness so necessary for good industrial communication.  MQTT offers a publish/subscribe mechanism and many-to-many connectivity, but lacks a standard data protocol and the ability to handle messages intelligently.  OPC UA is a good choice for in-plant connectivity, but suffers from the traditional server/client design that requires an open firewall port to connect from the Internet.  REST over HTTP is popular for general IoT applications, but has issues with bandwidth, latency, scalability, symmetry, and robustness when faced with the high speed and large number of connection requirements of the IIoT.  To implement security Blockchain may sound good in theory, but a closer look shows why it will fail in practice.

A New Approach

Clearly, a new approach specifically designed for IIoT is needed.  This approach should use the robust foundation of TCP, the security of a publish/subscribe model like MQTT, and the in-plant connectivity of OPC UA.  Its bandwidth use, latency, and scalability should far exceed RESTful HTML.  This new approach should support edge processing, and in fact, provide the means for edge processing, cloud processing, and fog processing, as dictated by the circumstances on the ground or in the field.  It should be available as a public cloud, a private cloud, or a hybrid combination of public and private clouds.

Something That Actually Works

Most important, this approach should actually work.  You should be able to install it in greenfield or brownfield projects.  It should connect to existing systems, use open protocols, and provide secure, robust, real-time performance at speeds not much slower than Internet propagation speeds.  And it should be available today, right now.  If you’re interested, give us a call.

Go back to Table of Contents

Is OPC UA the Answer for IIoT?

/by
Part 9 of Data Communication for Industrial IoT

OPC Unified Architecture (UA) is the latest standard from the OPC Foundation. Its purpose is to unify the OPC Classic standards of Data Access (DA), Alarms and Events (A&E), and Historical Data Access (HDA) into a single, extensible framework. At the same time OPC UA offers improved networking support, a more sophisticated security model, platform independence, and comprehensive information modeling.

The OPC UA spec allows for implementation across a wide range of hardware platforms and operating systems. The different UA implementations that are possible within this extensible and flexible framework all share a common core UA functionality and interoperability.

The UA standard has been expanded to include or interface with a large number of industrial data models, and it has been chosen as a communication layer standard for Industrie 4.0.  There is considerable conversation about UA serving as a data communications protocol for the Industrial IoT.

As we see it, OPC UA does its job very well.  It works well to provide secure connectivity between clients and servers on an industrial network.

An open firewall port

However, following the traditional industrial client-server architecture OPC UA cannot ensure the complete isolation of the plant network when connecting to the IIoT.  To access data from a UA server, an OPC client outside the plant network needs an open firewall port.  As we explained previously, this exposes the plant network to attack.

Developers are aware of this limitation in OPC UA, which is why we are now seeing a rise in UA-to-Something gateway software.  The most common seems to be OPC UA to MQTT.  The idea is excellent in principle – use UA for in-plant communication and an IIoT protocol for communication to the cloud.  In practise, be careful which IIoT protocol you choose.  I cover the most popular ones in other posts.

Unless OPC UA gets an upgrade to a pure push technology (where the server makes an outbound connection to the client), it does not seem practical to use UA for the cloud segment of the data path.  OPC UA is going to own the industrial plant, but IIoT needs something else.

Continue reading, or go back to Table of Contents

Access the Data, Not the Network

/by
Part 4 of Data Communication for Industrial IoT

The idea of a client/server relationship where the server is the source of information is ingrained strongly into the typical software available today.  As a system design that is very difficult to eliminate.  Some companies try to make this into a “secure” mechanism by trying to add a layer of security on top of the client/server connection.  That layer of security is generally a VPN or (in rare cases) a point-to-point tunnel like SSH tunneling.  Since a VPN is typically the answer, it deserves a little more examination.

The purpose of a VPN is to create a virtual IP subnet that is shared only by computers that are authorized to join that subnet.  Packets transmitted on the subnet are automatically encrypted, even if neither the sender nor receiver is consciously using encryption.  That definitely makes it harder for an outsider to intercept communication among members of the VPN.

Inside the security perimeter

The big concern with a VPN is that once a computer or device is a member of the VPN, it is effectively like being on a local area network containing all other members of the VPN.  If a computer is inside the VPN it is inside the trusted perimeter.  This exposes the other VPN members to attack from within, even if they are safe from attack from without.  This is similar to what happened in a big box store in 2013, where attackers gained access to the LAN by breaching a third-party company who had “secure” access to the store’s internal network.  The larger the number of computers on a VPN, the more points of entry through the secure perimeter you have.

In the Internet of Things, security concerns have been pushing away from VPNs for a while.  A blog posting at Microsoft from 2013 takes a look at VPNs and the issues surrounding them.  If you haven’t seen it, it’s worth a read.

When we are talking about collections of devices, plant control systems or data acquisition systems on a larger network a VPN might seem like a compelling solution, but it inevitably exposes your network to attack, either due to a compromise in a VPN member, a compromise in the VPN server or simple theft of network credentials.  Once you have any of those, every machine on the VPN becomes a sitting duck.

There is no valid reason why you should provide external access to the whole network any more than you should provide external access to an embedded device.  In exactly the same way that you protect your devices by having them transmit data outbound to a middleman you can protect any data source, like an industrial control system, using the same mechanism.  You can have remote access to your data without exposing your internal network.

In the world of IIoT you should aim to access your data, not the network.

Continue reading, or go back to Table of Contents

Access the Data, Not the Device

/by
Part 3 of Data Communication for Industrial IoT

Front and center to data communication for the IIoT is the idea that IoT devices never stop talking.  They are always connected to the Internet, and always accessible.  The accepted wisdom is that for IoT devices to be accessible they must be data “servers”—always listening for somebody to contact them to request information or perform an action.  If we cannot reach the device remotely, how can we access the data it contains?  However, this presents a security problem. If the device is always listening and reachable from the Internet, it is exposing an “attack surface”—a point of contact that a hacker can try to use to compromise the device.

Client-server architecture

This thinking comes from an entrenched understanding that a client-server architecture is the right model for information sharing.  It’s the basis of the World-Wide Web, after all, and we have all seen how successful that is.  Web browsers (clients) talk to web servers.  The web servers contain the information and the clients consume it.  The analogy with IoT devices is perfect.  IoT devices contain information, and smart phones, web browsers and other IoT devices consume it.  The device is the server, right?  But, if the device is always listening for client connections then it is therefore exposing an entry point for attacks from the Internet.  The big issue, in this world view, is that device makers must do a really good job of network security.  Every device manufacturer, whether making a car or a toaster, must employ highly-specialized and rare experts in network security to ensure that hackers don’t imprint images of Elvis in your breakfast or shut off your car engine on the highway.  Alright, hackers didn’t do the toast.  But they did hack the car.

A Fundamental Misunderstanding of the Problem

Frankly, the device-as-server world view is insane.  Why would you ever need to put a web server in a car and then expose it to the cellular network?  Why must the car be listening for any connection at all, ever?   Why must IoT devices be listeners?  Why must they expose an attack surface to the Internet?  The answer lies in a fundamental misunderstanding of the problem.  You want to access the data that the device contains.  You don’t want the world to have access to it.  Just you.  So, you don’t need the device to listen for you (and the world) to contact it.  You can tell the device where to send the information and pick it up from there, so you never need to talk to the device directly.  Effectively, the device transmits its information to a middleman, and when you want to know what your device is up to, visit the middleman to find out.

Then the question becomes – who is this middleman?  That is the role of a cloud service.  It’s a secure point of contact between you and your device.  Yes, it listens for communication from both you and the device.  Yes, it exposes an attack surface to the Internet.  But it relieves that responsibility from both you and the device.  There are far fewer IoT cloud services (tens or hundreds of them) than there are devices (billions of them), thus reducing the number of rare experts we need to achieve decent security.

Using a middleman like this does not mean that you will have to put up with slow communication, or that you will be unable to control your device.  It just means that there is an extra hop in the communication chain between you and your device, eliminating the need for the device to be directly visible on the Internet.  Questions of speed and bi-directionality are answered by the design of the cloud service.

Continue reading, or go back to Table of Contents