Process Parameter Recording System 2026: RFP and FAT/SAT

When you compare vendors for a process parameter recording system, beginning with “how many tags can it store at what sampling rate?” puts the buying decision on the wrong footing. You do not need a larger pile of data. You need evidence that can reconstruct a production event: which product or lot ran; on which machine and recipe version; what the intended setpoints and source actuals were; whether timestamps and data quality were trustworthy; who changed and approved what; and how the event linked to inspection and disposition.

This article turns that evidence ledger into a practical procurement specification. It organizes parameter registration, data ownership, time, missing records, corrections, offline operation, cybersecurity, retention and recovery into eight gates, then converts them into FAT/SAT test scenarios. It does not retell 4M change management or quality-data management. Its distinct purpose is to define the event-level join that connects those disciplines without silently replacing the original values.

The official-source scan performed before drafting found no announcement within the preceding 48 hours that directly changed process-parameter-recording requirements. The article therefore relies on the current official standards and guidance listed in the source ledger. Every investment and benefit figure below is a TOMAS TECH illustrative assumption, not survey evidence, a market price or a promise of results. Replace every input with your own baseline.

Agree on “reconstructability” before procuring a process parameter recording system

Capturing a value from a PLC or sensor and writing it to a time-series database does not complete a process record. A temperature trend is weak evidence if you cannot tell which recipe version was intended, whether the machine received it, when the value existed at the source, whether it arrived later after a network outage, whether the sensor reported bad quality, or whether somebody corrected the value afterwards.

The buyer should define success as neither a tag count nor a screen count, but as the speed and confidence with which the system can answer questions such as these:

• Can it identify the affected product, lot or serial without ambiguity?
• Can it identify the equipment, operation, recipe and version applied to that production event?
• Does it keep setpoints and actual values distinct and show the source and time of each?
• Can users distinguish good values from bad quality, communications loss, missing records and manual entries?
• Does a correction preserve the original while recording the new value, reason, actor and approver?
• Do stable keys connect the process event to inspection, disposition, quarantine, rework and release?
• Can the same event still be reconstructed after a system failure and restore?

We call that outcome “production-event reconstructability.” In an RFP, it is more useful to write “given a lot, the system shall export the complete evidence package while retaining original records” than to list an assortment of feature names.

Gate 1 — Define the decision the record supports and the event boundary

Write down who decides what before saying “collect everything”

The starting point for collection is a decision register, not a tag register. Quality may need to decide release or containment. Process engineering may need to isolate the cause of a parameter excursion. Maintenance may need to distinguish an equipment condition. Customer service may need to narrow the affected population. Different decisions require different granularity, retention, lookup keys and evidence formats.

Put operational use cases like these at the beginning of the RFP:

Define event boundaries in both machine-cycle and business terms

If “one manufacturing record” has no clear boundary, every downstream join is fragile. A continuous process may use lot start and end. A batch process may use charge, process and discharge. Discrete manufacturing may map a serial number to a machine cycle. The machine’s cycle and the business lot or serial are not automatically the same unit.

Specify the event start, end, interruption, restart, split, merge and rework rules. “One event until the lot number changes” cannot explain partial quantities, mixed production, rework or a stopped machine. Draw boundary cases, identify the signal or action that establishes the event ID, and define how a provisional ID is handled before the business identity becomes available. Make those cases part of FAT.

Use ISA-95 as a boundary map, not as a substitute for a data contract

ISA’s official page provides the ISA-95 overview and lists ANSI/ISA-95.00.01-2025 as the current Part 1. ISA-95 is a useful shared language for the boundary between enterprise and manufacturing activities. Merely naming the standard in an RFP, however, does not guarantee an unambiguous production event. The contract still needs to state exactly how equipment identifiers map to manufacturing orders, lots, products and operations.

Gate exit: the buyer, production, quality, process engineering and IT/OT can explain the decision and event boundary with the same examples, and assign a unique event ID to representative normal, interrupted and rework cases.

