Paper Machine

A fine-paper machine and its scanning quality control system, over OPC UA. Eight sections from stock preparation to the reel, 118 nodes.

Most continuous processes report a point value: a pressure, a level, a flow. A paper machine also reports a profile across the sheet.

The quality control system drags a scanning head across a sheet 8.4 m wide moving at 1,100 m/min, so a single measurement is a curve across the sheet rather than a number. That gives two axes, and both terms appear in the tag names and on the operator view:

MD control is an ordinary loop: moisture low, add steam. CD control is twenty-four dilution valves in the headbox, each trimming the fibre delivered to one slice of the sheet. The operator view shows both axes, because a side elevation alone cannot show a profile: the machine along the top, and below it the sheet seen from above, one bar per dilution zone, with the scanner head at its live position.

Four scenarios ship with the solution. The first causes the third, with nothing in the model connecting them directly.

Fibre giveaway. Not a fault, and always present. Paper is sold by area and made by mass, so every gram per square metre above the customer minimum is fibre nobody paid for. The mill must keep the thinnest part of the sheet legal rather than the average, so the aim point is the specification minimum plus the profile spread plus an operating margin. A machine that cannot hold a flat profile runs heavier and pays that margin on every tonne, with nothing alarming. Flatten the profile and the aim point comes down.

A stuck headbox dilution valve. The slice it feeds runs heavy. A dilution valve does not affect only its own slice: the diluted stock spreads before it reaches the lip, so one valve moves its neighbours, and a controller cannot correct anything narrower than its own response width. Cross-direction two-sigma goes from about 0.4 to about 1.6 g/m2 and stays there; the aim point follows it up within a scan or two, and giveaway follows the aim.

A sheet break, two sections downstream. A heavier slice is also a wetter slice, and the dryers are controlled on the scanner average, so the average comes right while the streak stays wet. A wet line through the sheet is a weak line, and the open draw between the press and the first dryer is where it lets go. No fault is injected at the press.

A plugged press felt. A point of dryness lost at the press is a point the dryers buy back with steam, and drying is the largest energy consumer on the machine. Steam per tonne goes from about 1.45 to about 1.85 with quality and production unchanged, which is why this condition can run for months. Neither the steam figure nor the dryness figure identifies the cause alone; the analytics group joins them.

The node names follow what a paper machine's DCS and QCS publish to the mill historian, which is the level Litmus Edge reads: BasisWeightGsm, MoisturePct, CdSigma2, DrynessAfterPressPct, SteamPerTonne, FreenessCsf, JetWireRatio.

Two groups exist for specific scenarios. BasisWeightGsm and BwAimGsm are separate nodes, and the gap between them is the giveaway. CdZone01Bw through CdZone24Bw are the databoxes across the sheet, and CdZone01Valve through CdZone24Valve are the dilution valves that feed them: the measurement sits on the scanner and the actuator on the headbox, which is where each of them physically is.

There is no OPC UA companion specification covering this domain model, so the node names are the solution's own. The protocol provides discovery, typed values and subscription, not borrowed semantics.

Every group is multi-input. A single threshold on a single tag is what a SCADA alarm already provides; the join is what Litmus Edge adds.

The cross-direction profile is served as twenty-four sibling scalar nodes rather than one array node. DeviceHub reads a tag as a value, so an array would arrive as one opaque tag that no analytics group could threshold and no twin attribute could bind to.

Download pulp-paper-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:4020. 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. That is deliberate: the simulation does not tick and no value is shown until Litmus Edge is verified to hold the devices and poll 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 OPC UA and the Edge subscribes to 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, they report as online, 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 reports why.

This solution can also publish its 8 Digital Twins into Litmus Unify, one message per asset under northwood-paper/northwood-mill/.... 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 fibre giveaway in dollars per hour with tonnes beneath it, the cross-direction two-sigma against the flat-machine floor, steam per tonne, and production with break and downgrade counts.

Below that is the machine, stock preparation to reel, drawn side on with the sheet threaded through it: flat on the wire, through the press nips, over and under the dryer cans, then onto the reel, which grows as the jumbo builds. The sheet changes colour along the line as water leaves it, which shows where the machine is spending its energy.

Below the machine is the sheet from above: one bar per dilution zone against the aim, with the scanner head at its real position. A stuck valve is visible here and nowhere else.

Each scenario has a card naming the DataHub topics to watch and what changes about them.

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: inline styles, inline charts, no scripts and no external requests, so it opens offline, emails and prints. It carries the shift totals, the cross-direction profile against the specification band, giveaway and specific steam against time with the flat-machine baseline marked, the reel record with its dispositions, and the Litmus Edge configuration that produced it.

[email protected]