Reference · built on requestOperator by FibricProduction & maintenance

Batch Deviation

Watches a running batch against its recipe limits and proposes the deviation record and operator action when a value leaves them.

Request accessPricing ↗

About

Batch Deviation is an operator for excursions during a running batch. The ISA88 committee's scope is guidelines for the design and specification of batch control systems, including recipe management; this operator works from the recipe limits your batch record carries. It reads process values from AVEVA PI System through PI Web API, batch phases as PI event frames, and controller tags over OPC UA where the historian lags.

When a value leaves its limit inside a phase, it proposes the deviation record in Jira or ServiceNow and the operator action the recipe lists, and proposes an event frame that keeps the values with the batch. It never touches a setpoint.

This is a reference listing. It documents what Fibric would read from Batch Deviation and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Process values for the running batch: PI Web API GetRecorded and GetInterpolated on the points the recipe names, or live changes over a channel
  • Batch phases and their start and end times as PI event frames, with the referenced elements and captured values
  • The batch record and its recipe limits per phase, kept in a Tulip Table or a sheet: parameter, low limit, high limit, and hold time
  • Controller tags observed over OPC UA with the sourceTimestamp the controller applied, where the historian lags the line
  • Alarm events Ignition has journaled for the same tags: source, priority, eventtype, and eventtime from alarm_events
  • Deviation issues already open in Jira or ServiceNow for the batch, so one excursion does not raise two records

Proposed actions

  • Target capability: propose a deviation record in Jira or ServiceNow when a value leaves its recipe limit in a phase: batch, parameter, limit, values, duration
  • Target capability: propose the operator action the recipe lists for that excursion, as a task assigned to the person on the batch, for their acknowledgement
  • Target capability: propose a PI event frame for the excursion through CreateEventFrame with CaptureValues, so the values are kept with the batch
  • Target capability: propose an annotation on the phase's event frame through CreateAnnotation, recording the deviation and the action taken
  • Target capability: propose closing the deviation once the batch record shows the disposition, with the closing note drafted for the reviewer

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Record an excursion from PI as a Jira issue

    A temperature attribute leaves its phase limit. The operator reads the recorded values, proposes a Jira issue with batch, phase, limit, peak, and duration, and proposes a PI event frame that captures the values with the batch.

    With AVEVA PI System, Jira

  • Raise a ServiceNow deviation with the recipe's action

    Limits per phase come from a Tulip Table. On an excursion the operator proposes a ServiceNow record and the operator action the recipe lists, assigned to the person on the batch.

    With Tulip, ServiceNow, AVEVA PI System

  • Fill the gap where the historian lags

    Tags the historian does not hold are subscribed over OPC UA with their sourceTimestamp. Ignition alarm_events for the same tags are attached to the proposed record so the reviewer sees what the HMI showed.

    With OPC UA, Ignition, Jira

Requirements

  • A historian connector: AVEVA PI System through PI Web API, with the batch's points or AF attributes readable
  • A batch record with recipe limits per phase: a Tulip Table, or the batch record table your MES holds
  • A work-management connector for deviation records: Jira or ServiceNow
  • Optional: an OPC UA server for tags the historian does not hold, and Ignition for alarm history
Authentication
The historian, controllers, batch tables, and trackers are reached through their own connectors and the accounts those connectors carry; the operator has no account of its own.

Limits

  • PI channel messages are not guaranteed to arrive in chronological order and poll at ChannelPollingInterval, 1000 milliseconds by default, so sub-second excursions can be missed
  • It compares values with limits. Whether an excursion affects the product is a decision for quality review, and the deviation record says so
  • It never changes a setpoint, holds a phase, or aborts a batch. The operator action is a task for a person
  • Recipe limits are read as written in the batch record. A limit typed wrongly produces a deviation that is wrong

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Batch Deviation ↗

Questions and answers

What does the batch reviewer approve?
The deviation record and the operator action. You see the batch, the phase, the parameter, the limit, the values with their timestamps, and the action the recipe lists. Approve, edit the text, or dismiss. The event frame and annotation in PI are separate proposals.
What record remains?
The values read with their timestamps, the limit applied, the record as Jira or ServiceNow created it, the event frame or annotation written to PI with its WebID, who approved each and when, and the reversal for each write.
Can it act on the batch itself?
No. It never writes a setpoint, calls a method, holds a phase, or aborts a batch. Its writes are records: an issue, a task, an event frame, an annotation. Each is applied once after approval.
Ask about Batch Deviation

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy