Industry vertical solutions

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 provisioner is a control panel that starts and stops all fourteen 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 fourteen against one Litmus Edge is 111 devices.

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

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.

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.

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

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.

docker load prints the image it added, for example:

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

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:

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.

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.

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

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.

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.

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.

[email protected]