Presenter: Chris Teubert (christopher.a.teubert@nasa.gov)

In-room help: Chetan Kulkarni & Rajeev Ghimire

Online help: Katelyn Griffith

Technical Help: Raise your hand if you need technical help, someone from our team will come around and help you.

Questions: Please put questions in the Whova App during the presentation or we will stop at various points to answer questions.

Pre-Work¶

1. Download Whova¶

Please download the Whova App for live Q&A during the session. The Q&A can be found here: https://whova.com/portal/webapp/phm1_202411/Agenda/4229218

2. Installing ProgPy¶

We recommend installing ProgPy prior to the tutorial

ProgPy requires a version of Python between 3.7-3.12

The latest stable release of ProgPy is hosted on PyPi. To install via the command line, use the following command:

$ pip install progpy

3. Start Jupyter Notebook¶

Either by cloning the git repo

$ git clone https://github.com/nasa/progpy.git

or using binder: https://mybinder.org/v2/gh/nasa/progpy/master?labpath=examples/2024PHMTutorial.ipynb

4. Download data¶

Next, lets download the data we will be using for this tutorial. To do this we will use the datasets subpackage in progpy.

Note, this downloads the battery data from the PCoE datasets: https://www.nasa.gov/intelligent-systems-division/discovery-and-systems-health/pcoe/pcoe-data-set-repository/

Introduction to ProgPy¶

NASA’s ProgPy is an open-source python package supporting research and development of prognostics, health management, and predictive maintenance tools. It implements architectures and common functionality of prognostics, supporting researchers and practitioners.

The goal of this tutorial is to instruct users how to use and extend ProgPy. This tutorial will cover how to use a model, including existing models and additional capabilities like parameter estimation and simulation, as well as how to build a new model from scratch.

The tutorial will begin with an introduction to prognostics and ProgPy using ProgPy's documentation. Please follow along in the ProgPy Guide.

Tutorial Outline¶

0. The Dataset
1. Using an existing model
   • Loading a model
   • Model parameters
   • Simulation
   • Prognostics with data
2. Building a new model
   • State transition
   • Outputs
   • Events
   • Using the model
   • Parameter estimation
   • Prognostics example
   • Final notes
3. Advanced Capabilities

The Dataset¶

Let's prepare the dataset that we will use for this tutorial.

The dataset includes 4 different kinds of runs: trickle, step, reference, random walk. We're going to split the dataset into one example for each of the different types for use later.

Let's take a look at the trickle discharge run first.

Now let's do the same for a reference discharge run (5).

Now let's do it for the step runs. Note that this is actually multiple runs that we need to combine.

relativeTime resets for each "run". So if we're going to use multiple runs together, we need to stitch these times together.

Next, we should combine the data into a single dataset and investigate the results

Finally, let's investigate the random walk discharge

Like the step discharge, we need to stitch together the times and concatenate the data

Now the data is ready for this tutorial, let's dive into it.

Using an existing Model¶

The first component of ProgPy are the Prognostics Models. Models describe the behavior of the system of interest and how the state of the system evolves with use. ProgPy includes capability for prognostics models to be physics-based or data-driven.

All prognostics models have the same format within ProgPy. The architecture requires definition of model inputs, states, outputs, and events which come together to create a system model.

ProgPy includes a collection of included models which can be accessed through the progpy.models package.

Loading a Model¶

To illustrate how to use a built-in model, let's use the Battery Electrochemistry model. This model predicts the end-of-discharge of a Lithium-ion battery based on a set of differential equations that describe the electrochemistry of the system Daigle et al. 2013.

First, import the model from the progpy.models package.

Next, let's create a new battery using the default parameters:

Model parameters¶

Model parameters describe the specific system the model will simulate. For the Electrochemistry model, the default model parameters are for 18650-type Li-ion battery cells. All parameters can be accessed through batt.parameters. Let's print out all of the parameters, followed by the specific parameter for Ohmic drop, denoted as Ro in this model.