Gate 2 — Build a parameter evidence register and data-ownership map

Promote the tag list into an evidence register

A conventional tag list often stops at address, name, type, unit and collection interval. That is not enough for evidence. Add the business meaning and accountability of every item.

The system of record matters. The same temperature may exist in the PLC, edge gateway, historian and MES. If the project has not designated the original, nobody can adjudicate a difference. This is also where the buyer decides whether to retain raw values, transformed values, conversion formulas and configuration versions.

Separate who approves meaning from who maintains the connection

The machine vendor understands the signal technically. Process engineering understands its production meaning. Quality understands what makes it usable as evidence. IT/OT owns storage, access and recovery. Putting every responsibility under one department usually produces either a working connection with the wrong meaning, or a correct meaning that cannot be operated and restored.

For each evidence domain, name the meaning approver, connection maintainer, change approver, user and first responder. The contract should also define who updates the register, screen, report and test specification after a tag is added or renamed post-handover.

Gate exit: every FAT evidence item has a completed meaning, origin, system of record, time, quality, relationship key and owner. Any unresolved field appears in an explicitly approved exception register.

Gate 3 — Separate recipe, setpoint, actual, event and manual context

Never store “what we intended” and “what happened” in the same field

A recipe is intent, a setpoint is an instruction issued to the machine, and an actual value is a result observed from sensing or control. The names may be similar, but their evidentiary meanings are different. Saving a recipe temperature does not prove the machine received it or that the actual temperature followed it. Saving only the actual loses the intent against which it should be assessed.

Require separate fields for recipe ID and version, setpoint issue time, machine acknowledgement or application status, actual value and acceptance evaluation. If a recipe can change during production, keep the applicability period or event, not merely the version recorded at the beginning.

Alarms and events provide the context that explains a trend

A numerical trend cannot explain by itself why a value changed abruptly. Connect run, stop, setup, cleaning, calibration, mode change, communications loss, interlock and alarm acknowledgement to the same timeline. Avoid an unlimited free-text event field, which destroys search and comparison. Separate event type, code, subject, state transition, reason code and notes.

Preserve manual context and label it as manual

Operators sometimes need to supply context that no machine can capture. Manual entry is not inherently the problem; indistinguishability from an automatic value is. Preserve the person, entry time, target event, reason, basis and approval state. Corrections must create history rather than overwrite the prior entry.

The approval workflow and scope of a 4M change are covered in our dedicated guide to a 4M change management system. The job of the process parameter recording system is different: connect the approved change ID unambiguously to the recipe version actually applied, its effective production event, and the first-piece or verification result.

Gate exit: intent, instruction, result, state and manual context remain distinct types even when displayed or exported together, so users cannot accidentally treat them as equivalent.

Gate 4 — Preserve Source Time, Receive Time, quality state and clock-health evidence

A value can need more than one timestamp

OPC UA Part 6 defines DataValue fields for Value, StatusCode, SourceTimestamp and ServerTimestamp. The procurement lesson is not simply that a protocol “supports timestamps.” It is that the time at which a value existed at its source can be distinguished from the time another layer received or handled it.

We use Source Time for the origin time and Receive Time for the collector’s receipt time. They may be close in normal operation and diverge greatly after a network outage and buffered replay. Sorting only by Receive Time can make old values look newly produced after recovery. Trusting Source Time without qualification can hide a drifting or reset machine clock. Keep both and retain evidence of clock health.

Do not collapse bad quality or missing data into zero

Some equipment holds the last good value on screen during a sensor or communication fault. That may help operations, but saving it as a new actual silently changes the evidence. Ingest value, quality and source time as one unit, and distinguish bad, uncertain, stale and missing data. Zero may be a valid value and must never be used as a generic missing-data substitute.

Include the clock topology in the RFP

NIST publishes an introduction and recommended practices for using NTP in e-manufacturing. Although the publication is not recent, its core lesson remains useful: clock topology is part of the evidence chain, not merely a server configuration detail.

