Events

For the machines configured within MAT, events are recorded, each of which is described by a series of information such as its code, type, the aggregators set at the time the event occurs, etc.

Some examples of events that are usually recorded are:

  • alarms: a dedicated table is used to log all the alarms triggered by the machine when certain conditions are met;

  • notifications: these events, usually triggered by the machine, are recorded in a dedicated table;

  • state changes: in the MAT system, the transition from one state to another is considered an event. Although there isn't a dedicated table to log this event, state change occurrences can still be viewed among the events as they are dynamically calculated by the application;

  • button presses: every time an operator interacts with the machine by pressing a button, the event is logged in the appropriate table;

  • parameter changes: a dedicated table is used to monitor the changes of certain parameters selected during the machine's configuration;

  • image acquisition: for machines equipped with cameras, this table is maintained to record each image acquisition.

The endpoints described in this section allow you to retrieve information about the events and perform an analysis based on various interesting parameters.

/apis/events/<assetId>

GET Method

chevron-rightRequesthashtag
HTTP
GET https://{BASE_URL}/apis/events/<assetId>

where:

  • assetId : machine ID to consider.

Query

JSON
{
    "subAssetId": "subAssetId"
}

where:

  • subAssetId : sub-machine ID to consider. This field can be omitted if the asset in question is not a multi-machine setup.

The purpose of this endpoint is to retrieve all types of events recorded by the system for the selected machine. The response returns some useful information for each event type, such as the unique ID that identifies that type, a descriptive ID that helps better understand which event it is, the table in which those events are recorded, and the set of data columns that can be used to create a Pareto chart based on the data from that event.

Note that all elements in the "uniqueId" key of each object can be used to invoke the endpoint with a POST method to obtain events of that type, as explained later in the documentation. If the "uniqueId" key is associated with a list of values, then it is possible to choose one of those values.

Example

chevron-rightRequesthashtag

Query

An example of a response could be as follows. Note that for each event, an object describing that event is returned.

chevron-rightResponsehashtag

Code

OpenAPI

get

This endpoint returns the list of all the available event types. Note that events have to be configured into the machine-profile.json file correctly.

Authorizations
AuthorizationstringRequired
Bearer authentication header of the form Bearer <token>.
Path parameters
assetIdstringRequired
Query parameters
subAssetIdstringOptional

Sub-machine ID. If the machine for which the assetId has been specified is a multi-machine, then this field must always be specified as well.

Responses
chevron-right
200

A list of all the available event types.

application/json
get
/apis/events/{assetId}

POST Method

The functionality of this endpoint allows you to retrieve data related to a specific event. After retrieving all possible events by calling the endpoint with a GET method, you can specify the event to request from the obtained "uniqueId" parameters.

chevron-rightRequesthashtag

where:

  • assetId : machine ID to consider.

Query

where:

  • subAssetId : sub-machine ID to consider. This field can be omitted if the asset in question is not a multi-machine setup.

Body

In the request body, you can specify the following parameters:

  • uniqueId: a unique ID representing the event type. If this information is unknown, it can be retrieved by calling the endpoint with a GET method, as specified above.

  • from: the start timestamp from which you want to begin downloading the data, expressed in UTC in the format "YYYY-MM-DDThh:mm

    .sssZ" (ISO 8601 Standard).

  • to: the end timestamp of the interval for which you want to download the data, expressed in UTC in the format "YYYY-MM-DDThh:mm

    .sssZ" (ISO 8601 Standard). If this field is omitted or set to null, it will automatically be set to the current timestamp at the time of the request.

  • limit: this numeric field specifies the maximum number of events to return. The value specified in this field allows you to request the most recent {n} events. This field can be used in various ways:

    • "limit" without "from" and "to": the most recent {n} events will be retrieved;

    • "limit" with "from" and without "to": the behavior in this case is the same as the previous scenario. The most recent {n} events will be returned;

    • "limit" with "from" and "to": in this case, the most recent {n} events will be returned, with the end of the interval being the "to" field. The events will be the most recent ones recorded before the timestamp specified in the "to" field;

    • "limit" with "to" and without "from": this option is not allowed and will result in an error;

  • filterBy: this field allows you to specify a filter to apply to the events. The value should be a dictionary where the keys represent the fields to filter on, and the value represents what is to be accepted for that field. Events that do not match the filter criteria will be discarded;

  • calendar : boolean value indicating whether the calendar should be considered in data analysis. By default, this value is set to false.