Parameter values can be configured in various ways. Parameter values can be passed into the constructor as keyword arguments when the model is first instantiated or can be set afterwards. Let's change two parameters to be more specific to our battery use-case:

In addition to setting model parameter values by hand, ProgPy includes a parameter estimation functionality that tunes the parameters of a general model to match the behavior of a specific system. In ProgPy, the progpy.PrognosticsModel.estimate_params() method tunes model parameters so that the model provides a good fit to observed data. In the case of the Electrochemistry model, for example, parameter estimation would take the general battery model and configure it so that it more accurately describes a specific battery. The ProgPy documentation includes a detailed example on how to do parameter estimation.

Simulation¶

Once a model has been created, the next step is to simulate it's evolution throughout time. Simulation is the foundation of prediction, but unlike full prediction, simulation does not include uncertainty in the state and other product (e.g., output) representation.

Future Loading

Most prognostics models have some sort of input, i.e. a control or load applied to the system that impacts the system state and outputs. For example, for a battery, the current drawn from the battery is the applied load, or input. In this case, to simulate the system, we must define a future_loading function that describes how the system will be loaded, or used, throughout time. (Note that not all systems have applied load, e.g. ThrownObject, and no future_loading is required in these cases.)

ProgPy includes pre-defined loading functions in progpy.loading. Here, we'll implement the built-in piecewise loading functionality.

Simulate to Threshold

With this in mind, we're ready to simulate our model forward in time using ProgPy's simulation functionality.

Physical systems frequently have one or more failure modes, and there's often a need to predict the progress towards these events and the eventual failure of the system. ProgPy generalizes this concept of predicting Remaining Useful Life (RUL) with events and their corresponding thresholds at which they occur.

Often, there is interest in simulating a system forward in time until a particular event occurs. ProgPy includes this capability with simulate_to_threshold().

First, let's take a look at what events exist for the Electrochemistry model.

The only event in this model is 'EOD' or end-of-discharge. The progpy.PrognosticsModel.event_state() method estimates the progress towards the event, with 1 representing no progress towards the event and 0 indicating the event has occurred. The method progpy.PrognosticsModel.threshold_met() defines when the event has happened. In the Electrochemistry model, this occurs when the battery voltage drops below some pre-defined value, which is stored in the parameter VEOD. Let's see what this threshold value is.

With these definitions in mind, let's simulate the battery model until threshold for EOD is met. We'll use the same future_loading function as above.

Let's visualize the results. Note that the simulation ends when the voltage value hits the VEOD value of 3.0.

In addition to simulating to threshold, ProgPy also includes a simpler capability to simulate until a particular time, using simulate_to().

Prognostics with data¶

Now that we have a basic simulation of our model, let's make a prediction using the prognostics capabilities within ProgPy. The two basic components of prognostics are state estimation and prediction. ProgPy includes functionality to do both.

To implement a prognostics example, we first need data from our system. We'll use the data we've already uploaded and prepped above.

For the battery electrochemistry model, we'll need to use a state estimator because the model state is not directly measureable, i.e. it has hidden states. We'll use a Particle Filter and the estimate method. ProgPy also includes a Kalman Filter and an Unscented Kalman Filter.

First, let's load the necessary imports.

State estimators require an initial state. To define this, we'll first initialize the model and then define the initial state as a distribution of possible states around this using a multi-variate normal distribution.

With our initial distribution defined, we can now instantiate the state estimator.

With this, we're ready to run the State Estimator. To illustrate how state estimation works, let's estimate one step forward in time. First, we'll extract the measurement at this time.

Next, we'll estimate the new state by calling the estimate method.

Finally, let's look at the difference between the estimated state and the true measurement. In the following plots, blue circles represent the initial distribution and orange circles represent the estimated result. The orange circles are more refined and give a better estimate, highlighting the usefulness of the state estimator.

Now that we know how to do state estimation, the next key component of prognostics is prediction. ProgPy includes multiple predictors, and we'll implement a Monte Carlo predictor here. Let's load the necessary imports.

