Industrial IoT · Infrastructure & systems engineering
I engineer the connections between gas devices, communications networks, servers, and operational software. My work includes defining system requirements, evaluating infrastructure options, and coordinating manufacturers and stakeholders so the interfaces, dependencies, and support responsibilities fit the operation.
01 — The engineering role
Connected gas infrastructure crosses several technical and organizational boundaries: meters and detectors, control panels, concentrators, networks, servers, data, and the people making operational decisions. I work across those boundaries to turn operating needs into an implementable system.
Devices → Platform
My hands-on work includes integrating 4G remote terminal units with existing gas-control panels for monitoring and lockout, and configuring the monitoring middleware.
Alongside that implementation work, I define device behavior, platform features, and operator-interface requirements with manufacturer engineering teams, then review samples and integration behavior against the intended use.
Stakeholders → Decisions
I assess cloud and on-premises options, stable server endpoints, routing and isolation requirements, scalability, and recurring cost. Each choice affects how the infrastructure connects, who can access it, and who will maintain it.
I bring together operational stakeholders, field teams, IT, management, and manufacturers to clarify requirements, resolve technical dependencies, and agree the next engineering decision.
02 — Infrastructure scope
The responsibility matrix below describes the decisions I work through across connected-gas projects. The selected devices, communications paths, and platforms depend on the installation and its operating requirements.
| Layer | My engineering responsibility | Decision to resolve |
|---|---|---|
| Devices & control | Define functional requirements for meters, detectors, concentrators, and gas-control interfaces. Review device behavior, remote-command requirements, samples, and manufacturer capabilities. | What must be measured or controlled, what feedback is available, and how will the behavior be validated? |
| Communications | Assess coverage, device-to-concentrator links, cellular uplinks, and connection dependencies. Specify the applicable SIM, APN, domain, IP, and server settings. | Which path is supported, how does it report, and what are its coverage, maintenance, and cost implications? |
| Servers & platforms | Evaluate cloud and on-premises models, stable endpoints, network isolation, platform access, scalability, and support responsibilities. | Where does each service run, which systems can reach it, and who operates and maintains it? |
| Data & integration | Clarify the supported software interfaces, data and database dependencies, asset mapping, units, timestamps, reports, and access requirements. | How will information move into operational software with the context and permissions its users need? |
| Stakeholders & decisions | Translate operating scenarios into technical specifications and manufacturer questions. Reconcile feedback, dependencies, and acceptance needs across the teams involved. | Who supplies, decides, validates, and supports each part of the system? |
Work through the monitoring, control, access, and reporting scenarios with the people who will use and support the system.
Confirm what the manufacturer supports, select the connection and platform approach, and identify the infrastructure dependencies.
Review samples, configure the required connections, and check device behavior, data, permissions, and failure cases against the requirements.
Make support responsibilities, outstanding constraints, maintenance needs, and the next acceptance or implementation step explicit.
Reporting frequency is a design input. An hourly device report and an on-demand control action have different requirements. A dashboard refresh cannot make the underlying device transmit more often.
03 — Integration validation
Commissioning is one part of this review. The wider task is to confirm that the device, communications path, software interface, data, and access model behave as the agreed workflow requires.
| Check | Question to resolve | Why it matters |
|---|---|---|
| Connection & interface | Does the selected uplink reach the intended server, and does the exposed interface match the agreed integration route? | Connectivity and application integration have distinct dependencies to verify. |
| Command feedback | What does a command acknowledgement confirm, and where is the resulting device state observed? | Sending, receiving, and executing a command are distinct states to validate. |
| Asset identity | Does the device map to the correct site, tank, or meter? | A valid reading attached to the wrong asset can send a team to the wrong location. |
| Value & unit | What does the value represent, and how is it scaled or calibrated? | Level, volume, consumption, and device status are different quantities. |
| Time & freshness | When was the measurement taken, received, and last updated? | A plausible value can still be stale. |
| Missing reports | How is a gap detected, investigated, and handed over? | An absent update needs an owner and a defined response. |
| Access & alerts | Who can see the asset, and who receives the relevant notification? | Visibility and responsibility need to match the operating structure. |
04 — Architecture decisions
In a smart-metering review, stakeholders needed to understand how concentrator data could reach a third-party building-management system. I worked through the communications model with the manufacturer to establish which interface could support that requirement.
The question
The concentrator had an RS-485 connection. Its physical presence raised an integration question that required confirmation of the actual transport and supported behavior.
The clarification
The manufacturer confirmed that the serial link carried proprietary concentrator-to-server communications. The supported third-party integration point was the management software’s Web API. The concentrator also supported one uplink mode at a time.
The review outcome
The clarification established where the integration needed to happen and which infrastructure and software dependencies required further work. The outcome was a confirmed interface boundary and a clearer integration brief.
The same review discipline applies to site-level access, tenant separation, notification recipients, and reporting schedules. I work through the operator and administrator scenarios, document the supported behavior, and turn capability gaps into precise manufacturer questions and stakeholder decisions.