Message Configuration

For an initial MSI connection between PAS-X and system:inmation, a Message Configuration object is not needed but as soon as data is exchanged, the Message Configuration object is required to send or receive messages.

Be aware, that most of the properties of a Message Configuration are intended to specify an Order Parameter Message and especially the parameter involved, while other message types like Order Status Message only require small amount of configuration.

The settings for each Message Configuration, which will be explained in the following section.

Message Configuration objects can be created below Message Processor and Message Broker objects in the I/O Model. TO do this, right click on the parent object and select Admin  New  External Interfaces  Message Configuration from the context menu to open the Create Object wizard.

Message Configuration Properties
Figure 1. Message Configuration Properties

Apart from the mandatory Object Name and optional Object Description properties, the important properties are described below. These configure the header information of the message:

In the Common property compound:

  • Processing Mode - During these configuration steps, the Processing Mode should be kept in "Configuration" mode. When everything is fully configured and ready to start, the Processing Mode is set to "Operation". The other two modes are used for automatic generation of the configuration or generation of XML messages, which both will be explained later.

In the Communication Options property Compound:

  • Communication Mode - This property configures whether the message shall be Sent from PAS-X to inmation or Received by Pas-X. Be aware, that definition can be percieved as counter intuitive as is defined from the PAS-X point of view, but it is configured in inmation. In this example we have a message which is sent from PAS-X to inmation.

In the Message Description Properties property compound:

  • Message ID - This is the id of the message, this field is mandatory and is used within inmation to identify the message.

  • Supplier ID - this field defined the id of the supplier, this field is mandatory.

  • Device Type ID - this field defined the type of device in question, it is also mandatory.

  • Description - this gives a short, human-readable description of the message, which is optional.

  • Supplier Version - this field is intended to distinguish between several version of a message configuration on supplier side, it is optional, as message description are versioned within PAS-X independently.

  • System Name - this field hold the system name information and is option.

  • Functional ID_ - this field provides a functional ID, which is also optional.

After these fields are configured, the header of an Order Parameter Message is defined.

Tag List

The next thing to configure is the actual message content also called “parameters” in the MSI realm. The parameters are defined within the Tag List table property, which can be opened from the object properties panel.

Message Configuration - Tag List Table Property
Figure 2. Message Configuration - Tag List Table Property

The column names and configuration options are detailed below:

  • Object Name: The object name defined the name of the parameter in the MSI message

  • Object Description: this is an optional field for further information on that object

  • Data Type: this defined the datatype of the parameter. With the Data Type automatic type conversion is managed on the inmation side.

  • Direction: Is this a parameter that is send from MES to Shopfloor, or is it send from Shopfloor to MS.

  • MES Qualifier: this information is used in order to identify the correct EBR and Basic Function, this message belongs to on the MES side. As the example shows a Send message, which is send from MES to SF, this field does not hat a meaning.

  • Shopfloor Qualifier: this field identifies,if the parameter is used as a qualified, meaning it identified e.g. the device the message shall be routed to, or the process this message belongs to (in case, there are several processed running simultaneously on a device). Currently this parameter is not used by inmation.

  • Range Low and Range High: These fields defined the allowed Range of valued for this parameter, this makes only sense for numeric values.

  • UOM: Unit of Measure: this defines the unit of measure for the given parameter. The entries here should match the units of measure defined within the PAS-X MES system, there is no validity check on this text field.

  • Locked: This field is only used for automatic taglist generation and not needed if the taglist is configured manually (which is recommended)

A more complex message would look like the following screenshot, here some parameters are only send from MES to Shopfloor other are send from Shopfloor to MES and others are bidirectional.

Message Configuration - Tag List Table More Complex
Figure 3. Message Configuration - Tag List Table More Complex
Here the BatchID is bidirectional and MES Qualifier, therefore it is important, that the same BatchID received from the MES is returned in the response message. Otherwise the message will not be assigned to the correct EBR and will probably return an error.

Mapping Data to Tags

The next thing to consider is now, how the received information shall be processed or better, which tags it should be mapped to. Also, where information should be read from in case we want to send a message that is "receive" message.

There are several ways how the mapping can take place:

  • Direct Mapping - the simplest option, where parameters are mapped 1:1 to tags.

  • Group Mapping - A more complicated option, where one device out of a group of devices can be addressed

  • Custom Mapping - Here the mapping is performed by user defined Lua scripts.

This is defined in the Mapping Type property at the bottom of the Message Description Properties property compound.

Direct Mapping

Direct mapping is a simple form of mapping data from a MSI Message into the inmation system. In this case, each parameter of message is mapped onto exactly one IO-Item. In order to use direct mapping, the Mapping Type has to be configured to "Direct"

Mapping Type - Direct
Figure 4. Mapping Type - Direct

Open the Direct Mapping table property to configure the mapping. This table basically mapped the Object Name to an _Object Path. The Object name must be identical to the definition in the Tag List, otherwise the mapping will fail and no messages will be sent or received.

Direct Mapping Table
Figure 5. Direct Mapping Table
It is also possible to define a property of a object in the I/O Model as Source or Target of the information in a MSI message by using the appropriate property path.

