...
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 | |
Although OPC UA is an emerging standard, E&P Companies are still massively using OPC DA in legacy systems and - in |
some 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 | |
colour | BlueMedium | 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 | |
colour | BlueMedium | 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 | |
colourBlue | Medium | 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 |
Core | Data | Core | Metadata | Core | Command | SupportSupportAssess 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 |
Support | Scheduling | Support | Alerts & Notifications | 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 |
Client Registration & Distribution | Missing mechanism for backfilling historical data. (perform an export job from start-timestamp to end-timestamp) |
.System | System Management | Connection loss handling: changes made while offline will be cached and sent when connection is re-established | Edges could be often disconnected | Security | Security | Need to lock down access to EdgeX from remote hosts not authenticated | | 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 Export Service to Osisoft PI | 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
Export Service to InfluxDB
| 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 v00.5 6 release for further assessments.
A preliminary document was shared here EdgeX-Foundry-Oil&Gas-v3.pdf