A one-engineer software consultancy for industrial companies. We build, integrate, and support the software between plant floor and IT — protocol stacks and test tooling, data integration and historians, the legacy systems nobody else will touch — on published rates or at a fixed price.
Expand a service: the problem, what we do about it, and where we have done it before.
You need software that talks to your devices — a protocol library, a device emulator, an API that gives IT a clean view of the plant floor — and the off-the-shelf options are incomplete, unmaintained, or wrong for your hardware.
Most OT/IT gaps are not one integration problem but a stack of them: a protocol nobody has implemented properly, a device that deviates from the standard, an IT team that wants a REST endpoint rather than register addresses. We have programmed the controller end of these links, so a library is built for how the device actually behaves, not only for what the standard says.
We build at whichever level the problem sits. Protocol libraries written from the specification when existing ones cannot handle real device behaviour. Emulators that reproduce a device closely enough to test against without hardware on the bench. REST APIs that expose device state and data streams without leaking protocol internals.
Python for data work and fast iteration, Go for services that must be fast and concurrent. Everything is packaged, version-controlled, and delivered through CI with automated tests — you receive the source, the documentation, and the pipeline that builds the deliverable, whether that is a container, a package, or a binary.
You ship protocol stacks, firmware, or communication software and need proof that it behaves — under the specification, and under the malformed traffic real networks produce.
Communication software fails at the edges: odd frame sizes, timing, half-closed connections, devices that bend the standard. Manual testing does not reach them and cannot be repeated on every release.
We build specification-driven suites: unit tests written test-first so the harness is proven before the product code exists, and integration and end-to-end tests written as given/when/then scenarios that read as executable requirements. Where hardware is scarce, emulators stand in for devices so the suite runs in CI.
At Hilscher this covered DeviceNet, Modbus (RTU and TCP), Modbus Security, MQTT, TFTP, and CAN stacks, with AI-assisted generation of test cases from the product specification to extend coverage beyond what manual authoring reaches.
Your process data sits in PLCs, SCADA alarms, and lab systems that were never meant to talk to each other.
The usual starting point: you have a historian or data platform, but what arrives in it is incomplete. Some sources have no connector. Others drop samples when a link goes down. Tag names differ between lines and sites, so nothing can be compared.
We build one agent per source — OPC DA/UA, MQTT, file drops over FTP/SFTP, WinCC alarms, lab analysers — that maps its data to your tag schema and delivers it to a common sink. Agents buffer through outages and reconnect on their own, so a network interruption is a delay, not a gap.
Delivered at scale for Heidelberg Materials: Siemens WinCC controllers feeding PxTrend with time-series metrics, alarms, and lab analyser messages across production lines.
Your control logic needs to move, change, or be made consistent — a Honeywell strategy ported to Siemens, a PLC program nobody dares to modify, PID loops that were never tuned properly.
Process control logic is software with unusual constraints: it runs on a PLC or DCS, it is written in SCL, ladder, or function blocks, and a wrong edit stops production. Most integrators want the whole project; most software shops will not touch it.
We work in that gap. Control block libraries and ports between platforms — Honeywell semantics on Siemens hardware, so operators keep one control philosophy across the plant. Refactoring and documentation of existing PLC programs. Simulation and PID tuning support based on historian data rather than trial and error on the live process. The communication side of the controller as well: fieldbus and I/O architecture — Profibus, Profinet, Modbus RTU and TCP from the PLC's end — which signals are hardwired and which go over the bus, and how the controller exposes its data to OPC and the historian. We do the software side, remotely, and hand over to your integrator for commissioning.
Nine years of this at Solvay Sodi — Honeywell Experion and TPS, Siemens S7-300/1500, from concept through commissioning, ATEX units included — and three peer-reviewed papers on process control that came out of it.
You have a system that works and that nobody dares to change: the original developer has left, there are no tests, and every fix risks breaking something else.
Legacy industrial software rarely fails outright; it becomes untouchable. Undocumented business rules, no type information, no test coverage, and architectural decisions that made sense years ago now block every change.
We make it safe to change again. It starts with an audit that maps the code as it actually is — dependencies, dead paths, where the business logic really lives. Then we refactor incrementally, adding tests alongside each step so behaviour is preserved while structure improves. For larger systems we write arc42 architecture documentation, so the understanding survives the next staff change.
You keep operating throughout. Nothing is rewritten from scratch; there is no big-bang cutover.
A system your plant depends on — a historian, communication software, a legacy application — misbehaves, and your team and the vendor are out of depth.
We are the escalation point that understands the system well enough to intervene without making it worse. Second level: configuration changes, small enhancements, user questions. Third level: root cause analysis, hotfixes, and intervention at the system level when nothing else has worked.
The rule is understand before acting. Legacy systems have sparse documentation and unpredictable side effects; the value is in knowing the system, not in reacting fast. Systems we did not build start with an assessment that maps them and produces the runbooks support then runs on.
Remote-first. Rates and commitment tiers are on the pricing page; response times are agreed per client.
Peer-reviewed research on advanced process control and fuzzy logic — published in indexed engineering journals.
What it is, what it should do, and where it hurts. One message is enough to start; assessment and rates are on the pricing page.
Prefer email? contact@imbra.io