The response will return the requested events along with some supplementary information, such as the duration, their code, and the aggregators.

Example

chevron-rightRequesthashtag

In this example, we want to retrieve the events of type "notification" that occurred within the specified interval. In the example, the notification events have the ID "1bis".

The response is provided below:

chevron-rightResponsehashtag

Example - limit

In this example, we want to obtain the most recent alarm that occurred on the machine.

chevron-rightRequesthashtag

The response is indicated below:

chevron-rightResponsehashtag

Example - filterBy

In the following example, we want to retrieve all state changes that occurred while the operator "Luigi" was on duty.

chevron-rightRequesthashtag

The response is provided below. As noted, in this case both the starting state and the ending state are reported.

chevron-rightResponsehashtag

Code

The following script can be used to make a call to the endpoint /apis/events/<assetId> with the POST method. Be sure to correctly configure the parameters in the body of the request.

OpenAPI

post

This endpoint allows a user to select an event id and it returns all events of that kind. Some parameters can be specified to restrict the analysis.

Authorizations
AuthorizationstringRequired
Bearer authentication header of the form Bearer <token>.
Path parameters
assetIdstringRequired
Query parameters
subAssetIdstringOptional

Sub-machine ID. If the machine for which the assetId has been specified is a multi-machine, then this field must always be specified as well.

Body
uniqueIdstringOptional

Unique id associated with the event type in which the user is interested. This parameter is mandatory.

Example: 1
fromstringOptional

Initial moment of the interval within which the events must be returned. The timestamp must be expressed in UTC and follow the format 'YYYY-MM-DDThh:mm:ssZ'. If both "from" and "to" parameters are null, the last state will be returned.

Default: NoneExample: 2024-04-18T10:30:00Z
tostringOptional

Final moment of the interval within which the events must be returned. The timestamp must be expressed in UTC and follow the format 'YYYY-MM-DDThh:mm:ssZ'. The value can be omitted to default to the current timestamp.

Default: Actual timestampExample: 2024-04-18T10:30:00Z
filterByobjectOptional

Object indicating for each key which value is allowed. All data that do not meet this condition will not be taken into consideration. Notice that filters can only be applied to aggregator columns, i.e., those columns whose names follow the format "aggr" + number. Applying a filter to a table that doesn't have these columns will result in obtaining no data. Filters can only be applied to aggregator columns.

Default: NoneExample: {"aggr0":"Waluigi","aggr1":"recipe1"}
limitintegerOptional

This field can be used instead of "from" and "to" to return the last {n} events. If a range is specified with "from" and "to", the last {n} events within the indicated range will be returned. If only "from" is specified, the last {n} rows will be returned. Specifying only "to" is not allowed. The "limit" operation has no effect if a value for the "resampleBy" field is specified, as that command takes precedence over "limit". You can use "limit" by itself, with "from", and with both "from" and "to". You can never use "limit" with only "to". It is not allowed to use the "limit" field with events of type 3 or type relative to state transitions.

Default: nullExample: 10
Responses
chevron-right
200

A list of events of the specified type.

application/json
post
/apis/events/{assetId}

/apis/events/<assetId>/pareto

POST Method

A Pareto chart is a data visualization tool that represents the cumulative frequencies of variables in descending order. It is based on the Pareto principle, which states that a small number of causes (or categories) tend to produce the majority of effects (or results).

In a Pareto chart, the categories are arranged on the x-axis in descending order of frequency, while the cumulative frequencies are represented on the y-axis. This type of chart is often used to identify and focus on the main causes of a problem, allowing for efficient resource allocation to achieve the greatest impact.