Whenever a MSI message is sent to the MES System, the message processor must be notified to do so. In the case of a direct mapping, the object at the path of the Trigger Item is monitored, and if it is set to true, a message is sent. When the message was generated, the item is automatically reset to false.

Group Mapping

Group mapping is used, if there is a group of identical or exchangeable devices configured within inmation. In order to qualify as exchangeable, the layout of the I/O Items (regarding MSI) must be identical, only the base path may differ (for example, they are located under a different connector).

In order to use group mapping, the Mapping Type has to be configured to "Group" which will change the available Options below.

First of all, the device which shall receive or send a message has to be identified. To do this, open the Device List table property.

Device List Table Property
Figure 6. Device List Table Property

The columns in the Device List table should be configured as described:

  • DeviceName: Name of the device used in the message (if sent from MES to Shopfloor )

  • Device Path: this is the patch of the device, all tags must be below this path

  • Trigger Item: This trigger item is checked and if set to true, a message will be sent.

It is important that the name of a device send from MES to Shopfloor must exactly match the DeviceName in this table, otherwise the Device will not be found and the message cannot be received correctly.

In addition to the list of the devices, it is important to configure how the parameters shall be mapped to the device in question, to do this, open the Group Mapping table property:

Group Mapping Table Property
Figure 7. Group Mapping Table Property
  • ObjectName: name of the parameter in the TagList.

  • TagName: this is the second half of the path that will be addressed for that information. the full path is calculated as DevicePath .. "/"" .. TagName. This allows for structured Tag layouts, where Tags are defined in the subfolder of the device folder.

  • DeviceSelector: this flag identifies, which ObjectName shall be used as DeviceSelector, the first one found will be used. The content of the parameter defined by that ObjectName must match one of the DeviceNames in the Device List table!

Custom Script

The last mapping type is called custom script and the mapping is completely done by custom scripts.

In order to use custom mapping, the Mapping Type has to be configured to "Custom" which will change the available Options below.

Mapping Type - Custom
Figure 8. Mapping Type - Custom

There are two scripts, the first script is the Input Script, this script shall return a function, which is itself then called whenever a message has been received. The input parameter of this function is the content of the message as lua table. This script can return true or false.

A simple example of an input script like this:

local dataInPath = "/System/Core/integrationTest/MProC/DataIn"
local JSON = require('rapidjson')
local fun = function(content)
     local jsonData = JSON.encode(content)
     local res = syslib.setvalue(dataInPath, jsonData)
     return res
end
return fun

The second script is the Output Script, this script is called every second to see if there is data available for sending. If no message shall be sent, this script must return nil. Otherwise is must return the data matching the message configuration. An example of a simple output script, only returning data read from an IO-Item is:

local dataOutPath = "/System/Core/integrationTest/MProC/DataOut"
local JSON = require('rapidjson')
local fun = function(content)
       local jsonData = syslib.getvalue(dataOutPath)
       if jsonData then
             local data = JSON.decode(jsonData)
             syslib.setvalue(dataOutPath, "")
             return data
        else
               return
        end
end

The output table must be of the form:

{parameter={ ObjectName1= Value1, ObjectName2, Value2}}

Where "ObjectName1" and "ObjectName2" must match the object names defined in the Tag List table. In addition to the parameter section of the message, all other information needed to generate the message is taken from the configuration above. This includes qualifier information, MessageID etc.

XML Generation

If we have configured a message successfully following one of the possibilities described above, we still have to exchange the Message Configuration with the PAS-X MES system. Therefore a dedicated XML template is provided which is filled automatically by the system. If we switch the Processing Mode of the Message Configuration object to "Update XML-File" the XML Message Description is generated in the folder configured in the Message Broker object.

The generated XML will be displayed in the Message Configuration object properties panel as follows:

Generated XML
Figure 9. Generated XML

XML File Location gives the full path of the generated Message Description XML. The XML Output can be directly checked for consistency:

XML Output
Figure 10. XML Output
The generated XML file has to be loaded into PAS-X in order to be usable within an MBR.

Message Configuration generation

It is also possible to automatically generate the Tag List (in the case of a direct mapping) by configuring the Folder Settings table property.

Folder Settings
Figure 11. Folder Settings

Each row of the table defines the path to a folder which shall be scanned for "Tags". The default behavior is to include all Tags in the folder and in subfolders. With Whitelist the Tags are limited to all Tags containing the given in their name. Blacklist excludes all Tags which contain the given string in their name. Whitelist and Blacklist are case sensitive.

In this example : "/System/Core/Batch Simulation/Machine1/Data" is included "/System/Core/Batch Simulation/Machine1/AbortData" is not included.

And additionally: "/System/Core/DemoItems/Setpoint 1" is included. "/System/Core/DemoItems/Setpoint Goods" is not included.

In order to generate a message configuration from the tags in the selected folder, switch the Processing Mode of the message configuration to "Update Taglist".

As the Tags don’t carry any information regarding MES Identifiers or Shopfloor Identifiers, the generated Tag List will not have this information configured. Therefore it is advisable to check the generated configuration for completeness. The Direct Mapping is also created, but currently the direct mapping is not updated, when the Tag List is updated.