Minimum Hardware Specs for the Canary System (version 24)

Understanding Resource Demand

Since every Canary Historian could be licensed to potentially scale beyond two million tags and handle a variety of data speeds, system requirements can vary.  

Factors like scan class, change rate, data type, calculations, API queries, client activity, and additional variables can affect system resources.  Below are minimum hardware recommendations for a typical enterprise solution consisting of multiple sites each logging data to a corporate Canary Historian. 

Minimum Hardware/OS Recommendations

Canary is compatible with Windows Server 2019/Windows 10 (1903) and later.

Collector and Sender Machine

- Dual Core 2.0 GHz Processor

- 8 GB of RAM

- .NET 4.7.1 or greater

- 250 GB HDD @7200 RPM

Site Historian Server

- Quad Core 2.4 GHz Processor

- 16 GB of RAM

- .NET 4.7.1 or greater

- 500 HDD @7200 RPM

Corporate Historian Server

- Six Core 2.4 GHz Processor

- 32 GB of RAM

- .NET 4.7.1 or greater

- 4 TB HDD @7200 RPM

Storage Methodology and Considerations

The Canary Historian stores tags, organized into groups, referred to as DataSets.  By default, each DataSet archives data into daily Historical Database Files, also referred to as HDB files. Each HDB file contains all of the tag names, properties, timestamps, values, and qualities for an entire day.

Of course, HDB files are optimized for storage, and at the end of each day, are validated and compressed automatically by the Historian using a loss-less compression algorithm. Because it is loss-less, all original data values are maintained without using any interpolation while still featuring a 3:1 compression ratio.

Several factors contribute to the overall size of each HDB file:

Number of tags

Rather obvious, but the higher the tag count the more data; however, this is usually the only component that is considered when someone asks the "how much storage is required" question!

Length of tag names

Canary only writes the tag name one-time for each HDB file, but unnecessarily long tag names mixed with high tag counts (100,000+) can increase the footprint.

Sample rate

How fast the Canary Data Collector is requesting data will contribute to the number of timestamps, values, and quality scores that are written to an HDB file. Although Canary is super efficient by ignoring unchanged values, choosing to update the timestamp rather than duplicate the entry, fast sample rates on some analog tags can create a lot of values. Imagine a temperature sensor with one hundredth of a degree accuracy.  If polled every second, you would nearly always see a value change.

Using deadbanding features when setting up logging sessions with the Canary Data Collectors can help avoid this issue and provides balance for faster scan classes without having to worry about unnecessary data storage.

Date change rate

Just because tags are being scanned often does not mean they change often. As mentioned above, Canary writes by exception, ignoring unchanging values and updating the timestamp of the current value; however, understanding how often your tags typically change goes a long way to predicting what your storage footprint may look like. Some tags, like production values, alarms, or high/low set points, may only change a few times a minute, or only a couples times a day. In contrast, some tags like hydraulic pressures, might have data values that change a hundred times a second, all of which are valuable to record.

Data type

The type of data you collect will impact the overall storage requirements.  These could range from single byte Booleans to 8 byte floats.  Strings can also be stored.

Canary stores up to 100k unique strings a single time within an HDB file.

Timestamp resolution

If you don't need millisecond resolution in your timestamps, use the Timestamp Normalization feature of the Canary Data Collectors to reduce your timestamps to an appropriate length.  Long timestamps written tens of thousands of times per day per tag can add up.

Tag metadata

Depending on the type of Data Collector being used, you have the ability to record metadata, or properties, along with your tag values and quality scores.  Similar to tag names, lengths of strings used will impact overall DB file size.  

Estimating Storage Requirements

To estimate the potential hard driving sizing for your project, consider the following potential scenarios, both representative of typical complex systems.

7 Year Archive - 664 GB

• 10,000 tags
• 30% boolean, 20% analog integer, 50% analog float
• Average sample rate - 5 seconds
• Average change rate - 30%

7 Year Archive - 1.30 TB

• 10,000 tags
• 30% boolean, 20% analog integer, 50% analog float
• Average sample rate - 3 seconds
• Average change rate - 35%

Here are additional details of storage needs, based solely on data type.

1,000 two byte boolean tags

1,000 four byte analog float tags

1,000 four byte analog integer tags

With so many potential factors, estimating necessary storage can be difficult. Ultimately, the best way to predict what your long term storage needs require is to find the average HDB file size over a course of a week or month. Using this value, you will be able to have a better understanding of how much space you will consume over the course of years.

Read Activity

The number of clients connecting to the Historian to consume and read data out is more resource intensive than the writing and storage of data. Clients may be asking for months or years worth of data through Axiom, ODBC, Excel Add-in, or the Read API. On top of that, the Publisher and Calculation services also request data for their processes. This is important to keep in mind when determining the resources a Canary server may need.