Oilfield IoT Consortium

Ecosystem Overview

The Oilfield IoT Ecosystem is an open, standardized system of hardware and software that is interoperable. This creates a framework for multiple different stakeholders to collaborate with a limited amount of integration effort.
IoT Ecosystem
Oilfield IoT Ecosystem Overview
Using a standardized operating system, common data model, and predefined application programming interfaces (API) ensures that users of the system are not required to do any specialized programming. The level of standardization is broken into two sections, core and optional.

CORE

The following sections outline the core software features that ensure applications at the edge and in the cloud are interoperable. All pieces must adhere to the standard to ensure that software from different vendors are compatible without additional integration layers.

Common Operating System

By using a common operating system, applications can be developed that run on multiple hardware platforms, producers get more choice of applications, and there are greater opportunities for apps to interact with each other. This also opens up the ability for common development & deployment tools.
Common Operating System

The following components are combined to make a hardware agnostic operating system:

  • Embedded Linux Operating System
  • Docker Containers
  • Supervisor Application
  • Developer Applications
  • Common Data Models and Protocols

Push Data Model

Specifying a push data protocol removes the overhead associated with a polling architecture, allows for push by exception, and allows for encryption and compression.

Push Data Model

Lightweight Machine to Machine (LWM2M)

LWM2M is a standard push data protocol established by the Open Mobile Alliance (OMA) which is used in a number of other industries. This standard sets a common data model (objects), transport layer (UDP), and methods (CoAP).

Beyond the storage and transport of data, the standard:

  • Natively supports geo location
  • Has pre-defined criteria for report by exception
  • Has a registry of common objects
  • Has reserved sections for industry specific data models
  • Central Object Registry

    While there is a standard global registry defined by OMA, there is a need to define common objects that are specific to the oilfield. This will allow for a community driven approach where anyone can submit new object definitions.

    Object with resource definitions
    Once a new object type is defined and submitted, they go through an approval process to ensure that object types are not duplicated. It is then entered into the central registry and made available to all apps and services.
    Central Object Registry

    Edge App Application Programming Interface

    Apps are containerized and run in virtual environments to avoid collision between multiple different processes that are built and maintained by different vendors. Although apps can run independently, there is also the ability to interact. The Edge App API allows one app to obtain edge data from another application running on the same hardware. This will allow an app to perform a single smaller function or to bring together multiple apps to create a higher-level function.
    Edge App Interactions

    Communication Driver App

    Classic examples of this would include a class of apps that are essentially communication drivers. These drivers would communicate with a device or set of devices in their native protocol and bring the data into the common data model. They might push data back to the cloud directly, but will expose their data through the API so it can be used by an aggregator type app.

    Aggregator App

    An aggregator app is one that takes data from several other apps to perform a higher-level function such as a calculation or control function that depends on one or more pieces of data. An example would be a plunger lift application that utilizes an existing plunger lift controller and flow computer data to maximize production. It might also interact with a chemical injection application to time injection to avoid wasted chemical.

    Device Management Service

    A device management service is a collection of cloud-based applications that provides all of the management software to interact with remote devices and to route the incoming data to monitoring services. The device management service may be its own independent service, may be specific to a hardware vendor, or may be embedded in a monitoring service.
    Device Management Service

    Common functions include:

    • Report device location, health, and status
    • Receive data pushed from edge devices
    • Push data to one or more monitoring services
    • Install/update/remove edge applications

    Monitoring System Interface

    Each monitoring service must implement a common interface to receive data that is pushed from a device management service. By standardizing this interface, device management services can be seamlessly integrated to all compliant monitoring services. This opens the door for producers to switch monitoring services or use multiple complimentary services.

    Monitoring Service API

    OPTIONAL

    These optional sections are centered around physical layers which will be more difficult to implement and maintain. By implementing this level of standardization, more complex hardware systems become possible, hardware becomes more interchangeable, and the cost will drop dramatically.

    Hardware Architecture

    The hardware architecture should be modular and vendor independent. By having a core edge processor (motherboard) and snap in modules (expansion cards), the hardware can be more adaptable. All too often complete products are built that are either too expensive or not feature rich. By leveraging a common minimum core, the costs are minimized. A common expansion bus allows for additional I/O or other hardware features to be added without changing the base. In addition, various interoperable modules can be designed by different hardware vendors.

    Edge Processor with Snap In Modules

    A possible interface should include:

    • Power and ground
    • USB
    • I2C
    • SPI

    Local Wireless

    Another way to expand is to utilize low power wireless. This allows a piece of hardware to expand its reach without affecting certification, power supply, and physical connections. The challenge here is to standardize on a physical and protocol layer that is adopted by both edge processor and sensor manufacturers.

    Local Wireless

    A good first step is to standardize around a physical form factor. Using the XBee form factor will leave us open to use:

    • Bluetooth
    • Wi-Fi
    • Zigbee
    • LoRa
    • Many others
    For more information about how you can use or contribute to the Oilfield IoT Ecosystem please contact us and we’ll be happy to outline the value of the consortium and how it can benefit your organization.

        Join Us

        Registration
        1. Oil and Gas Producer (No Charge)Not-For-Profit Association (No Charge)Technology/Services Vendor ($500USD)Sponsor ($1,500USD)
        You are agreeing to:
        1. Be invoiced for the annual membership fee (plus GST for Canadian companies)
        2. Your company logo being displayed at www.OilfieldIoT.org
        3. Your email being used for group communication tools and newsletters.
        4. Your information being kept on record as long as you are a member
        Accounting Information (Vendors Only)
        1. Accounting Contact (if different from above):