Introduction

The goal of the Photizo Testing and Alert System is to have a plugin architecture whereby arbitrary tests may be added and configured; data passed to these tests; and results returned and recorded from these tests. This documents discusses the requirement and design decisions related to this section of Photizo.

Test Structure

Input

Data

Since the tests can be pretty much anything (see below), the best solution is probably to pass the entire list of readings to the test. Since Python is implicitly pass-by-reference, this will incur no more overhead than passing a four byte integer (or eight byte on 64 bit systems).

• The data will probably be wrapped in a object (which knows the required column name), which has a .value() method or some such so that the test will not need to know the column name.
  • Thought needs to be given to tests which may require more than one value per reading for its test. ** Example: comparing three redundant sensors.
  • Possible solution: The wrapper object will take a single column name or a list of column names. .value() will return the only (or first column) while .value(1) will return the second one, etc. The test will be coded to retrieve its data in this way.

Configuration

The configuration for a test can also be passed in. In the Photizo configuration file, parameters for the test will be added in a section for defining tests. These parameters will be passed to the test as a standard dict. This way, things such as date-range/temperature tests can be generalized, and not hard coded.

• I notice I’m still thinking of a framework in which each sensor has tests. It also needs to be general enough that tests can simply be defined, and then the sensors on which to run them can be configured.
  • One sensor can have zero or more tests
  • A test can be defined, and given one or more sensors to use for the test.

Testing the values

The test can be anything that Python can do. Possibilities include:

• Single value tests (sensor range)
  • Restrictions on date range
• Multi-value tests
  • Looking over the past N days, construction a curve, looking for anomalous values.

Output

Output will be GREEN, YELLOW, or RED (probably enums), along with a message describing the possible error condition.

Storage

The results from the tests will need to be stored. Elements needing to be stored:

• Time at which test ran
• Time of data analyzed
• Station
• Test
• Sensors to which test applies
• Test result
• Message result

Results will be derived from these, and will be displayed on a dash-board like layout, with drill-down for further analyzing test failures. (:notoc:)