When dealing with a data science problem, not all projects are the same. Depending on the data and the objective, different methodologies are applicable to the problem. The best methodology depends on many characteristics of the problem: amount of data, presence of a failure history, etc.
Here we will see one of the criteria used at Amiral Technologies to characterize the data: the cyclicity of the data.
Cyclical data? What is it?
At its simplest, what we call “cyclical data” are data resulting from a measurement of a phenomenon repeating over time. In this case, each measurement cycle is the set of time measurements (pressure, temperature, current, etc.) linked to one of these phenomena.
Here we can see an example from measurements during charge and discharge cycles of a battery (dataset link). This is a simple case of cyclicality, where the data from the different charge cycles constitute a cyclic data set, each cycle being “1 battery charge”.
Cyclical data is a type of problem that comes up regularly in data analysis. The main interest in identifying this particular type is that it is possible to apply specific algorithms to deal with these cases.
What are the precise conditions for having cyclical data?
“Having a repeating phenomenon” is an informal definition of “cyclical data”, and can be confusing. Airplane flights can be seen as a repeating phenomenon, the “phenomenon” here being flight. But the behavior between each flight can vary enormously, for example depending on the weather conditions or the route taken. In this case, the data is not considered cyclical, as most of the variations in the data are related to the nature of the flight. In contrast, a robotic arm that repeatedly performs the same cutting operation, always taking the same time, will have perfectly cyclical data.
In fact, to have cyclical data, the variations between two cycles must be related as much as possible to the state of health of the system that one wishes to study, and not to variations in the context of use.
In the event that the vast majority of variations are due to the context of use, the data is not considered cyclical. Starting from this worst case, there is a whole spectrum of intermediate cases where both sources of variations are present, up to the ideal case where the variations are only related to the state of the system studied. The closer the data is to the ideal cyclic case, the more likely the cyclic methods are to work.
In practice, it is generally the following points that must be checked to see if it is possible to approach the problem from a “cyclical data” point of view:
- Each cycle should be the same length, or at least a similar length. For example, for the charge cycles of a battery, the time is not exactly the same, but it is comparable, and the system follows the same timing logic.On the contrary, for the flights of an airplane, it is obvious that the times will be very variable.
- The data for each cycle must be comparable, and derived from a similar phenomenon. As mentioned previously, it is necessary to look if the differences between each cycle are rather related to a variation of the studied system, or if they depend essentially on the context of use. The idea behind this is to estimate whether variations intrinsic to systems will not be masked in the data by variations in context.
In practice, there are some subtleties that we will detail below.
Cycle length
When the data comes from a repetitive operation performed by a machine, generally the cycles are directly of the same length. Any slight variations can be corrected by resampling the data. This is the simple case, where the similar “length” is a time length: each cycle is the same time, and therefore it is clear that the data from these cycles are time series of the same length.
For example in the aforementioned case of charging a battery, the duration of the cycles varies on average by 4%, compared to the average duration of a cycle. In this case it is possible to resample all the cycles so that they are of the same length without significant loss of information.
There are also more subtle cases, where the data can be reduced to cycles of the same length versus length and not time. This is the case with some rotary systems, such as a turbine. In these cases, if we consider a cycle as the measurements (in particular vibrations) made during a revolution of the turbine, then the cycles vary in duration and strongly depend on the speed of rotation of the turbine. But by expressing the measured variables as a function of the current angle of the turbine and not as a function of time, each cycle is then of the same length, and can optionally be processed by cyclic methods.
Comparability
It is not enough to have cycles of the same length, it is also necessary to have comparable data. For example, many 30-second samples of measurements (temperature, pressure, current, etc.) taken randomly on a machine are generally not comparable. If the machine does many different operations, then the operation in progress at the time of the sample is generally going to be the primary factor influencing the measured data, which will tend to obscure the anomaly differences.
In an ideal case, the measurements forming the cycles result from the same repeated similar operation: the same movement for a robotic arm, the same resistance test of a part, the same starting phase, etc.
A regular special case is when the contexts influence the data a lot, but there are only a few different contexts of use within the framework of the problem being studied. In this case it is possible to have one model per context, if there is enough data to learn to recognize it. This learning of the context is important, because in failure prediction without a historical label, new contexts are very often categorized as failures.
The final word
In this article, we have seen what cyclical data is. This is data segmented into cycles, where each cycle corresponds to the repetition of a similar phenomenon, that is to say that the variations between each cycle are mainly due to changes intrinsic to the system studied.
In practice, there are no ideal cases, just cases where cyclical methods are more appropriate. In these contexts, it is in particular possible to use specific techniques for generating features. These techniques can, for example, improve the performance of blind failure detection models.
DiagFit contains a tool for generating highly discriminating features, analyzing the temporal evolution of each cycle. This feature generation step enables the high performance of the models when training on the data. Instead of learning the models on the raw data, the data is first transformed using a feature generator (possibly combined with other techniques), and then the models are built on this transformed data.
The next article will present a concrete case of using DiagFit for anomaly prediction without historical data, with cyclical data.
