Edge Device Communication Module


Intro to Edge Device Communication Module

Modbus Module (HBM)

It is a core component of Hermes.

Responsibilities

  • Telemetry acquisition (modbus only)
  • Alarams
  • Telemetry reporting
  • Glue layer (hub) between Nimbus and other edge apps
  • Telemetry channel provisioning
  • of the gateway from Nimbus

Messages

  • IODataReport
  • RequestIOConfig
  • RequestConfigSync
  • RequestDataWrite
  • ResponseDataWrite
  • Request_FileUpload
  • Request_FileDownload
Tip

Data-in-out, configuration, file, and set-point work flows can be tested in relative isolation without MM or Nimbus present by simply sending message samples to corresponding endpoints.

Endpoints

  • Data In / Data Out
  • Request In / Request Out
  • Config In / Config Out

Enron Modbus Module

This application provides the ability to query data from devices using the Enron/Davies Modbus protocol. Enron/Davies Modbus, also known as just Enron Modbus, is an extension of Modbus which allows for larger Modbus data queries and for direct querying of data types such as Int32 and Float. This application queries sets of registers and maps those values to data tags which are sent to the bus as IoDataReportMsg using the ‘DataOut’ topic. Configuration of the module allows customization of the data query rate, the registers queried, and the mapping of those registers to data tags. Additionally, the ability to write data to the data tags is done by mapping incoming data tags to the target registers on the device via configuration.

OPC UA Server

  • Communication with East/West OPC-UA Client devices over Ethernet.
  • The OPC-UA Server module implementation is compliant with OPC-UA v1.03 Specification.
  • The OPC-UA Server module, capable of handling multiple session for multiple client configuration.
  • Supports registration of server into Global Discovery Server (GDS).
  • Support for both secure and insecure endpoints exposed by the server.
  • Server and tag configuration via direct method calls from the edge and the cloud.
  • Tag configuration from other edge modules via config message.
  • Workflows for trusted clients in server mode.

OPC UA Server

OPC UA Client

  • Communication with southbound OPC-UA Server devices over Ethernet.
  • The OPC-UA client module implementation is compliant with OPC-UA v1.03 Specification.
  • The OPC-UA client module, capable of handling multiple session for multiple server configuration.
  • Supports discovery of Server devices via Global Discovery Server (GDS).
  • Support for both secure and insecure endpoints exposed by the server.
  • Persistent storage of server configuration and tag configuration.
  • Remote and Local workflows for managing trusted Servers in Client mode.
  • The docker container images are able to run on both arm32 and x86_64 devices.
  • Handling of multiple pollsets with the different timing requirement.

OPC UA Server

WITS Receiver

A WITS Receiver is a module that receives data from the WITS Server/Simulator. The data are numeric values (integer or fractional), as well as strings.

For more information see specification: WITS (Wellsite Information Transfer Specification) Fundamentals. The most commonly used values are from the first table.

Two client types can be used to connect to the WITS server: through TCP or Serial port.

Setting

WITS Receiver settings can be set in the module.json file or using alternate configuration.

module.json

{
  "Name": "WitsReceiver",
  "AEA2": {
    "BusClient": {
      "Server": "mqtt-net-server",
      "Port": 707,
      "UseDataIn": true
    },
    "LogLevel": "Debug"
    }
  },
  "WitsReceiver": {
    "ClientType": "Serial",
      "PortName": "/dev/ttyXR0",
      "BaudRate": 9600,
      "Parity": "None",
      "StopBits": "One",
      "DataBits": 8,
      "Pason": true,
      "PasonWaitTime_ms": 1000
    },
    "TCP": {
      "Server": "127.0.0.1",
      "Port": 54802
    },
    "DeviceId": 257
  },
  "AgoraSender": {
    "Conversions": [
      {
        "InName": "TQA",
        "OutName": "STOR",
        "a": 1,
        "b": 0,
        "c": 0,
        "d": 1
      }
    ],
    "GroupID": "EDGE"
  },
  "TimeZone": "Asia/Muscat"
}

WitsReceiver:

  • ClientType: method of connection to the WITS server, can be used "TCP" or "Serial" values.
  • Serial: settings in the case of the connection to the WITS Server through Serial port.
  • TCP: settings in the case of the connection to the WITS Server through TCP/IP port:
    • Server: IP address of the WITS Server/Simulator.
    • Port: port number that is used for connection.
  • DeviceId: device ID, used in the IODataReport message as "device:id" of the WITS Reader.

