A data-centric approach to the study of system-level prognostics for cyber physical systems: application to safe UAV operations

Software tools & simulation methods

The development of simulation-based and data-driven environments that have grown to a level of complexity where managing the generated data becomes a burdensome task fraught with errors. Therefore, it is imperative for system health management platforms to adopt a robust and well-defined framework that focuses on the data management aspects as much as the simulation. More than 10 years ago, Uckun et al.^[3] highlighted the lack of standardization within the PHM community and critically pointed out that many PHM experiments lacked statistical rigor. While statistical evaluation methods for PHM applications have made significant advances, the PHM community still lacks a universally accepted research methodology using simulations and standard conventions for data quality and management. Developing new technology often starts with creating simulations and simulation testbeds. Typically, these simulations are developed "in-house", rely on specialized dependencies, are poorly documented, and are often difficult to replicate or extend. To overcome these problems, we propose a systematic approach to designing end-to-end simulation systems, and our key claim is that the simulation approach should be designed around the data first - not the other way around.

Modeling and simulation tools such as Simulink, LabVIEW, or Modelica are industry standards for a number of engineering applications. They also facilitate the generation and use of data. However, these tools do not enforce any policies or rules on how the generated data is managed. These are open-ended tools, meaning there is no framework to specify and implement such policies or interfaces, it is all left to the user. Given the skill-set disconnect between engineers or research scientists, the users of these tools, and the database engineers or the enterprise software developers who typically implement data schemas, the data management practices and implementations needed to facilitate experimentation often fall through the cracks.

Morris et al.^[4] remark that a well-organized approach to planning and reporting simulation studies involves formally defining the purpose of the study, exhaustively enumerating all sources of data, the parameters that are being estimated, the methods used, and performance measures. While they focus on the field of medicine, their methodologies may be easily expanded to other domains of study. Typically what is seen in the literature is an overemphasis on the purpose of the study and methods used, with little attention given to properly documenting the component modeling or data these components generate. Simulink is the underlying software tool used for the simulation environment in this work; however, we provide all of the building blocks necessary to ensure simulation conformity and reduce the burden on the end user.

The NASA Diagnostics and Prognostics Group has developed the Prognostics Python Packages, prog_models ^[5] and prog_algs ^[6]. These are a collection of open-source research tools for developing prognostic models, simulating system degradation, performing prognostics, analyzing results, and developing new prognostic algorithms. The Prognostics Python Packages encapsulate design improvements over the previously released MATLAB Prognostics Libraries (PrognosticModels, PrognosticAlgorithms, and PrognosticMetrics) and C++ Generic Software Architecture for Prognostics (GSAP) ^[7]. The packages implement common functionality found in PHM applications (e.g., state estimation algorithms, predictors, sampling methods) and provide clear interfaces and tools for extending that functionality. NASA also had an effort to explore the challenges associated with a Service-Oriented Architecture (SOA) for Prognostics, called Prognostics As-A-Service (PaaS) ^[8]. This effort explored different architectures for PaaS, including structures for long-term data storage to enable outer-loop model optimization approaches.

While the Prognostics Python Packages and GSAP focus on implementing common functionality across PHM applications and enforce constraints on the physics-based models and composition of components within a system, it does not provide any systematic framework for the handling or storage of data. A running theme throughout this paper is the importance of understanding and addressing data concerns first, and then building the simulation software around those requirements. The data management framework proposed in this work does just that, and enables researchers to focus on their specific experiments with little upfront effort to incorporate the data schema into their work. This framework can also interoperate with any of the tools discussed above. Next we discuss data generation aspects in more detail.

Data generation & management

Over the last several years, there has been a rise in the use of deep learning methods in prognostics research to achieve results that were previously unobtainable. Nevertheless, as we have seen, there is a general lack of data management and attention to data provenance in these studies, which results in data that lacks appropriate descriptors, unverifiable origins, or any of the other several aforementioned issues presented previously that make replication or validation tasks hard to achieve. We argue that these issues persist due to the lack of data management standards and policies. The goal of data management is to produce "self-describing datasets"^[9] such that scientists and practitioners can discover, use, and interpret the data across multiple experiments.

