Skip to content

Stop Logs as Seeq Conditions

ABB Knowledge Manager records every stop of a plant's equipment in its stop logs: when the stop started and ended, its major cause, the detailed reason, the shift, and more. The ABB Knowledge Manager connector can bring those stop logs into Seeq as conditions, one per stop log and one capsule per stop. Downtime then sits beside the process signals that already come from the same Knowledge Manager, in the same asset tree, ready for Seeq's analysis tools.

This is new in the next release and is off until you turn it on, per connection.

What it makes possible

  • See stops on the trend. Add a stop log to a worksheet and every stop appears as a capsule under the process signals, so a temperature excursion, a feed change or an alarm can be read against when the equipment stopped and why.
  • Analyze downtime by cause, reason or shift. Each capsule carries the stop's fields as properties. A capsule table lists them; Seeq's condition tools filter on them, for example only mechanical stops:
$stops.keep('MajorCause', isEqualTo('Mechanical'))

and turn them into totals over time (Signal from Condition: total duration of stops per day, week or month). - Look at what happened before a stop. Seeq can work back from each stop's start (for example the hour before it), so the process conditions leading up to stops of one cause can be compared. - Keep stops out of production figures. Removing the stop periods from a signal gives running-time averages and KPIs that are not pulled down by downtime:

$production.remove($stops)
- Combine with everything else in Seeq: other conditions, other datasources, scorecards and reports.

What you see in Seeq

  • A Stop Logs asset under the plant, with the stop logs in their own Knowledge Manager folders. The signal tree is unchanged.
  • One condition per stop log, named as in Knowledge Manager, carrying the log's Knowledge Manager ID, folder, group and channel numbers.
  • One capsule per stop, with the properties chosen for the connection. By default: MajorCause, ReasonText, Shift, StopType, and Duration (h). Other stop fields can be added (secondary reasons, ERP status and the cause dimensions Knowledge Manager supports).
  • A stop still in progress runs to the present and is drawn as uncertain until it ends, with Open = true. Seeq asks again later and shows the stop's end once Knowledge Manager records it.
  • A stop longer than the condition's maximum duration (30 days by default, adjustable) is shown up to that length and marked Truncated = true; its real length stays in Duration (h).

Stops are read from Knowledge Manager when Seeq asks for them, a block of time at a time, as for the signals. Nothing is copied in advance, and Knowledge Manager is only read, never written.

Turning it on

A Seeq or agent administrator adds a StopLogs block to the connection in the connector's configuration, then requests an index:

"StopLogs": { "Enabled": true }

Everything else has a default: maximum duration, which stop logs (by name, with wildcards), which properties, and how far the stops are treated as final. See Stop logs in the user guide for every setting.

We suggest starting with one connection and the people who analyze stops, and agreeing two things with them: - which properties are useful; - how long after a stop its cause and reason are usually entered, which decides how far Seeq should treat recent stops as final (LastCertain).

Turn it on only for a Knowledge Manager that keeps stop logs. With stop logs on, an index that gets no stop logs back is treated as a problem on the Knowledge Manager side: it keeps the existing conditions and is shown as failed in Seeq.

What is not included

  • Who entered a reason. Knowledge Manager stores the user who entered each stop's reason, and a free-text explanation. Neither is offered: capsule properties are visible to everyone who can read the datasource in Seeq, often a wider group than Knowledge Manager's own users, and attributing stops to people can need agreement under privacy rules or with employee representatives. If your site needs them, talk to us; they can be added as an explicit opt-in.
  • Writing back. Stops are read only. Causes and reasons are entered and corrected in Knowledge Manager as today.
  • Other Knowledge Manager event data (for example LIMS samples) is not part of this feature.

What it needs
Connector The release that adds stop logs (see the release notes)
Knowledge Manager The ExtDataAccess web service with its stop-log calls (GetStopLogList, GetStopLogData), the same service the connector already uses for signals
Stop logs Configured in Knowledge Manager, each with its Knowledge Manager ID. A stop log without one is left out and named in the agent log
License The connector's existing license; stop logs use no extra datasources