These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is defining not just their APIs, but their schema, and other moving parts of their API operations.28 Sep 2016
I am spending a portion of my time each week learning about how APIs are being applied at the industrial level. An example of this can be found over at Opto 22, with their approach to using REST across their Programmable Automation Controllers (PAC). As I do with other industries I spend my time looking through the approaches of API pioneers in the space, which leads me to other contributing factors to why web APIs are being used to change how things are done in any industry.
For now, my industrial API research is a pretty big umbrella, encompassing oil & gas, manufacturing, and often moving into other areas I'm already tracking agriculture and energy. This approach allows me to identify companies who are leading the charge (like Opto 22), as well as specifications, tools, and other elements that are contributing to the evolution of APIs in each area--in this case, its broadly industrial usage of web APIs.
In my researching of industrial APIs I have come across the OPC format which was originally known as the Object Linking and Embedding for Process Control, which is defined as:
OPC is the interoperability standard for the secure and reliable exchange of data in the industrial automation space and in other industries The OPC standard is a series of specifications developed by industry vendors, end-users and software developers. These specifications define the interface between Clients and Servers, as well as Servers and Servers, including access to real-time data, monitoring of alarms and events, access to historical data and other applications.
I'm still getting going with the world of industrial automation, but I am looking through the OPC Unified Architecture to see where I can find any common definitions and schemas that could apply to industrial API design. I don't have any sense of how open these standards bodies are with their specifications, and I don't want to end up like Carl Malumud, but I do want to help identify and encourage common patterns in use for industrial automation.
Many consumer and B2B API implementations don't get me that interested, but I find the usage of them at the industrial level often more compelling, prompting me to add companies like Rockwell and Opto 22 to my industrial research. I'm adding the OPC standard as well, and will keep working to learn which other companies are doing interesting things with industrial APIs, and the standards that are guiding, or I guess possibly hindering expansion in the usage of web APIs across the industrial landscape.
I was learning more about the Programmable Automation Controller (PAC) API from Opto 22 and fouind myself intrigued by their usage of the word strategy to describe the role a web API can play when it comes to making the industrial automation process more programmable. I'd say the over API design is still very rough and represents the engineer's view of a PAC, but the potential for industrial IoT strategy orchestration is still present.
I'm learning about PAC APIs through the lens of my drone API research, where the role an API can play in the devices strategy creation, as well as execution. Meaning, with a drone, I can use the API to get at the data from one or many drone flights, as well as use the data, then the API again, to help me execute on the strategy. When this line of thought is applied in an industrial setting, the potential for an API driven strategy increases pretty dramatically.
A PAC API takes this strategy concept further down the road for me than it did with the drone alone. Each PAC can have its own DNS, and its own API, and the overall industrial process I am building a strategy for might contain many different PACS--allowing me to orchestrate in an unlimited number of industrial scenarios. I guess the API surface area for a PAC-enabled industrial workflow expands, contracts, and communicates very differently than it has for a single drone or even a drone fleet. I will have to take what I've learned from PACs and apply to drones.
This is the part of my API Evangelist existence I enjoy the most--the cross-pollination between the different sectors I am learning about.
When you hear about the Internet of Things (IoT) you often hear about the hopeful consumer side of thing, like with Nest thermostat, and the next wave of Internet-connected devices that will change our personal worlds forever. Personally, when I think about the concept of Internet-connected devices actually seeing adoption, and getting traction, I think of it being applied in an industrial setting.
The RESTful programmable automation controllers (PACs) APIs out of Opto 22 resemble this vision of IoT which I have in my head. APIs making everyday objects used in a variety of industrial processes, programmable, and accessible over wired or wireless networks. Making everything from manufacturing to water and energy facilities more automated and efficient, while potentially generated data that can be used to monitor, and optimize these industrial workflows--this is IoT.
The dream of home automation just doesn't do it for me. I just don't buy the Jetsons vision of the home, but I can buy into the potential for IoT making the industrial processes which we depend on to make our world operate more efficient. Consumer IoT seems like a bandwagon to me, but proven industrial equipment manufacturers like Opto 22 realizing the potential of web API infrastructure, and baking it into the devices they manufacture, seems like real world IoT business to me.
If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.