Description
To be updatedScope 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
To be updated.
Design
To be updated.
Code
To be updated.
Current status
To be updated.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 |
| 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 |
| 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. |
| 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. | California | ||||||
| 4 | Device | Zigbee | Missing |
| 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 |
| 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 |
| 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 |
| 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 |
| 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...) |
| 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 |
| 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 |
| 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) |
| 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 |
| 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 | California | ||||||
| 14 | Applications | Export | Missing 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 | California | ||||||
| 15 | Security | TPM | Hardware 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