PI Vision tells you what the plant is doing. Seeq helps an engineer work out why it did something last Tuesday. Sites that treat these as competing purchases usually end up paying for one tool to do a job it was never designed for.
Our principal consultant spent 18 years on operational data and reporting projects for BHP, Rio Tinto, Senex Energy and Mackay Sugar, delivered while working with previous consulting employers. We resell neither product.
PI Vision is monitoring for a broad population, built on asset-relative displays so one screen serves every asset of the same type. Seeq is investigation for a small population, built to cleanse signals and reason about periods of time.
If your engineers export to Excel whenever they need to answer a real question, you have the gap Seeq fills. If your supervisors cannot see equipment state, more analytics will not help.
A browser client over the PI System. Displays are built against an Asset Framework template and then applied to every instance of that equipment, so covering four hundred pumps does not mean building four hundred screens. Users trend ad hoc, check status and drill into recent history.
Question it answers: what is happening, and what did this asset do recently?
An analytics application that connects to your existing historian rather than storing data itself. Engineers cleanse signals, align periods that are not the same length, define conditions that describe events, and assemble the result into a document that someone else can reopen and check. Python is available for the parts that need it.
Question it answers: why did this happen, how often does it happen, and what changed?
Read down the row that matches what your people are trying to do.
| Aspect | PI Vision | Seeq |
|---|---|---|
| Primary job | Monitor current and recent equipment state | Investigate why something happened and how often |
| Typical user | Operators, supervisors, anyone who needs to look | Process and reliability engineers, a smaller group |
| Stores data | No. Reads the PI Data Archive it belongs to | No. Connects to PI, AVEVA Historian, Canary, IP.21, PHD, SQL and cloud sources |
| Signal cleansing | Not a feature. Bad data shows as bad data | Core capability. Outliers, dropouts and stale values handled before maths |
| Reasoning about events | Ad hoc trending. No concept of a period as an object | Conditions and capsules. Periods become countable and comparable |
| Scaling across assets | Asset-relative displays. One definition serves every instance of a template | Asset-aware, and inherits whatever hierarchy your historian exposes |
| Reproducibility | A display is a display. Ad hoc analysis leaves no trail | Worksheets and Organizer documents can be reopened and audited |
| Depends on asset modelling | Heavily. Display templates come from Asset Framework | Benefits from it. Works without it, at the cost of manual tag wrangling |
| Commercial shape | Part of the PI System you already licence | Separate subscription, sized by user population |
Connector coverage and licensing for both products change. Confirm current detail with AVEVA and Seeq before committing to an architecture.
Before comparing feature lists, watch what your engineers actually do when someone asks a hard question.
The common pattern on sites with a mature historian and no analytics layer is that investigations happen in spreadsheets. An engineer pulls a few months of tags out, builds a workbook, deletes the rows where the sensor was clearly wrong, works out an answer, and emails a chart. The answer may well be correct. What the site has no way of knowing is how it was reached, because the judgement calls live in one person's deleted rows.
That matters more than convenience when the number ends up in a regulatory submission or a capital case. A conclusion nobody can reproduce is a conclusion the organisation cannot defend, and the person who built the workbook eventually changes jobs.
Adding displays does not address any of this, which is why a site can have excellent PI Vision coverage and still have no repeatable analysis. The reverse also holds: buying an analytics tool for a site whose historian has no asset context gives engineers a faster way to wrangle raw tags, and the tag wrangling was the actual problem.
The last option is the one worth sitting with. A tool purchase made while nobody trusts the underlying data produces a faster route to numbers people still argue about.
No, and sites that buy it as one are usually disappointed. PI Vision is a monitoring tool: it shows the current state of equipment on displays that operators and supervisors watch, and it does that on screens built once against an asset template and applied to every instance. Seeq is an investigation tool: a process engineer opens it to work out why a value moved, cleansing signals, comparing periods and defining the conditions that describe an event. Neither does the other job well. Most sites that already run PI Vision keep it and add Seeq for the engineering population.
Yes. Seeq does not store your process data, it connects to whatever already does. It has connectors for the PI System, AVEVA Historian, Canary, Aspen InfoPlus.21, Honeywell PHD and a range of SQL and cloud sources, and it reads from them live rather than copying the data into its own archive. That is a real advantage during evaluation, because you can point it at production history without a migration project. It also means Seeq inherits whatever quality and context problems your historian has, so a site with no asset model gets a faster way to look at uncontextualised tags.
Three things account for most of the value. It cleanses signals, so a sensor that dropped out for six hours does not corrupt an average. It defines conditions, which turn a period of time into an object you can count, compare and aggregate, so questions like which batches ran hot for more than ten minutes become answerable. And it holds an investigation as a document you can reopen and hand to someone else, rather than a trend somebody rebuilt from memory. PI Vision can display a value and let you trend it ad hoc. It cannot reason about periods.
Operational monitoring at scale, cheaply per user. Asset-relative displays mean one screen definition serves every pump of the same template, which is how a site covers hundreds of assets without building hundreds of screens. It is licensed and deployed for a broad viewing population, sits inside the PI System you already run, and needs no additional connector or contract. For the control room and for supervisors checking status, it is the right tool and Seeq would be an expensive substitute.
It depends who is frustrated. If operators cannot see equipment state, that is a display problem and more Seeq licences will not fix it. If your process engineers export to Excel every time they investigate something, that is the gap Seeq closes, and the Excel habit is the signal worth paying attention to because it means investigations are not repeatable and nobody can audit how a conclusion was reached. Sites with both typically give PI Vision to the many and Seeq to the few.
Not comfortably, for high-resolution process data. Power BI is built for modelled and aggregated data, and it refreshes on a schedule rather than reasoning about continuous signals, so signal cleansing and event detection end up as brittle DAX or as a preprocessing job somebody has to maintain. Power BI earns its place one layer up, distributing the aggregated result to management. Using it for process investigation tends to produce a slow report that engineers stop trusting.
Tell us what happens at your site when someone asks a hard question about last month. That answer usually settles the tooling question faster than a feature matrix does.