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

#	Area	Microservice	Gaps Identified	Criticality	Why Important	Recommended Actions	Roadmap
1	Device	OPC UA	Missing	HIGH	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
2	Device	OPC DA	Missing	HIGH	E&P Companies are still massively using OPC DA in legacy systems and - in limited cases - in new installations as well	Assess resources & roadmap with TSC	N/A
3	Device	Modbus	Seems 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.	HIGH	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: 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. Maximum Simultaneous Requests – the default would be 4 which means the device service would make only 4 calls at a time 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 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
4	Device	Zigbee	Missing	LOW	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
5	Device	LoRa	Missing	LOW	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
6	Device	GPS	Missing	MEDIUM	Could a GPS DS serve to get the coordinates (lat/long - 2 floating point metrics) from the gateway?	Assess resources & roadmap with TSC	Delhi
7	Device	Profinet	Missing	LOW	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 EdgeX	Assess resources & roadmap with TSC	N/A
8	Device	DDS	Missing	MEDIUM	DDS is used in drilling for data messaging on critical items	Assess resources & roadmap with TSC	N/A
9	Applications	UI	No UI for configuration (Data ingestion, Data Export...)	HIGH	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 this	N/A
10	Applications	Rules Engine / Analytics	Need a light & easy CEP engine	MEDIUM	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 edge	Engage Applications WG and discuss with them how to handle this	Delhi
11	Core	Logging	Need to be able to specify persistency policies for type of logs	HIGH	Different logs are required for liability purposes and can be assessed in case of incidents	Engage Core WG and discuss with them how to handle this	Delhi
12	Applications	Export	Missing mechanism for backfilling historical data. (perform an export job from start-timestamp to end-timestamp)	MEDIUM	Retrieve historical data back to the cloud	Engage Applications WG and discuss with them how to handle this	Delhi
13	Applications	Export	Missing Osisoft PI Export Capabilities	HIGH	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
14	Applications	Export	Missing InfluxDB Export Capabilities	HIGH	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
15	Security	TPM	Hardware security module support (e.g. TPM)	MEDIUM			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

Browser not supported