Description

Scope of this activity is to perform a gap analysis on the current status of EdgeX microservices and deliver specific market requirements to other Working Groups.


Requirements

As part of the gap analysis, common requirements in Oil&Gas will be taken into account.


Design

#AreaMicroserviceGaps IdentifiedCriticalityWhy ImportantRecommended ActionsRoadmap
1DeviceOPC UAMissing

New installations of SCADA systems are typically expected to be compliant with the OPC UA standard, this standard is good for new facilities

Engage Device WG and discuss with them how to handle this

PROPOSAL

Integrate Samsung DS for OPC UA

California
2DeviceOPC DAMissing

E&P Companies are still massively using OPC DA in legacy systems and - in limited cases - in new installations as wellAssess resources & roadmap with TSCN/A
3DeviceModbusSeems like the current Modbus implementation is querying 1 register at a time on the Modbus Slave. Modbus requests should be grouped together requisting multiple registers with a single call.

Sending too many requests is invasive on the PLC which needs to conserve CPU cycles to perform its control duties

Engage Device WG and discuss with them how to handle this

PROPOSAL

Ideally there should be the following configuration parameters in the Device Service:

  1. Maximum Response Data Length in Bytes – by default this will be 250 which means that the Device Service can ask for up to 125 16-bit registers on a single call. Some PLC will allow for more but it is better so stay in that range as a default.
  2. Maximum Simultaneous Requests – the default would be 4 which means the device service would make only 4 calls at a time
  3. Request Timeout – the default should be 500 ms. This is a parameter that you specify when making a Modbus call and your Modbus Master in the Device Service will wait that amount of time for an answer
  4. Minimum Delay Time Between Requests – the default should be 20ms to give a break to the PLC before sending him another group of request (we mentioned above 4 at a time as simultaneous)


Based on the above, in ideal situations the DS can request all the way up to 125x4=500 registers at a time, waiting 20ms before making another call.


What happens when the registers I am asking for in a single schedule are not consecutive?

Let’s assume I configured as part of a single GET the following registers to be retrieved on a schedule at 1000ms:

  • 0-20
  • 30-40
  • 70-100
  • 105
  • 115

Is it more efficient to have 5 separate calls or one combined call (0-115) discarding the results that are not relevant? The best strategy is to read all of them at once in a single combined call (0-115). Modbus is better at replying with a single bigger chunk of memory space rather than replying to multiple smaller requests.

California
4DeviceZigbeeMissing

Wireless sensors are slowly gaining traction for non-critical measurements as wiring can be tough in certain constrained environments. Zigbee would be a good option.Assess resources & roadmap with TSC
N/A
5DeviceLoRaMissing

Wireless sensors are slowly gaining traction for non-critical measurements as wiring can be tough in certain constrained environments. LoRa would be a good option.Assess resources & roadmap with TSC
N/A
6DeviceGPSMissing

Could a GPS DS serve to get the coordinates (lat/long - 2 floating point metrics) from the gateway?Assess resources & roadmap with TSC
Delhi
7DeviceProfinetMissing

Siemens hardware is used in many Oil&Gas installations (e.g. North Sea) and Profinet I/O would be a suitable protocol for interfacing with EdgeXAssess resources & roadmap with TSC
N/A
8DeviceDDSMissing

DDS is used in drilling for data messaging on critical itemsAssess resources & roadmap with TSC
N/A
9ApplicationsUINo UI for configuration (Data ingestion, Data Export...)

E&P Companies use systems with a provided UI. Relying on postman would not even get them started with tests.Engage Applications WG and discuss with them how to handle thisN/A
10ApplicationsRules Engine / AnalyticsNeed a light & easy CEP engine

In order not to transfer all data to the cloud (an Offshore Rig generates 1TB per day) you need to move some of the logic to the edgeEngage Applications WG and discuss with them how to handle thisDelhi
11CoreLoggingNeed to be able to specify persistency policies for type of logs

Different logs are required for liability purposes and can be assessed in case of incidentsEngage Core WG and discuss with them how to handle thisDelhi
12ApplicationsExportMissing mechanism for backfilling historical data. (perform an export job from start-timestamp to end-timestamp)

Retrieve historical data back to the cloudEngage Applications WG and discuss with them how to handle thisDelhi
13ApplicationsExportMissing Osisoft PI Export Capabilities

Majority of E&P Companies use Osisoft PI as historian in the data center. Need to be able to export data to such system.

Vertical Solutions WG will develop this. Sync with Applications WG.

PROPOSAL

Export Service to Osisoft PI

California
14ApplicationsExportMissing InfluxDB Export Capabilities

There is a need for a local optimized time series database in order to handle big amounts of data for long periods due to the disconnected nature of operations

Vertical Solutions WG will develop this. Sync with Applications WG.

PROPOSAL

Export Service to InfluxDB

California
15SecurityTPMHardware security module support (e.g. TPM)



Delhi


Code

If specific code addressing some of the identified gaps will be implemented as part of this project, the contributor will submit a PR on the relevant github repository.


Current status

Waiting on 0.6 release for further assessments.

A preliminary document was shared here EdgeX-Foundry-Oil&Gas-v3.pdf