01
Brownfield discovery
Inventory equipment, protocols, registers or tags, timing, control boundaries, and conditions that must remain untouched.
IIoT integration
Connect existing equipment to monitoring, data, and application layers without ignoring brownfield constraints.
System boundary
Keep the connected path visible.
The exact scope can begin at one layer. Its adjacent interfaces and ownership still remain explicit.
- 01
Existing equipment and control limits
- 02
Protocol, gateway, and data contract
- 03
Monitoring, application, or connected service
Common situations
Where this work usually begins
These are scoping signals, not assumptions about your system. Discovery confirms which one actually matters.
- 1
Multi-vendor equipment exposes useful signals through different protocols and naming conventions.
- 2
A retrofit must add visibility without disturbing the working control path.
- 3
Remote or connected workflows need a clear boundary for access, buffering, and support.
Engineering workstreams
Work organized around reviewable boundaries
02
Data and interface contract
Define signal meaning, mapping, units, quality, timestamps, polling, ownership, and behavior when data is unavailable.
03
Gateway and application integration
Implement Modbus, OPC UA, MQTT, CAN, or adjacent adapters across the edge and consuming application.
04
Commissioning evidence
Exercise representative equipment states, disconnects, malformed values, recovery, and operator-visible outcomes.
Delivery evidence
Concrete outputs, scoped to the engagement
The final set depends on the system and acceptance needs. These are the kinds of assets and evidence that can be made explicit during scoping.
Potential deliverables
- Equipment, protocol, and ownership inventory
- Register, tag, or message mapping with data semantics
- Gateway, adapter, or application integration components in scope
- Configuration and commissioning guide
- End-to-end integration and recovery evidence
Validation evidence
- Representative equipment states and data mappings
- Disconnect, timeout, invalid-value, and reconnect behavior
- Local operation and buffering boundaries where required
- Operator-visible confirmation of the intended workflow
Scoping questions
Questions worth answering first
Useful scope begins with operating context and evidence, not a predetermined technology list.
- 01
Which existing equipment and control paths must remain untouched?
- 02
Which signals matter to the downstream decision or workflow?
- 03
What should happen when a device or network stops responding?
- 04
Where are remote access and support allowed to cross the plant boundary?
Discuss iiot integration
Bring the boundary, constraints, and evidence you have.
The first conversation can determine whether discovery, scoped delivery, engineering extension, or modernization is the right starting shape.