Canary Historian architecture: collectors, store and forward, Views, Axiom and how it is licensed

The Canary System from Canary Labs is a process historian with its own collectors, a store and forward service, a time-series database, an asset layer called Views and a set of clients. This article explains, from Canary's own documentation, how data moves from the plant into the Historian, where each part should run on a plant network, how users read the data and how Canary licenses the system. For what a historian does in general and how it compares with FactoryTalk Historian, AVEVA PI System and Ignition, see What is a process historian.

What the Canary System is made of

Canary's product page lists these components:

How data gets in: collectors

Canary's knowledge base lists one collector per source type:

• OPC UA and OPC DA, following the OPC Foundation standards, with deadbands, update rate, metadata and data transformation;
• MQTT, following the Sparkplug B specification 2.2 and 3.0, and also JSON payloads, with several brokers and TLS;
• SQL: Microsoft SQL Server, MySQL and Oracle, read from a queue table at a set interval, not from the production tables;
• CSV files, imported when they arrive;
• CygNet, through its .NET API;
• a module for Inductive Automation's Ignition, which logs Ignition tags to one or more Canary Historians;
• a gRPC or Web API for custom collectors.

Canary states that collectors are not licensed: they come with the Canary System. A tag reaches the Historian only through one of these collectors, so the first design question is what software in the plant already holds the data. For Allen-Bradley PLCs, that is covered in Logging Allen-Bradley PLC data to Canary.

Store and forward: what happens when the network drops

Each collector hands its values to a store and forward service, which pushes them to the store and forward service paired with the Historian. The two talk over gRPC; when the collector is on another machine, Canary describes a single gRPC endpoint on port 55291 between them. If that link is lost, the collector-side service caches data to its local disk. By default it stops writing new values to disk when only 4,000 MB of free space remains. When the link returns, it backfills the Historian with the buffered values and clears the cache. The service also watches the connection and can notify an administrator when a DataSet stops receiving data.

Two rules in the same article matter for design. The OPC UA and OPC DA collectors reject values with historical or duplicate timestamps, so they are meant for live data, not for back-loading old records; other collectors can be set to allow insertions. And when two OPC collectors log the same tags for redundancy, store and forward keeps the first value that arrives for each timestamp ("first-in-wins").

Where each part runs

Canary's architecture article gives several layouts:

Canary also notes that the components can be placed to match the Purdue / ISA-95 levels, with Publisher and the ODBC server at level 3 or 4, and that for more than about 50 concurrent clients it is worth running separate Views services for Axiom users and for API or third-party applications.

Reading the data: Views, Axiom and other clients

Clients do not read the Historian directly. Views is the gate: it controls client access, can stitch several Historians together, and holds Virtual Views, the asset model that groups raw tags into equipment and areas. Axiom is Canary's client for dashboards and trends, the Excel Add-in brings the same data into spreadsheets, and Calcs & Events connects through Views, calculates KPIs or detects events, and writes its results back through store and forward; events are kept in a local SQLite database by default. Other software reads through the ODBC server or the Read API.

How Canary licenses the system

Canary's pricing page describes the model without needing a quote:

• a licence is sized by tag count, where a tag is one stream of time-series values (also called a point);
• Axiom and Excel clients are unlimited, on perpetual and on subscription licences;
• a perpetual licence is paid once, with CustomerCare (updates, security patches, support) renewed each year; a subscription includes CustomerCare;
• Canary also offers a hosted private cloud and optional add-ons such as the ODBC Connector.

This article does not give prices. The input any quotation needs is a reliable tag count: how many tags will be logged now and in the next few years.

What to agree before installing

• The tag list and count, grouped by source (OPC server, MQTT broker, Ignition gateway, SQL table).
• Where each collector and its store and forward service will sit, and how much free disk it has for buffering.
• The firewall rules between levels: the gRPC port between store and forward services (55291) and the connections clients need to reach Views.
• Whether the Historian must be redundant, and how many concurrent clients will connect.
• How tags will be organised in DataSets and in Virtual Views, so that names and the asset model are settled before data starts to build up.

How TDL approaches it

TDL Industrial Automation is a Canary Certified Partner, listed on Canary's partner page for Vietnam. Our historian work so far has been on Rockwell Automation platforms, for example FactoryTalk View SE with FactoryTalk Historian on the Vinh Hoan FeedOne aquafeed plant. On a Canary project we start from the tag list and the plant network: which PLCs and SCADA servers hold the data, where collectors and store and forward can run, and which levels the firewalls separate. More on SCADA and historian services: SCADA, HMI and plant data integration.