# AI for Litmus Edge: Machine Data Collected Locally, Answered Alongside Your ERP

> Source: https://netray.co/erp-ai/litmus-edge-ai-erp
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for 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.

## Kind

platform

## Erp Family

mfg-systems

## Erp Products

- Litmus Edge

## Industries

- Manufacturing
- Automotive
- Electronics
- Food and Beverage

## Region

Global

## Persona

OT/IT Integration Lead

## Eyebrow

Litmus Edge + on-prem AI

## Intro

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.

## Pain Points

### Clean machine data, no business meaning

**Detail:** 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

**Detail:** 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

**Detail:** 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

**Detail:** Some plants have intermittent or restricted uplinks, so any AI feature requiring a cloud model is unreliable or disallowed.

### Dashboards proliferate

**Detail:** Each new question becomes another dashboard in a downstream tool, which then needs maintenance.

## Use Cases

### Machine state by work order

**Description:** Report run, idle and fault time per production order by joining published state tags with ERP order times.

**Erp Objects:** Production orders, operation confirmations, work centers; machine state tags

**Outcome:** Order-level utilisation views that previously needed manual timestamp matching.

### Tag and device discovery

**Description:** Search the Litmus Edge device and tag model in plain language and explain units and meaning.

**Erp Objects:** Device definitions, tags, digital twin models; equipment master

**Outcome:** Quicker onboarding for engineers and fewer duplicated tags.

### Cycle time versus standard

**Description:** Compare observed cycle signals to routing standards and flag operations where standards look stale.

**Erp Objects:** Routings, standard times; cycle count and timing tags

**Outcome:** A ranked list for industrial engineering to review.

### Condition watch with maintenance history

**Description:** Present rising temperature or current trends beside past maintenance and open orders.

**Erp Objects:** Maintenance orders, equipment history; sensor tags

**Outcome:** Technicians see context before deciding on action; approvals stay with people.

### Product changeover analysis

**Description:** Measure changeover duration from machine states and group by product family pairs.

**Erp Objects:** Production order sequence, product groups; state tags

**Outcome:** Data for scheduling and SMED discussions grounded in actual durations.

### Scrap and parameter correlation

**Description:** Surface parameter windows around scrap postings for engineer review.

**Erp Objects:** Scrap and quality records; process parameter tags

**Outcome:** Candidate drivers to investigate; correlation does not prove cause.

### Edge data quality reporting

**Description:** Report stale tags, flat-lined sensors and missing data by line to the OT team.

**Erp Objects:** Device connection status, tag quality; equipment master

**Outcome:** Earlier detection of silent data gaps before they undermine analysis.

## Architecture

**Overview:** 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.

**Layers:**

#### Edge data publication

**Detail:** 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.

#### Plant data store

**Detail:** A time series or relational store holding the published values with retention suited to the questions asked.

#### ERP read path

**Detail:** Read-only ERP views for orders, routings and maintenance, mapped to devices by equipment key.

#### Local inference

**Detail:** Open-weight models on a plant GPU server, usable without internet access.

#### Governance

**Detail:** Logged queries, role-based visibility and human approval for any write-back.

## Deployment Options

### Fully on-prem plant server

**Fit:** Defense, regulated and low-connectivity plants

**Detail:** Broker, store, ERP read path and model all inside the plant network.

### Multi-site with central model

**Fit:** Companies with several plants

**Detail:** Each site publishes to a local store, and a central private cloud model queries site stores through controlled links.

### Hybrid with cloud history

**Fit:** Plants already forwarding to cloud analytics

**Detail:** Live questions served locally and long-range analysis delegated to the cloud store, subject to data policy.

## Compliance

### Edge to enterprise data flow is one-directional where possible, with the AI tier outside the control zone.

**Framework:** IEC 62443

### Network segmentation and monitoring for the added servers consistent with ICS guidance.

**Framework:** NIST SP 800-82

### On-prem model and data store let the customer keep controlled technical data within its own boundary.

**Framework:** ITAR / CMMC (customer obligation)

### Evidence retrieved from machine data is stored read-only and referenced in quality records.

**Framework:** IATF 16949 / AS9100 traceability

## Integration Notes

- 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.

## Product Fit

### Custom build

**Why:** Litmus Edge is a DataOps platform, so the integration is a custom read path, tag catalogue and private model deployment.

### ERPray

**Why:** Adds grounded ERP answers with shown queries and roles to combine with machine data.

## Engagement

### Data review

**Duration:** 1-2 weeks

**Deliverables:**

- Published tag inventory
- Equipment key plan
- Network zone design
- Priority questions

### Pipeline

**Duration:** 2-3 weeks

**Deliverables:**

- Broker or store configured
- Retention rules
- ERP read views
- Tag catalogue

### Pilot

**Duration:** 3-5 weeks

**Deliverables:**

- Selected lines
- Evaluation questions
- Call transparency
- Audit logs

### Expansion

**Duration:** 2-4 weeks

**Deliverables:**

- More devices and sites
- Monitoring
- Runbook
- Hardware sizing review

## Buyer Questions

- 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?

## Faq

### Does the AI connect to PLCs?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

litmus edge ai, litmus edge erp integration, litmus edge llm, industrial dataops ai, litmus edge on-prem generative ai, litmus edge mqtt erp, litmus edge digital twin ai, edge platform erp integration manufacturing, litmus edge opc ua ai, litmus automation ai, litmus edge sap integration, air-gapped industrial ai

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json