Data and connectivity foundations: the plumbing under every other pillar
This pillar asks whether the data your routines depend on arrives without retyping and means the same thing on every line. It also asks who can reach that data, and whether connecting machines has left the plant more exposed.
What this pillar covers, and why it matters more than it looks
This is one pillar among six, and it is not an Industry 4.0 maturity model. It does not reward the amount of technology in the plant. It asks whether the data foundations are good enough for the management practices scored in the other pillars, and whether they are looked after.
We score five things: how connected your machines are (data1), how reference data such as ideal cycle times and reason codes is managed (data2), how production data is integrated with other systems (data3), who can access the data and under what rules (data4), and how shop-floor (OT) cybersecurity is handled (data5).
The weight of this pillar shows up indirectly. Every hour a team leader spends typing counts into a spreadsheet is an hour not spent at the line. An ideal cycle time taken from the nameplate makes the performance loss either invisible or absurd, and the meeting stops believing the figure. A machine connected to the network with a supplier's remote-access tool nobody knows about is a risk that can stop the plant.
Every level on this pillar can be reached with modest means: a run/stop signal from a relay contact, a shared database, a written change process, a separated network. The model names standard options such as OPC UA, MQTT and simple I/O signals only as examples, and it favours none of them. For guides to monitoring approaches, see factorymetrics.org.
The five levels as you would see them in the plant
| Level | What you see on the floor | What the numbers look like in meetings |
|---|---|---|
| 1 Reactive | No machines connected; counts come from operator tallies. Performance files live on personal laptops. Nobody knows how many devices sit on the shop-floor network, and suppliers connect with their own tools. | Figures differ depending on who prepared them. Nobody can say which cycle time was used to calculate performance. |
| 2 Aware | Some machines have local displays, or PLC data that nobody collects. Cycle times come from the nameplate. Data is typed into the ERP by hand and stored on shared drives. The IT policy is applied to the shop floor without adaptation. | Performance figures above 100%, or implausibly low, appear and are explained away. Month-end closing takes days of reconciliation. |
| 3 Structured | Bottleneck machines are connected and their data is collected centrally. Ideal cycle times and reason codes are defined for the main lines. Some automated exports exist. Production data sits in a central database, with access on request. Office and production networks are separated. | Meetings use the same figures from the same source. Anyone who wants a different cut of the data goes through one person. |
| 4 Proactive | Most critical machines are connected through a standard interface. Reference data has an owner, a change process and a periodic review. The production system exchanges orders and counts with the ERP or MES. Access is role-based, with retention rules and documented definitions. An OT security policy covers the asset inventory, remote access and patching, following IEC 62443 principles. | Production and ERP counts agree without manual correction. Every change to a cycle time can be traced. Nobody asks which file is the right one. |
| 5 Excellent | A standard connectivity architecture covers all lines, and data requirements are written into every equipment purchase. Reference data is harmonised across sites. Integration runs both ways and the data model is documented. Engineers use a data catalogue and analyse data themselves. OT risk assessments and incident drills are routine, and security requirements are part of purchasing. | Engineers answer their own questions from the data. Sites are compared without recalculating anything. Incident response has been rehearsed. |
Plants are often uneven here: a well-connected bottleneck next to reference data nobody owns, or a sound network next to hand-typed ERP entries. The assessment scores each question separately. The levels page explains the pillar index and the weakest-pillar rule.
The five questions, and how to check your own answer this week
data1. How connected are your machines? We are asking whether the plant gets stop and count data from its machines without someone writing it down, starting with the constraint. Connection for its own sake scores nothing.
Plants over-rate when PLCs are on a network but nobody collects their data, or when the only connected machine is a pilot away from the bottleneck. They under-rate when they assume a simple run/stop signal is not real connectivity. The model explicitly accepts simple I/O signals, and for older equipment they are often the most sensible choice.
List every machine on the bottleneck line with its controller type, whether it can output a run/stop signal and whether that signal is stored somewhere. Then try to retrieve yesterday's list of stops on the bottleneck without asking an operator or opening a paper log.
data2. How is reference data managed? We are asking whether the yardsticks used to judge performance are right, and whether anyone owns them. Ideal cycle times, reason codes and the product list quietly shape every figure the plant reports.
The common over-rating is to say ideal cycle times are defined when the figures are standard times from costing or planning, which include allowances. Those are not the best sustained rate of the machine. A reason-code list that has grown to include near-duplicates and a heavily used 'other' code is another sign that nobody owns it.
For the three highest-volume products on the bottleneck, compare the ideal cycle time in your system with the best rate you have seen the line sustain over a stable hour. If any shift shows a performance rate above 100%, the reference is wrong. Then ask who last changed a reason code, and how.
data3. How is production data integrated with other systems? We are asking how much data is typed twice, and whether the production system and the ERP agree on what was ordered and what was made.
An export that someone must launch, clean and re-import every week is often counted as automated. It is Level 3 at best, and the person who does it is a single point of failure. Integration at Level 4 means orders and good-part counts flow without anyone touching them, and differences are flagged rather than silently corrected.
Follow one production order from release in the ERP to the good-part count posted back. Write down every manual step and who does it, and time those steps over a normal week.
data4. Who can access production data, and under what rules? We are asking whether the people who need the data can get it without asking for a favour, and whether the definitions behind each field are written down.
A central database suggests Level 3, but if only one person can query it, engineers still build their own files and the plant is back to parallel versions. Level 4 also needs retention rules and documented definitions, which many plants skip.
Ask a process engineer to produce last month's stop time by reason for one line. Note how long it takes and how many people are involved. Then check whether the definition of planned production time in the database matches the written one used in performance visibility.
data5. How is shop-floor (OT) cybersecurity handled? We are asking whether production systems are protected in a way that suits the shop floor, where availability comes first, equipment stays in service for many years and suppliers need remote access.
The typical over-rating is to claim the networks are separated while supplier VPNs, remote-desktop tools on HMIs or cellular modems in machine cabinets bypass the separation. Another is a firewall between the zones whose rules allow nearly everything.
List every remote-access path used by suppliers in the last year, including software installed on line PCs and modems inside cabinets. Compare the list with what IT believes exists. Then ask who can approve a patch on a line PC, and when that last happened.
What Level-4 plants do differently
Plants at Level 4 on this pillar are rarely the ones with the most technology. They connect for a purpose and write down the rules. These are the practices we look for.
- Connect for a question. Every connection answers a question asked in a routine, such as how long the bottleneck stopped and why. The plant defines its own minimum signal set, for example run/stop, good count and reject count where available, rather than collecting every tag.
- One documented way to connect per equipment type. A one-page standard says which interface is used for which kind of machine: OPC UA where the controller supports it, MQTT for publishing data, hardwired I/O for older equipment. The choice matters less than having one.
- A reference data sheet with history. For each product and line: the ideal cycle time, how and when it was measured, and its owner. Changes follow a short process (request, approval, effective date) and the history is kept. The sheet is reviewed on a set cycle and whenever a product or machine changes.
- A reason-code list kept short enough to use. The plant sets its own ceiling on the number of codes, watches the share of time coded as 'other', and reviews the list when that share grows.
- Daily reconciliation. Production counts are compared with ERP postings every day, and exceptions are listed and explained rather than overwritten.
- Roles and a glossary. Access is defined by role (operator, team leader, engineer, manager, supplier) and every key field has a written definition in one place.
- OT basics done properly. An asset inventory is maintained. Supplier remote access goes through one controlled path, with named accounts and sessions opened on request. Patching is agreed with production for each class of equipment, and lines are separated into zones in line with IEC 62443 principles.
A 90-day plan to move up one level
The plan assumes most answers sit at Level 2 or 3. Your report from the assessment gives a specific next move for each gap; start with the lowest-scoring question.
- Weeks 1–2Take stock. List the machines on the bottleneck line with their controllers and available signals. List every device on the shop-floor network and every remote-access path. Map where production data is typed in twice and how long it takes. Note where reference data lives today, and in how many versions.
- Weeks 3–6Connect the bottleneck with a run/stop signal and a count, and store the data centrally. Measure the best sustained cycle time of the main products and publish one reference sheet with a named owner. Close uncontrolled remote-access paths and separate the production network from the office network if that is not yet done.
- Weeks 7–12Automate the most time-consuming manual transfer, even as a scheduled file. Write the change process for reference data. Draft an OT security policy covering the asset inventory, remote access and patching. Define access by role. In week 12, check that the daily meeting uses bottleneck data nobody retyped, and retake the assessment.
| Role | Owns during the 90 days |
|---|---|
| Plant manager | Sets priorities and settles conflicts between production needs and security constraints. |
| Engineering or automation | Machine inventory, the bottleneck connection and the one-page connection standard. |
| Process engineering or CI | Reference data: measured cycle times, the reason-code list and the change process. |
| IT working with OT | Network separation, the remote-access path, the device inventory and the draft security policy. |
| ERP owner or finance | The automated transfer and the daily count reconciliation. |
| Purchasing | Starting to add connectivity and security requirements to new equipment specifications. |
Evidence a jury looks for in verification
In verification you upload artefacts, then take two jurors through them in a 45-minute video interview. They look for signs that the data foundations are used in the plant's routines, not for architecture diagrams of future projects.
Artefacts that count:
- The machine list with connection status and interface type for each critical machine.
- A simplified network diagram showing the separation between office and production.
- The reference data sheet with its change history, and the reason-code list with its owner.
- A description or screenshot of how orders and counts move between systems, plus a recent reconciliation record.
- The list of access roles and the glossary of field definitions.
- The OT asset inventory, the remote-access procedure with a sample of its log, and the OT security policy.
- A recent equipment specification that includes connectivity or security requirements.
What does not count: supplier brochures; architecture slides for a project that has not started; a connected pilot machine whose data is not used in any meeting; a security policy copied unchanged from IT; screenshots of dashboards nobody opens.
Redact IP addresses, device names and anything that describes how to reach your systems. Never share credentials. Jurors need to see that a practice exists and is followed, not the details an attacker would want.
Pitfalls that keep plants stuck on this pillar
- Connecting everything, using nothing. Hundreds of tags collected, and the morning meeting still runs on a hand-written sheet.
- Nameplate cycle times. The performance loss disappears or looks absurd, and people stop trusting the whole figure.
- Reason-code sprawl. Every new problem gets its own code until operators pick the first one in the list.
- Two sources of truth for counts. The production system says one thing and the ERP another, and someone corrects the difference by hand every week without asking why.
- Starting from the system instead of the question. Choosing a platform or an integration project before agreeing definitions and reference data means rebuilding both later.
- OT security as IT's problem. Or the opposite: production blocking every patch for years because nobody agreed a maintenance window.
- The forgotten supplier access. A remote-access tool installed during commissioning years ago, still running and still using the original password.
- A data store nobody queries. Data collected centrally that only one specialist can reach is no better than a shared drive.
Where to go next
Take the assessment to see this pillar's index beside the other five, and whether it is the pillar holding your overall level down. Data foundations exist to serve performance visibility, where the questions turn to how losses are captured and whether people trust the numbers, so read that one next. For OEE figures and benchmarks, which the FEI does not measure, see oee-benchmark.org.
Questions
Can we reach Level 3 overall if our data pillar is weak?
Under the weakest-pillar rule, your overall level can be at most one level above your weakest pillar. A plant at Level 2 on data can therefore be Level 3 overall, but not Level 4. Many plants reach Level 3 on this pillar with a connected bottleneck, defined reference data and a separated network.
Should we choose OPC UA or MQTT?
The model does not prefer either. The right choice depends on your equipment and existing systems, and many plants use more than one, alongside simple I/O signals for older machines. What scores is a documented standard for each type of equipment, applied consistently.
Our older machines have no PLC. Can they be connected?
Usually yes, with a simple I/O signal: a relay contact, the stack light or a sensor on the machine's motion. A run/stop signal and a part count answer most of the questions the daily routines ask, and the model accepts them fully.
Is this an Industry 4.0 maturity assessment?
No. The FEI measures management practice across six pillars, and this pillar checks only whether the data foundations support those practices. A plant with modest technology and disciplined routines can score higher overall than a heavily digitised plant without them.
Do we need IEC 62443 certification for Level 4 on OT security?
No. Level 4 asks for an OT security policy that covers the asset inventory, remote access and patching, following IEC 62443 principles. Certification is not required and is not scored.