Getting Started

https://mybinder.org/badge_logo.svg

The NASA Prognostics Center of Excellence (PCoE) Prognostics Models Package (prog_models) is a Python framework for defining, building, using, and testing models for prognostics (computation of remaining useful life) of engineering systems. It also provides a set of prognostics models for select components developed within this framework, suitable for use in prognostics applications for these components and can be used in conjunction with the Prognostics Algorithms Library to perform research in prognostics methods.

The foundation of this package is the class prog_models.PrognosticsModel. This class defines the model interface and provides tools for analysis and simulation. New models must either be a subclass of this model.

Installing

Installing Pre-Release Versions with GitHub

For users who would like to contribute to prog_models or would like to use pre-release features can do so using the ‘dev’ branch (or a feature branch) on the prog_models GitHub repo. This isn’t recommended for most users as this version may be unstable. To use this version, use the following commands:

$ git clone https://github.com/nasa/prog_models
$ cd prog_models
$ git checkout dev
$ pip install -e .

Summary

A few definitions to get started:

  • events: something that can be predicted (e.g., system failure). An event has either occurred or not occurred.

  • event state: progress towards event occurring. Defined as a number where an event state of 0 indicates the event has occurred and 1 indicates no progress towards the event (i.e., fully healthy operation for a failure event). For gradually occurring events (e.g., discharge) the number will progress from 1 to 0 as the event nears. In prognostics, event state is frequently called “State of Health” or “SOH”.

  • inputs: control applied to the system being modeled (e.g., current drawn from a battery).

  • outputs: measured sensor values from a system (e.g., voltage and temperature of a battery).

  • performance metrics: performance characteristics of a system that are a function of system state, but are not directly measured.

  • states: Internal parameters (typically hidden states) used to represent the state of the system- can be same as inputs/outputs but do not have to be.

  • process noise: representing uncertainty in the model transition (e.g., model uncertainty).

  • measurement noise: representing uncertainty in the measurement process (e.g., sensor sensitivity, sensor misalignements, environmental effects).

Use

The best way to learn how to use prog_models is through the tutorial. There are also a number of examples that show different aspects of the package, summarized and linked below:

  • examples.sim

    Example of a battery being simulated for a set period of time and then till threshold is met.


  • examples.benchmarking

    Example benchmarking the computational efficiency of models.


  • examples.new_model

    Example defining and testing a new model.


  • examples.sensitivity

    Example performing a sensitivity analysis on a new model.


  • examples.events

    Example further illustrating the concept of ‘events’ which generalizes EOL.

    ‘Events’ is the term used to describe something to be predicted. Generally in the PHM community these are referred to as End of Life (EOL). However, they can be much more.

    In the prog_models package, events can be anything that needs to be predicted. Events can represent End of Life (EOL), End of Mission (EOM), warning thresholds, or any Event of Interest (EOI).

    This example demonstrates how events can be used in your applications.


  • examples.noise

    Example demonstrating approaches for adding and handling model noise


  • examples.dataset

    Example downloading and using a NASA prognostics dataset.

    In this example, a battery dataset is downloaded from the NASA PCoE data repository. This dataset is then accessed and plotted.


  • examples.generate_surrogate

    Example of generating a Dynamic Mode Decomposition surrogate model using the battery model


  • examples.linear_model

    This example shows the use of the LinearModel class, a subclass of PrognosticsModel for models that can be described as a linear time series.

    The model is used in a simulation, and the state is printed every second


  • examples.visualize

    Example demonstrating the Visualization Module.


  • examples.future_loading

    Example demonstrating ways to use future loading.


  • examples.param_est

    Example demonstrating the model parameter estimation feature.


  • examples.derived_params

    Example demonstrating ways to use the derived parameters feature for model building.


  • examples.state_limits

    Example demonstrating when and how to identify model state limits.


  • examples.dynamic_step_size

    Example demonstrating ways to use the dynamic step size feature. This feature allows users to define a time-step that changes with time or state.


  • tutorial

Model-Specific Examples

Extending

You can create new models by creating a new subclass of prog_models.PrognosticsModel or prog_models.LinearModel (for simple linear models).

To generate a new model, create a new class for your model that inherits from this class. Alternatively, you can copy the template prog_model_template.ProgModelTemplate, replacing the methods with logic defining your specific model.

The analysis and simulation tools defined in prog_models.PrognosticsModel will then work with your new model.

See examples.new_model for an example of this approach.

Tips

  • To predict a certain partial state (e.g., 50% SOH), create a new event (e.g., ‘SOH_50’) override the event_state and threshold_met equations to also predict that additional state.

  • If you’re only doing diagnostics without prognostics- just define a next_state equation with no change of state and don’t perform prediction. The state estimator can still be used to estimate if any of the events have occured.

  • Sudden events use a binary event_state (1=healthy, 0=failed).

  • You can predict as many events as you would like, sometimes one event must happen before another, in this case the event occurance for event 1 can be a part of the equation for event 2 (‘event 2’: event_1 and [OTHER LOGIC]).