Tire Manufacturing
A passenger and light-truck tire plant from the mixing room to final finish, over EtherNet/IP. Nine Allen-Bradley controllers on one chassis, 357 tags.
Operator view | port 4023 |
|---|---|
EtherNet/IP chassis | port 5033 |
Devices and tags | 9 devices, 357 tags |
Litmus Edge driver | AB Logix Ethernet |
Image | tire-manufacturing-demo |
Overview
Two Banbury mixers make compound, two tread extruders and a ply calender turn it into stock, two tire building machines assemble green tires, a bank of six curing presses vulcanises them, and final finish inspects them.
That is three process archetypes in one material flow. Mixing and curing are batch (ISA-88), extrusion and calendering are continuous, and building is discrete. The coupling is the demonstration: how well a compound was mixed is a batch property, it is carried by a discrete item, the green tire, into another batch process, the cure, and the press never learns which compound it holds.
Area | Devices |
|---|---|
Mixing | Banbury 1, Banbury 2 |
Preparation | tread extruder 02, tread extruder 03, ply calender |
Building | tire builder 1, tire builder 2 |
Curing | the press bank, one controller for six presses |
Finish | final finish, uniformity and inspection |
The simulated clock runs at 60x real time, so a fourteen minute cure is watchable. Everything a tag publishes is in simulated time and internally consistent.
Scenarios
Six scenarios ship with the solution. The first produces the second and the third, with nothing in the model connecting them directly.
A batch mixed on time instead of on energy. Banbury 2's drop criterion reverts from accumulated specific energy to elapsed time, and nothing alarms. Every charge differs by a few percent, and dropping on energy absorbs that while dropping on time passes it straight through, so some batches leave under-dispersed and cure slowly. The tires they make are the right shape, pass uniformity, pass X-ray, and are undercured.
Containment by genealogy against containment by clock. Because a batch is consumed over an hour and its tires cure hours later, the suspect tires are scattered through the day with good ones between them. Holding by compound genealogy holds 220 tires at $11,440; holding everything since the last batch known good holds 561 at $29,172.
The same compound running heavy at the extruder. An under-dispersed compound is more viscous, so it swells at the die and every tread comes off heavy. No tire is unsafe and nothing is rejected; the plant ships free rubber. An extruder screen pack blinding reaches the same giveaway by a different route, with cure conformance untouched.
Two causes of one undercure, told apart by where they fall. A failing steam trap on Press 06 runs its platen two degrees under setpoint, which looks like nothing on a gauge and undercures every tire from that press. Undercures scattered across the bank mean the compound; undercures piled on one press mean that press. The containment basis follows from where they land.
A splice drifting on one builder. Builder 1's ply splice overlap walks past the drawing, and its tires fail radial force variation at final finish hours later and two areas away. The first harmonic carries almost all of the rejections while the total force variation is still inside its limit.
A bladder leak and a die cavity spread. A leaking curing bladder on Press 03 aborts the cycle, which is loud, immediate and cheap. Die position 2 on the extruder running wider on conicity than position 1 keeps treads mostly in spec and shows only in the per-cavity capability figure.
The cure-state join
A curing press knows how much heat it delivered, as EquivCureMin, the equivalent-cure integral it computes over the cycle. A Banbury knows how much heat its compound needs, as T90RequiredMin. Cure state is delivered divided by needed.
The numerator is on the press bank controller and the denominator on a mixer: two controllers in two ISA-95 areas that share no data path. The Cure State Verification group joins them on Litmus Edge, and that join is what this solution is built around.
Tag names
The register name on the AB Logix Ethernet driver is the Logix symbolic tag, so Mixer.MixEnergyKWh is the address itself rather than a label over a register number. Representative tags: SpecificEnergyKWhT, DropCriterion, T90RequiredMin, EquivCureMin, TreadWeightGPM, ScreenPackDPKPa, SpliceOverlapMM, RadialForceVarN.
Every device points at the same host and port and differs only in its route, 1,<slot>: port 1 is the backplane and the slot is the controller. That is how a real ControlLogix rack is addressed, and it is why Banbury 1 and Banbury 2 carry identical tag names: they are two controllers running the same program.
The mixing cycle is published as twenty-two named elements, each with a standard and an actual time. Which elements are running is a packed word, ElementActiveWord, one bit per element, because elements overlap; it is unpacked on the Edge.
What it creates on Litmus Edge
Component | Created |
|---|---|
DeviceHub | 9 devices on the AB Logix Ethernet driver, 357 tags |
Digital Twin | 6 models, 9 instances |
Analytics | 8 groups, 158 processors |
The two Banburys are two instances of one model, because they are the same machine, and so are the two tire builders and the two extruders.
Analytics group | Computes |
|---|---|
Cure State Verification | heat delivered at each press against the heat the compound needs |
Compound Quality | whether a batch was mixed or merely timed, from specific energy and the drop criterion |
Tread Weight Giveaway | tread weight against target, as giveaway |
PCVC Capability and Variation | run chart and capability per extruder and die cavity |
Mixing Cycle Elements | the packed element word, unpacked against the recipe's standard times |
Curing Recipe Interlock | the green tire's recipe against the recipe the press is running, before the loader picks |
Press Bank Utilisation | press running state against steam |
Uniformity and Genealogy | radial force variation against its limit and the splice overlap of the builder that made the tire |
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: the solution reaches the Edge's API, and the Edge reaches this host on port 5033
Deploy
The solution ships two ways. Use the registry if the host can reach Google Artifact Registry, and the downloaded archive if it cannot.
Option 1: pull from the registry
Requires a read-only registry credential, supplied by Litmus separately.
cat key.json | docker login -u _json_key --password-stdin https://us-docker.pkg.devSave this as docker-compose.yml:
services:
tire-manufacturing:
image: us-docker.pkg.dev/litmus-customer-facing/litmus-solutions/tire-manufacturing-demo:0.5.0
container_name: tire-manufacturing-demo
restart: unless-stopped
ports:
- target: 4023
published: 4023
protocol: tcp
- target: 5033
published: 5033
protocol: tcp
environment:
EDGE_URL: "${EDGE_URL:-}"
EDGE_API_TOKEN: "${EDGE_API_TOKEN:-}"
SIM_HOST: "${SIM_HOST:-auto}"
APPLY_ON_START: "${APPLY_ON_START:-1}"
EDGE_VERIFY_TLS: "${EDGE_VERIFY_TLS:-0}"
HTTP_PORT: "4023"
EIP_PORT: "5033"
LOG_LEVEL: "INFO"Put the three values in a .env file beside it:
EDGE_URL=https://10.0.0.5
EDGE_API_TOKEN=your-token
SIM_HOST=10.0.0.9Start it:
docker compose up -dOption 2: load the downloaded archive
Download tire-manufacturing-demo-0.5.0-amd64.tar.gz from the solution's page on portal.litmus.io. The archive is the container image, not a source bundle, and needs no registry access.
docker load -i tire-manufacturing-demo-0.5.0-amd64.tar.gzdocker load prints the image it added:
Loaded image: us-docker.pkg.dev/litmus-customer-facing/litmus-solutions/tire-manufacturing-demo:0.5.0That reference is the one the compose file above already names, so the same docker-compose.yml and .env now work offline with no docker login:
docker compose up -dOpen http://localhost:4023. Within about a minute the Edge is configured and the page fills in.
The page stays on its waiting panel until the Edge carries this solution's devices and is polling them. That is deliberate: the simulation does not tick and no value is shown until Litmus Edge is verified to hold the devices and read from them, so nothing on screen can be mistaken for data that never made the trip. With APPLY_ON_START at its default of 1 the solution configures the Edge itself on startup, which takes 30 to 60 seconds. If you set it to 0, or the apply failed, press Apply to Edge in the page header.
Configuration
Variable | Default | Purpose |
|---|---|---|
EDGE_URL | the Docker host | Litmus Edge to configure |
EDGE_API_TOKEN | unset | token for that Edge. Alternatively EDGE_USERNAME and EDGE_PASSWORD, or EDGE_CLIENT_ID and EDGE_CLIENT_SECRET |
SIM_HOST | auto | address the Edge polls to reach the chassis |
APPLY_ON_START | 1 | configure the Edge on startup |
EDGE_VERIFY_TLS | 0 | 1 verifies the Edge's certificate |
SIM_HOST requires attention. The solution serves EtherNet/IP and the Edge polls it, so the Edge needs an address it can route to. Leave it auto when the solution runs on the Edge itself or with host networking. 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 and no tag ever reads a value, because the address written into the template is one the Edge cannot reach. The solution refuses to apply a template whose address is obviously unreachable, and does not open its page until the Edge reports the devices as polling, not just present.
Operator view
The header shows four figures: cure conformance with the lowest cure state against the release limit, the saving from containment by genealogy with the tires held each way, tread giveaway per day, and grade A at final finish.
Below that is the plant, mixers to final finish. Clicking a machine opens its Digital Twin instance under the drawing: the model, its DataHub topic, its static attributes and every dynamic attribute with its live value. Clicking any press opens the press bank, because one controller carries all six.
The rest of the page follows the material: the mixing cycle element by element, extruder capability and OEE, the curing recipe interlock and the compound genealogy, and rejection attribution by building machine against cavity.
Each scenario has a card naming the DataHub topics to watch and what changes about them. An undercure takes six to nine minutes to appear after the Banbury fault goes in, because the batch has to pass the stock rack, the extruder, a builder and a cure first.
Apply and remove
The header carries both controls. Apply to Edge pushes the devices, twins and analytics, and greys out once the solution is on the Edge. Remove from Edge previews first, listing what would be removed and from which Edge, then offers to remove it.
The solution removes only what it created, and records which Edge its apply landed on, so repointing at a different Edge cannot leave a solution stranded on the first one.
Reports
Preview report and Export report produce one self-contained HTML file that opens offline, emails and prints. It carries the cure state record, the containment arithmetic, where the undercures landed, the mixing cycle, the recipe interlock, uniformity rejections by the equipment that made the tire, extruder OEE, the press bank, the faults injected, and the Litmus Edge configuration that produced it.