Imbra is an engineering-led company helping industrial plants, device manufacturers, protocol vendors and automation teams solve the software between the plant floor and IT. We build, test, integrate, and support protocol stacks, data flows, historians, and legacy systems — with direct access to the founder.
Expand a service: the problem, what we do about it, and where we have done it before.
Protocol stacks, device communication, emulators and test tooling for the software that talks to industrial devices.
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.
You receive the test suite, the agreed scenarios, reproducible results and instructions to run them. Simulation complements hardware testing. It does not prove full hardware compatibility or replace formal certification.
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.
PLC software and the data paths that connect PLCs, SCADA and laboratory systems to IT platforms.
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.
Before building, we agree the sources, the target, the tag mapping, the timestamps and what happens when a link fails. You receive the integration components, the mapping specification, validation evidence and operating guidance. Third-party licences are not included.
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.
Historians, legacy modernisation and the long-term operation of the systems that hold plant data.
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, the vendor and the integrator point at each other, and your team is 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.
Intermittent faults rarely appear on request. We work in a fixed order: reproduce the failure, capture it with existing logs or dedicated monitoring, and where neither works, isolate it layer by layer, from the application down to the physical link. You receive a documented root cause (a 5 Whys and fishbone analysis backed by captured evidence), corrective actions in priority order and an agreed way to validate the fix.
The rule is understand before acting. Legacy systems have sparse documentation and unpredictable side effects, so the value is in knowing the system, not in reacting fast. We start with a free assessment of your needs and our mutual fit. Where code, logs or architecture need investigation, we agree the scope, deliverables and price before starting paid work. For familiar systems, we use existing knowledge and agree any additional checks needed.
Rates and commitment tiers are on the pricing page. Response times are agreed per client. A guarantee of zero downtime is not included.
Every engagement follows the same four steps. You always know which one you are in, what comes next, and what it costs.
A free conversation about your needs, goals, constraints and working expectations helps both sides decide whether to work together, without obligation.
Choose hourly support with reserved capacity or fixed-price project delivery. Any technical investigation has its scope, deliverables, time limit and price agreed before it starts; delivery terms are then agreed in a Statement of Work.
Work runs in short cycles with written progress reports; architecture is documented as it is decided, and nothing is done until you sign off.
After go-live, committed hours cover escalation support and further work, at a rate set by how long you commit.
AI tools are part of how we deliver, not a service we sell. What we think shapes how we work. What we commit to holds on every engagement.
Progress is software that runs and passes its tests, not hours spent.
A fix in one layer can break another, so we follow the data from the device to the IT platform first.
When the risk is unknown, a short paid investigation comes before a fixed price.
Industrial software outlives the people who wrote it; what is not written down leaves with them.
We use AI tools to draft code, work through unfamiliar specifications and legacy sources, and try alternatives quickly, so working software reaches you sooner and more time goes into your system's edge cases.
We produce tests and documentation with the code and keep them current as it changes, deriving test cases directly from product and protocol specifications.
An engineer reviews every change and is accountable for it. Nothing is delivered until you have signed it off.
Source code, tests, architecture documentation and runbooks are yours and transferable. Another team can take over without us.
Tell us what is failing. The free assessment checks whether we are a good fit, without obligation. Any technical investigation is agreed and priced separately. Rates are on the pricing page.
Prefer email? contact@imbra.io