WITSML Client

In this WITSML Project customer wants to implement the process which reads incoming well/wellbore data from the field on an edge gateway and and then update the information at the server running on the Gateway or send it to the WITSML server repository to create/update the associated well/wellbore information.

The edge application was built to run on any Agora Edge Gateway, and it is leveraging the Agora Edge App SDK (2.0) and C# .NET 6.0 for configuration, logging, and sending/receiving data from the Agora Edge App MQTT Broker.

In WITSML we have two major components :-

Architectural Overview

This section provides a brief overview regarding the architecture showing how Agora applications and edge devices are being used, how they transmit log data, and how they store log data.

Agora

Figure 1 : Agora Edge Apps Field Architecture

  • Agora gateways are installed on rig/well site for data collection.
  • Agora Edge Apps (AEAs) are packaged as Docker containers.
  • AEAs are deployed and configured on the gateway by AgoraOps personnel.
  • The WITSML Client is communicating with AEAs bus. AEA through broker may receive data from other applications which are running on the gateway or externally using the WITSML protocol.
  • The existing WITSML Client creates/reads/writes/updates data on external WITSML Servers, such as InterAct.
  • The WITSML Client will have a Wep Application (will be developed) which will enable field engineer to activate (/check status) of the active Wellbore for the Well

WITSML Server

In this WITSML Project customer wants to implement the process which reads incoming well/wellbore data from the field on an edge gateway and and then update the information at the server running on the Gateway or send it to the WITSML server repository to create/update the associated well/wellbore information.

The edge application was built to run on any Agora Edge Gateway, and it is leveraging the Agora Edge App SDK (2.0) and C# .NET 6.0 for configuration, logging, and sending/receiving data from the Agora Edge App MQTT Broker.

In WITSML we have major 2 components :-

WITSML Server will provide data from the edge Gateway to a WITSML Client. Data will be stored on the gateway and made available to authenticated/authorized WITSML Client using basic Auth (username/password) as described by the WITSML server specification.

` Agora

Figure 1: WITSML Server

Technical Overview

The application is developed using C# .NET Core 6 and leverages the existing Agora Edge Apps SDK with facilities for Logging, Configuration, and communicating to the gateway's Message Broker.

WITSML Server

The WITSML Server app is on the same network as a WITSML Client. The application listens for data published by other apps on the gateway using the MQTT broker as well as responds to WITSML requests from external WITSML Clients using a web endpoint.

The following are the points to consider for the WITSML Server Application:

  1. Should have the capability to authenticate the incoming requests against configurable username/passwords (not stored as clear text). a. A password configuration file (not part of the AEA2 SDK Configuration) will act as User Database.
    b. The password configuration file should be stored in the config folder so that AgoraOps can update the users allowed to access the system. c. Should have the capability to reload the config file if some user changes the username/password in the config file.
  2. If the user is authenticated, the app will allow those users to access the data that they want to access if authorized. (CRUD Operations)
  3. App stores the data locally in a File structure.
  4. App will only support Well, Wellbore, Log, and Log Curve WITSML data types.

Architectural Overview

This section provides a brief overview regarding the architecture showing how Agora applications and edge devices are being used, how they transmit log data, and how they store log data.

Agora

Figure 1 : Agora Edge Apps Field Architecture

  • Agora gateways are installed on rig/well site for data collection.
  • Apps are developed for the gateway using the Agora Edge App SDK 2.0 (AEA2 SDK) using .NET Core 6.0.
  • Agora Edge Apps (AEAs) are packaged as Docker containers.
  • AEAs are deployed and configured on the gateway by AgoraOps personnel.
  • The WITSML Client or Server are AEAs and may receive data from other applications running on the gateway or externally using the WITSML protocol.
  • The WITSML Client creates/reads/writes/updates data on external WITSML Servers, such as InterAct.
  • The WITSML Server provides a web endpoint that will allow external WITSML Clients to create/read/write/update data.
  • The WITSML Server stores data on the gateway using files.

Technical Details

Agora

Server Details

InterAct Server

Env Development and Testing Purpose
Server URL https://evt.interact.slb.com/Witsml/Store/Store.asmx

Create Connection with WITSML Server (InterACT)

For making the connection with the InterACT Test server the following information shall be provided in the AEA.json file.

  • Server URL
  • Username
  • Password (clear text)
"WITSMLSender": {
    "ServerURL": "https://evt.interact.slb.com/Witsml/Store/Store.asmx",
    "Username": "username",
    "Password": "password",