...
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: - 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: 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 |
CoreApplications | 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 |
Core Applications WG and discuss with them how to handle this | N/A |
10 |
SupportApplications | 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 |
SupportCore | 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 |
Client Registration & Distribution | 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 |
Client Registration & Distribution | 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 |
Export Client Registration & Distribution | 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 |
Export Need to lock down access to EdgeX from unathorized accessSecurity | TPM | Hardware security module support (e.g. TPM) | |
YellowHigh | High security concerns | Californa Release should address this. No need for action
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 v00.5 6 release for further assessments.
A preliminary document was shared here EdgeX-Foundry-Oil&Gas-v3.pdf