 |
The Xentara ONNX Engine v2.0
User Manual
|
|
The Xentara ONNX Engine v2.0
User Manual
|
The Xentara ONNX Engine Model is a type of Xentara I/O component. A Model is a computing instance, allows Xentara real time processing using machine learning techniques implemented by ONNX Runtime which supports plethora of accelerating hardware libraries. The ONNX Engine Model uses a set of input samples for processing and processes a set of output values that can be used for further processing or decision making.
The Xentara ONNX Engine requires a pre-trained model type of onnx format for the assigned task. Optionally, an execution providers can be selected and configured based on the available hardware. The Xentara Onnx Engine plug-in supports plenty execution providers to accelerate the computing process.
The ONNX Engine plug-in supports plenty execution providers to accelerate the computing process.
Available execution provider list:
More supported execution providers can be found in Onnx website.
The set of inputs and the set of outputs may have the same or different data type.
The supported data types listed on the table bellow :
| Datatype | Description |
|---|---|
| FLOAT | float 32bit |
| DOUBLE | float 64bit |
| INT8 | signed integer 8bit |
| INT16 | signed integer 16bit |
| INT32 | signed integer 32bit |
| INT64 | signed integer 64bit |
| UINT8 | unsigned integer 8bit |
| UINT16 | unsigned integer 16bit |
| UINT32 | unsigned integer 32bit |
| UINT64 | unsigned integer 64bit |
| BOOL | Boolean |
The Xentara ONNX plug-in supports three input types for the models, Scalar, Array and Time series. For each type the plug-in has specific requirements.
In Scalar input type, on collect task the values of the datapoints are collected in a array buffer. The order in the data values in the buffer is the same with the order the datapoints assigned.
On the run task, the buffer forms an one dimensional tensor with the size equal to the number of the datapoints set in the input.
The model must provide an input for single dimensional tensor with the size lenth equal with the number of the datapoints set in the input.
In Array input type, the input datapoints must be type of "array". On collect task the values of each datapoints "array" are collected in a buffer. Each "array" datapoint may have different size but they must have size at least the size assigned for the input.
On the run task, each input "array" buffer collected on collect task is stacked on the top of the other in the same order the datapoints assigned in the input and form a two-dimensional tensor. The first dimension of the tensor has size equal with assing input size in the input and the second dimension has size equal to the number of the datapoints. In case of a single "array" datapoint assinged the as input, the input tensor is two dimensional with the second dimension equal to 1.
The model must provide a tensor input with the excact shape and sizes with the formed tensor.
In Time Series input type, on the collect task a single sample for each datapoint is collected in to a fixed size buffer. The collect task must be collected over specified regural intervals. Each buffer has the structure of queue (FIFO) and works as sliding window over the time. Every time the collect task is called, the data samples are collected from each datapoint feeds its own buffer until it reaches its full capacity. When all buffers are full, the run process is enabled. Once the buffers are full and new data samples pushed into the buffers, the oldest samples is removed.
On the run task the buffers are stacked on the top of each other in the same order they have been assigned in the input and form a two dimensional tensor. The first dimension size of the tensor is equal with the size of the time steps and the second dimension has size equal with the number of the datapoints. In case of single "timeSeries" datapoint assigned as input, the input tensor is two dimensional with the second dimension equal to 1.
The model must provide a tensor input with the exact shape and sizes with the formed tensor.
Compute delay defines the number of steps is set to delay the trigger of the run task. By default the value is 0 and means that once the run task is called, It will form a tensor with all the data in the buffer at the moment. For example, if this number is set to 5, it will collect other 5 samples in the next 5 steps. After the 5th step, the model will preform calculations with input tensor formed at that point of time. The compute delay number can be a positive integer number.
The model output allowed to have only one tensors as output. The selected output must provide a tensor with 1 or 2 dimension. In case of two dimensional tensor the second dimension must has the size of 1. Each value in the array can be defined as Output by it's index. The output values are updated when the run task is been completed.
The Data Logger allows Onnx Engine to store the input values in files in ".csv" format. When the data logger is active, the input values append to the logger file on run taks. The data logger generates a separate file for each input defined in the model.
The Onnx Model provides a read and write attribute "sampleCounter" which defines the number of the pending samples to be stored. The data logging process is active while the sample counter contains a positive integer higher than "0". The default state of the data logger is not active with the sample counter equal to "0". At any time, when the Onnx Engine is running, the sample counter can be set to the desired number of the sample required to stored in the file. If the sample counter was "0", a new data logger file will be created. Every time the run task is called the new values with the timestamp append on the file and the sample counter is reduced by "1". When the sample counter reaches "0", no other values append to the file and it is ready to be collected. The sample counter can be updated before it reaches "0" and set to a larger or smaller number and continue appending the next samples values with the timestamps in the existing data logging file.
While the data logger is active the run process is revoked and the output quality and error are updated accordingly.
In addition to the standard members of Xentara I/O points, Model have the following attributes:
| quality | The quality of the output’s value. See xentara_io_points_quality in the Xentara user manual for an explanation of an I/O point’s quality. |
| changeTime | The last time the output's value has changed. |
| updateTime | The last time the output’s value was updated. |
| error | The error that occurred the last time the output’s value was updated. The attribute contains one of the error string value describing error. |
| runDuration | An integer value containing the run duration process in nano seconds. |
| sampleCount | An integer value containing the amount of samples pending to be stored by the data logger. |
Collect Task reads the input samples from the datapoints. For a Scalar and Array input types, the collect task must be called before the run task to update the input values. In case of Time series input type, the collect Task must be called at standard regular intervals which defines the sample rate. The sample rate must match with the sampling rate that the ONNX model has been trained.
For a Scalar and Array input types, the run process is enabled with one Collect Task. In case of Time series input type, the run task process is enabled once the input buffer reaches the full capacity for the first time.
If the run task is triggered while an other run task is in progress, the last run task is executed after the fist task is finished. If there are multiple run task requests while an other run task is in progress, most recent task will be executed and the rest will be ignored.
| collect | Reads the input datapoint's and push the data to the buffer. |
| run | Triggers the run process on the ONNX model. |
The hasRun event is triggered when the evaluation process is finished and the output data are ready to be collected. The hasRun task can trigger tasks to use the output.
error event is triggered when during the run process an error has occurred.
| hasRun | This event is triggered once the run process is complete. |
| error | This event is triggered once an error occurred during the run Task. |