Configure the OT Bus Stop

Hide Topic ContentsShow Topic Contents
  1. Configure the OT bus stop
  2. Create message definitions
    1. Introduction
    2. Create a message definition to send counter data to Intelligence
    3. Create a message definition for equipment states and modes
    4. Create a message definition for process variables.
    5. Create a message definition for production run data for Intelligence.
  3. Create channel messages

This document details the steps required to create an OT bus stop in ATS Bus.  For further details, please refer to the ATS Bus Documentation. 

Configure the OT bus stop

Follow these steps to configure the OT bus stop to send counter, state, mode, variable and production run data to Intelligence:

Create operations and topics in the ‘Master data’ section of ATS Bus Cockpit that are used by the ADOS and OT bus stop.

Create message definitions (see: Create message definitions).

Create channels and channel messages and link the correct message definition (see: Create channel messages).

Create or update an OT bus stop.

Select the operations and topic in the ‘Operations’ and ‘Topics’ tab, the ADOS bus stop should have the same operations and topics selected.

Select the channels from the ‘Channels’ tab.

Configure channel messages actions to publish the counter, mode, state, variables and production run data to Intelligence. The ‘PublishAsWorkPerformance’ action is an action that publishes this data as ‘ProcessWorkPerformance’ bus messages.

Create message definitions

Introduction

The IT, ADOS and Cloud bus stop channel messages work with contextualised data, data that is formatted in such a way that the meaning and the context of each value is obvious. Most common used data formats are XML and JSON. These bus stop convert the channel message data to and from B2MML using an XML transformation which is relatively easy to build.

The OT channel messages on the other hand work with one or more individual items, named tags. A tag only provides a value, data type and the source or destination but it does not provide a description explaining where the value is used for.

For example, a serial port reads the value e.g. 25. This value does not say anything, it is 25. It could be 25kg coffee, 25 cars, 25 bottles or something completely different. The ‘tag’ only provides the value 25, the data type integer and the location where it is coming from namely the 10th byte in the stream coming from the serial port.

The OT bus stop uses a message definition and message fields to transform the channel message into a shopfloor message (which is used by the OT bus stop internally). A shopfloor message stores the tag values based on the class type specified in the message definition that the channel message refers to. This classifies (contextualizes) the data and tells the user what kind of data is stored in the tag. Each class type refers to a specific location in the B2MML information models and this enables the OT bus stop to convert between shopfloor messages and B2MML.

This section explains which class types to use to send counter, equipment mode and state, production run and downtime data to Intelligence.

Create a message definition to send counter data to Intelligence

Counter data sent to Intelligence contain the following items:

Counter for good materials

Counter for scrap materials

Counter for total materials

An equipment ID that reports these counts

The counters are defined as class type ‘Counters’ and there are 3 preconfigured counters: ‘Good’, ‘Scrap’ and ‘Total’. The equipment ID is considered equipment context and the class type ‘EquipmentContext’ provides a preconfigured item for the equipment ID.

The message definition for any channel message that provides counter data for Intelligence should contain message fields with the following class types:

Counters -> Name = Good

Counters -> Name = Scrap

Counters -> Name = Total

EquipmentContext -> Name = EquipmentId

This message definition can be linked to any upload channel message to select the ‘source’ of the data. The channel message can then be published on the bus as a ProcessWorkPerformance bus message by assigning the ‘PublishAsWorkPerformance’ action. This action will create B2MML containing the following content:

<JobResponse>

  <EquipmentActual>

    <EquipmentID>ENTERPRISE.SITE.AREA.CELL.UNIT1</EquipmentID>

    ...

  <EquipmentActual>

  <MaterialActual>

    ...

    <MaterialUse>Produced</MaterialUse>

    <Quantity>

      <QuantityString>4</QuantityString>

      <Key>Good</Key>

    </Quantity>

    <Quantity>

      <QuantityString>1</QuantityString>

      <Key>Scrap</Key>

    </Quantity>

    <Quantity>

      <QuantityString>5</QuantityString>

      <Key>Total</Key>

    </Quantity>

    ...

  </MaterialActual>

