Flash back to just over a decade ago when the fieldbus wars raged between vendors, inflicting casualties on early adopters and leaving automation engineers unsure of where to make their technology investments. Apprehension toward new technology became the industry norm.
Then the Internet happened—and it changed everything through Ethernet and TCP/IP.
The Internet created the concept of easily and quickly sharing data and resources through open standards and technology—connecting people, businesses and customers like never before. It rolled out faster than almost any industry could keep up with. Almost overnight, companies that didn’t invest in the rising web economy found themselves at an increasing competitive disadvantage, or even out of business.
Flash forward to today and the industrial automation industry is faced with another technological advancement that is changing everything: the Industrial Internet of Things (IIoT).
OT/IT technology convergenceAdding Ethernet and TCP/IP to industrial assets was a huge leap forward in system interoperability. Ethernet and TCP/IP made configuration, connectivity, deployment and support of automation applications much easier. They also created the opportunity to share data from plant, factory or field networks with IT systems like databases and enterprise resource planning (ERP) and manufacturing execution system (MES) software.
However, moving data from OT systems into IT systems can be difficult, requiring complex middleware and lengthy, expensive integration work. These hurdles can also cause asset support and lifecycle management potholes down the road. That’s why it’s time for the industry to move further up the technology stack and enable OT/IT convergence at the software level.
REST APIs are poised to streamline that convergence and unlock the vast data our existing automation assets can provide. So what are REST APIs and how do they work?
First, the APIAn API (application programming interface) documents how to interact with a software program. For example, the API shows how to format a request to obtain a given response. APIs have been around since computer programming began. But they got a lot more interesting around 2000, when they started emerging on the web.
An example of a web API is the Google Maps API. When a business displays a map of its location on its webpage, often the webpage code uses the Google Maps API to structure a request to Google Maps to generate the map. When correctly requested according to the API, Google Maps renders the map and sends it back for display on the company’s website.
An API mashup is a technique by which a website or web application uses data, presentation or functionality from two or more APIs to create a new resource. Developers use API mashups to rapidly stitch together new web applications. For example, suppose a developer wanted to put together a mobile app for delivery drivers to find the quickest route between locations given the current traffic conditions. The developer might mash up the Google Maps API with a database API to check delivery addresses and a traffic API to generate the fastest route to each destination. APIs mean using less code to create new applications in a much shorter amount of time.
Now, the RESTToday, there are more than 15,000 APIs to all kinds of applications. Yahoo Finance, Weather Underground, and even Big Data and predictive maintenance applications like IBM’s Watson, GE’s Predix and PTC’s ThingWorx all have APIs. New APIs are released every day. Lightweight mobile apps use APIs to cloud applications to put data-center-level computing power in your pocket.
Some vendors sell their APIs and provide support, spawning the API economy, a marketplace where developers purchase other developers’ APIs to generate a new application that they then sell. To ensure these APIs work with one another, they are designed using a common architecture called REST (Representational State Transfer). The REST architecture defines a set of constraints—like routines, protocols and tools—that API developers build their APIs against to ensure that it communicates and works with other APIs.
REST minimizes the coupling between client and server components in a distributed networking application—for example, the IIoT. The IIoT requires a common application architecture to support the many different types of devices and applications that will be connecting to each other to exchange data and share resources. REST APIs are that common architecture. They provide a standard toolset for developers to rapidly build new IIoT applications.
So how do these REST APIs work? They operate like the client/server architecture of websites. A client like a web browser makes an HTTP/S request to a website for a webpage on an HTTP/S server. Then the server responds with the correct data payload and formatting information to display the webpage correctly.
But what do architectural styles of web applications have to do with moving data in and out of industrial automation assets? Simple. Using a REST API with a programmable automation controller (PAC), for example, means that all of the tag values in the PAC can be made available to other applications in the same way—as resources accessible through HTTP/S hyperlink addresses to the PAC’s RESTful web server.
In an IIoT scenario, a predictive maintenance application (a client) could open a secure HTTPS connection to a PAC (the server) on the factory floor, requesting motor runtime data. Because of a well-documented REST API, the client knows exactly how to connect to the PAC, obtain a list of available data resources, and read and write the values of those resources. The PAC’s HTTPS server would respond back to the predictive maintenance application with the motor’s run time in JSON (JavaScript Object Notation) data format. JSON is important in IIoT system architecture because it uses a lightweight, key-value pair data interchange format that almost any software language can consume.
Another example involves using REST APIs directly within database applications. Microsoft’s SQL Server 2016 has built-in support for storing, managing and parsing JSON data. By using Transact SQL, developers can directly query PACs through the REST API and parse the resulting JSON into database tables—no middleware, OPC, ODBC or other software application required.
Why REST APIs for IIoT?Traditional industrial system architecture is built around a bus topology. Assets are connected to the bus and speak the same protocol. The problem with leveraging this architecture in IIoT applications is that systems that are not a part of the bus and do not understand the bus protocol cannot leverage the data and resources available on the bus.
But for the IIoT to be viable, IIoT hardware and software assets must connect and start talking to each other. REST APIs offer a standard form of sharing data and resources between IIoT devices and IIoT software. Ethernet and TCP/IP were the first step toward the IIoT. REST APIs are the next step in moving up the OT/IT technology convergence stack.
REST APIs are the tools that allow OT and IT engineers to connect real-world physical assets like sensors, motors, pumps, relays and control systems to the digital world and communicate directly to the cloud—no middleware, protocol conversion, or edge gateways required. REST APIs are used all across the Internet today. They’re the technology that stitches the IIoT together.