Anyone who has connected a SCADA or HMI to a complex system not using OLE for Process Control (OPC) will be familiar with calling a REST Web API to obtain important data. As the world of process control gets more data-hungry and systems need to be ever more connected, more data is being shared between the business and control networks.
One way to keep our business and process control networks separate and still maintain the required segregation of the networks is by calling Web APIs to have access to remote data through firewalls, with authentication and the possibility to connect to the broader network world outside of our control environments.
Currently, REST APIs are a ubiquitous and commonly understood communication layer in the Software Engineering world, and also increasingly in the controls domain. But with the volume of data required by operational systems forever increasing and the closer integration between IT and OT departments, control system engineers and developers are finding it harder to meet the challenges of developing streamlined data integration solutions using REST APIs.
Enter GraphQL
GraphQL is an alternative to using REST API's. It is an open-source data query and manipulation language released by Facebook in 2015, and it addresses a number of pain points experienced when developing solutions using REST APIs.
One of the main challenges faced when working in the operational data domain is changing data requirements in operations as the focus of operations changes. REST API endpoints are statically defined, the shape and content of the data is determined at design time. Being static in nature, the chances increase that the consumer of this data will invariably over or under fetch data. Meaning;
- The data can either include extra material that slows the network down, taking longer to query and placing more load on storage and transmission that isn’t required, or...
- The data to be returned in defined sections may not include all the relevant data, requiring multiple trips to the REST API at the cost of time and efficiency.
GraphQL replaces an endpoint for every type of data (as required when using a REST API) with a single endpoint. This allows the engineer to send a query to the endpoint, asking for only the information required. GraphQL enables the engineer to indicate which fields to return and which ones to ignore, eliminating the problem of over and under fetching.
GraphQL also supports nesting types of data, meaning all related objects can be returned with their child information. For example, a recipe can be returned, including all the ingredient children, which in turn may contain allergy information related to each ingredient, rather than listing the ingredients, iterating that list, and looking up each ingredient with individual calls to REST API endpoints.
With the use of GraphQL, the controls engineer can be connected to a complex data set in a self-service fashion. Removing the need to continually add or change endpoints that serve very specific data to the controls network when their requirements change.
A few additional benefits to take note of:
- GraphQL allows data to be exchanged in industry-standard formats like JSON, bound to controls or indications on screens, or used in decision-making with ease.
- Another benefit of using GraphQL for the Controls Engineer is the built-in Introspection feature. GraphQL endpoints can tell a user about what it supports and how to query for data, including all the Types (tables or entities usually from a database, for example), filters, and mutations, including comments – all extracted from the source code of the GraphQL implementation.
- With GraphQL, the documentation is always in sync with the implementation. Thus documentation of the supported features of your GraphQL implementation should be enough for a third party to understand how to access and consume data without additional cost.
- GraphQL can be consumed by modules supported directly by your SCADA / HMI, or handcrafted HTTP POST Request Response handling. In the worst case, this is marginally more difficult than a standard REST API GET Request, and in the best case, supported directly with no additional effort.
