This
is the 3rd article of series: Thingworx Analytics introduction.
1st
article introduces Analytics Function and Modules.
2nd
article introduces Non Time Series TTF prediction.
Environment:
Thingworx Platform 8.5, Analytics Server 8.5, Analytics Extension 8.5.
In TTF
prediction, Time Series Data model is better than Non Time Series Data model.
What’s
Time Series Data model?
As
per Machine Learning concept, the process of training model is to find the best
matching parameters, and to use them to combine with features to calculate the result
values.
For
Non Time Series Data models, it’s not relevant between current values and
previous values.
But
for Time Series Data, during each time of calculation, it will check not only
current values, but also previous values, and the previous values are time
relevant.
There’re
2 important terms here: look back size, and data sampling frequency.
Look
back size = numbers of data samples need to look back.
Data
sampling frequency = the frequency of taking a new data sample.
Look
back size * Data sampling frequency = the total numbers will be feed to run
calculation, for which I call it Look back area, the data is queried from Value
Stream, with maxItems = look back size, and startDate = current date – look back
area.
For
example, if look back size = 4, data sampling frequency = 1 minute, then look
back area = 4 minutes.
Thingworx
used Value Stream to log Time Series Data, we can run service of QueryProperyHistory
to get historic data:
Some
other notes for TTF prediction models:
• Always
set useRedundancyFilter = true
• Always
set useGoalHistory = false
• Always
set lookahead = 1
• Training
time is much longer than Non Time Series data
After
the model is published, test of model requires to input not only current values
of all features, but also previous values as defined in look back size, than
click Add Row to add the new record.
When
creating Analysis Events, please be noted that the Thing Properties of Inputs
Mapping should be Logged, because only Logged Properties can be queried with
historic values from Value Stream.
And
for Results Mapping, if we bind the result to Thing Property, even if that Property
is set Logged, somehow the update by Analytics will not be logged into Value
Stream. We can create another Property, and bind it with Results Mapping, and
sync it with the final Property you’re monitoring by Service or Subscription,
and Log it into Value Stream. After that, we can track all of the historic
changes with TimeSeriesChart.
Below
charts show the comparison between Time Series Data models predicted TTFs and
actual TTFs.
We
can see that, compare to Non Time Series models, the prediction is much more
accurate, and is faster to match the actual TTF curve.
Below
table lists out the settings of all models:
Another
note, to make sure to write all features into Value Stream in same moment in
same record, we should use UpdatePropertyValues instead of SetPropertyValues.
Some
codes for reference:
----------------------------------------------------------------------
//
Use UpdatePropertyValues to make sure to update all attribute in the same
moment
var
params = {
infoTableName : "InfoTable",
dataShapeName : "NamedVTQ"
};
//
CreateInfoTableFromDataShape(infoTableName:STRING("InfoTable"),
dataShapeName:STRING):INFOTABLE(VSTestDataShape)
var
tempDable =
Resources["InfoTableFunctions"].CreateInfoTableFromDataShape(params);
var
time = new Date();
tempDable.AddRow({
time: time,
name: "F1",
quality: "GOOD",
value: 71
});
tempDable.AddRow({
time: time,
name: "F2",
quality: "GOOD",
value: 72
});
tempDable.AddRow({
time: time,
name: "F3",
quality: "GOOD",
value: 73
});
tempDable.AddRow({
time: time,
name: "F4",
quality: "GOOD",
value: 74
});
tempDable.AddRow({
time: time,
name: "F5",
quality: "GOOD",
value: 75
});
me.UpdatePropertyValues({
values: tempDable /* INFOTABLE */
});
var
result = tempDable;
----------------------------------------------------------------------