</ JobResponse >

Create a message definition for equipment states and modes

Equipment state and mode data sent to Intelligence contain the following items:

Equipment state

Equipment mode

The time at which the mode or state changed.

An equipment ID that reports these modes and states.

Modes, states and equipment ID are represented by the following message field class types:

EquipmentCondition -> Name = EquipmentState, the equipment state.

EquipmentCondition -> Name = EquipmentStateTimeStamp, the time at which the state changed.

EquipmentCondition -> Name = EquipmentMode, the equipment mode.

EquipmentCondition -> Name = EquipmentModeTimeStamp, the time at which the mode changed.

EquipmentContext -> Name = EquipmentId

The ‘Index’ property used by the ‘EquipmentCondition’ and ‘EquipmentContext’ class types must be equal for each equipment, this property ensures that the equipment conditions and context are grouped in the same EquipmentActual B2MML node. The ‘Index’ property is stored as the first Description element in this EquipmentActual node. The following XML snippet shows and example of an EquipmentActual node created by message fields listed above:

<EquipmentActual>

  <EquipmentID>EquipmentContext->EquipmentID</EquipmentID>

  <Description>Index</Description>

  <EquipmentActualProperty>

    <ID>EquipmentMode</ID>

    <Value>

    <ValueString>EquipmentCondition->EquipmentMode</ValueString>

    <Key />

    </Value>

    <Value>

    <ValueString>EquipmentCondition->EquipmentModeTimestamp</ValueString>

    <Key>Timestamp</Key>

    </Value>

  </EquipmentActualProperty>

  <EquipmentActualProperty>

    <ID>EquipmentState</ID>

    <Value>

    <ValueString>EquipmentCondition->EquipmentState</ValueString>

    <Key />

    </Value>

    <Value>

    <ValueString>EquipmentCondition->EquipmentStateTimestamp</ValueString>

    <Key>Timestamp</Key>

    </Value>

  </EquipmentActualProperty>

<EquipmentActual>

The message definition shown below adds mode and state information for multiple equipment to the bus message which the Intelligence channel can handle:

EquipmentCondition -> Name = EquipmentState, Index = “Equipment1”

EquipmentCondition -> Name = EquipmentStateTimeStamp, Index = “Equipment1”

EquipmentCondition -> Name = EquipmentMode, Index = “Equipment1”

EquipmentCondition -> Name = EquipmentModeTimeStamp, Index = “Equipment1”

EquipmentContext -> Name = EquipmentId, Index = “Equipment1”

EquipmentCondition -> Name = EquipmentState, Index = “Equipment2”

EquipmentCondition -> Name = EquipmentStateTimeStamp, Index = “Equipment2”

EquipmentCondition -> Name = EquipmentMode, Index = “Equipment2”

EquipmentCondition -> Name = EquipmentModeTimeStamp, Index = “Equipment2”

EquipmentContext -> Name = EquipmentId, Index = “Equipment2”

The message definition above gives the following B2MML:

<EquipmentActual>

  <EquipmentID>EquipmentContext->EquipmentID</EquipmentID>

  <Description>Equipment1</Description>

  <EquipmentActualProperty>

    <ID>EquipmentMode</ID>

    <Value><ValueString>EquipmentCondition->EquipmentMode</ValueString><Key /></Value>

    <Value><ValueString>EquipmentCondition->EquipmentModeTimestamp</ValueString><Key>Timestamp</Key></Value>

  </EquipmentActualProperty>

  <EquipmentActualProperty>

    <ID>EquipmentState</ID>

    <Value><ValueString>EquipmentCondition->EquipmentState

</ValueString><Key /></Value>

    <Value><ValueString>EquipmentCondition->EquipmentStateTimestamp</ValueString><Key>Timestamp</Key></Value>

  </EquipmentActualProperty>

<EquipmentActual>