Next, a key factor in modeling any real-world application is noise. See the ProgPy noise documentation for a detailed description of different types of noise and how to include it in the ProgPy architecture. Here, let's add some process and measurement noise into our system, to capture any uncertainties.

Next, let's set up our predictor.

To perform the prediction, we need to specify a few things, including the number of samples we want to use for the prediction, the step size for the prediction, and the prediction horizon (i.e., the time value to predict to).

We also need to define a future loading function based on the load in the dataset we are using. Let's extract the necessary information and define a function.

With this, we are ready to predict.

Let's visualize the results. We'll plot 1) the data (in orange), 2) the predicted mean value (blue), 3) the individual predictions to show uncertainty (grey).

Now that we understand the basics of state estimation and prediction, as well as how to implement these concepts within ProgPy, we are ready to do a full prognostics example. We'll use the state estimator and predictor we created above.

First, let's set a few values we'll use in the simulation.

Next, let's initialize a data structure for storing the results, using the following built-in class:

Now we'll perform the prognostics. We'll loop through time, estimating the state at each time step, and making a prediction at the PREDICTION_UPDATE_FREQ.

For the sake of this tutorial and the data we're using, we need to change the default voltage threshold value. By changing this, we'll make the simulation run faster for our in-person demo, and ensure that samples reach EOD before the simulation is over. In practice, this value should be chosen based on the specific use-case you're considering.

With our prognostics results, we can now calculate some metrics to analyze the accuracy.

First, we need to define what the ground truth value is for end-of-discharge.

We'll start by calculating the cumulative relative accuracy given the ground truth value.

We'll also generate some plots of the results.

Data-driven Capabilities and Surrogate Models¶

In addition to the physics-based modeling functionalities described so far, ProgPy also includes a framework for implementing data-driven models. Included methodologies are Dynamic Mode Decomposition, LSTM, and Polynomial Chaos Expansion. This data-driven architecture also includes surrogate models which can be used to create models that approximate the original/higher-fidelity models, generally resulting in a less accurate model that is more computationally efficient.

Building a new model¶

The last section described how to use a prognostics model distributed with ProgPy (BatteryElectroChemEOD). However, in many cases a model doesn't yet exist for the system being targeted. In those cases, a new model must be built to describe the behavior and degradation of the system.

