# Production Line Digitization Checklist

> What to settle before a line's machines and paper records feed one data backbone, and AI after it.

Source page: https://mnpsystems.ca/resources/production-line-digitization-checklist/
PDF: https://mnpsystems.ca/downloads/production-line-digitization-checklist.pdf (free, no email required)

MNP Systems is an engineering consultancy based in Brampton, Ontario, Canada, that takes work from anywhere: remotely, or on site where a job needs hands on the equipment.
Contact: https://mnpsystems.ca/contact/ or contact@mnpsystems.ca.

This checklist is for a line that already runs, with machines that measure more than anyone sees and records that still live on paper. It is not about choosing an MES vendor or modelling the whole plant.

It follows one shape: an edge gateway reads the controllers without changing them, the checks people make move from paper to a tablet at the station, both publish into one topic tree, and OEE, quality records and later AI read from that tree. Most projects that stall do not stall on the software. They stall on names nobody agreed, a form that lost its reaction plan, or a network nobody separated.

Work through it before the pilot line, and again before you copy the pilot to the next line. The first pass sizes the job; the second tells you whether the pattern is ready to repeat.

## 1. The line and its questions

- [ ] One pilot line is chosen, with a known bottleneck, clear cycle signals and an owner who can define its stop reasons
- [ ] The questions the data must answer are written down first (why did the line stop, was this lot within limits, how many good parts per shift) rather than "collect everything"
- [ ] Today's figures for output, downtime and scrap are recorded, however rough, so the project can be judged against numbers rather than memory
- [ ] Every paper form the line fills in is collected, with who fills it in, how often, and who reads it afterwards
- [ ] The people who run, maintain and inspect the line have seen the plan, and someone on the floor owns it

## 2. Reading the machines

- [ ] Every controller, drive and instrument the questions need is listed, with the protocols it can already speak (OPC UA, Modbus TCP or RTU, EtherNet/IP, Profinet)
- [ ] Each signal is documented with its address, units, scaling and sample rate, and a reason it is being read
- [ ] The gateway reads only. It opens no write path into a controller, and safety functions and interlocks are untouched
- [ ] Values are timestamped where they are read, from a clock synchronised across the line
- [ ] The gateway buffers data when the network drops and sends it when the connection returns, so an outage leaves a delay rather than a gap

## 3. Moving paper checks to the station

- [ ] The first digital form asks the same questions in the same order as the paper one, and changes come after it has run
- [ ] Each reading is entered against its limits, and an out-of-limit value shows its reaction plan at the station and alerts the person who must act
- [ ] Every person signs in as themselves; no shared login exists on any tablet
- [ ] Every entry records who, when, the line, station, part and lot, and the revision of the form it was entered on
- [ ] A correction is a new entry with a reason, and the original stays visible
- [ ] The form works with gloves, at arm's length, in the operators' own words, and keeps working when the wireless network does not

## 4. The topic tree

- [ ] The tree follows the plant's own layout using ISA-95 levels (enterprise, site, area, line, cell or station, signal), and the naming rules are written down
- [ ] Every asset has exactly one path, and no two systems use different names for it
- [ ] Units and scaling are applied once, at the gateway, not in each dashboard
- [ ] Machine states (running, idle, starved, blocked, faulted, planned stop) are defined in writing and agreed with the people who will read the reports
- [ ] The order, part number and lot on the line are published to the tree, so process values carry their production context
- [ ] The payload format is written down: Sparkplug B where many devices and vendors meet, or plain MQTT with a documented schema

## 5. OEE and quality records

- [ ] Planned downtime and the ideal rate for each part are agreed before the first OEE figure is shown
- [ ] Availability, performance and quality are counted from machine states, cycle counts and check results, not typed in at the end of the shift
- [ ] Stops past a set length ask the operator for a reason from a short list, and the list is reviewed after the first month
- [ ] A lot can be traced through every station it passed, with the process values and checks recorded while it was there
- [ ] Record retention is set from the quality system and each customer's own requirements before the first record is kept
- [ ] Paper and tablet run side by side until quality has checked the digital records against the paper ones and signed off

## 6. Security

- [ ] The line's network is separated from the office network, and the gateway is the one controlled path between them (zones and conduits, as IEC 62443 describes)
- [ ] Data leaves the line outbound and encrypted, and nothing outside the plant can open a connection into it
- [ ] Each gateway and tablet has its own credentials and may publish only to its own part of the tree; everything else only reads
- [ ] Tablets are enrolled in device management, on their own wireless network, locked to the app, and can be wiped remotely
- [ ] Remote support, if there is any, goes through one logged and approved path that is off when not in use

## 7. Before AI

- [ ] The tree has run long enough to hold months of history with stop reasons, rejects and maintenance events attached
- [ ] The first AI use changes nothing on the line, such as answering questions from procedures, shift notes and quality records
- [ ] Any model reads from the tree and never writes to a controller, and a person makes every decision it suggests
- [ ] Each AI use is measured against the line's own figures from before it went in

## Where this usually goes wrong

**The dashboard comes before the definitions.** A screen appears early, and soon three people have three explanations of why its number differs from theirs. Agree the states, the ideal rates and the units before anything is counted.

**The form is digitized but the reaction is lost.** The tablet records an out-of-limit reading and nobody is told. The reaction plan has to come across with the form, or the paper version was safer.

**The whole plant is modelled first.** A site-wide twin or MES rewrite takes a year before anyone on the floor sees a result. One line, done properly and copied, gets further in the same time.

## When this needs outside help

Most plants can work through this list with their own maintenance, quality and IT people, and should. It is worth bringing in help when:

- The controllers are old or undocumented, and nobody on site can say which registers hold the values the questions need
- The records are audited by customers, so the digital version has to be right, traceable and accepted before the paper one can go
- The line's data has to reach an MES, an ERP or a cloud system securely, and the controls and IT sides of the plant have never had to work together

If any of those describe where you are, this is work we do: **contact@mnpsystems.ca**.
