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.

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.

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.

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.

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.

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.

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.

Download tire-manufacturing-demo-0.6.1-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 prints the image it added, which is the one the files below name:

Save this as docker-compose.yml:

Put the three values in a .env file beside it:

Start it:

Or, without Docker Compose, run the same image with the same .env:

Flags given with -e take precedence over .env, so change APPLY_ON_START or EDGE_VERIFY_TLS on the command line rather than in the file.

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

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.

This solution can also publish its 9 Digital Twins into Litmus Unify, one message per asset under litmus-tire/ravenna/.... It stays off until two things are true: the UNIFY_ values above are set, and the Litmus Edge has a Litmus UNS connector, which the Solutions provisioner can pair in one click. The next apply then publishes the twins, the page header shows how many are arriving, and removing the solution from the Edge removes its branch from Unify as well. Leave the values empty to keep Unify out of it.

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.

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.

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.

[email protected]