<EquipmentActual>

  <EquipmentID>EquipmentContext->EquipmentID</EquipmentID>

  <Description>Equipment2</Description>

  <EquipmentActualProperty>

    <ID>EquipmentMode</ID>

    <Value><ValueString>EquipmentCondition->EquipmentMode</ValueString><Key /></Value>

    <Value><ValueString>EquipmentCondition->EquipmentModeTimestamp</ValueString><Key>Timestamp</Key></Value>

  </EquipmentActualProperty>

  <EquipmentActualProperty>

    <ID>EquipmentState</ID>

    <Value><ValueString>EquipmentCondition->EquipmentState</ValueString><Key /></Value>

    <Value><ValueString>EquipmentCondition->EquipmentStateTimestamp</ValueString><Key>Timestamp</Key></Value>

  </EquipmentActualProperty>

<EquipmentActual>

Create a message definition for process variables.

Process variable data sent to Intelligence contain the following items:

Property name, value, unit of measure and a timestamp.

Equipment ID.

Properties and equipment ID are represented by the following message field class types:

Property -> Name = the name of the property. Value is provided via channel message.

PropertyAttribute -> Name = “Timestamp”, Index = the name of the property.

EquipmentContext -> Name = EquipmentId

The OT bus stop is currently unable to map the unit of measure.

The following XML snippet shows how these class types are converted to B2MML:

<JobResponseData>

  <ID>Contains the name of the property</ID>

  <Value>

    <ValueString>Contains the value obtained by the channel message</ValueString>

  </Value>

  <Value>

    <ValueString>2018-04-24T18:26:58.6971443+02:00</ValueString>

    <Key>Contains the string ‘Timestamp’ given by the PropertyAttribute named ‘Timestamp’</Key>

  </Value>

</JobResponseData>

<EquipmentActual>

  <EquipmentID>The equipment identifier obtained by the channel message</EquipmentID>

<EquipmentActual>

Create a message definition for production run data for Intelligence.

Production run data sent to Intelligence contain the following items:

Work order ID

Material ID

Lot ID

The name of the operation (optional)

Equipment ID

The time work/operation started

The time the work/operation ended

The items above are represented by the following message field class types:

Context -> Name = OrderId

Context -> Name = MaterialId

Context -> Name = LotId

Context -> Name = Operation

EquipmentContext -> Name = EquipmentId

OperationTimes -> Name = StartTime

OperationTimes -> Name = EndTime

The message definition above results in the following XML when applying the ‘PublishAsWorkPerformance’ channel message action:

<?xml version="1.0" encoding="utf-8"?>

<WorkPerformance xmlns="http://www.mesa.org/xml/B2MML-V0600">

  <PublishedDate>2018-04-24T18:26:58.7441781+02:00</PublishedDate>

  <WorkResponse>

    <ID>OrderId</ID>

    <JobResponse>

      <JobOrderID>Order ID</JobOrderID>

      <StartTime>The time the operation/work started</StartTime>

      <EndTime>The time the operation/work ended</EndTime>

      <JobResponseData />

      <EquipmentActual>

        <EquipmentID>Equipment identification</EquipmentID>

        …

      </EquipmentActual>

      <MaterialActual>

        <MaterialDefinitionID>Material definition ID</MaterialDefinitionID>

        <MaterialLotID>Lot ID</MaterialLotID>

        <MaterialSubLotID>MaterialSubLotId_112368997</MaterialSubLotID>

        <MaterialUse>Produced</MaterialUse>

        …

      </MaterialActual>

    </JobResponse>

  </WorkResponse>

</WorkPerformance>

Create channel messages

Channel messages define the source of the data and configuring OT channel messages is explained in the ATS Bus online help here. A channel message requires a message definition to contextualise the data.  Creating a message definition is also explained in the ATS Bus online help and the previous chapter Create message definitions explained which message field class types are required. A good design would be to create channel messages per Intelligence data type.  It is therefore recommended to create separate channel messages for counter data, equipment modes and states, etc.

Can we improve this topic?