Examples of Advanced Concepts and Configurations

Updated March 2023

Introduction

This page describes some advanced concepts in how to implement monitoring via the Tempurity™ System.

For a general overview of the Tempurity System architecture see the brief monitoring architecture overview.

The system allows a high degree of redundancy in its hardware and software components that can be anywhere on a computer network. You can implement as many NTMS hardware units collecting from as many freezers (or other instruments) as you want. You can have as many Tempurity Servers as you want collecting data from those NTMS-network-enabled units. You can have as many Tempurity Monitors as you want watching the data coming into Tempurity Servers for alarms and initiating alarm notifications as needed.

For many customers this concept is confusing. What use is redundancy? In this document we describe some example implementations that may facilitate monitoring capability in some situations.

(1) Create a "bellwether" monitored device

In the Tempurity System an alarm notification group applies to both value alarms and communication alarms. From Networked Robotics' perspective if you care enough to want to know that the monitored device is out-of-range, you also care enough to want to know that the machine is not collecting data at all. But sometimes you might want someone in a network group, or someone that is in a position to fix network, power, or connection issues to know of the problem before the scientific or quality staff is aware of it. In these cases consider creating a bellwether device in the Tempurity System.

To do this create a new line ( a new Monitored Device) in the Tempurity Server Configuration utility, giving it the same IP address and port number, but a different name than the "real" monitored device. It will be collecting similar, but not exactly the same data as the "real" device because data will be collected at slightly different times. You should name it in a way that indicates its use as a bellwether, or duplicate, such as "BellJ209". If you want communications alarms only to be relevant, give this device extremely wide value (temperature, co2, humidity, voltage etc.) ranges - such that it will never trip a value alarm. Remember the "real" device will trip value alarms so you will get notified as long as an alarm notification group has been defined with the "real" device in it.

For the bellwether device, set the Comm Error 1 Threshold time to some value lower than for the real device. For example, the bellwether device might have a Comm Alarm Stage 1 Threshold of 15 minutes, while for the "real" device and other nearby instruments, the Stage 1 Communications Threshold might be two hours.

Define an alarm notification group for the "bellwethers". The alarm notification address should be that of your network support personnel.

This configuration allows support staff to realize that there is a problem, before it becomes a laboratory or quality issue. An ultracold freezer takes many hours to become warm to dangerous levels even if the power is off. This type of configuration allows the problem to be fixed while there is little relevance to sample quality.

(2) Create a redundant "monitored device"

The Tempurity System sends a round of alarm notifications at Stage One and another round of alarm notifications at Stage Two. Then it stops sending until the condition is cleared and another alarm occurs.

In order to set up Tempurity to send additional rounds of alarm notifications you can create a redundant monitored device (as described above) with Stage One and Stage Two threshold times that are different than on the "original" monitored device.

For example the "original" monitored device may have a one hour Stage One threshold and a three hour Stage Two threshold. On the duplicate monitored device you can give it the same allowed value ranges but give it a Stage One time of two hours and a Stage Two time of four hours.

In this configuration you will get alarm notifications at one, two, three, and four hours after the freezer is out-of-range.

You must give the duplicate monitored device a different name, for example J-209R1 for the original and J-209R1D as the duplicate.

You can extend this strategy as needed with additional duplicates.

(3) Create a redundant Tempurity Server/Monitor

A Tempurity Server must be running somewhere on your network in order for data to be collected and for alarm notifications to be sent. It can, however, be anywhere on your network - on another floor, in another building, or at another site - just as long as a firewall or other network security does not block access to your Networked Robotics NTMS hardware.

A network failure, computer failure, or power failure at the Tempurity Server can prevent alarm notifications from being sent. A failure at the mail server can also prevent alarm notifications from being sent. While you can install backup systems (power for example) no backup is ever foolproof. For example a UPS will eventually run out if the house power is out for long enough.

Creating a second, redundant Tempurity Server protects you from all three conditions above (or four counting mail) depending on where it is located. Redundant, "backup", or "alternate" Tempurity Servers, are best located as far as possible physically from the "main" or "primary" Tempurity Server. This immunizes the server from "common mode failure". For example if you put the primary server next to the alternate, a power failure would take both servers down. But a power failure at the primary is unlikely to affect the alternate if it is in another state or country. The remote server can detect that data is not being collected and will send alarm notifications (communications alarms if there is a network or power issue, or value alarms if there is a server computer hardware failure and also freezer failure as specified in the alarm notification group. These alarm notifications are best sent through a different mail server from the primary.

A redundant server can be used to create a whole new set of alarm notifications to different people, or to the same people at different times thus allowing the first two advanced implementations above in a different way than suggested above.

Tempurity Monitor instances are named. The name is sent in the alarm notification. You can set things so that you can tell if it was the primary or backup server sending the alarm notification.

back to Support / Tutorials