---
title: Industry vertical solutions
slug: solutions/industry-vertical-solutions
docTags: 
createdAt: 2026-08-17T14:41:28.427Z
---

Solution demos for a working plant that configures Litmus Edge and then runs against it. Every one brings up an operator view, a live industrial protocol server that the Edge polls, and a set of scenarios that can be injected on demand.

They are demonstrations rather than production systems, but nothing on the Litmus Edge side is simulated: real DeviceHub devices and tags, real Digital Twin models and instances, real Analytics processors, over the protocol the industry uses.

## Solutions

| Solution                                                       | Industry              | Devices and tags                | Protocol                           |
| -------------------------------------------------------------- | --------------------- | ------------------------------- | ---------------------------------- |
| [Bottling line](docId\:OT5kfuTtHgw1Hzg_hANuB)                  | Food and beverage     | 6 devices, 94 tags              | Modbus TCP                         |
| [Bioreactor suite](docId\:E4QZQM3SPssunnGM1h3YY)               | Pharmaceuticals       | 5 devices, 94 tags              | Modbus TCP                         |
| [Collection system](docId:1bGLlAQ8b2H8Q-mu-XzDa)               | Water and wastewater  | 9 devices, 274 tags             | DNP3                               |
| [Vision inspection](docId:7Qqbn_p9STTq7CX-S1UHj)               | Food and beverage     | 1 device, 15 tags               | Modbus TCP and NATS                |
| [Body shop framing line](docId\:u1pKuOwr7J5eSedC_pyjC)         | Automotive            | 7 devices, 181 tags             | Modbus TCP and Open Protocol       |
| [Rotating equipment reliability](docId\:z1yepHlFSrpVcKYjIB-Vn) | Power and utilities   | 6 machines, 90 tags             | Sparkplug B over MQTT              |
| [Grid substation](docId\:itFwzpZXXe6HjtGNbjJBK)                | Power and utilities   | 9 devices, 69 points            | IEC 60870-5-104                    |
| [Steel mini-mill](docId\:mDhvkjDA4DcdKUUiLsMP9)                | Metals                | 8 devices, 122 tags             | OPC UA                             |
| [Aerospace machining](docId\:K39O52gUuTcxLsNomAj93)            | Aerospace and defence | 7 machines, 133 tags            | MTConnect                          |
| [Gas gathering system](docId\:M_ZNwL_3xqma6GDMeIkKZ)           | Oil and gas           | 8 flow computers, 121 registers | Enron Modbus                       |
| [Paper machine](docId:_dDjzflyKudYvCIsBWe2H)                   | Pulp and paper        | 8 sections, 118 nodes           | OPC UA                             |
| [Packaging hall](docId\:B8FznZwcQCRLmqmR5eldE)                 | Food and beverage     | 18 devices, 293 tags            | Modbus TCP                         |
| [Injection molding cell](docId\:wvey6e1cDhz5HRhcP_Gwx)         | Plastics and rubber   | 8 devices, 158 tags             | OPC UA (EUROMAP 77) and Modbus TCP |
| [Tire manufacturing](docId\:j9M8A0RF0CaYwmQ8m2ekl)             | Rubber and tire       | 9 devices, 357 tags             | EtherNet/IP                        |
| [CNC machine shop](docId\:yw_wLGADrqe-tVHj0yEWQ)               | Industrial machinery  | 10 machines, 300 tags           | S7comm, FOCAS2 and LSV2            |

