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 |
|---|---|---|---|---|---|---|
| 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 |
| 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 |
| 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:
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:
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. |
| 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 |
| 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 |
| 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 |
| 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 |
| 8 | Device | DDS | Missing | MEDIUM | DDS is used in drilling for data messaging on critical items | Assess resources & roadmap with TSC |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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 v0.5 release.
A preliminary document was shared here EdgeX-Foundry-Oil&Gas-v3.pdf