In this section we will create a new model from scratch, specifically a new physics-based model. ProgPy also includes tools for training data-driven models (see data-driven tab, here: https://nasa.github.io/progpy/prog_models_guide.html#state-transition-models), but that is not the approach we will be demonstrating today.

Physics-based state transition models that cannot be described linearly are constructed by subclassing progpy.PrognosticsModel. To demonstrate this, we'll create a new model class that inherits from this class. Once constructed in this way, the analysis and simulation tools for PrognosticsModels will work on the new model. https://nasa.github.io/progpy/prog_models_guide.html#state-transition-models

We will again be using the battery as a target, creating an alternative to the battery model introduced in the previous section. We will be implementing the simplified battery model introduced by Gina Sierra, et. al. (https://www.sciencedirect.com/science/article/pii/S0951832018301406).

First, we import the PrognosticsModel class. This is the parent class for all ProgPy Models

State Transition¶

The first step to creating a physics-based model is implementing state transition. From the paper we see one state (SOC) and one state transition equation:

$SOC(k+1) = SOC(k) - P(k)*\Delta t * E_{crit}^{-1} + w_2(k)$

where $k$ is discrete time. The $w$ term is process noise. This can be omitted, since it's handled by ProgPy.

In this equation we see one input ($P$, power). Note that the previous battery model uses current, where this uses power.

Armed with this information we can start defining our model. First, we start by declaring our inputs and states:

Next we define parameters. In this case the parameters are the initial SOC state (1) and the E_crit (Internal Total Energy). We get the value for $E_{crit}$ from the paper.

Note: wont actually subclass in practice, but it's used to break apart model definition into chunks

We know that SOC will always be between 0 and 1, so we can specify that explicitly.

Next, we define the state transition equation. There are two methods for doing this: dx (for continuous) and next_state (for discrete). Today we're using the $dx$ function. This was selected because the model is continuous.

Outputs¶

Now that state transition is defined, the next step is to define the outputs of the function. From the paper we have the following output equations:

$v(k) = v_{oc}(k) - i(k) * R_{int} + \eta (k)$

where

$v_{oc}(k) = v_L - \lambda ^ {\gamma * SOC(k)} - \mu * e ^ {-\beta * \sqrt{SOC(k)}}$

and

$i(k) = \frac{v_{oc}(k) - \sqrt{v_{oc}(k)^2 - 4 * R_{int} * P(k)}}{2 * R_{int}(k)}$

There is one output here (v, voltage), the same one input (P, Power), and a few lumped parameters: $v_L$, $\lambda$, $\gamma$, $\mu$, $\beta$, and $R_{int}$. The default parameters are found in the paper.

Note that $\eta$ is the measurement noise, which progpy handles, so that's omitted from the equation below.

Note 2: There is a typo in the paper where the sign of the second term in the $v_{oc}$ term. It should be negative (like above), but is reported as positive in the paper.

We can update the definition of the model to include this output and parameters.

Note that the input ($P(k)$) is also used in the output equation, that means it's part of the state of the system. So we will update the states to include this.

NOTE: WE CHANGE TO next_state. Above, we define state transition with ProgPy's dx method because the model was continuous. Here, with the addition of power, the model becomes discrete, so we must now use ProgPy's next_state method to define state transition.

Adding a default P state as well:

Finally, we're ready to define the output equations (defined above).

Events¶

Finally we can define events. This is an easy case because our event state (SOC) is part of the model state. So we will simply define a single event (EOD: End of Discharge), where SOC is progress towards that event.

Then for our event state, we simply extract the relevant state

The threshold of the event is defined as the state where the event state (EOD) is 0.

That's it. We've now defined a complete model. Now it's ready to be used for state estimation or prognostics, like any model distributed with ProgPy

Using the Model¶

First step to using the model is initializing an instance of it.

To demonstrate/test this model, we will start by simulating with a constant load

Everything seems to be working well here. Now let's test how well it fits the random walk dataset. First let's prepare the data and future load equation. Note that this future load uses power instead of current (which the last one used)

We can simulate using that future load equation

Now let's take a look at the result, comparing it to the ground truth

This is a terrible fit. Clearly the battery model isn't properly configured for this specific battery. Reading through the paper we see that the default parameters are for a larger battery pouch present in a UAV, much larger than the 18650 battery that produced our dataset

To correct this, we need to estimate the model parameters.

Parameter Estimation¶

Parameter estimation could be a tutorial on its own. Sometimes it can be considered more of an art than a science.

Parameter Estimation the process of estimating the parameters for a model. This is done using a mixture of data, knowledge (e.g., from system specs), and intuition. For large, complex models, it can be VERY difficult and computationall expensive. Fortunately, in this case we have a relatively simple model.

See: https://nasa.github.io/progpy/prog_models_guide.html#parameter-estimation

First, let's take a look at the parameter space

This is a very simple model. There are really only 7 parameters to set (assuming initial SOC is always 1).

We can start with setting a few parameters we know. We know that $v_L$ is about 4.2 (from the battery), we expect that the battery internal resistance is the same as that in the electrochemistry model, and we know that the capacity of this battery is significantly smaller.

Now let's take a look at the model fit again and see where that got us.

Much better, but not there yet. Next, we need to use the parameter estimation feature to estimate the parameters further. First let's prepare some data. We'll use the trickle, reference, and step datasets for this. These are close enough temporally that we can expect aging effects to be minimal.

NOTE: It is important to use a different dataset to estimate parameters as to test

Now let's print the keys and the error beforehand for reference. The error here is what is used to estimate parameters.

Next, lets set the bounds on each of the parameters.

For $v_L$ and $R_{int}$, we're defining some small bounds because we have an idea of what they might be. For the others we are saying it's between 0.1 and 10x the default battery. We also are adding a constraint that E_crit must be smaller than the default, since we know it's a smaller battery.

Finally, we'll estimate the parameters. See Param Estimation for more details.

We can throw all of the data into estimate parameters, but that will take a LONG time to run, and is prone to errors (e.g., getting stuck in local minima). So, for this example we split characterization into parts.

First we try to capture the base voltage ($v_L$). If we look at the equation above, $v_L$ is the only term that is not a function of either SOC or Power. So, for this estimation we use the trickle dataset, where Power draw is the lowest. We only use the first section where SOC can be assumed to be about 1.

Let's take a look at what that got us:

A tiny bit closer, but not significant. Our initial guess (from the packaging) must have been pretty good.

The next step is to estimate the effect of current on the battery. The Parameter $R_{int}$ (internal resistance) effects this. To estimate $R_{int}$ we will use 2 runs where power is not minimal (ref and step runs). Again, we will use only the first couple steps so EOL can be assumed to be 1.

Again, let's look at what that got us

Much better, but not there yet! Finally we need to estimate the effects of SOC on battery performance. This involves all of the rest of the parameters. For this we will use all the rest of the parameters. We will not be using the entire reference curve to capture a full discharge.

Note we're using the error_method MAX_E, instead of the default MSE. This results in parameters that better estimate the end of the discharge curve and is recommended when estimating parameters that are combined with the event state.

Let's see what that got us

This is even better. Now we have an "ok" estimate, ~150 mV (for the sake of a demo). The estimate could be refined further by setting a lower tolerance (tol parameter), or repeating the 4 parameter estimation steps, above. Talk to Chetan Kulkarni (chetan.s.kulkarni@nasa.gov) with questions on this.

Prognostics Example¶

Let's repeat the above example that uses BatteryElectroChemEOD with the same data, so we can compare the results.

This does require an extension of the SimplifiedEquivilantCircuit model.

In BatteryElectroChemEOD, EOD is defined as when voltage passes below some threshold (VEOD). This is frequently called "functional EOD", because after this point the battery can no longer perform its function.

For SimplifiedEquivilantCircuit, EOD is defined as the point where there is no charge, far after functional EOD. To compare the two, we define a new event: "Low V", for when voltage hits a specific threshold (VEOD).

We can then initialize the state distribution. Here we define a distribution with significant noise around SOC and no noise around the power (which is overwritten each step anyway).

Now we can construct the Particle Filter with this guess

Finally we define the process and measurement noise and initialize the predictor.

Now let's lake a look at a single prediction using this setup, and plot the results

Pretty good, now let's repeat the example from earlier

Note the runtime.

Finally let's take a look at the results.

Final Notes on Building New Models¶

Here we built a brand new model, from scratch, using the information from a paper. We estimated the parameters using real data and compared its performance with the include BatteryElectroChemEOD.

This is one example on how to build a new model, for more details see https://nasa.github.io/progpy/prog_models_guide.html#building-new-models and the 04_New Models.ipynb file. Other model-building topics include:

• Advanced Noise Representation: e.g., Other distributions
• Complex Future Loading Methods: E.g., moving average, loading with uncertainty or functions of state
• Custom Events: e.g., warning thresholds
• Data-driven models
• Derived Parameters: parameters that are functions of other parameters
• Direct Models: Models of state, future_loading -> Time of Event without state transition
• Linear Models
• Optimizations

Note that this model can be extended by changing the parameters ecrit and r to steady states. This will help the model account for the effects of aging, since they will be estimated with each state estimation step.

Other Advanced Capabilities¶

• Combination Models: https://nasa.github.io/progpy/prog_models_guide.html#combination-models and 06_Combining_Models
• Dynamic Step Size
• Integration Methods
• Serialization
• prog_server

Closing¶

Contributing: Thank you for attending this tutorial. ProgPy is a collaborative effort, including NASA and external collaborators. If you're interested in contributing or learning more, reach out at christopher.a.teubert@nasa.gov

We are looking or interns for this summer- email christopher.a.teubert@nasa.gov for details