Specify the reference clock, synchronization path, behaviour when it is unreachable, the method for setting permitted drift, time-zone handling, integration with regions that use daylight saving, recovery after reboot and auditing of clock changes. Do not copy a universal tolerance from an article. Determine it from process dynamics, control behaviour and the ordering precision required for investigation, then force a clock anomaly during FAT/SAT.

Gate exit: tests involving communications loss, buffered replay, clock drift and restart preserve Source Time, Receive Time and quality in storage, display and export, and make the anomaly visible to the user.

Gate 5 — Join equipment, recipe, lot, serial, operator and 4M change without ambiguity

Join with stable keys, not display names

Display names such as “Line A” and “Product X” are easy to read but fragile as database keys. They change with renaming, relocation, cloning and localization. Establish stable, version-aware keys for equipment, operation, product, recipe, production order, lot, serial, operator and change request.

Do not encode all meaning into one giant string. Relate distinct masters and events, preserving enough history to show what a name meant at the time. When the relationship between a lot and a machine cycle is not one-to-one, represent the intermediate association event explicitly.

Never discard a record because automatic association failed

A missed barcode read or delayed production order can temporarily leave a value without a lot. Discarding it, or automatically assigning it to the previous lot, manufactures a convenient history. Keep it as an unassociated original record and use a controlled procedure to link it later, preserving the entire change history.

Divide responsibilities with quality and inspection systems

Definitions, approval, aggregation and trending of quality metrics belong to a quality data management system. Instrument and inspection-machine acquisition belongs to an inspection data collection system. The process parameter recording system should not replace them. It should connect them through the event ID, product identity, time and disposition key.

This allows users to move from an excursion to the affected population, inspection evidence, quarantine, rework and release. A fuzzy time-window join alone is dangerous under clock drift or parallel production. Time is a supporting criterion; stable keys are the primary criterion.

Gate exit: users can navigate from a representative lot to process conditions, changes, inspections and disposition, and backwards from an abnormal condition to affected lots or serials. Orphans, duplicates and any time-based inference are explicitly explained.

Gate 6 — Design exception, correction, override and audit-trail behaviour

Evidence quality becomes visible after something changes

Process data sometimes needs correction because of input errors, equipment replacement, calibration, association errors or an approved recipe change. A blanket ban on changes only drives work into uncontrolled channels. The safer design preserves the original, appends the new value and reason, and distinguishes current from original in both display and export.

OPC UA Part 11 covers Historical Access concepts. Its handling of historical modifications describes retaining original information and the change actor and generating an audit event. OPC UA Part 5 defines AuditEventType fields and semantics, while Part 2 addresses auditing in the security architecture. These are strong implementation references; adopting OPC UA does not by itself complete the business audit trail. The application, database, identity service and operating procedure must be tested as one evidence chain.

Distinguish change types in the RFP

Test not only whether an authorized person can perform an action, but whether an unauthorized action is rejected and the attempt itself is audited. Cover shared or emergency identities, revocation after role change, and audit ordering when clock synchronization is degraded.

Scope FDA and MHRA references to regulated industries

FDA’s *Data Integrity and Compliance With Drug CGMP Q&A* is December 2018 guidance for drug CGMP. MHRA’s *GxP Data Integrity Guidance* is March 2018 guidance for the regulated GxP domain. They provide useful thinking about original records, audit trails, authority and review, but they are not universal legal requirements for every factory. A regulated drug or GxP site should have its quality and regulatory functions determine applicability. Other factories should set the required level from contractual, customer and quality risks.

Gate exit: demonstrate authorized correction, unauthorized change, emergency change and repair of an unassociated record, then export original, current value, reason, actor, approver and time as one evidence package.

Gate 7 — Make architecture, offline operation, security, retention and recovery testable

Draw the architecture as a data path, not an equipment inventory

