Litmus Edge + on-prem AI
AI for Litmus Edge: Machine Data Collected Locally, Answered Alongside Your ERP
Short answer
AI for Litmus Edge uses the edge platform's normalised device data, whether from OPC UA, Modbus, Siemens S7 or EtherNet/IP sources, and joins it with ERP orders and maintenance records so engineers can ask questions in plain English. Because Litmus Edge runs on the plant network, the whole stack including the language model can stay on-prem and offline-capable.
- ERP
- Litmus Edge
- Industries
- Manufacturing, Automotive, Electronics, Food and Beverage
- Written for
- OT/IT Integration Lead
Litmus Edge is an industrial DataOps platform that runs on edge hardware or virtual machines inside the plant. It connects to PLCs and machines through device drivers, normalises tags, applies processing, and publishes data to destinations such as MQTT brokers, databases and cloud services. Its role is to make machine data usable before it goes anywhere else.
That position is attractive for AI because the data is already local, cleaned and named. But Litmus Edge deliberately does not know about orders, customers or maintenance plans. Those sit in the ERP, so a question such as which jobs ran on the machines that showed rising current last week still needs two systems and a person to link them.
Plants choosing Litmus Edge often do so to keep control of data flows, and that preference extends to AI. A language model that runs on a plant server, reads published data and ERP views, and never calls a public API fits the same posture.
This page explains how to connect an AI layer to Litmus Edge outputs, what to keep at the edge, and when Litmus' own analytics and flows are enough.
What usually gets in the way
The problems we hear most from ot/it integration lead teams running Litmus Edge.
Clean machine data, no business meaning
Tags are normalised and published, but the association to work orders, part numbers and quality outcomes is missing and added later in ad hoc ways.
Many devices, many tag naming styles
Different controllers and drivers expose different names and units. Even after modelling, fleet-wide questions need careful mapping.
OT and IT teams own different halves
OT teams know the tags, IT teams know the ERP. Questions that cross the boundary wait for whoever has time to bridge them.
Connectivity limits
Some plants have intermittent or restricted uplinks, so any AI feature requiring a cloud model is unreliable or disallowed.
Dashboards proliferate
Each new question becomes another dashboard in a downstream tool, which then needs maintenance.
Where AI earns its place in Litmus Edge
Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.
Machine state by work order
Report run, idle and fault time per production order by joining published state tags with ERP order times.
Touches: Production orders, operation confirmations, work centers; machine state tags
Outcome: Order-level utilisation views that previously needed manual timestamp matching.
Tag and device discovery
Search the Litmus Edge device and tag model in plain language and explain units and meaning.
Touches: Device definitions, tags, digital twin models; equipment master
Outcome: Quicker onboarding for engineers and fewer duplicated tags.
Cycle time versus standard
Compare observed cycle signals to routing standards and flag operations where standards look stale.
Touches: Routings, standard times; cycle count and timing tags
Outcome: A ranked list for industrial engineering to review.
Condition watch with maintenance history
Present rising temperature or current trends beside past maintenance and open orders.
Touches: Maintenance orders, equipment history; sensor tags
Outcome: Technicians see context before deciding on action; approvals stay with people.
Product changeover analysis
Measure changeover duration from machine states and group by product family pairs.
Touches: Production order sequence, product groups; state tags
Outcome: Data for scheduling and SMED discussions grounded in actual durations.
Scrap and parameter correlation
Surface parameter windows around scrap postings for engineer review.
Touches: Scrap and quality records; process parameter tags
Outcome: Candidate drivers to investigate; correlation does not prove cause.
Edge data quality reporting
Report stale tags, flat-lined sensors and missing data by line to the OT team.
Touches: Device connection status, tag quality; equipment master
Outcome: Earlier detection of silent data gaps before they undermine analysis.
Reference architecture
Litmus Edge publishes normalised data to a plant database or message broker. A private orchestrator reads from that destination and the ERP read-only, and a locally hosted model plans bounded queries.
- 1
Edge data publication
Litmus Edge configured to publish selected tags to an MQTT broker or database inside the plant, so the AI layer never talks to PLCs directly.
- 2
Plant data store
A time series or relational store holding the published values with retention suited to the questions asked.
- 3
ERP read path
Read-only ERP views for orders, routings and maintenance, mapped to devices by equipment key.
- 4
Local inference
Open-weight models on a plant GPU server, usable without internet access.
- 5
Governance
Logged queries, role-based visibility and human approval for any write-back.
Integration notes for your ERP team
- Configure Litmus Edge to publish only the tags needed, to a broker or database inside the plant, not directly to the AI service.
- Keep topic naming and units consistent across devices and document the convention.
- Use an equipment ID on each device model so the ERP join is deterministic.
- Set retention in the plant store deliberately; raw high-frequency data may need downsampling.
- Do not allow the AI layer to write to devices or flows; keep control paths separate.
- Confirm current Litmus Edge destinations and APIs with product documentation for your version.
Deployment options
Fully on-prem plant server
Defense, regulated and low-connectivity plants
Broker, store, ERP read path and model all inside the plant network.
Multi-site with central model
Companies with several plants
Each site publishes to a local store, and a central private cloud model queries site stores through controlled links.
Hybrid with cloud history
Plants already forwarding to cloud analytics
Live questions served locally and long-range analysis delegated to the cloud store, subject to data policy.
Compliance and data control
How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.
IEC 62443
Edge to enterprise data flow is one-directional where possible, with the AI tier outside the control zone.
NIST SP 800-82
Network segmentation and monitoring for the added servers consistent with ICS guidance.
ITAR / CMMC (customer obligation)
On-prem model and data store let the customer keep controlled technical data within its own boundary.
IATF 16949 / AS9100 traceability
Evidence retrieved from machine data is stored read-only and referenced in quality records.
How an engagement runs
Phase 1 . 1-2 weeks
Data review
- -Published tag inventory
- -Equipment key plan
- -Network zone design
- -Priority questions
Phase 2 . 2-3 weeks
Pipeline
- -Broker or store configured
- -Retention rules
- -ERP read views
- -Tag catalogue
Phase 3 . 3-5 weeks
Pilot
- -Selected lines
- -Evaluation questions
- -Call transparency
- -Audit logs
Phase 4 . 2-4 weeks
Expansion
- -More devices and sites
- -Monitoring
- -Runbook
- -Hardware sizing review
Questions to ask any vendor, including us
A short list that separates real Litmus Edge AI work from a chatbot demo.
- Does the AI layer read from Litmus Edge destinations or talk to devices directly?
- Can the entire stack run without internet access?
- How are tags tied to ERP equipment IDs?
- How is high-frequency data downsampled for questions?
- Who owns tag naming and unit conventions?
- How do we prevent any path to controllers?
- What GPU hardware is needed at each site?
- When are Litmus Edge flows and analytics enough?
Frequently asked questions
Does the AI connect to PLCs?
No. Litmus Edge handles device connectivity and publishes normalised data. The AI layer reads from a plant broker or store and from read-only ERP views. Keeping it away from controllers is a deliberate design choice that simplifies security review and avoids any chance of control interference.
Can it work offline?
Yes, if the model, store and ERP read path are all inside the plant network. Open-weight models served locally do not need internet access once the weights are installed. Updates are applied through a controlled offline process, which suits air-gapped and low-connectivity sites.
How is machine data tied to orders?
Through an equipment or work center identifier carried on each Litmus device model and mapped to the ERP, plus aligned timestamps. Without a deterministic key the result is unreliable, so the first project step is usually cleaning up that mapping rather than prompting the model.
Does this replace Litmus analytics?
No. Litmus flows and analytics are the right place for real-time processing at the edge. The AI layer is for after-the-fact questions that cross machine and ERP data. Keep latency-sensitive logic in the edge platform.
What hardware is required?
A plant server with a GPU sized to the chosen model and expected concurrent users. Smaller open-weight models can handle many structured query tasks. Sizing depends on model, context length and concurrency, and is worth estimating before purchase.
Can it control machines or change flows?
No, and it should not. Read-only access keeps the AI tier outside the control path. Any suggested change, such as a maintenance request, is drafted for human approval in the proper system.
Is it worth it with only a few connected machines?
Probably not. With a small number of devices, simple dashboards answer most questions. The value grows with device count, naming inconsistency and the number of cross-system questions engineers ask each week.
Related guides
AI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
RAG + SQL + permissionsA Private LLM Grounded on Your ERP Data
How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.
On-prem AI, any ERP, A&DOn-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing
A hub guide to on-prem AI across SAP, Infor LN, Costpoint, IFS, and Oracle EBS for aerospace, defense, and electronics manufacturers under ITAR, CMMC, and AS9100.
SyteLine + air-gapped AIAn Air-Gapped Private LLM for SyteLine, Built for Defense Suppliers
Deploy a private LLM on an air-gapped network alongside Infor SyteLine for defense suppliers: no internet egress, ITAR and CMMC-aware architecture.
SAP PM/EAM + on-prem AIAI for SAP Plant Maintenance: Notifications, Work Orders, and Predictive Signals
AI grounded on SAP PM data that triages notifications, drafts work orders, standardizes failure codes, and flags predictive maintenance signals, on-prem.
Opcenter Execution + private AIAI for Siemens Opcenter Execution MES, Running Inside Your Own Network
Add private, grounded AI to Siemens Opcenter Execution MES: ask questions over lots, work orders, nonconformances and genealogy without leaving your network.
Plan it with numbers
OEE Calculator (Overall Equipment Effectiveness)
Break your Overall Equipment Effectiveness into availability, performance, and quality, and see how far you sit from the 85% world-class benchmark.
Free ToolManufacturing Downtime Cost Calculator
Combine lost contribution margin, idle labor, and absorbed overhead into a defensible monthly and annual downtime cost - with recovery effects modeled.
Free ToolSelf-Hosted LLM Hardware Estimator
Estimate the VRAM footprint, GPU count, and hardware budget required to self-host an open-weight LLM with your concurrency and context needs.
GuideIoT Sensor to ERP Data Integration for Manufacturing
Build reliable IoT sensor to ERP data pipelines for manufacturing. Covers MQTT, edge processing, data normalization, and ERP API ingestion patterns.
GuideEdge Computing for Manufacturing ERP Integration
Deploy edge computing for manufacturing ERP integration. Covers edge gateway selection, local processing, latency reduction, and offline-capable ERP operations.
GuideAir-Gapped LLM Deployment Patterns That Actually Work
Air-gapped LLM deployment patterns that work: offline model transfer, update workflows, monitoring without telemetry, and CMMC-ready architectures.
Talk it through with an engineer who knows Litmus Edge
Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.