Case Study: Industrial Automation, an Optense Product

ICS replaces a rigid factory PLC with software. It talks to any Modbus machine, monitors it live, and runs your rules. An Optense product, live for a year.

Running on Unilever's floor for over a year, no dedicated PLC required.
The ICS app showing a sensor reading, its prediction, and an anomaly score
About the Project

ICS (Industry Control System) is one of Optense's products, and the one running quietly in the background at real factories. After we piloted SCM with Unilever, their engineering team asked whether I could talk to their machines over Modbus, A long-standing protocol for communicating with industrial sensors, relays, and controllersreading and changing the state of the sensors, relays, and actuators on the floor. That question became ICS. It connects to industrial machines, reads them in real time, and runs automation rules you define in software. It has been running on many of Unilever's machines for over a year.

Systems EngineeringRustIndustrial AutomationML
The ICS architecture: machine, controller, AI processor, and optional server
The Monitoring Gap

Factories already automate with PLCs, and they work, but they are rigid. A PLC Programmable Logic Controller, the dedicated hardware that traditionally automates industrial machinescan raise an alarm when a value crosses a fixed limit, yet it cannot learn, cannot adapt, and cannot be extended without rewiring. Unilever's engineering head put it plainly. Their PLCs were too fixed, adding capabilities was expensive and vendor-locked, and reconfiguring them meant wrestling with confusing hardware. What they wanted was simple. Full visibility into every instrument and the freedom to change how the floor behaves without the hassle.

A machine and the instruments ICS talks to, its sensors, relays, and actuatorsA machine and the instruments ICS talks to, its sensors, relays, and actuators
Software-Defined Control

ICS gives a plant the same core job as a PLC, condition monitoring and automated responses, but with the logic living in software instead of fixed hardware. It connects to any Modbus instrument without replacing what is already there, and it lets an operator write rules. When a sensor reading crosses a point, change a relay or an actuator. Updating a PLC rule means calling an engineer. Updating an ICS rule means changing a setting. In one example, three chillers cooling a production line ran on a fixed daily timer, burning energy even when the reservoir was already cold. ICS replaced the timer with a rule per chiller that responds to the actual temperature. By our estimates, running them only when the temperature genuinely calls for it could cut their power use by around 40 percent and add roughly a year and a half to each chiller's life through the reduced wear.

The chiller rules and the estimated energy and lifespan gainsThe chiller rules and the estimated energy and lifespan gains
The Hard Part

Reading a machine over Modbus was the easy part, a week or two of work. The trap was that these instruments are shared. Other systems on the floor use them too, so I could not hold a connection open, I had to take it, read, and release it. My first design gave each instrument its own thread that opened a connection, read the state, and dropped it. On my machine it was flawless. In the plant, it would run for a day or two and then quietly stop reading, with nothing in the logs. I chased it for months. I added delays, which made it last longer before halting. I blamed the Raspberry Pi and moved to a beefier computer, and it still happened. In the end I threw the whole reading mechanism out and rebuilt it around a single priority queue. State-changing commands jump to the front, and everything else round-robins through the registered instruments one at a time. That is the version that has run without halting for over a year.

The priority task queue that replaced the thread-per-instrument design
The AI Layer

Because the rules live in software, ICS can grow an AI layer that the same rule engine can act on. The first piece is anomaly detection. A single sensor reading has no memory, so I turn it into context. The recent average tells the model what normal looks like right now, the standard deviation tells it how volatile things are, the change from the last reading separates a gentle drift from a sudden spike, and the hour of day captures the fact that machines follow human schedules. A gradient-boosted tree then predicts what the next reading should be, and the gap between that prediction and the real value is the anomaly score. The threshold adapts to each instrument, set at three times its training RMSE, Root Mean Square Error, a measure of how far a model's predictions land from the real valuesso a naturally jumpy chiller gets a wider tolerance automatically. It all runs on its own dedicated device on-site, training and running its models on demand, per instrument, with no cloud and no dependency on any single vendor's platform.

The four features the model uses: recent average, volatility, change, and hourThe anomaly graph, comparing the predicted reading against the actual one
Outcome

The core of ICS, the monitoring and the rules, has been stable on Unilever's floor for over a year, which for an industrial system is the number I am proudest of. The AI layer is newer. I have built and tested it locally, and it is not yet part of that production deployment. The same design also means a use-case like ALS, using vision to decide an action, could live inside ICS rather than as a separate product. Object detection feeding the rule engine is the next step. The idea behind all of it is that industrial intelligence does not require a new facility. It just needs the right software running in the one you already have.