[Solutions provisioner](#) is a control panel that starts and stops all fifteen from one page and connects them to a Litmus Edge once rather than one at a time. It is optional; each solution runs on its own.

The solutions are designed to run side by side. Ports do not collide, and all fifteen against one Litmus Edge is 119 devices.

## Requirements

- **Litmus Edge 4.0.x**, reachable over HTTPS from the host running the solution
- **An API token** for that Edge, or a username and password, or a client id and secret
- **Docker**, and Docker Compose for the compose deployment
- **A network path in both directions.** See the note on `SIM_HOST` below

## Required configuration values

Each solution takes three values, either directly in its compose file or in a `.env` file beside it.

| Value            | Purpose                                                                                                                |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `EDGE_URL`       | the Litmus Edge to configure, for example `https://10.0.0.5`                                                           |
| `EDGE_API_TOKEN` | a token for that Edge. Alternatively `EDGE_USERNAME` and `EDGE_PASSWORD`, or `EDGE_CLIENT_ID` and `EDGE_CLIENT_SECRET` |
| `SIM_HOST`       | the address the Edge connects to in order to reach the solution                                                        |

`SIM_HOST` requires attention. The solution serves an industrial protocol and Litmus Edge connects to it, so the Edge needs an address it can route to. Leave it as `auto` when the solution runs on the Edge itself or with host networking, and the address is derived from the route to the Edge. Otherwise set it to the address of the host running the solution, as the Edge sees it.

An incorrect value fails quietly: the devices are created, they report as online, and no tag ever reads a value, because the address written into the template is one the Edge cannot reach. Each solution refuses to apply a template whose address is obviously unreachable and reports why.

## Deploy

Each solution ships two ways. Use the registry if the host can reach Google Artifact Registry, and the downloaded archive if it cannot. Both run the same image and take the same three values.

### Option 1: pull from the registry

Images are published to `us-docker.pkg.dev/litmus-customer-facing/litmus-solutions`. Litmus supplies a read-only registry credential separately.

```bash
cat key.json | docker login -u _json_key --password-stdin https://us-docker.pkg.dev
docker compose up -d
```

### Option 2: load the downloaded archive

Each solution's page on portal.litmus.io carries a `.tar.gz` under **Downloads**. The archive is the container image, not a source bundle, and needs no registry access.

```bash
docker load -i <solution>-0.5.1-amd64.tar.gz
```

`docker load` prints the image it added, for example:

```javascript
Loaded image: us-docker.pkg.dev/litmus-customer-facing/litmus-solutions/pulp-paper-demo:0.5.1
```

That is the same reference the compose file names, so the compose file works offline after the load, with no `docker login`:

```bash
docker compose up -d
```

To run a solution without Compose, pass the three values on the command line. Ports and image name come from the solution's own page:

```bash
docker run -d \
  --name <solution> \
  --restart unless-stopped \
  -p 4020:4020 \
  -p 5030:5030 \
  -e EDGE_URL=https://10.0.0.5 \
  -e EDGE_API_TOKEN=your-token \
  -e SIM_HOST=10.0.0.9 \
  us-docker.pkg.dev/litmus-customer-facing/litmus-solutions/<image>:0.5.1
```

One solution cannot be run this way. Rotating equipment reliability is two containers, a simulator and an MQTT broker, and requires its compose file.

Open the operator view on the solution's UI port. Within about a minute the Edge is configured and the page fills in.

## Order of operations

1. Start the Litmus Edge, and have an API token or a login for it.
2. Start the solution, with `EDGE_URL` and a credential in its environment or its `.env`.
3. The solution configures the Edge itself on startup, which takes 30 to 60 seconds. With `APPLY_ON_START=0`, press **Apply to Edge** on its page instead.
4. Open the operator view once the Edge carries its devices.

**Until the Edge carries a solution's devices, its page shows a waiting panel and the simulation does not tick.** That is deliberate: no number appears on screen until Litmus Edge is verified to hold the devices and poll them, so nothing can be mistaken for data that never made the trip.

## If it does not come up

| What you see                                                         | What it means                                                 | What to do                                                                          |
| -------------------------------------------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| the waiting panel, "no Litmus Edge configured"                       | the container has no `EDGE_URL` or credential                 | stop it and start it again with them; a running container cannot be told afterwards |
| the waiting panel, "the Edge does not carry this solution's devices" | the templates have not been applied                           | press **Apply to Edge**, or start with `APPLY_ON_START=1`                           |
| devices on the Edge, every tag reading `Failed`                      | `SIM_HOST` is an address the Edge cannot reach                | set it to this host's address as the Edge sees it, and apply again                  |
| the page loads and no value ever changes                             | the simulation is gated, which is the first row or the second | check `/health`: `sim_time` stays at 0 while the gate is shut                       |

## What each solution creates on Litmus Edge

With `APPLY_ON_START` at its default of `1`, a solution configures the Edge on startup:

- **DeviceHub** devices and their tags, pointed at the protocol server the solution runs
- **Digital Twin** models and instances for the equipment
- **Analytics** groups and processors behind the KPIs the operator view shows

This takes 30 to 60 seconds, because Litmus Edge restarts DeviceHub while it applies. The UI is available immediately and reports progress.

Set `APPLY_ON_START=0` to run the simulator without writing to an Edge.

Each solution can also remove exactly what it created, so a shared Edge can be returned to its previous state.

## Ports

Each solution serves its operator view on **401x** or **402x** and its industrial protocol on **502x**, or on **51xx** when it needs a port per controller, so they can run at once. None of these collide with Litmus Edge's own services.

| Solution                       | Operator view | Protocol                         |
| ------------------------------ | ------------- | -------------------------------- |
| Solutions provisioner          | 4009          |                                  |
| Bottling line                  | 4010          | 5020                             |
| Bioreactor suite               | 4011          | 5021                             |
| Collection system              | 4012          | 5022                             |
| Vision inspection              | 4013          | 5023                             |
| Body shop framing line         | 4014          | 5024, and 5124 for Open Protocol |
| Rotating equipment reliability | 4015          | 5025                             |
| Grid substation                | 4016          | 5026                             |
| Steel mini-mill                | 4017          | 5027                             |
| Aerospace machining            | 4018          | 5028                             |
| Gas gathering system           | 4019          | 5029                             |
| Paper machine                  | 4020          | 5030                             |
| Packaging hall                 | 4021          | 5031                             |
| Injection moulding cell        | 4022          | 5032 and 5132                    |
| Tire manufacturing             | 4023          | 5033                             |
| CNC machine shop               | 4025          | 5135 to 5144, one per controller |

## TLS

`EDGE_VERIFY_TLS` is `0` by default, because a Litmus Edge ships a self-signed certificate and verification would fail for a reason unrelated to the connection. Set it to `1` wherever the certificate is a real one: these solutions send an API token over that connection.

## Support

[support@litmus.io](mailto\:support@litmus.io)
