Developer Information

Development Goals

1. Usability: GSAP should be user friendly and easily adaptable to the user's system of interest.
2. Compatibility: GSAP should be compatible across many OSs (Windows, Mac, Linux).
3. Consistency: GSAP should be as consistent as possible with standards, naming schemes, etc.
4. Extendability: GSAP should be designed to be modular, supporting the extension to include additional tools, configurations, and features.
5. Scalability: GSAP should be designed to be scalable, capable of running with many prognosers and communicators, and large amounts of data.

Components

GSAP consists of the framework and support library, each described below.

Framework

The GSAP framework embodies the core functionality for running and initiating Prognostics. It is deployed by the creation of Models, Prognosers, and Communicators.

Support Library

The support library is a collection of tools designed to support Prognosers, Communicators, and the Prognostics Framework. Some examples of such tools are the logger, statistics tools, filters, configuration management tools, etc.

Things to Keep in Mind

Compiling: CMake will be used in the first steps to generate makefiles and compile Framework and Support Libraries.

Running a GSAP Deployment: This requires an entry point that essentially points the Prognostic Manager to the relevant primary configuration file. Visit example/progMain.cpp as an example.

Prognosers:

1. Prognostic systems that do not follow a model-based structure: a new prognoser is created to support a new method for performing Prognostics.
2. Prognostic systems that do follow a model-based structure: do not require the creation of a new prognoser, only the creation of a new model that will be used by the ModelBasedPrognoser class.

Communicators: GSAP comes with the three standard communicators: Playback, Recorder, and Random, but new communicators may be added to adapt GSAP to the system of interest.

Observer and Predictor Algorithms: The same system model serves as the framework for which the chosen Observer and Predictor algorithms are applied.

Logging

ThreadSafeLog contains a singleton class for logging messages for debugging. This should be used heavily throughout GSAP. Create a reference to the singleton logger object using the following line:

1. Log & logger = Log::Instance();

To use the log you can then use the WriteLine and FormatLine functions. These functions take the logging level (described below), the tag (Some identifier for that piece of code: Could be a class name), and the message. For example

1. logger.WriteLine(LOG_FATAL, "ClassName", "Error Description");
   
2. logger.FormatLine(LOG_WARNING, "ClassName", "Key %s not recognized. Did you mean %s? Ignoring key", key, otherKey);
   
3. logger.LogVerbatim("Some text");
   

The first argument is the level of the log. Choose from the following list:

1. OFF: No logging at all will be performed.
   
2. FATAL: Critical errors that would normally result in termination of the program.
   
3. ERROR: All errors not covered by FATAL
   
4. WARN: Potentially, but not definitely, incorrect behavior
   
5. INFO: Information about normal actions taken by the plugin.
6. DEBUG: More verbose information useful for debugging.
7. TRACE: Log all the things!

The verbosity can be set anywhere using logger.setVerbosity(). All messages of that severity or above will then be written to the log. For example. If you have the following lines:

1. logger.WriteLine(LOG_TRACE, "Example", "Trace");
2. logger.WriteLine(LOG_WARN, "Example", "WARNING!");

If verbosity is set to INFO, only the second line will be written. If verbosity is set to ERROR, nothing will be written. Finally, if verbosity is set to TRACE, both lines will be written.

NOTE: DO NOT use setVerbosity inside any Framework or Support files. This should only be done by the end user in their main file.