Founded in 1985, Canary specializes in centralizing, distributing, and analyzing time-series process data. The Canary Historian is a proprietary, non-SQL database that can gather millions of data points without data loss or purging.
With over 17,000 installations around the world, Canary’s solution can be implemented as a small local historian or scaled to a full enterprise level solution, allowing for both a
simple and clean installation as well as on going database administration.
Custom API and ODBC connections allow for easy data flow and a variety of web service clients will ensure the entire organization can access the historical process data when necessary.
Data Acquisition
Canary has many ways to collect process data. The most common form is via OPC server, allowing for direct connections to PLC, SCADA, HMI, or sensor data. The Canary Logger Administrator connects directly to the OPC server and obtains tag names and common profile information from the OPC server. You can configure your data as needed, changing the tag name, description, properties, or dead band. You can also perform a single tag data calculation in the logger. Within a logging session you can create logging groups. Each logging group can be associated with an individual data set, a collection of specific tags that are grouped in the historian for better tag organization.
The logging group can be customized to have preset update rates so that you are not forced to accept the value change rate that is delivered from the PLC/SCADA system. You also have the option to create a logging trigger, allowing you to start and stop logging a group based on a specific tag’s value.
The logger passes data through to the historian using the Canary Store and Forward Service. Store and Forward is comprised of two components, a Sender Service and a Receiver Service. These two services communicate using Windows Communication Foundation (WCF) and all data is encrypted during communication.
The OPC server, Canary Logger, and Store and Forward Service can be installed on the same machine as the Canary Enterprise Historian or sit on their own independent machine and connect to several historians across multiple networks. If contact is lost between the Sender and Receiver Service, the Sender Service will cache data to local disk. When communications return, the cached data is transferred to the historian in time sequence order and removed from the Sender Service.
Not only can one Sender Service connect to more than one historian, but multiple logging machines can also be configured and networked to one historian. These loggers can be setup across multiple networks to monitor remote sites as well. The Canary system does not limit the number of loggers used, and there is no additional charge for adding extra loggers as needed.
The Sender Service can connect to SQL databases using the Canary SQL Connector and a custom API is in place as well. Using the API, you can write your own data into the historian and eliminate the need for both the OPC server and Logger program. The API also supports dynamic tag configuration. In addition to the SQL and API Connector, the Sender Service can import CSV and flat files.
Historian Database
The Canary Historian is a non-SQL, proprietary database that specializes in the storage and retrieval of time-series process data using “lossless” compression. Unlike other historians, Canary never converts actual data to approximations. Also, the historian never purges or dumps data and resolution remains the same whether the data is one day or several decades old.
The database is comprised of self-contained .HDB files and features time-based organization. Every data update contains a Time Stamp, Value, and Quality (TVQ) reading. Generally, unless otherwise specified by the user, files are rolled over nightly, allowing for simple archiving and data retrieval. Files can be taken offline and easily moved from one historian to another making system restoration extremely simple.
The historian is capable of write speeds up to 2,800,000 TVQs per second and can support sub-second data with a timestamp resolution of 100 nanoseconds. Manual data entry is also supported and can be done directly into the historian. Read retrieval speeds approach 4,600,000 TVQs per second and due to the time-based database structure allow for effortless data recall even when spanning large timeframes.
An HDA server is available for third-party consumption as well as the Canary Trend Reporter client.
The Canary Views Service connects to the Historian Service and allows for client interaction via WCF. Canary’s Axiom Core, TopView Alarming client, and Excel Add-In client connect to the historian using the View Service. Also, the View Service allows for both a custom API and an ODBC connectors to be made available for data retrieval.
The Views Service will also allow for connections to multiple other Canary Historians through the Canary Mirror Service as well as third party historians using either HDA or UA. All data transferred between the View Service and other clients is encrypted and passes through a single firewall port.
Canary Administrator
The administrator tool makes data historian admin simple and quick. Using the Canary Administrator, you can manage multiple historians and sites, quickly toggling between them using a simple drop down selector.
From the administrator, you can monitor the logger, sender, receiver, and historian. Visual indicators allow for quick notification if one of the services begin to buffer as well. Email notifications can also be setup to notify users if any data sets stop logging.
You can easily view, stop, and start all services as need be as well as monitor the number of clients that are connected through the View Service. A messages tile allows you to view any warning or error messages, as well as view a full audit of all past messages.
A License Administration tile will make the monitoring, transfer, and configuration of available licenses convenient. It also allows for the addition of licenses through the internet as well as manually entered.
The Historian tile allows you to view each individual data set and configure each one individually. From there, you can set up email notification parameters if a data set stops receiving data as well as schedule rollover frequency. If you would like to purge data after a set period, this can also be scheduled from the Historian configuration tile.
Data sets can be closely monitored and raw data can be quickly obtained as well. Since the database is sorted by time, you can quickly scan through years of data to find an exact period. Then, select the tag and have access to all of the raw data as well as the tag properties. A simple trend tool allows you to visualize the last 1,000 TVQ values without having to leave the administrator.
Security and Access
Security remains as high a priority to Canary as our data integrity. Our focus is on both secure client access as well as data logging security.
Canary Administrator access is restricted to only users or groups designated by the
administrator. This privilege allows for complete monitoring and management of the Canary system, including the monitoring of active client connections and data access services. Also included is the ability to audit all manual data entry as well as original data overwrites.
To guarantee secure data, access to the Canary platform is limited using a Microsoft Windows security infrastructure. An administrator can use local security or active directory user accounts and groups.
Using the above methodology, the administrator can control access to not just historians and data sets, but individual tags as well.
With multiple data logging options available, local and remote access is restricted to a single port per service. Port numbers may be changed from their defaults and communications can be encrypted using either a self-signed certificate or a certificate issued by a trusted root certificate authority.
Data Mirroring and Redundancy
The Canary Historian provides the mirroring of stored data on multiple historians to provide high levels of data redundancy as well as to simplify data retrieval. However, historian redundancy is not limited to pulling data through the Canary Mirror Service. Since each individual Store and Forward Service can point to multiple historians, systems can be developed that push data to multiple databases. This model allows for both communication and database redundancy including fast disaster recovery.
With appropriate security privileges, data reads can be made across any of the connected historians. Users can have access to multiple data sets and tag values across multiple sites while still being restricted to other historians or tag groups.
System Requirements
Canary Enterprise Historians can store tens of millions of tags and can support timestamp resolution to 100 nanoseconds. The system requirements below are based on a total system size of 1,000,000 tags with up to 300,000 tags at each local historian. Core count, processor speed, and hard drive space may need to increase as the system increases. It is assumed that each data tag has one second resolution with a sixty percent change rate.
OPC and Logging Server Store and Forward Server
- Dual Core 2.0 GHz Processor
- 8 GB of RAM
- Windows 7 64 bit or greater
- .NET 4.5 or greater
- 500 GB HDD @7200 RPM
Local Historian Server
- Quad Core 2.4 GHz Processor
- 16 GB of RAM
- Windows 7 64 bit or greater
- .NET 4.5 or greater
- 1 TB HDD @7200 RPM
Corporate Historian Server
- Six Core 2.4 GHz Processor
- 32 GB of RAM
- Windows Server 2012 or greater
- .NET 4.5 or greater
- 2 TB HDD @7200 RPM
