From Facilities to Action: ISA-95 Based Insights from Old Paper Machines

[Cengiz Özemli]

## From Facilities to Action: ISA-95 Based Insights from Legacy Paper Machines

This article addresses the design elements and processes of a successful and repeatable ISA-95 based architecture using data from brownfield paper machines, through three use cases and a case study.

While brownfield paper machines generate large amounts of quality control system (QCS) and distributed control system (DCS) data, many teams still spend hours reconstructing what happened after downtime, slow quality transitions, and quality deviations. This article presents a control-safe, practitioner-friendly blueprint to turn existing automation data into repeatable actions: data extraction from QCS or DCS using a read-copy method, combined with buffering at the edge, a historian, a context layer linking quality and reel information, and a set of role-based views suitable for daily operations.

### Key Takeaways

• A large portion of production losses is hidden in ambiguous downtimes, inconsistent transitions, and slow quality resolution. Making these losses measurable and repeatable provides the quickest gains.
• The read-copy data extraction method should be prioritized; the control system should remain the system of record, and no write-backs should occur without approval.
• A small number of clean and selected tags with well-defined ownership is more sustainable than a large number of uncontrolled tags.
• Dashboards should be embedded in daily and weekly routines, with named owners and a follow-up process.

### Technical Architecture

• QCS and DCS remain at the control system layer as data sources.
• Data collection is done to the historian using a read-copy method.
• Edge buffering prevents interruptions.
• The context layer links information such as quality, recipe, reel and bearing IDs, and downtime segments to temporal data.
• The consumption phase ensures operational usability with role-based views.

### ISA-95 Based Asset and Tag Model

• A hierarchical structure is established to reflect the plant's operating model: enterprise → site → area → unit → equipment → control modules.
• A data contract is prepared for each critical tag (including definition, location, effects, unit, limits, owner, etc.).
• Consistency in tag naming is ensured (e.g., PM1.HEADBOX.PRESSURE.PV).

### Data Quality Management

• NTP should be used for time synchronization, and PTP in precise situations.
• Scaling and units must be verified, and sampling and filtering documented.
• Invalid data should be flagged; users should not follow erroneous data.

### Three Important Use Cases
1. Downtime Loss Visibility: Reduces ambiguous downtimes and makes losses visible by coding downtime reasons and supporting them with an evidence package. Goal: Reduce unknown downtime from 40% to below 15%.
2. Quality Change Stabilization: Transforms quality transitions into repeatable processes, managing them with a timeline and event log. Goal: Reduce average stabilization time from 12 minutes to 6 minutes.
3. Quality Loss Mapping: Monitors quality deviations within event windows with pre- and post-context. Goal: Reduce recurring quality events by 25-40%.

### Governance and Cybersecurity

• Clear ownerships must be assigned for automation, operations, and reliability.
• Segmentation according to the Purdue Model should be implemented, access logged, and backup-patch processes disciplined.

### Phased Implementation Plan
1. Build reliability (time, unit, scale validations)
2. First success: User-friendly view and weekly review
3. Context layer and second use case
4. Reliability integration (ticket and work order connections)
5. Replication: Applying the same model to other machines

### Case Study: Brownfield Application

• Unknown downtime reduced from 40% to 14%,
• 42% improvement in diagnostic times,
• 50% reduction in stabilization time achieved.

### Lessons Learned

• Time synchronization is critical; delays create debate.
• A small and clean tag set is good for broad scalability.
• Definitions must be clarified and fixed in advance.
• Dashboards are just decoration if not followed up.
• User adoption is achieved with routine and simple screens.

## Conclusion
A successful brownfield digital program creates repeatable gains with stable boundaries, clear definitions, and disciplined modeling. This system enables teams to understand what happened, take action, and verify results, transforming a digital project into a real business process.