Status, Abort, Timeout and Exception Messages

This page describes how Status Messages, Abort Messages, Timeout Messages and Exception Messages can be configured/generated.

MES Qualifiers in Status and Abort Messages
Status Messages, as well as Abort Messages, can include MES qualifiers, which are required by the MES to identify the Electronic Batch Record (EBR) to which the individual message belongs. As each Status or Abort Message is generated by a Message Configuration, the qualifiers are defined by the Tag List, and only the entries marked as 'To MES' and 'MES Qualifier' are considered here.
Additionally, the Abort and Status Messages use the same 'Mapping Type' to read the values of the MES Qualifier and therefore, the generations differ depending on the Mapping Type.

Status Messages

The MSI interface is capable of generating Status Messages. These do not include any parameters, but may include qualifiers, which are used to assign a message to the correct basic function. Therefore, Status Messages are most suitable for bidirectional communication. In this scenario, a bidirectional Order Parameter Message is configured. An incoming message will include the required qualifier values, which can be stored in the system or on a connected OPC-UA Server or PLC if configured appropriately.

Status Message
Figure 1. Status Message Configuration

Alongside the qualifiers, the Status Message also includes the Status Text. This text can either be predefined or be read from a path within the system. If no path is provided, or the path is not readable, the predefined status text will be used.

The Status Message is sent whenever the Trigger Item is set to 'true' or a triggering script returns 'true'. If the message was sent by a Trigger Item, this item will be reset to 'false' when the message has been generated. The Message Name is for documentation purposes only.

Notes on Mapping

  • Group Mapping
    In order to allow different Status Texts per device and to allow different trigger items on a "per Device" basis, each device will need its own set of Status Message Configurations.
    To identify the device for which the individual configuration is valid, the property Device Name needs to be configured with the individual Device Name. The Device Path is still available, but deprecated and will be removed in the future.
    Based on the Device Name, the path of the qualifiers is resolved.

  • For Flexible Mapping and Historian Mapping, the Status Message configurations must not be used. The required qualifiers are not available and thus, the communication will not reach the correct place in the EBR.

  • For Function Mapping and Custom Script Mapping, Status Messages are not currently supported.


Abort Messages

The MSI interface is also capable of generating Abort Messages. These do not include any parameters, but they may include qualifiers, which are used to assign a message to the correct basic function. An Abort Message is intended as an alternative to the Order Parameter Message, providing an error response to bidirectional communication. Therefore, Abort Messages are most suitable for bidirectional communication. In this scenario, a bidirectional Order Parameter Message is configured. An incoming message will include the required qualifier values, which can be stored in the system or on a connected OPC-UA Server or PLC if configured appropriately.

Abort Message
Figure 2. Abort Message Configuration

Alongside the qualifiers, Abort Messages also include an Error Code and the Error Text. Both can either be predefined or read from a path within the system. The predefined Error Code and Error Text are used if no associated path is provided or if the provided path is not readable.

Abort Messages are sent whenever the Trigger Item is set to 'true' or the triggering script returns 'true'. If the message was sent by a Trigger Item, this item will be reset to 'false' when the message has been generated. The Message Name is for documentation purpose only.