Place sensors, PLCs, machine PCs, OPC UA servers, edge gateways, networks, historian/MES, identity services, backups and clients on the drawing. Trace where each datum originates, transforms, buffers and persists. At every boundary identify protocol, authentication, encryption, time, replay behaviour and owner.

NIST SP 800-82 Rev. 3 was finalized in September 2023 and explains OT security in the presence of performance, reliability and safety requirements. Accordingly, do not apply an ordinary IT control to machinery without considering its effect on availability and safety. Design asset visibility, zones, access control, monitoring, backup and incident response around the production risk. A declaration of NIST alignment is not proof of security; the controls need testing against the actual architecture and threat assumptions.

Test the meaning of offline buffering, not only its capacity

An edge buffer is not trustworthy if replay changes order, creates duplicates, drops quality status or assigns the wrong lot. Require the following:

• What is buffered, what starts buffering, what happens when full, and how it is monitored.
• Replay that preserves Source Time and quality state.
• Replay identifiers and deterministic deduplication.
• A resume point when the upstream partially accepted a transmission.
• Ordering across clock drift and restart.
• Reconciliation evidence that buffered records reached durable storage.

Do not lift a generic duration from an article. Calculate the necessary capacity from tag scope, intervals, data volume, expected outage and risk, and give every bidder the same sizing assumptions.

Derive retention and export from investigation scenarios

Set retention from product life, customer contracts, regulation, warranty, investigation and backup operations, not storage price alone. Fast online retention and slower archives may be separated, but an archive is useless unless the software, versions, keys and master data needed to interpret it also survive.

“Export to CSV” may be inadequate. Include values, units, field definitions, recipe version, Source Time, Receive Time, quality, relationship keys, change history, extraction criteria and generation time in a machine-readable package. The ability to migrate and reconcile original records when changing products or vendors is also an RFP evaluation point.

Test event reconstruction after restore, not merely backup success

A successful backup log does not prove that IDs, times, audit records and attachments can be restored. Select representative events and repeat search, relationship traversal, history display and export in the recovery environment. Define restoration authority and approval, treatment of data arriving during restoration, and post-restore reconciliation.

Gate exit: after network loss, upstream outage, edge restart and backup restore, the selected event’s original values, times, qualities, relationships and changes remain reconstructable.

Gate 8 — Accept the system with normal, boundary, failure and reconstruction cases

FAT should generate evidence, not merely demonstrate screens

A standard product demonstration does not test your event boundaries, signals, exceptions or IDs. FAT should use the machine or credible simulated signals and connect input, expected storage, screen result, audit result and export in one test record. Include boundary values, bad quality, missing values, reversed arrival order, duplicates and unauthorized attempts—not only easy normal values.

FAT/SAT scenarios to place in the RFP

SAT repeats the intent with the site’s real machines, network, clock topology, identity service and operators. FAT success is not an automatic SAT pass. Site-specific conversions, latency, permissions, backups and work instructions must be covered.

Remove ambiguity from pass/fail wording

“Displays correctly” invites disagreement. Define preconditions, action, expected data, reconciliation method, permitted exceptions, evidence files and signatories. A major unresolved item should not be passed without a controlled workaround, owner, due condition and retest criterion.

Gate exit: a second person can use the test evidence from normal, boundary, failure and restore cases to reconstruct an event and explain every difference from the expected result.

RFP comparison matrix for a process parameter recording system

Score evidence and testability, not just feature availability.

Give every bidder the same use case, sample fields and failure conditions. Otherwise, a price difference may only reflect different assumptions. Explicitly draw the estimating boundary around machine modifications, signal work, network, clocks, identity integration, migration, FAT/SAT support, training and support.

The quality of a procurement specification also depends on making unresolved matters visible. Before contracting, it is not unusual for signal names and units to differ by machine, for the point at which a lot becomes final to vary by process, or for the department accountable for change approval to remain undecided. Do not bury those matters as vague assumptions inside the price. List the decision deadline, decision owner, affected test items and method for repricing a change. If an assumption changes after the vendor starts design, this register also shows which evidence fields and test records must be revised, reducing the risk that a consequential change is missed.

