Define useful line states, counts, stop causes, time rules and secure interfaces before connecting an automatic packaging line to OEE, MES or production reporting.
1. Start with the production decisions the data must support
Do not begin with a request for every available PLC tag. Define the questions the site needs to answer: how many accepted packs were produced, where the first loss began, why the line stopped, which format ran, whether rejects were removed and whether the line met the agreed acceptance condition.
Each required decision can then be mapped to a source, definition, count point, time rule and owner. This creates a smaller and more reliable interface than an unstructured tag dump.
2. Define line states, events and first-cause logic
Use consistent state names across the line, even when individual machines retain their own internal state model. Define what “ready”, “running”, “held”, “stopped”, “complete” and “faulted” mean at line level and how machine conditions map to those states.
For stop analysis, identify the initiating event before dependent machines respond. A downstream blockage can stop several upstream modules; reporting every resulting condition as a separate loss hides the first cause. Record the initiating device or condition, affected state, start time, clearance and return to stable accepted output.
OMAC’s PackML resources provide recognised machine-state terminology where a standardised model is appropriate. The project still needs a documented mapping and test cases for the actual implementation.
3. Agree count points and quality status
Select the authoritative good-count point and define how later rejects, rework, manual removals and incomplete packs are treated. Machine totals captured at different positions will not reconcile unless the line logic or reporting system understands those boundaries.
| Data item | Definition to agree | Common failure |
|---|---|---|
| Good count | Exact count point and final quality status | Counting before a later reject or manual removal |
| Reject count | Detection, reject action and confirmed removal | Counting a reject signal without proving the pack left the line |
| Ideal cycle | Format-specific basis and owning machine or line | Using a nominal brochure rate for every format |
| Production order | Source, format identity, revision and fallback procedure | Local machine names that do not match site records |
| Stop event | First cause, start, end and recovery rule | Several dependent machines recording the same interruption |
4. Decide where data is created, consolidated and owned
Define whether each value comes from a machine controller, a line PLC, a supervisory system or an enterprise application. Record the interface protocol, update behaviour, communications-loss response, network boundary and responsibility for future changes.
A line-level controller can consolidate counts and states, but it should not silently change the meaning of machine data. A site system can calculate OEE, but it needs the same agreed production boundary and time rules used during acceptance. Keep a controlled data dictionary alongside the controls narrative and interface schedule.
5. Plan time synchronisation, network boundaries and secure access
Event order and duration become unreliable when controllers and reporting systems use different clocks. Define the approved time source, time zone, daylight-saving treatment and behaviour when synchronisation is unavailable.
Operational-technology connectivity should be designed with the customer’s security and availability requirements. The UK National Cyber Security Centre describes OT as technology that interfaces with the physical world and emphasises safety, reliability and availability alongside cyber security. Its guidance on maintaining a definitive view of OT architecture recommends documenting assets, connectivity and third-party risks.
Define who may connect, by what approved route, for what purpose, with what authorisation and how access is logged and removed. Do not assume that an internet-connected remote-support method is acceptable to every site.
6. Test the data interface with production and fault scenarios
Acceptance should prove meaning, timing and recovery, not only that a connection exists. Use representative scenarios to confirm counts, states, alarms, rejects, recipe identity, communications loss and restoration.
| Scenario | Evidence to witness |
|---|---|
| Normal production | Good and reject counts reconcile at the agreed boundary |
| Downstream blockage | One first cause is recorded and dependent machines enter the expected state |
| Format change | Correct format identity and parameters appear across required systems |
| Lost communications | Defined fallback, alarm, data-quality flag and recovery occur |
| Power or control restart | Time, counters, current order and state recover according to the specification |
7. Information to provide for a data-integration brief
- Required business and production decisions
- Authoritative good-count and reject points
- Line-state and first-cause stop definitions
- Format, recipe and production-order ownership
- Existing OEE, MES, SCADA, historian or reporting platform
- Approved network architecture, protocols and time source
- Remote-access and third-party security policy
- Retention, export, reporting and acceptance requirements
Use the controls architecture guide for machine handshakes and recipes, and the line balancing and OEE guide for performance interpretation.