Troubleshooting a machine should bepredictable.
simplifies machinery troubleshooting by bringing together controllers, electrical drawings, manuals, and technical documentation — reducing skill dependency and helping technicians of all experience levels answer one critical question:
Why isn’t the machine running?
How it worksHow it fits together
Ask the question. AIM finds the answer in your machine.
AIM is built around your specific equipment, not general knowledge about how machines should work. It uses your technical documentation, the controller’s live state, and historical alarm data to understand what is happening on your machine.
Monitoring
Agents for Industrial Machines
The answer comes from your plant, not from a model.
AIM does not rely on generalized knowledge from someone else’s machine. It works from your machine’s actual data, technical documentation, live controller logic and status, and alarm history. Every answer is traceable to its source, including the specific drawing sheet, logic rung, or event timestamp. This gives technicians more than an answer; it gives them the evidence to verify it and the confidence to act on it.
Read-only. On-premise. Nothing installed on the PLC.
Asked
“Why did the transfer pump trip?”
- from the alarms
- LI_101_HiHi latched 09:41:12
- from the controller
- P_Motor_1.Run 1 → 0 · LIT_101.PV 88.4 %
- from the documents
- MainRoutine :: 14 · sheet E-204 · manual p.63
Retrieved, not recalled. The model does not hold your machine in its weights — it looks it up, and shows you where it looked.
- 01
Your documents
Everything the machine came with, in one place that answers.
AIM organizes your machine information in two complementary ways. The graph database maps how the machine is connected, including tags, logic rungs, I/O channels, and electrical drawings. The vector database makes manuals, drawings, and other technical documentation searchable. Every question is checked against both, allowing AIM to provide answers that point directly to the relevant sheet, page, or logic rung rather than simply generating a response.
- 02
Your controller
What the machine is doing now, not what a drawing says it should.
Every controller-scope tag on a poll loop, classified into I/O groups, so live state sits alongside the documentation instead of in a separate system you have to correlate by hand. Read-only by construction: there is no write path in the codebase, the API is GET-only, and nothing is installed on the controller.
- 03
Your alarms
Which one actually fired, and when — not which ones exist.
AIM automatically discovers alarm information directly from the machine logic, eliminating the need for manual configuration and keeping alarm history clear and consistent. Each alarm becomes a starting point for troubleshooting, allowing AIM to trace it back to the logic rung that triggered it and the field device behind it.
What it does
Five things, in the order the product actually works.
- 01
Discover
The controllers, I/O and motor drives that belong to the machine — and nothing else.
Controllers, I/O cards, remote I/O, motor drives and the devices wired to them, including a CPU sitting behind a separate communications module rather than missed because of it. Scoped to the machine, not to the network: even on a flat plant network where everything is reachable, NemoClaw security is embedded in the agent’s runtime, so it only ever sees what matters.
- 02
Read
A live inventory of the machine, without anyone walking the floor to build it.
Full tag list on a poll loop, structured and classified into I/O groups. UDTs and structures are read in a single batched request rather than member by member.
- 03
Watch
A fault history worth reading a month later.
ALMA and ALMD instruction tags are discovered automatically and only state changes are written, so the history stays useful instead of filling with duplicates. The tag list is fingerprinted — download new logic and alarm discovery re-runs on its own.
- 04
Reconcile
Is the machine running the program you think it is? Most plants cannot say.
Upload the .ACD, AIM converts it to L5X and diffs the project against the live controller. Most plants cannot answer this question today, and no amount of historian data answers it.
- 05
Trace
One question instead of an afternoon between the drawings and the code.
A graph database links the PLC logic to the electrical drawings, joined on physical I/O channel addressing. Follow a tag to the rungs that drive it, to the other tags gating those rungs, to which of them is physically wired, to the channel and the sheet.
What the dependency costs
The real cost isn’t the repair — it’s the production lost during downtime.
AIM does not prevent failures or make repairs. It reduces the most time-consuming part of a machine stoppage: finding the root cause. This is especially valuable for electrical and control faults, where troubleshooting time can vary significantly depending on the technician’s experience and familiarity with the machine.
Where mean time to repair goes
- Detection
- 5–10%
- Diagnosis
- 40–60%
- Repair
- 20–35%
- Test and restart
- 10–15%
Diagnostic time is often spent chasing an intermittent sensor, a corroded connector, or an undocumented logic issue. How quickly it’s found depends heavily on the technician’s skills. Cut that troubleshooting time by more than half, and you can eliminate about 30% of electrical and controls downtime — without changing anything on the production line.
A model, not a quote. It applies published bottling benchmarks and standard reliability ratios to a 200-employee plant running continuously. It is not your plant. Four numbers would make it yours:
- Revenue or margin per hour on the lines in question — the single biggest driver of the model
- CMMS or MES failure codes tagged electrical, mechanical or controls
- The real operating schedule, in shifts and days per week
- Current mean time to repair, broken out by detection, diagnosis, repair and restart
200-employee bottling plant · continuous
- 01~893 hrs
Unplanned downtime a year
10.2% of an 8,760-hour year — the rate published for a 200-person brewery running three filling lines and two canning sealers.
- 02225–310 hrs
Electrical and controls share of it
25–35% in bottling, against 15–25% in general manufacturing. Line speed, dense servo synchronisation, washdown moisture and frequent changeovers all push it up.
- 03$2M–$5M
What those hours cost
At $8,000–$25,000 an hour of lost production. For most plants that is two to three times the entire maintenance budget.
- 04$600K–$1.5M
Recovered from a 60% cut in diagnosis
Cutting diagnosis by 60% takes about 30% off total electrical and controls downtime. No failure has been prevented; the fault was simply found sooner.
Too many documents, simplified
Redefining the 10-Step Lean Troubleshooting Process
Every plant follows a similar troubleshooting process, whether it is formally documented or not. Much of that process involves searching for the same information across separate systems: the live controller, PLC project, electrical drawings, and machine manuals. This is where valuable time is lost and troubleshooting can vary from one technician to another. AIM brings those sources together, turning multiple searches into a single question and simplifying the entire troubleshooting process.
Today
10 steps
- 01Ensure safety
- 02Capture the fault
- 03Check the controller state
- 04Isolate the layer
- 05Verify at the field device
- 06Cross-reference the schematic
- 07Correct the fault
- 08Remove forces and verify
- 09Log the event
- 10Root cause, if recurring
With AIM
6 steps
- 01Ensure safety
- 02Ask
The alarm and the moment it latched, the controller state around it, the rung gating the tag, the channel it is wired to and the sheet it is drawn on. One question, and every part of the answer cited.
- 03Verify at the field device
The same walk with the same meter — but you know which terminal before you leave the panel.
- 04Correct the fault
- 05Remove forces and verify
- 06Root cause, if recurring
Starts from a record, because recurrence is visible rather than argued about.
4 → 1
Four steps become one question
Capturing the fault, establishing controller state, isolating the layer and cross-referencing the schematic are four searches across four systems. They are one query against one graph.
1 → 0
One stops being a step
The alarm, its timestamp, the state around it and the path that was followed are recorded as they happen. Nobody writes the log from memory at the end of a shift.
4
Four do not change
Lockout, metering at the device, the repair itself and the verification cycle. Two of those are electrical safety and one is change control — AIM has no write path to a controller, so it could not touch them if asked.
What shortens troubleshooting, and which parts are not ours
Five things shorten troubleshooting time. AIM is three of them.
- AIM
Alarm history with plain-language fault codes
Alarms are discovered from the logic and written on state change, so the history is still readable when someone needs it.
- AIM
Shorten detection to diagnosis
Live state, alarm history, drawings and manuals answer as one thing instead of as three systems and a filing cabinet.
- AIM
Standard troubleshooting guides per fault type
The graph is that guide, built from the plant’s own machines and drawings rather than written by hand and then left to go stale.
- Partly
Cross-trained technicians
It removes the bottleneck on one specialist. It does not train anybody — that is still a staffing decision.
- Yours
On-site spares for the top failure modes
AIM knows the bill of materials. What to stock, and what stocking it costs, is a plant call.
Before you approve it
Four answers, before anyone asks how it works.
Read-only, by construction
AIM cannot change a machine, so adopting it does not touch your management-of-change process. There is no write path in the codebase — discovery and reads only — and the API exposes twelve routes, every one of them a GET.
On-premise
No plant data leaves the building and no vendor sees your drawings or your logic. Reasoning runs on hardware at your site, with no cloud dependency and no outbound connection required to operate.
Sandboxed agent
The agent cannot reach your network, only AIM. It runs inside NemoClaw, an isolated runtime whose network policy permits GET requests to the AIM API and nothing else.
Docker, and only Docker
Reversible in an afternoon. Nothing is installed on the host and nothing on the controller — remove the stack and the folder and it is gone, data included.
What the money actually buys
Not “these tags exist”. This rung’s condition comes from that input point, on that sheet.
A graph database links your PLC logic to your electrical drawings. The two are joined on physical I/O channel addressing — the mapping routines in the project reference the same channels the drawings terminate.
That turns a fault into a path you can follow instead of a tag name you have to go and look up. A vector database over device manuals and vendor documentation sits alongside it, so the answer comes with the page that explains it.
Answering it requires the project file, the drawings, and a way to join them — which is why no amount of historian or monitoring data gets you there, and why this is the part a competitor cannot simply add.
Multi-hop traversal
- 01A tag you care about
- 02the rungs that drive it
- 03the other tags gating those rungs
- 04which of them is physically wired
- 05the channel, and the sheet
What it supports
Rockwell / Allen-Bradley, today
ControlLogix and CompactLogix over EtherNet/IP, including controllers reached through a separate communications bridge. Remote I/O, motor drives and adapters are inventoried in the same scan.
Siemens S7-1200 / 1500, planned
Via OPC UA. Not built yet — and we would rather tell you that here than in the third week of a project.
And the rest of the job
AIM is built by the controls house that can also integrate it, build the panel, wire it and commission it.
EPIC is Electrical, Process Instrumentation and Controls. AIM is our first product; everything below is a service we deliver — which is the part a software vendor cannot offer you.
Control Systems Integration
PLCs, motor drives, instrumentation and networks unified into one control platform.
OT Networking
Segmented industrial networks built to Purdue model practice — connected without being exposed.
UL508A Panel Fabrication
In-house builds to UL508A, from a single enclosure to a production run.
PLC Programming
Logic written and commissioned for Allen-Bradley, Siemens and other platforms.
HMI / SCADA Development
Operator interfaces and supervisory systems, with historian and alarm management.
Field Wiring & Installation
On-site wiring and terminations by the team that engineered the panels.
Startup & Commissioning
Loop checks, functional testing and troubleshooting to bring systems online.
AI-Driven Industrial Analytics
Predictive maintenance and anomaly detection layered on your historian data.
Thirty minutes, and your controls group will tell you if it is real.
AIM is ready to deploy today. The demo runs against real hardware, needs nothing sent from your plant, and is worth putting your most sceptical engineer in front of.