Treat the operational handover as part of acceptance as well. Do not merely receive a completed tag table at delivery. Verify that the buyer’s own staff can follow the approved procedure to add a field, update equipment, revise a recipe, change an operator’s authority, investigate a communications outage and confirm a recovery. Handover must cover more than screen operation: it must explain which original records to protect during an anomaly, whom to notify, and under what conditions replay or correction may be authorized. Otherwise, evidence quality can collapse after go-live changes. Confirm that procedures, responsibility matrices, registers and test records use the same terms and identifiers.

Finally, reuse the representative events selected for acceptance in periodic post-go-live checks. Do not test only whether a screen is visible. Confirm from the same perspective that original values, timestamps, quality states, relationship keys, change history and export still preserve the evidence chain accepted at handover. When equipment or software updates change a data path, retest the affected representative events and retain the before-and-after results. Connecting the RFP, FAT/SAT and operational checks through one evidence model makes it easier to prevent a system that was orderly only at procurement from gradually becoming ineffective.

Investment decision — replace every TOMAS TECH illustrative input with your own

The following model assumes that better evidence can reduce some evidence-retrieval labour and some overly broad containment. It is an explanation model, not a market benchmark, a typical Thai-factory result or a guarantee. Build your inputs from your own event history and have quality, production and finance agree on avoidability.

Shared TOMAS TECH illustrative assumptions

• Initial deployment: 2,400,000 THB
• Annual software, support and verification: 360,000 THB/year
• Evidence-retrieval labour: 16 cases/month × 5 people × 1.5 hours × 130 THB/hour × 12 = 187,200 THB/year
• Containment events: 18 events/year × 1,200 units/event × 240 THB/unit

The model treats all 187,200 THB/year as a benefit. In real operations, investigation itself does not disappear, so you should apply your own reducible share. The containment benefit varies the share avoidable through more precise scope identification.

Conservative case: 10% avoidable share

Containment benefit:

18 × 1,200 × 240 × 10% = 518,400 THB/year

Gross annual benefit:

187,200 + 518,400 = 705,600 THB/year

Net annual benefit:

705,600 - 360,000 = 345,600 THB/year

Simple payback:

2,400,000 ÷ 345,600 = 6.944... ≈ 6.94 years

Base case: 20% avoidable share

Containment benefit:

18 × 1,200 × 240 × 20% = 1,036,800 THB/year

Gross annual benefit:

187,200 + 1,036,800 = 1,224,000 THB/year

Net annual benefit:

1,224,000 - 360,000 = 864,000 THB/year

Simple payback:

2,400,000 ÷ 864,000 = 2.777... ≈ 2.78 years

Upside case: 30% avoidable share

Containment benefit:

18 × 1,200 × 240 × 30% = 1,555,200 THB/year

Gross annual benefit:

187,200 + 1,555,200 = 1,742,400 THB/year

Net annual benefit:

1,742,400 - 360,000 = 1,382,400 THB/year

Simple payback:

2,400,000 ÷ 1,382,400 = 1.735... ≈ 1.74 years

The model does not say that the investment will pay back. It shows that the decision is dominated by event frequency, units contained per event, consequence per unit, avoidable share and annual cost. Build inputs from your own history before procurement and define post-implementation benefit verification alongside FAT/SAT.

Thailand BOI’s Q1 2026 release reports 61 Smart and Sustainable Industry applications totalling THB 7.071 billion. This is investment context, not evidence of project ROI or incentive eligibility. Check BOI’s Smart and Sustainable Industry page and confirm your project directly with BOI.

Pre-procurement checklist

Business and data

• The supported decision and user are defined.
• Event boundaries cover normal, interrupted and rework cases.
• The evidence register includes source, system of record, time, quality, relationship key and owner.
• Recipe, setpoint, actual, event and manual context are separated.
• Unassociated data is preserved and repaired through a controlled procedure.
• Join keys to 4M change, quality, inspection and disposition are defined.

