These IIoT tools can help put the EaaS model to work in your machinery quickly and affordably.
With the impact of recent economic upsets still playing out, many equipment manufacturers may be feeling pressure to transform the way they do business. Equipment-as-a-service (EaaS) is an alternative business model that may help OEMs and machine builders adapt in a time when customers are eager to reduce capital expenditure.
EaaS involves renting out or providing access to equipment and collecting payment periodically, rather than selling the equipment outright. This payment model enables end-users to pay for costly or infrequently used equipment as an ongoing operating expense, which can open new markets for you as a machine builder. When you become a service provider as well as a manufacturer, your company also has the potential to capture more revenue by taking responsibility for additional services, like integrating, maintaining, and even operating equipment. As your internal efficiencies improve, this relationship can actually reduce operating expenses for your end-users.
Common pricing models for EaaS include time- or usage-based methods and operational or financial outcome-based methods. What matters most, however, is that you and your customers agree on how to appropriately assess, measure, and report the value delivered by your equipment. This is one of the biggest obstacles for vendors seeking to adopt this business model.
Therefore, regardless of which pricing model is used for a given application, the ability to remotely monitor equipment may be necessary in order to make pricing details transparent for both you and your customer. For instance, it may be difficult to manually track and report the hours of operation of a large installed base or to count the number of work cycles completed by a robot in order to produce an accurate invoice.
Along with remote data acquisition for billing, OEMs already using this model find that acquiring and analyzing the performance data of installed equipment can be an important new asset. That data can be shared with end-users as an additional service, or you can use it to design and operate machinery more efficiently.
While there are many considerations, and even precautions, related to transitioning into this way of doing business, thanks to growing interest in the industrial internet of things (IIoT), the technology needed to make it possible is readily available. Combined with appropriate network infrastructure, these technologies can connect remote equipment with back-end systems from anywhere in the world.
Here are three examples of IIoT technologies that can quickly make your equipment EaaS-ready.
The foundation of an EaaS implementation is secure edge data processing and connectivity. It’s becoming easier to create this foundation, because sensors and other smart remote devices are becoming more capable. Rather than requiring layers of supporting middleware, like PLCs, PCs, or SCADA/OPC servers, the latest industrial edge devices include the processing, communications, and security capabilities needed to be first-class participants in a distributed system.
In addition to intelligent signal processing and control logic, these devices typically provide multiple media interfaces (serial, Ethernet, WiFi, cellular, and so on) and support IT communication standards like DNS, DHCP, HTTP/HTTPS, REST APIs, SSL/TLS encryption, and VPN. And unlike consumer IoT devices, industrial edge devices are designed to rigorous standards for operating temperature, electrical safety, and hazardous environments.
This combination of features makes it easy to add secure remote connectivity to a piece of equipment, independent of customer infrastructure. With a variety of options available, it’s possible to quickly retrofit existing equipment using edge I/O or to completely redesign equipment around edge connectivity using an edge controller.
The first case will generally be preferable for vendors seeking an affordable way to experiment with EaaS, since I/O signals can be connected to an edge I/O module in parallel with the existing control system and without modifying control logic. Some edge I/O can be powered over Ethernet or provide flexible I/O options to further simplify installation.
Edge controllers include more powerful processors, expandable I/O, and more programming and communication options than edge I/O systems. Taking this approach means migrating control logic to a new platform but can be a good choice when designers are planning to leverage other edge processing capabilities, like local database management or multi-protocol device integration. For new machine designs, edge controllers provide more flexibility for future development than PLCs with less maintenance overhead than PCs.
Industrial edge computing addresses critical physical-layer requirements in a tidy package, providing the foundation for application-layer connectivity.
A common obstacle to industrial connectivity is the need to integrate data from many types and brands of devices communicating via different OT or IT protocols. This obstacle has given rise to IoT platforms designed specifically to interface with, transform, and integrate data from disparate sources. These platforms are the glue for large-scale IIoT systems and can provide the framework for EaaS applications as well.
Many proprietary IoT platforms are available, but thanks to IBM’s Emerging Technology Services Group, there is also an open-source option, running on Node.js, called Node-RED. It has taken the IT world by storm with over 2 million downloads since 2013 and is growing in popularity for industrial applications as well.
Node-RED boasts a library of more than 2,500 nodes that you can combine into visual data flows to create programs that extract, transform, and load IoT data (Figure 2). Functions range from serial device communication to data visualization to database transaction management. A partial list of supported databases includes InfluxDB, MySQL, MSSQL, Cloudant/CouchDB, MongoDB, Firebase, and Oracle DB. And since Node-RED is an open platform, you can also leverage Node.js libraries to create custom nodes if needed.
The complete Node-RED package includes a runtime engine and browser-based development environment but is still light enough to run on an embedded processor. Running on top of an edge device that provides a secure interface to the digital world, Node-RED lets you send machine data anywhere it needs to go.
By itself, Node-RED is capable of sending machine data directly into remote or cloud-hosted databases, but this can become costly if an application requires frequent communication over a metered cellular connection. Cost may also become an issue as networks of connected equipment grow. Of the many communication protocols available, MQTT (formerly MQ Telemetry Transport) may be the most beneficial for addressing this issue because of its lightweight, highly efficient format.
MQTT was originally designed by IBM and Arcom Control Systems (now Cirrus Link Solutions) to address cost and stability issues in distributed TCP/IP SCADA networks for Phillips ‘66. They abandoned the traditional poll-response communication model in favor of a brokered publish-subscribe model in which a central server (the broker) manages data delivery for the entire network (Figure 3). MQTT-enabled field devices and gateways publish data to the broker when they detect a change in a monitored value, rather than responding to cyclic update requests. The broker then routes published data to any registered subscribers, which can be back-end software applications or even other field devices (think: Twitter for machines).
Combined with its streamlined payload—as small as two bytes—the communications model used by MQTT results in an 80-90% reduction in overall bandwidth consumption compared to traditional poll-response communications. This efficiency allows MQTT networks to scale up to millions of connections.
The architecture also has important implications for data integrity and security. Since the MQTT server cannot store or modify data, only distribute it, each publisher is the single source of truth for its data, reducing the potential for discrepancies and data “siloing.” Additionally, MQTT connections are device-originating (outgoing), so that only the broker is required to have open firewall ports. Field equipment can be completely locked down while still permitting bi-directional communication. The broker alone manages user authentication, data access rights, and message delivery, simplifying network management and allowing each client to remain anonymous to other network members. In combination with TLS encryption and certificates of trust to authenticate the identity of connected endpoints, secure site-to-site MQTT communication is feasible even over public networks.
MQTT was also designed with a very simple specification, resulting in a lightweight implementation that can run on constrained field devices. Node-RED supports MQTT communications natively, and there are several open-source implementations available through the Eclipse Paho project. Several popular and robust MQTT server implementations are available as well, both in commercial and free, open-source varieties.
Making the switch
Experts caution manufacturers who are considering an equipment-as-a-service model to prepare their organization for a significant transition. Determining the appropriate pricing model is crucial, and your customer service group should expect to become ongoing partners with end-users, rather than merely offering after-sales support. A gradual transition may be the best option, steadily increasing the number of customers with service agreements and decreasing the number of capex sales.
Fortunately, open-source technology options like Node-RED and MQTT support this kind of experimentation. As a designer, you don’t have to commit to costly up-front licensing agreements in order to develop the communications infrastructure you need to support the new business model. Both technologies are easy to get started with as well, and a proof of concept can probably be built in a couple of days.
Times of economic turbulence can be fertile ground for innovation. Could this be the right time for you to try something new?