chevron-rightRequesthashtag

where:

  • assetId : machine ID to consider.

Query

where:

  • subAssetId : sub-machine ID to consider. This field can be omitted if the asset in question is not a multi-machine setup.

Body

In the request body, you can specify the following parameters:

  • uniqueId: a unique ID representing the type of event. If this information is unknown, it can be retrieved by invoking the endpoint with the GET method, as specified above.

  • paretoColumn: the column on which the Pareto chart should be built. Note that a Pareto chart is essentially a group-by operation. This field can be considered as the data on which the group-by operation is performed. To know which fields can be used for constructing the Pareto chart, you can invoke the endpoint with the GET method and refer to the key named "availableColumnsForParetoConstruction."

  • from: the start timestamp from which you want to begin downloading the data, expressed in UTC in the format "YYYY-MM-DDThh:mm

    .sssZ" (ISO 8601 Standard).

  • to: the end timestamp of the interval for which you want to download the data, expressed in UTC in the format "YYYY-MM-DDThh:mm

    .sssZ" (ISO 8601 Standard). If this field is omitted or set to null, it will automatically be set to the current timestamp at the time of the request.

  • filterBy: this field allows you to specify a filter to apply to the events. The value should be a dictionary where the keys represent the fields to filter on, and the value represents what is to be accepted for that field. Events that do not match the filter criteria will be discarded.

  • groupBy: this field allows you to group the data according to one of the specified values. The value should be a string indicating the field on which you want to aggregate. For more advanced usage, you can specify a list of strings;

  • calendar : boolean value indicating whether the calendar should be considered in data analysis. By default, this value is set to false.

This endpoint allows the user to request event data formatted in Pareto style. It is mandatory to specify the type of event and the column on which the Pareto chart should be built. These two pieces of information can be obtained by invoking the endpoint /apis/events/<assetId> with the GET method.

The column used for constructing the Pareto chart is crucial, as it will be used for grouping the data. For each value taken by this column, an object representing a Pareto bar will be returned, including relevant information.

Example

chevron-rightRequesthashtag

In this example, we want to create a Pareto chart of alarms to identify which category of alarms lasted the longest. To do this, the "paretoColumn" is specified as the column containing the alarm code, while the "uniqueId" used is the code associated with the alarms.

The response is as follows:

chevron-rightResponsehashtag

As you can see, each element in the list represents a Pareto bar. Each object contains two keys: the first, "groupByValues", contains the value taken from the "code" column, while the second, "data", contains the information for the Pareto bar associated with that value of "code".

If we were to interpret this response, we could say:

"For the machine 40-line, from May 15 until now, a total of five alarms have occurred. Three alarms had the code 'al_M1_2' and had a total duration of 1118.61 seconds. One alarm of type 'al_M1_1' occurred within the interval and lasted 1512.46 seconds, and the same situation applies to alarms of type 'al_M1_3' as only one occurred with a duration of 525.04 seconds."

Example - filterBy

chevron-rightRequesthashtag

In this example, we want to construct a Pareto chart of the alarms that occurred when the active operator was Luigi. This condition has been specified in the request using the "filterBy" field.

The response is as follows:

chevron-rightResponsehashtag

Example - groupBy

The following example demonstrates how to create a Pareto chart of alarms based on both the alarm code column and the active operator at that time. To achieve this, it is sufficient to include the "groupBy" field in the request body.

chevron-rightRequesthashtag

The response is as follows:

chevron-rightResponsehashtag

As you can see, the Pareto chart in this case is constructed using two columns: "code" and "aggr1". The various values taken by these two columns are specified in each object within the "groupByValues" key.

Code

The following script can be used to make a call to the endpoint /apis/events/<assetId>/pareto with the POST method. Be sure to correctly configure the parameters in the body of the request.

OpenAPI

post

This endpoint allows a user to request some events data formatted in a Pareto style. It is mandatory to specify on which kind of event and on which column the Pareto has to be constructed.