Oracle (https://www.oracle.com/database/what-is-data-management/) defines data management as the practice of collecting, keeping, and using data securely, efficiently, and cost-effectively. One thing not specifically mentioned in this definition is data organization, however, it can be inferred that the ability to use data efficiently implies some form of underlying organization. Microsoft (https://dynamics.microsoft.com/en-us/ai/customer-insights/what-is-a-data-management-platform-dmp/) defines data management as the collection, organization, and activation of data from various sources to put into a usable form. They define this in terms of a data management platform as a tool to facilitate data management, a critical piece that is missing in the scientific and engineering literature. This point is perhaps the biggest reason why such poor data management practices exist within the PHM community (not to remark on the acumen of our researchers, but simply the identification of a skill-set gap that exists).

TechTarget (https://searchdatamanagement.techtarget.com/definition/data-management) adds to the above by bringing accuracy into the picture, which can be interpreted as a form of assurance on the validity of the data and its provenance. Munappy et al.^[10] define data management specifically for deep learning applications as a process that includes collecting, processing, analyzing, validating, storing, protecting, and monitoring data to ensure consistency, accuracy, and reliability of the data are intact.

However, these definitions do not address how this data is generated or its origins. This is one point of contention that must be addressed within the context of engineering or scientific disciplines that use simulation studies to draw conclusions. These studies are used to drive technological development of some system or algorithm that is eventually used in the real world, with real implications, and the validity of the data used is of utmost importance. Therefore, our definition includes data generation, in addition to the definition proposed by Munappy et al.^[10], as follows:

Definition 1 (Data Management for CPS)A formal method for generating, validating, storing, documenting, and retrieving data that guarantee data security, consistency, availability, and persistence even long after the project that generated such data is finished.

Most of the effort in the application of machine learning algorithms is spent on data preparation^[11]. The performance of a machine learning algorithm is directly related to the quality of the data sets employed for the learning task. Machine learning models are highly dependent on the underlying data, and, therefore, consistency, accuracy, and completeness of the data is essential to train models that are capable of sufficient generalization and performance^[10]. Thus, good data management principles and practices need to be adopted throughout the entire development process. The majority of engineers focus on the development of the machine learning algorithms and simply deal with the fact that data preparation is going to be their most time-consuming part. This is largely because of the gap that exists between the skill-sets of a data management professional and that of a machine learning engineer.

Data consistency is hard to achieve or guarantee without a systematic and pragmatic approach to data management. Lack of consistency in the data ultimately results in a poorly trained model and has negative effects on any downstream processes^[12]. Data validation can address these problems, and a properly implemented data schema can perform automatic validation, alleviating many of these issues. Lack of metadata or data descriptors creates confusion and poor understanding of the data, resulting in ambiguous data semantics that makes data discovery a cumbersome and sometimes impossible task. Data dependency, memory management, concurrency, the problem of noisy data, and data inconsistency can be solved in an integrated manner using a DataBase Management System (DBMS) within the workflow of simulation studies or machine learning applications ^[13].

Most datasets discussed in the literature are schema-free^[14], meaning they do not share a standard format. This results in data organization methods that do not conform to a set of predefined rules or systems of organization. As a result, validating machine learning models is a major challenge. Accessing data from one dataset may not be the same as in another, even if the datasets are for similar applications. A well-defined data schema is necessary as it encodes and specifies what correct data is, and valid types and ranges for the data. In this manner, it enforces data relationships and other constraints to ensure data validity. Our aim is to propose a data schema that provides standards and explicit rules for data management for the PHM community to address the issues outlined in this paper. We provide this data schema and discuss the primary SLP use case next.

System-level prognostics

Prognostics brings together the study of how systems fail with life-cycle management to ensure safe and proper operations of the system ^[15]. Put simply, prognostics is predicting how a system's state and performance will change with time, and when a future event, typically End Of Life (EOL), or some safety or performance threshold violation^[16], will occur. One common approach to assessing when failure will occur is to use empirical data provided by component manufacturers, such as Mean Time Between Failure (MTBF). However, MTBF specifications fail to account for system usage, therefore, are limited in their practical usability, especially when systems operate under a variety of operational and environmental conditions. Prognostics, in contrast, encompasses methods for estimating future performance based on telemetry data from system sensors, its current state of health, and predicted use over time. Because prognostics methods project system behavior into the future, the predictions are uncertain and are often expressed as probability distributions with confidence bounds ^[17].

In general, prognostics methodologies can be divided into three basic categories ^{[18, 19]}:

1. Data driven: These methods use probability-based ^[20] and machine learning algorithms ^[21] to map component measurements to the degradation parameters of a component, and often need run-to-failure datasets that are rarely available. Regression and deep learning techniques fall into this category.

2. Model based: This prognostic approach uses first principles physics and differential equation models of the system dynamics to develop parameterized degradation models of a component ^{[22, 23]}. Filtering techniques that utilize different Kalman and Particle Filtering techniques fall into this category.

3. Hybrid approaches: Hybrid approaches combine the best aspects of model-based and data-driven techniques. For example, Neerukatti et al.^[24] proposed a hybrid approach for damage state prediction using a crack growth model and then showed using regression techniques how the model could be updated as new measurements became available. They demonstrated that the hybrid approach was more accurate and reliable than pure data- or model-based methods. This approach easily extends from the component level to the system level, where models of the components are used to update the component and state degradation parameters, and the generated data is used to make RUL estimates for individual components as well as the overall system.

Typically, prognostics is used at the component level to predict when an individual component, such as a battery or motor, will fail. This approach does not account for multiple degrading components in a system, and ignores the interactions between the individual components when estimating overall system health. SLP studies the combined effects of multiple degrading components in a system on overall system behavior and performance ^[25].

Definition 2 (System-Level Prognostics (SLP))SLP is a methodology for estimating future performance and time of events, such as component and system End of Life (EOL) or performance threshold violation, for a system comprised of multiple interacting components that degrade simultaneously.

SLP must account for uncertainty, external influences, component damage accumulation, the interactions among these components, and the effects of multiple component degradation on system performance. Components interact with one another, so individual component degradation is no longer an isolated function of inputs and environment, but includes the complexities of interactions with other components. Degradation models that predict performance at the system level are an aggregation of the individual component degradation models, and because the interactions can be complex and nonlinear, they are not solvable analytically. In addition, variability in the environment parameters and uncertainty in the aggregated degradation functions necessitates the use of stochastic simulation methods to derive system performance over multiple missions. Events of interest in system-level prognostics include EOL for individual components (computed from RUL estimates) and system life (computed using estimated system performance). System EOL represents an estimated point in time when the system performance drops below pre-specified thresholds. System failure is expressed as the union of component failure conditions in conjunction with the violation of one or more system-level performance constraints. This is further discussed in sections 3 and 6.

In our previous work^[26], we demonstrated that system performance degrades much faster than individual components due to the nonlinear effects of the joint interactions among the components and their degradation functions. However, we did not perform true RUL computations, and instead performed short-term forecasts via linear extrapolation, which only detected EOL events within the forecast horizon. This method also assumes that system-level performance degradation is linear within the forecast horizon, which may or may not always be guaranteed. While these predictions were accurate, they lacked a confidence interval because a Monte-Carlo base stochastic simulation was not used to account for uncertainty.

Perhaps the first true system-level prognostics approach that addresses these shortcomings with a convergent confidence interval with the use of Monte-Carlo simulations was demonstrated by Khorasgani et al.^[25]. They developed a formal framework for SLP and applied it to the analysis of a full-wave rectifier circuit consisting of two capacitors concurrently degrading at different rates. The authors defined system-level RUL prediction as a function of the set of component degradation models, degradation parameters, system performance function, system performance threshold function, and the probability density functions of the system state variables. By combining the degradation rates of individual components using a particle filter approach, they generated accurate and stable results for system RUL events, i.e., when system performance dropped below pre-specified thresholds. We have incorporated this approach into the simulation environment developed in this paper and discuss it in greater detail in the following section.

There are a large number of excellent articles within the PHM literature that have led to health management advances that are being deployed today for real-world use-cases ^{[27, 28]}. However, many of these are application-specific methods, when viewed from a larger context of SLP are difficult to generalize across systems or applications ^{[29, 30]}. A large contributing factor to this is the increasing system complexity and the sheer volume of data generated from these systems. As system complexity continues to increase and physics-based models become more expensive to develop and maintain, more advanced data-driven machine learning techniques are required to support prognostics and health management methodologies and applications. This need paves the way for deep learning and reinforcement learning based prognostics, which require large amounts of data for training and validation. Such datasets simply do not exist, and for practical reasons, as outlined above, they must be generated by simulation. This leads to a set of primary challenges that we address in this paper.

System-level data generation for prognostics

Individual component behavior depends on many factors, including usage and the health and functionality of other components. The system behavior is typically a function of the behaviors of these tightly coupled components, which results in complex nonlinear dynamics. All of these phenomena need to be accurately captured in the system model. Therefore, the system dynamic function $$ f $$ comprises all equations required to characterize each component's behavior and their interactions. If each component is treated in isolation, the system's $$ RUL $$ might not correspond with the minimum $$ RUL $$ among all components, and even more so, the minimum $$ RUL $$ among the components also likely does not correspond with the system-level $$ RUL $$. For example, one or more motors and the battery pack may degrade simultaneously during UAV flight. As a result, the propulsion generated by the vehicle is a combined result of both sources of degradation, and it is unlikely that a closed-form expression can be derived for the overall propulsion change over time. Continued operations in such degraded state may weaken the propulsion generated by the vehicle significantly, and that will affect the ability of the vehicle to follow the specified reference trajectory, or maintain a safe level of charge in the battery. This can result in position errors for the UAV that exceed pre-specified bounds, or complete failure midflight due to loss of power. As discussed in previous sections, the data must be properly organized in order to build high quality machine learning models for prognostics, and to correctly compare and evaluate different prognostics algorithms. Current approaches do not adequately support such approaches outside of very specific use cases that cannot be easily generalized.

The study of reliable system-level prognostics methodologies is critical for safe operations of complex cyber physical systems. Currently, this is a very active area of research ^[35]. Due to the challenges in developing prognostics applications discussed in the previous sections, we have proposed a data management framework to support prognostics studies for real or simulated systems. All cyber physical systems are made up of multiple components and subsystems, and each of these components degrades with use and over time. By measuring system inputs and outputs over time, we can track the degradation and performance of individual components, as well as the overall system. Therefore, the set of relevant input and output variables in the system as well as the parameters associated with components and system performance, constitute the data management framework, as illustrated in Figure 1.

Figure 1. System-level data generation for prognostics applications. The decoupling of the data generation, whether it is from a real system or a simulation, from data organization and consumption (machine-learning, data analysis, etc.), allows for multiple systems and system types to be studied with the same core functionality and codebase.

System description

The system used in our experiments is a generic octorotor UAV using parameter values provided in ^[36]. Table 2 lists the variables and their descriptions. The Newton-Euler equations of motion for a rigid body dictate the dynamic behavior of the system as follows^[38]:

where $$ {\bf{v}}_B $$ and $$ {\bf{w}}_B $$ are linear and angular acceleration in the body frame, respectively; $$ F_M \in \Re^3 $$ is the resultant force generated by the motors, $$ F_D \in \Re^3 $$ is the drag force resulting due to the movement of a UAV through the air, $$ M_M \in \Re^3 $$ is the moment generated by the motors, $$ m $$ is the mass of the UAV, $$ J_m $$ is the inertia matrix of vehicle, $$ g $$ is the acceleration due to gravity, $$ R_{IB} \in \Re^{3 \times 3} $$ is the rotation matrix from the inertial frame to the body frame, and $$ {\bf{e}}_z=[0\; 0\; 1]^{T} $$. The rotation matrix is calculated based on the Euler angles $$ [\phi, \theta, \psi] $$^[44]. In this work, we ignore the effects of drag moment.

The octocopter made up of multiple components, which simultaneously affect the overall system performance. For example, the degradation of a motor affects the resulting generated forces and moments ($$ F_M $$ and $$ M_M $$) over time; this affects the ability to follow a reference trajectory. In the current simulation model, brushless DC motors commonly used in UAVs are modeled as generic DC-motor models, i.e., Equations 11 and 12 describe the dynamic behavior of each motor $$ i $$:

where $$ R_m=\frac{2}{3}\sum_{j=1}^{3}R_j $$ is the equivalent electric resistance of the motor coils j of a 3-phase motor, $$ K_e $$ is the back electromotive force constant, $$ \omega_i $$ is the angular velocity of the $$ i $$th motor, $$ T_f $$ is the static friction torque, $$ D_f $$ is the viscous damping coefficient that allows to estimate the dynamic friction torque ($$ D_f\omega $$), $$ J_m $$ is the inertia of the motor, $$ v_{m} $$ is the input voltage control signal, $$ i_c $$ is the current demanded from the battery pack, and $$ T_{p} $$ represents the torque load generated by the propellers. The battery is modeled using an equivalent circuit representation ^{[26, 37]}. The model of the UAV also includes a GPS that consumes an average of 690mA with an average power consumption rate of 8.26Wh^[45]. Noise associated with the position and velocity measurements are modeled as $$ N(0, \sigma) $$ distributions with $$ \sigma $$ values of $$ .2 $$ meters and $$ .01 $$ meters per second, respectively.

The airframe, motor, and battery parameters and their values are given in Tables 3, 4, and 5, respectively, shown below. Together, these values are used in the simulation environment to create the physics-based models that are simulated to generate data for usage in downstream processes such as those shown at the bottom of Figure 1.

System model

The five major blocks of the system-environment simulation are navigation, control, powertrain, dynamics, and environment as depicted in Figure 4. Initially, values for position and velocity are provided in the UAV's start state in a continuous space 3-D world. A reference trajectory is derived offline before flight and supplies the navigation block with coordinates to fly to. The GPS model adds position and velocity noise (with a bias of 0 as we are not modeling sensor faults) and supplies the control block with the reference position, true position, true velocity, GPS position, and GPS velocity. The control block calculates the position errors and uses PD controllers for orientation and angular velocity. It outputs an N-dimensional array of voltage reference signals; in the case of an octorotor, N = 8.

Figure 4. Simulation model.

Figure 5. Nominal voltage distribution.

The voltage reference signals are fed to the powertrain block, which contain the motors and battery models. The second input to the powertrain block is the current demand from all other components in the system (such as the GPS). The output of the powertrain block is a vector of motor RPMs that is sent to the dynamics block, which implements the aerodynamic equations of the UAV. The environment block is also an input to the dynamics block, where external factors such as wind gusts are translated to forces that are applied to the airframe. The output of the airframe block is updated position and velocity in the inertial axis, which is sent to the navigation block, and the flight control process is repeated.

It is important to also discuss the sources of uncertainty and noise, as well as the random variables in the simulation. Noise is attributed to processes and measurements within the system, system components, and environment. Measurement noise for a given parameter is modeled as an additive value. Uncertainty is modeled similarly and is captured in the confidence intervals for a given random variable, such as for the component degradation models. For each degradation parameter, $$ Q $$, $$ R_0 $$, and $$ R_m $$, we use a standard deviation of 2% of the mean value. Noise and uncertainty are also captured in the battery state estimator mentioned above, and for a more in-depth review, we direct the reader to (^[46-48]).

Another source of uncertainty is the variation in the fully charged battery voltage for each charging episode. This is modeled as a skewed distribution in Figure 5 with approximately 90% of the values falling between 21.2 and the nominal voltage, 22.2, and 10% of the values falling between 22.2 and 22.6. This effectively models what is experienced in the real world for charging batteries: sometimes they overcharge or undercharge, and usually the final charge value is within some range of the rated output voltage value.

System performance parameters

System-level performance parameters are random variables computed from system variables, and they are a proxy for the State Of Health (SOH) of the system. For the UAV, overall system performance is a function of the SOH of the battery and the SOH of the eight motors. A Sigma Point Kalman Filter ^[47] is used to perform battery (state and degradation) parameters estimation, and resistance measurements with additive noise are used to assess the motor (degradation) parameter. These are common and well-documented methods not discussed further in this work. We instead will focus on the implementation of the system-level performance parameters.

The first two parameters are (1) the battery State of Charge (SOC) ($$ z $$), (2) the battery output voltage ($$ v_{out}) $$, and the second two are (3) the average position error ($$ \epsilon_{\mu{pos}} $$), and (4) the position error standard deviation ($$ \epsilon_{\sigma{pos}} $$)(see Table 6). Due to the feedback loops among degrading components and the effects these components have on battery performance outside of the battery's operating characteristics and degradation in isolation, we track these battery indicators directly. The performance parameters for the battery are computed from its degradation parameters, the internal resistance, $$ R_0 $$, and overall charge capacity, $$ Q $$, which are indicators for battery SOH. Battery SOH in turn, contributes to overall system health. A similar comparison is made for the position error parameters; the combined interactions among multiple components degrading effect the UAV's ability to stay on its intended course, not just motor degradation ($$ R_m $$). are used to track overall system-level performance in this work. Together, these four parameters provide the information needed to perform SLP.

The set of system performance parameter constraint functions ($$ \wp_i(y_n)) $$) are implemented as a set of linear temporal logic (LTL) equations (Equation 13-16) that specify certain states the system should never reach. It is prudent to set the threshold values for these parameters below that of actual or unrecoverable failure. In order to tie back into the high level safety goals our system should achieve, one must leave some buffer space to take action (such as immediate landing procedures, return to base, etc.), if necessary, prior to actual failure. These functions together comprise ($$ T(\wp_i(y_n)) $$) in Equation 1, the system performance threshold equation, defined in section 3.

Definition 4$$ \wp_z $$, System Performance Parameter Constraint Expressions

The battery state of charge shall always remain above 20%.

The battery output voltage shall always be greater than 18.71 volts.

The average position error shall always remain below 2.8 meters.

The position error standard deviation shall always be less than.7 meters.

Degradation models and environment conditions

In this work, we consider the effects of the simultaneous degradation of eight motors and the battery pack. Specifically, stochastic degradation profiles are generated for three parameters: the equivalent electric resistance of the motor coils ($$ R_m $$), the battery charge capacity ($$ Q $$), and battery internal resistance ($$ R_0 $$). Altogether, the degradation profiles describe how the degradation parameters $$ \alpha_n $$ change with time (function $$ g' $$ in definition 4). We empirically derived degradation profiles for three parameters considered through run to failure experiments as described in ^{[43, 49]} (battery), and ^[50] (motor). Figure 6 shows the resulting nonlinear degradation profiles that are dependent on usage-based factors such as cumulative load demand.

Figure 6. Degradation profiles for battery charge capacity ($$ Q $$) and internal resistance ($$ R_0 $$), and motor internal resistance ($$ R_m $$).

The battery charge capacity is the amount of charge available in a fully charged battery. Battery charge capacity degrades as the battery undergoes multiple charge-discharge cycles over time. This can be attributed to the internal chemical processes within the battery as well as environmental factors, such as temperature. The degradation rate for $$ Q $$ is also a function of power delivered to the loads. Therefore, a fast discharge of the battery ages the battery faster than a slow discharge. The charge cycle also causes aging effects and degradation, however, the degradation rate is lower during charging than it is during discharging. The battery internal resistance ($$ R_0 $$) also increases over time caused by Lithium corrosion, plating, and electrolyte layer formation ^[51]. Consequently, this increases the current drawn from the battery, which, in turn, affects $$ Q $$ and causes the voltage delivered by the battery to drop. Motor coil resistance is used as a proxy for modeling loss of performance of the motors, which may be attributed to factors such as continued use over time and exposure to adverse weather conditions. As a result, throttle increase is required to compensate for these effects, thus increasing the battery's rate of drainage. In previous experiments ^{[26, 39, 48]}, we only considered the degradation of one motor, which resulted in a consistent position error deviation with respect to the direction of flight and the direction of wind. In real life, all of the motors can degrade simultaneously, and this would result in unpredictable trajectory deviations.

Besides simultaneous component degradation, environmental factors can affect the operation and performance of the system. In this work, we consider three environmental parameters: temperature, wind, and obstacles. Temperature is known to have an effect on both flight and battery performance. At high temperatures, flight performance is reduced due to the aerodynamic affects of increased molecular air speed causing a reduction in lift. This reduction in lift causes the motors to draw more current to produce the increased forces necessary to counter the reduction in lift. This further increases the rate of damage accumulation for the motors and the battery. Furthermore, in ^[52], the authors show that battery aging increases in high temperature conditions, and battery charge capacitance decreases in low temperature conditions.

Wang et al.^[53] provide a comprehensive analysis of different types of wind conditions and describe models of their effects on flight. Wind effects create load on the airframe, which puts stress on both the motors and the battery as the controller works to compensate for this additional force to maintain stability. While many different wind models exist, we implement a discrete wind gust model that acts along the three axes of UAV flight. Each axis samples a magnitude and direction from a normal and uniform distribution, respectively. Then, a duration value is sampled from a distribution where $$ \mu $$ = $$ 1.0_{sec} $$ and $$ \sigma $$ = $$ 0.1_{sec} $$.

Obstacles are either static, i.e., their location in the global coordinate frame (time and space) does not change, or they are dynamic, in which case their temporal-spatial location changes. Static obstacle influence system behavior during the trajectory planning phase and are easier to deal with than dynamic obstacles. In this experiment, we consider static obstacles that are part of the map, and save dynamic obstacles for future experiments.

Trajectories

The flight trajectory of the UAV (see Figure 7) plays a role in its overall safety and risk of failure during flight. Trajectories with sharp movements can also impose heavier impulse loads on components, which as discussed above, impact degradation rates. To study these effects in depth, the trajectories must be tracked and linked to other data objects. In general, a trajectory is represented as a multidimensional array capturing a time series, where each axis ([0,1,2]) is the equivalent x, y, z axis in space. A triplet is a single slice across the matrix that represents a specific point in space where the UAV is located at a specific time. Trajectories can be grouped into sets based on distance, estimated flight time, risk, or reward (although risk and reward are not considered in this work). Six trajectories of the set of trajectories flown (eight in total) are shown in Figure 7. Trajectories are formed in two steps using probabilistic roadmaps (PRM), followed by B-spline smoothing (see https://github.com/darrahts/uavTestbed/blob/main/livescripts/trajectories.mlx for a Matlab implemention of generating trajectories.) described below.

Figure 7. Available Trajectories in set $$ \tau_1 $$.

A Probabilistic Roadmap (PRM) is a graph structure where the nodes represent collision-free waypoints and the edges represent a realizable path between these waypoints (^[54]). Two parameters, number of nodes and maximum connection distance, must be supplied by the user. First, the graph is created by generating random nodes in the search space, and then checking if they are valid nodes. Then, each node is connected to every other node within the maximum connection distance, so long as that connection is also valid using the k-nearest neighbors method. Generating a graph is the first phase of the algorithm, which is executed offline based on the navigation map. In the query phase, the start location, waypoints, and end location are connected to their closest nodes of the graph, and the path is obtained by using Dijkstra's shortest path algorithm. If there is no valid path (i.e., collision-free) from a supplied location to an existing node on the graph, then that location is deemed unreachable. Figure 8 depicts three scenarios of the trajectory generation process that show the outcome of different parameter selections.

Figure 8. Trajectory generation. (L) too few nodes have been supplied and the waypoint at (160, 390) cannot be reached. (M) the connection distance is increased but now it is clear that the flight path is not optimal. (R) enough nodes have been selected and the connection distance has been reduced, providing the optimal trajectory.

Piecewise B-spline curves of degree $$ k $$^[55] are used for generating a smooth trajectory based on the waypoints derived by the PRM method for a desired cruise speed. This method has been widely used in robotic applications because of its desirable properties of convex hull and maintaining continuity up to the $$ k+1 $$ derivative for a curve of degree $$ k $$. Specifically, we considered cubic B-splines (^[56]) with a desired cruise speed of 1.0 m/s for the UAV flights. This ensures that any hard pivot points in the trajectory are curved for optimal performance with respect to energy consumption, flight time, and control.

Monte carlo simulation

A Monte Carlo simulation approach is used to derive data-driven models and provide confidence bounds on what is being estimated, in this case, the system-level RUL. This is in the context of its safety goals discussed above, as well as operational goals, such as flying to each waypoint in the trajectory. Algorithm 1 presents the pseudocode for the Monte Carlo simulation program, and is detailed below.

Algorithm 1: Monte-Carlo System-Level RUL Data Generation Simulation Process
Result: System-Level RUL Distribution   Data: models $$ f $$, $$ g $$, $$ h $$, $$ g' $$   Input:$$ u_{n:z} $$, $$ \alpha_{n:z} $$   Output:$$ RUL_{n:z} $$, $$ x_{n:z} $$, $$ \theta_{n:z} $$, $$ \kappa_{n:z} $$

The algorithm consists of three functions in addition to Main, which are Initialize (line 1), SingleFlightProcess (line 5), and RunToFailureProcess (line 16). This organization makes the code more readable, and allows the reader to refer back to Figures 2 and 3, which depict the simulation program graphically. Starting in the Main function on line 25, two empty arrays are instantiated that hold the EOL and RUL distribution values at each iteration. The value $$ N $$ is used for creating the MC simulation samples, and we use the number of available CPUs for parallelization. Other values for $$ N $$ can be used as well. The true system UAV is created using values for the Tarot T18 Octorotor, which are provided in the data management framework.

In line 30, degradation processes are attached to the UAV simulation, which means that the tracking mechanism that works behind the scenes can inform researchers of the degradation models that were used for this experiment. In line 33 (Initialize), the degradation parameter distributions are first estimated, and then sampled to produce $$ \alpha_n $$, thereby implementing $$ g' $$ from Equation 7. The starting voltage for the battery is also stochastic and generated by a sampling process, along with selecting a trajectory. This process (Equations 4-6 of section 3) happens at the beginning of every flight, which takes place on line 34, and is depicted in Figure 2, section 4.

Line 7 of the SingleFlightProcess is where the system performance parameters are checked, which refers back to Equation 3 in Section 3. After each flight of the true system and subsequent steps in the single flight process, the program enters the Monte Carlo block in lines 38-44 (Figure 3, Section 4). A number of MC samples are created until a system performance threshold is violated by checking $$ T(\wp_n)=\top $$ in Equation 3, and then the results of each MC sample are combined to form an EOL distribution (Equation 2 of section 3). From this, the true system RUL can be derived in line 44 (Equation 1, Section 3).

In this current form, we allow the true system to reach actual failure as the stopping condition for the program, since this is a data collection experiment. In all other cases, the stopping criteria would be another boolean LTL function that operates on the most recent RUL distribution estimate. At the end of the program, a 2D array is returned, with the first dimension being the mean RUL, and the second dimension being the standard deviation.

Requirements

Design decisions are driven by requirements, which are themselves driven by higher level goals. In this case, the goal is to simplify and facilitate system health management analyses, and in particular, SLP research. We have developed four general and five specific requirements to meet this goal, as outlined below.

R1 - Reproducibility. This represents the ability to reproduce experiments, and, therefore, supports a better peer-review process while establishing connections with other experiments. This is accomplished by explicitly specifying data, meta data, and asset organization. This is also an important requirement for validation tasks.

R2 - Explainability. This is directed towards making the specific methodologies employed for tracking all of the influences explicit and transparent, from modeling approaches to algorithms used in the simulation and data generation process. Explainability is required to achieve proper data provenance.

R3 - Extensibility. The code base needs to be developed using a modular, decoupled approach behind well-defined interfaces that facilitate superficial changes and the running of new experiments without having to make substantial alterations to the underlying codebase or having to rewrite significant amounts of code. This makes it easier for engineers not familiar with data management practices to incorporate the framework into their experimental approaches. Overall, it supports wider adoption.

R4 - Maintainability. This is focused on ensuring that the codebase and data storage is consistent across multiple experiments. Maintainable systems also make it easier to track bugs and fix errors. Maintaining a consistent and modular code base makes it easier to run machine learning experiments that generate consistent and reproducible results. We do not deal with the software aspects of PHM applications (e.g., see the GSAP framework^[7]), but these concepts apply to data management, and this requires the specification of a well-defined data schema.

R5 - System Composition. The framework should enable seamless composition of component and degradation models to construct the desired system models for simulation. This enables running a variety of prognostic experiments by pulling component and degradation models from a system library, instead of building models from scratch or trying to embed them in the executable code for every experiment.

R6 - Operational Variability. The framework should support multiple operational cycles, where a cycle is a single run of the system. Operational cycles are defined by assigning values to a set of parameters, such as the load setting for the charge-discharge cycle for a battery, and setting the waypoints to define an aircraft flight trajectory, or a sequence of deliveries for a UAV.

R7 - Monte Carlo Simulations. Monte Carlo simulations represent a generalizable approach to generating data associated with a problem specification, taking into consideration variations in operating and environmental conditions, which are represented as stochastic variables. They provide a systematic methodology for generating large amounts of data that support data-driven analyses.

R8 - Data Validation. Automatic validation of the data is a key requirement that ensures the data conforms to explicit constraints and can be guaranteed to be correct, without overburdening the user. This allows researchers to focus more on their specific application, and less on the nuances of ensuring the data is correct.

R9 - Data Integrity and Availability. The framework should also guarantee accessibility, discoverability, and persistence of data. This should be accomplished with an application programming interface (API) that exposes various methods for storing, retrieving, and updating records (among other functions).

A system designed to meet these requirements will allow for automated or semi-automated workflows that are self-documenting in terms of the data, meta data, and data provenance. Such a design pattern for data management within the context of PHM will improve the development pace and collaboration among researchers. Our data management framework adopts an asset, process, and data methodology to address these requirements. This framework captures and organizes high fidelity simulation data to support the development, testing, and evaluation of health management applications.

Assets

Assets are the tangible components that make up a system, in our example, the system is a UAV, and the assets are the UAV itself and its components, i.e., the battery, motors, airframe, and a GPS sensor. Each asset acts as a first class object, meaning it is the archetype model that all components of the UAV inherit from. This includes many other types of components not listed above that may make up the UAV. All physical components are assets, including the UAV. This is perhaps one of the most fundamental concepts of the framework and central to interoperability among components, systems, environmental effects, and degradation models.

All assets have an associated asset-type (with predefined asset-types given in Table 7), which holds meta-data about the asset. The table name is $$\texttt{asset_type_tb}$$, and it contains the fields $$\texttt{id}$$, $$\texttt{type}$$, $$\texttt{subtype}$$, and $$\texttt{description}$$. The $$\texttt{type}$$ property is the high level component type, such as airframe or battery. The $$\texttt{subtype}$$ property is used for further specification, such as whether or not the battery is a discrete_eqc (discrete equivalent circuit) or a continuous_ec (continuous electro-chemistry). There is a one-to-one mapping between an asset-type and a data table for specific component information of that type. For example, asset-type with id 1 (Table 7), has an associated table called $$\texttt{airframe_octorotor_tb}$$ that holds the model parameters for the airframe dynamics of an octorotor UAV. When a user defines a new asset-type, an associated table is created automatically with the necessary fields required to work with the framework. The user can then specify additional fields relevant to their application. The $$\texttt{description}$$ property contains information regarding the source of the model that is used by the asset, or any other contextual information about the model the user wishes to provide. For example, DC motor dynamics are well understood and simple models like the one used here can be considered generic. But it may be more appropriate to cite an author and year for more complex models, such as $$\texttt{plett_2015}$$ for a specific battery model. Further asset-types might include electronics or equipment, among many other possibilities.

An asset-type must exist before an asset of that type can be created. This is stored in a table called $$\texttt{asset_tb}$$. Required fields necessary to properly interface with the rest of the framework are $$\texttt{id}$$, $$\texttt{owner}$$, $$\texttt{type_id}$$, $$\texttt{process_id}$$, and $$\texttt{serial_number}$$. The $$\texttt{id}$$ field is automatically generated and cannot be altered; $$\texttt{owner}$$ and $$\texttt{serial_number}$$ fields will automatically generate values if none are supplied (the current user and a random 8 digit hexadecimal value); the $$\texttt{process_id}$$ is not required. However, if one is supplied it will be validated against an existing process ID; and finally, the $$\texttt{type_id}$$ is required and the API automatically assign the correct value for the given type. The $$\texttt{type_id}$$ field of the $$\texttt{asset_tb}$$ table is a foreign key reference to the $$\texttt{id}$$ field of the $$\texttt{asset_type_tb}$$ table. The relationship between the asset table and asset-type table is depicted at the bottom of Figure 10.

Figure 10. Relation diagram (assets).

Four other tables are depicted in Figure 10 that store the model parameters for the asset-types listed in Table 7. These are parameters of the component models and are specifically related to that component model type, a.k.a., asset-_type. There is a one-to-one relationship between a given model class and an entry in the asset-type table, however, there can be any number of model instances of the same model class. This is reflected in the real world, especially thinking about organizations that operate fleets of the same vehicle made of the same parts. Enforcing this constraint (and others) using a database management system is straightforward and works reliably when properly implemented. All other tables that have a relation with the asset table are defined with a data schema using the same mixed approach as described for the asset table. We direct the reader to the documentation (https://github.com/darrahts/phm_data_framework) for more in depth information on all aspects of the data schema and implementation. Each table (with the exception of $$\texttt{uav_tb}$$) presented in Figure 10 comes with default parameters that are provided from the information in the $$\texttt{description}$$ field of the $$\texttt{asset_type_tb}$$. For the battery, we use the model given by Plett^[37], and thus the default parameters for this model come from that source. Each of these tables is linked to the asset table via foreign key relationships on the $$\texttt{id}$$ fields, whereby the asset table entry must exist before the derived component model entry is created. This enforces a required constraint that is necessary to properly track a component that generates data to the model parameters are for that model, and it decouples the model definition from the source code. This decoupling between model parameters and the object representation they hold when used in simulation is another aspect that supports a robust data generation process and improves traceability. Finally, there is the $$\texttt{uav}$$ type (see Table 7), a special type of asset that serves as a container to store asset IDs of the installed components and links to the process and environmental models. This is one of many concepts applied that provide modularity and data organization, and serves as the common interface among all components. Correctly storing and extracting data generated from different sources and experiments can be very tedious and prone to errors. The metadata provided by the asset makes it easy to track the components with all other factors and sources of data within the simulation. This is a subtle, but very critical piece of the framework that is repeated with not just assets like motors and batteries, but with processes, like degradation or wind.

Processes

Processes capture dynamic interactions between the system and the environment. Many different types of processes can be modeled. In this work, we model internal component degradations and external wind gusts. Each component has its own set of degradation profiles and failure modes that are separate from, but affect the overall operation and health of the system. Therefore, the framework must have the ability to track processes just like tracking components. In a similar manner to modelling components as assets having asset-types, the process archetype also has process types (Table 8). Processes and assets are closely related as depicted in Figure 11. It is required that every process modeled be mapped to an asset, so as to track the relations between processes and components. This is something that is easy to lose sight of, and something as simple as a small parameter value change can have large differences in the resultant data. Therefore, processes and assets are tracked together. Each process has a foreign key relation $$\texttt{type_id}$$ on the $$\texttt{process_type_tb}$$$$\texttt{id}$$ field, which has a foreign key relation $$\texttt{asset_type_id}$$ on the $$\texttt{asset_type_tb}$$$$\texttt{id}$$ field. With these relationships and constraints established, the joint interactions between various processes and whole system performance are captured in the database by design, and require no special attention by the researcher as long as the framework is implemented correctly.

Figure 11. (a) entity relationship among processes and assets; (b) entity relationship with data fields and types.

Having a well-defined foundation for managing assets also makes parallelization and performing Monte Carlo simulations easier. Multiple assets can be created to run the same code in separate instances, separate machines, or even in the cloud. Data-driven experiments, this one included, are typically based on stochastic simulations and this flexibility simplifies planning, optimizing, and executing them. "The devil is in the details", and correctly storing and extracting data generated from these experiments can be very tedious and prone to errors. This framework addresses these challenges simply through its inherent organization and use of an underlying database management system.

Data management

We are especially concerned with components, degradation models, environmental models, and other internal and external events that generate information useful for prognostics applications. Metadata is just as important to capture as the raw data as well. Ensuring these complex interactions are captured and all relevant metadata and data from components, processes, the environment, and all other sources is the cornerstone of any data-driven CPS process, especially that of system-level prognostics. All data that is generated is inherently organized correctly when this framework is used in conjunction with a simulation environment. In this manner the entire process of data generation, storage, retrieval, and analysis among flights with different components can be executed with the same code. It is left to the individual practitioner to implement the dynamical models of their system; this framework handles everything else.

The data relationship diagram is shown in Figure 12, where three primary types of data are considered: degradation data, summary data, and telemetry data. The $$\texttt{flight_degradation_tb}$$ and $$\texttt{flight_telemetry_tb}$$ tables have a foreign key relation on the $$\texttt{flight_summary_tb}$$, which is the table that links back to the UAV and all tangible assets or processes in the simulation environment. The $$\texttt{flight_summary}\texttt{_tb}$$ contains aggregate data from each mission such as its ending state of charge (z_end), average position error (avg_pos_err), or distance travelled (for a complete description of the table schemas see https://github.com/darrahts/uavTestbed/blob/main/sql/table_schema.sql). Some of these data fields are application-specific, such as average position error. If this framework were applied to a different CPS, such as an energy grid, the flexibility in this framework allows for the end researcher to tailor their data needs to their specific application. This is made available with the API. We discuss how this is implemented with a UAV system in an urban environment in the following section.

Figure 12. Relationship diagram (data).