Technology and operations

• Source Time, Receive Time, quality state and clock health are retained.
• Outage, replay, deduplication, full-buffer and restart behaviour is specified.
• Correction, override and audit preserve original values.
• Cybersecurity reflects OT performance, reliability and safety constraints.
• Retention, archive, export, migration and recovery can be tested.
• Owners for register change, incident, access and training are named.

Contract and acceptance

• Every bidder receives the same scope and test data.
• Machine work, network, clock, identity and migration are in the estimating boundary.
• FAT/SAT covers normal, boundary, failure, restore and reconstruction cases.
• Evidence, deviations, workarounds and retest rules are defined.
• Every input in the benefit model has been replaced with a company baseline.

FAQ — process records and manufacturing history management

What is a process parameter recording system?

It captures recipe versions, setpoints, actuals, states, alarms, timestamps and data quality from machines, PLCs and sensors, and associates them with lots or serials, equipment, people, changes, inspection and disposition. Its essential outcome is reconstructability while preserving original records—not maximum tag volume.

How much process data should manufacturing history management retain?

There is no universal answer. Define the scope from investigations, release decisions, customer requirements, contracts, regulation and process risk. Before collecting every tag at high frequency, build the evidence register and define recipe, setpoint, actual, time, quality and relationship keys.

How does 4M change management differ from process parameter recording?

4M change management controls request, assessment, approval, implementation and verification. Process recording shows where and when the approved change actually reached a machine and recipe version, and what actual and inspection results followed. Neither replaces the other.

Should it be integrated with a quality data management system and inspection acquisition?

Users should be able to trace the chain continuously, but every function does not have to live in one product. Systems can remain specialized when stable event, lot/serial, time and disposition keys connect them and the system of record and change owner are clear.

Does OPC UA automatically make a record trustworthy?

No. OPC UA provides useful standard concepts for timestamps and quality in DataValue, Historical Access and auditing. The equipment, application, identity layer, database and operating procedure must actually retain those semantics and prove them in FAT/SAT. Accept evidence, not a protocol name.

What belongs in FAT versus SAT?

FAT validates the agreed model using real or credible simulated signals across normal, boundary, bad-quality, correction, outage and restore cases. SAT verifies the same evidence chain with site machinery, network, clocks, identity, backup and operators. Both aim at event reconstruction.

Do FDA and MHRA data-integrity expectations apply to every factory?

No. The FDA source cited here is for drug CGMP and the MHRA source is for the regulated GxP domain. Regulated sites should have quality and regulatory specialists determine applicability. Other factories may use the principles as references while setting obligations from customer, contract and quality risk.

How should we evaluate return on a process parameter recording system?

Use your event frequency, units contained, consequence per unit, avoidable share, evidence-retrieval labour and annual cost. The 2,400,000 THB and other figures above are TOMAS TECH illustrative assumptions, not prices or promises. Reuse the equations, not the inputs.

Conclusion — buy reconstructability, not a tag count

The value of a process parameter recording system is not the amount of data stored. It is the ability to return to trustworthy evidence when a decision is required. That means one coherent design for decision and event boundaries, the evidence register, separation of recipe/setpoint/actual, Source and Receive Time, quality, stable keys, non-destructive correction, offline operation, cybersecurity and recovery.

In the RFP, do not score “supported” or “compliant” without a test. Specify inputs and expected evidence for normal, boundary, failure, correction and recovery. If a second person can reconstruct the same event from FAT/SAT evidence, the design is far more likely to support a real investigation after go-live. A feature list that cannot pass that test proves very little.

TOMAS TECH can help structure the RFP scope, evidence register and FAT/SAT scenarios even while machine signals and ownership are still being clarified. If you are at the evaluation stage, you are welcome to use our English contact form for a low-pressure initial discussion.