Authorizations
AuthorizationstringRequired
Bearer authentication header of the form Bearer <token>.
Path parameters
assetIdstringRequired
Query parameters
subAssetIdstringOptional

Sub-machine ID. If the machine for which the assetId has been specified is a multi-machine, then this field must always be specified as well.

Body
fromstringOptional

Initial moment of the interval within which the events must be returned. The timestamp must be expressed in UTC and follow the format 'YYYY-MM-DDThh:mm:ssZ'. If both "from" and "to" parameters are null, the last state will be returned.

Default: NoneExample: 2024-04-18T10:30:00Z
tostringOptional

Final moment of the interval within which the events must be returned. The timestamp must be expressed in UTC and follow the format 'YYYY-MM-DDThh:mm:ssZ'. The value can be omitted to default to the current timestamp.

Default: Actual timestampExample: 2024-04-18T10:30:00Z
uniqueIdstringOptional

Unique id associated with the event type in which the user is interested. This parameter is mandatory.

Example: 1
paretoColumnstringOptional

Name of the column belonging to the event's table that has to be used to construct the Pareto. Available values can be retrieved using the GET method of this same endpoint. This parameter is mandatory.

Example: code
filterByobjectOptional

Object indicating for each key which value is allowed. All data that do not meet this condition will not be taken into consideration. Notice that filters can only be applied to aggregator columns, i.e., those columns whose names follow the format "aggr" + number. Applying a filter to a table that doesn't have these columns will result in obtaining no data. Filters can only be applied to aggregator columns.

Default: NoneExample: {"aggr0":"Waluigi","aggr1":"recipe1"}
groupBystringOptional

Aggregator to be used for grouping the data. Group by can only be applied to aggregator columns.

Default: NoneExample: aggr0
Responses
chevron-right
200

A list of events data formatted in a Pareto style.

application/json
post
/apis/events/{assetId}/pareto

/apis/breakdowns/<assetId>

POST Method

A specific type of Pareto chart that can be viewed within MAT is the Downtime Pareto. A downtime occurs when the machine switches from a productive state to a non-productive state due to an alarm. The application includes a dedicated section for analyzing this type of event through the visualization of a Pareto chart. To obtain the exact same analysis performed in MAT, the following endpoint can be used.

chevron-rightRequesthashtag

where:

  • assetId : machine id.

Query

where:

  • subAssetId : ID of the sub-machine to be considered. This field can be omitted if the asset in question is not a multi-machine system.

Body

In the request body, the following parameters can be specified:

  • from: Start timestamp from which to begin downloading data, expressed in UTC in the format "YYYY-MM-DDThh:mm:ss.sssZ" (ISO 8601 standard);

  • to: End timestamp of the interval for which to download data, expressed in UTC in the format "YYYY-MM-DDThh:mm:ss.sssZ" (ISO 8601 standard). If this field is omitted or set to null, it will automatically default to the current request time;

  • paretoType: String indicating the type of Pareto chart to retrieve. To get the Downtime Pareto, specify the string "historyBreakdowns". Alternatively, you can specify other Pareto types as configured in the dashboard-breakdowns-alarms.json file of the machine;

  • filterBy: This field allows you to apply a filter to the events. The value must be a dictionary where the keys represent the fields to filter on, and the values specify the accepted values for those fields. Events that do not match the filter will be excluded;

  • groupBy: This field allows you to group the data by one of the specified values. The value should be a string indicating the field to group by. For advanced usage, a list of strings can be provided;

  • oeeLoss: Boolean indicating whether to include in the response the OEE loss caused by each type of downtime/alarm;

  • filterUnknown: Specifies whether to ignore downtimes with an unknown cause during the analysis;

  • unknownBreakdownsName: String specifying the label to use for downtimes with unknown causes;

  • calendar: Boolean value indicating whether the calendar should be considered in the data analysis. By default, this value is set to false.

Example

chevron-rightRequesthashtag

The response will include both data related to KPIs calculated from the data and the list of all downtime categories that make up the Pareto.

Last updated