Notes on Mapping

  • For Direct Mapping, Device Path and Device Name are ignored.

  • For Central Mapping, if the Mapping Type of the Message Configuration object is configured as 'Direct Mapping', the qualifier values will be determined according to the rules of the Direct Mapping. In this case, for all ObjectNames in the Tag List which are marked as qualifiers, there must be an entry for EquipmentId=<EquipmentId> and Tag=<ObjectName> in the Central Mapping Table. The Path from this entry will then be used to read the individual qualifier value.

  • For Group Mapping, in order to allow different Error Codes and Error Texts per device and to allow different trigger items on a "per device" basis, each device needs to have its own set of Abort Message Configurations. To identify the device for which the individual configuration is valid, the Device Name property needs to be configured with the individual name of the device. Based on the Device Name, the path of the qualifiers is resolved. The Device Path is still available, but deprecated and will be removed in the future.

  • To use Group Mapping in combination with Central Mapping, the Group Mapping must have one entry which identifies the DeviceSelector. This is required to identify which ObjectName from the Tag List shall be used as DeviceSelector.
    The 'Device Name' must be configured for the Status Message. This Device Name is combined with the ObjectName in the Tag List (which are marked as qualifiers) to identify the path of the qualifier in the Central Mapping Table. This table needs to have an entry for EquipmentId=<Device Name> and Tag=<ObjectName> for this combination of Device Name and Object Name. The 'Device Path' configuration is ignored.

  • For Flexible Mapping and Historian Mapping, Abort Message configurations must not be used. The required qualifiers are not available and thus, the communication will not reach the correct place in the EBR.

  • For Function Mapping and Custom Script Mapping, Abort Messages can be sent as a response instead of Order Parameter Messages. In order to send an Abort Message, there is an additional return value available for the Output Function (Function Mapping) or the Output Script (Custom Script Mapping). This additional parameter must include the Error Code, Error Text and the required qualifiers. The detailed structure of the response is described here: Function and Custom Script Mapping.

  • Using Central Mapping in combination with Function Mapping or Custom Script Mapping can generate Abort Messages, as explained below:

    • The Central Mapping Table is available as an additional input parameter to the Output Function (Function Mapping) and the Output Script (Custom Script Mapping). Therefore, in these functions, the mapping can be used to generate Abort Messages.


Timeout Messages

Timeout Messages are Abort Messages which are automatically generated whenever a bidirectional communication runs into a timeout. In order for a timeout to work correctly, the required MES Qualifier must be included in the incoming message and must be marked as 'Bidirectional'. This allows the qualifier from the incoming message to automatically generate a timeout message without any outgoing data.

The remaining configuration for a Timeout Message is the 'Error Code' and 'Error Text'.

Timeout Message
Figure 3. Timeout Configuration

Timeout Messages are generated automatically for each bidirectional communication which runs into a timeout, independent of the Mapping Type.

As Timeout Messages should be configured in a way such that the MES qualifiers can be derived from the incoming message, they do not need any mapping and therefore, are not linked to Central Mapping.

Exception Messages

The MSI interface is also capable of generating Exception Messages. These are independent from any qualifiers but may include data which can assign an exception to a running Electronic Batch Record (EBR).

The layout of the Exception Message is predefined by the MSI Standard and needs no further configuration. However, the exceptions within the Exception Message need to be created. Since many exceptions can occur during a short amount of time, the exceptions are read from a message queue. The ID of this message queue is predefined, but the object to which this message queue is attached can be configured in the Message Configuration.

Exception Message
Figure 4. Exception Message

In this example, a Message Processor is configured as the exception provider and exceptions are read from a message queue attached to the Message Processor. The following Lua code shows how exceptions can be created and placed in the message queue of the exception provider:

local JSON= require("rapidjson")
local MSI = require('mbro-msi')
local exProviderObj = syslib.getobject("/System/Core/MSIMessageBroker/MSIMessageProcessor")
local exProviderId = exProviderObj:numid()
local ex_queue_id = syslib.msgqueue(exProviderId, MSI.EXCEPTION_SLOT)

local exception = JSON.encode({
                        causedAt = "2020-11-28 12:20:00,000",
                        systemDescription = "inmation test system",
                        userDescription= "Exception",
                        exceptionComment = {{changeDate="2020-11-28 12:30:00,000",
                                            commentText="WTF",
                                            user= "me"
                                          },
                                          {changeDate="2020-11-28 12:40:00,000",
                                            commentText="Found it",
                                            user= "me"
                                          }
                                        }
    })
syslib.msgpush(ex_queue_id, exception)
'Exception Messages' are not currently linked to the Central Mapping Table, but the individual objects creating and handing over the events to the message queue can be linked to the Message Processor and as a result, have access to the Central Mapping Table.