Oil & Gas
Connected products built around the realities of oil & gas fields
Indeema works with SCADA, telemetry, field-equipment and oil-and-gas technology companies whose connected product already has equipment, interfaces and operating responsibilities in place.
Oil and gas software development starts by defining the handoff between that field system and the gateway, cloud services and applications added around it.
Existing field equipment, with one defined handoff to the connected product.
Start with what is installed
The field system already exists
This is not a blank device-to-cloud architecture. Equipment, a client SCADA product, sensor boards, field interfaces and operator workflows may all predate the software being added. They set the boundary the new product has to respect.
- 01
Installed equipment
The connected product begins beside equipment, sensor boards and field interfaces that already exist.
- 02
A defined handoff
The gateway and interface mark where field-system responsibility meets the software added around it.
- 03
Supervised operations
People provision devices, review status and choose when software updates move through the boundary.
- 04
Link conditions
The available connection, its limits and its ownership are architecture inputs – not assumptions hidden in a diagram.
For the wider energy operating context, see Energy . For a connected product spanning device, cloud and application, continue with Connected Product Engineering .
The responsibility boundary
Where is the handoff?
The gateway and its defined interface sit between a field system the client already owns and the connected software built around it. Making that seam explicit keeps observation separate from authority over the industrial process.
Supported responsibilities
Provision · Observe · Update
Our project work sits on the software side of the handoff. These responsibilities make a field product easier to operate without implying control of the underlying process.
- 01
PROVISION
Give each gateway or node the settings and identity it needs to join the product. In the VikingSCADA engagement, first-start provisioning assigned unique credentials and settings.
- 02
OBSERVE
Present sensor information and node status in the web application so people can understand what the connected layer receives. Observation does not grant process-control authority.
- 03
UPDATE
Show available software versions and let an authorised user start gateway-image or remote-node updates. The return path ends at the gateway and software boundary.
For reusable fleet monitoring and equipment-observability patterns, see Industrial IoT & Intelligence .
Architecture inputs
Work with what exists
An oil and gas software development company should not erase the current product in order to draw a cleaner diagram. Existing applications, hardware, interfaces and workflows are the starting material for the next architecture. Recording them together exposes incompatible assumptions before they become implementation decisions.
- 01
Applications
What the desktop application and portal already do, and which workflows must remain familiar.
- 02
Hardware and boards
Which units and RF sensor boards already exist, and what signals or data they expose.
- 03
Gateways and interfaces
Which module, API and field connection form the handoff to the new software.
- 04
Accounts and services
Which platform accounts, cloud services and access roles are already part of the product.
- 05
Operating workflows
Who provisions a unit, reviews its state and decides when an update is applied.
Define embedded behaviour in Embedded & Firmware , physical interfaces in Hardware & Electronics , connected services in Cloud & Connected Systems , and operator workflows in Applications & Experience .
VikingSCADA in practice
Connected software beside an existing field platform
The client already had a desktop application, hardware units, RF SCADA sensor boards, platform accounts and an initial architecture. Indeema’s work began at that existing system.
From the pump, through one gateway, to one operations view.
What already existed
Desktop software, field hardware, RF sensor boards, access to IoT platforms and a basic portal formed the starting point.
Gateway and provisioning
Lua scripts ran on LTE gateways in one phase and Python software on industrial PCs in another. First-start provisioning assigned unique credentials and settings.
Web product and updates
The cloud-backed web application presented configurable sensor views and node status, announced available versions, and supported gateway-image and remote-node update workflows. The team tested the application with multiple nodes.
Read the VikingSCADA case . For definitions and an explanation of how SCADA systems work, the separate SCADA article remains the informational guide.
Scope the field reality
Bring the boundary into the first conversation
Before choosing a stack, make the current system and the limits of the new product visible. Questions about field conditions belong in discovery until the available evidence and responsibility are clear.
- 01
Existing equipment
What is installed already, and which parts are outside the new product’s responsibility?
- 02
Available interfaces
Which boards, modules, APIs and data fields can the software actually use?
- 03
Link conditions
How does each field unit connect, and what limits must the architecture accommodate?
- 04
Roles
Who may add a unit, view its status, change its settings or initiate an update?
- 05
Update expectations
Which software can change remotely, who starts the change and where does responsibility stop?
- 06
Current artefacts
Which applications, source, diagrams, hardware and platform accounts can the team inspect first?
If that boundary is not documented yet, begin with Product Discovery & Technical Strategy . When the full device-to-cloud lifecycle is in scope, continue with IoT Product Engineering .
Start at the handoff
Bring the field product you already have
We can map the equipment boundary, available interfaces, link conditions, operating roles and update expectations before deciding what belongs in gateway software, cloud services or applications.
Bring us
- The current equipment, boards and gateway
- The interface or API at the handoff
- The workflows people use today