Introduction
A work order tells an operation what to do, it contains the order number, an operation ID, serial numbers for the products to produce, machine parameters like the tools to use and how many products should be produced. A work order is presented as a B2MML OperationsSchedule and the OT bus stop is able to consume it by subscribing to it.
The work order handling in the OT bus stop contains 4 major parts:
The datatype scope
The ability to subscribe to and enqueue the work order
A mechanism to store work order
Channel message actions to work with the work orders.
Datatype scope
Datatype scope is the granularity at which the operation reports. By default, the operation reports by order ID and Operation but there are operations that report per serial number or per batch. This concept is used when enqueuing a work order but also when selecting a work order to update it.
For more information about datatype scope and how to configure it, please click here.
The ability to subscribe to and enqueue the work order (B2MML OperationsSchedule)
To receive and queue work orders, the OT bus stop has to subscribe to the ‘ProcessOperationsSchedule’ bus message. The B2MML message contains work orders for multiple operations. By default, the B2MML OperationsSchedule is split per order and operation (because this is the default datatype scope) and each order is queued. If the datatype scope is set to order + operation + serial number, then each B2MML OperationsSchedule is split by order + operation + unique serial number where the serial number identifies the produced material. Example: Setting the datatype scope to Operation + Order Id + Serial Number will split an OperationsSchedule containing 1 order, 2 operations and 2 serial numbers per operation into 4 separate OperationsSchedules. Each containing 1 order, 1 operation and 1 serial number. Queueing the work order is done by assigning the ‘EnqueueOrderOperation’ to the ProcessOperationsSchedule bus message in the bus message handling tab of the OT bus stop.
A mechanism to store work order
The OT bus stop stores the work orders internally in something named a saga. A saga is something that stores information for long running operations (batch record / production run). A saga not only contains the original work order, it also contains the state the work order is in, a unique key that identifies every work order (composite key), the datatype scope for the work order and the shopfloor messages that have been handled for this work order. Work orders are described here.
Channel message actions that work with the work orders
Channel message actions are used to select and download a work order to the shopfloor and they are also used to update then using information from the shopfloor. There are 2 types of channel message actions:
Actions that select a saga and download the work order information to the shopfloor:
DownloadNextOrder: This channel message action selects the ‘oldest’ work order for a given operation and allows content to be sent to the channel using a channel message.
DownloadSpecifiedOrder: This action selects the saga by specifying the lot ID, Serial number or equipment ID for a given operation.
DownloadOrderByExpression: This action allows for an expression to select the work order. See here for more details. These actions will set the work order state to ‘Dispatched’.
Actions that selects one or more batch records to be updated with information from the shopfloor.
UpdateBatch: This actions allows the user to select one or more batch records to update. See here for more details about the ‘UpdateBatch’ action. This action sets the work order state to ‘Running’.
Scenarios
Queueing one or more work orders
The OT bus stop subscribes to one or more ProcessOperationsSchedule messages and assigns the ‘EnqueueOrderOperation’ to them. The incoming ProcessOperationsSchedule message is split into one or more work orders depending on the datatype scope set for a specific operation.
Starting an operation where the equipment requests an existing work order
The equipment may send a message via one of the OT bus stop channels. This message can then be assigned the ‘DownloadNextOrder’, ‘DownloadSpecifiedOrder’ or ‘DownloadOrderByExpression’ channel message action. This action will download work order information back to the equipment via the configured channel message.
Starting an operation where the equipment does not request an order first but sends an ‘unsolicited’ message with enough information to update an existing work order or have a new one created.
The message sent by the equipment should be handled by the ‘UpdateBatch’ action and it should contain enough information to enable the OT bus stop to find the batch record for a specific work order. The UpdateBatch action has a parameter named ‘FindOrderBy’. This parameter can be set to DataTypeScope, order ID, serial number, lot ID or Equipment ID. Setting this parameter to order ID, serial number, lot ID or EquipmentID will try to find one or more batch records via the work order data (B2MML operations schedule). Setting the value to ‘DataTypeScope’ will try to find the batch records via the scope keys of the batch record. The channel message should provide values for all datatype scope items to select one batch record because a scope key that is omitted will act as a wildcard. Assume that the datatype scope is set to Operation + Order + SerialNumber, omitting the serial number will select all batch records matching the operation and order ID. Caution is advised when using this. The ‘UpdateBatch’ action will add the shopfloor message to the batch record as an operation message.
When the ‘UpdateBatch’ action is unable to find a batch records, a new one is created where the order ID is set to ‘UNKNOWN’. This batch record will not include a work order and the MES application should make sure that this record is properly archived.
Examples of scenarios like this are:
Starting a test where results are sent to the OT bus stop when a barcode is scanned.
Equipment that notifies the OT bus stop that it started an operation because it might already be aware of the work orders.
Test operations on a conveyor belt. Products pass by an RFID reader that signal the start of an operation. The RFID might be the trigger to send test results to the OT bus stop.
Receiving Operations Schedule from IT System
An operation is in progress and reports progress per serial number. The data type scope is set to OrderID + OperationID + Serial number.
The incoming Operations Schedule contains 3 serial numbers so the OT splits the schedule into 3 separate schedules, 1 per serial number.
The OT will mark the work orders as ‘Created’ (or ‘OnHold’).
Machine Requests Work Order
The machine asks for a work order. The OT bus stop gets the oldest one available and hands it to the equipment. It also marks the work order as dispatched (D).
Machine Sends Work Order Update
Update Matches Single Work Order
The machine sends a work order update. The message contains the order number, serial number and a temperature value. The OT bus stop can find the work order in the internal storage using the scope keys and updates it. In this case, the OT bus stop will find one work order using all scope keys.
The OT bus stop will set the state of the work order to RUNNING (R).
Update Matches Multiple Work Orders
In this example the machine should provide a serial number but it doesn't. This means the OT bus stop will update the highlighted work orders because:
They have a matching order ID
They have a matching operation ID
The Workcenter bus stop will find the two matching entries in the internal storage and will update both. It will also set the saga state of both to RUNNING (R).
This can be prevented by enabling the Mandatory property of the required tags in the channel message dialog.
If the required tags are set to Mandatory then, when a channel message is sent that doesn't contain all the mandatory tags, an error message will be generated and the message won't be processed.
Update Matches Serial Number
A machine sends an update work order because it wants to update the temperature. It supplies a serial number but not an order number. There is also no work order marked as running and no work order has been dispatched to the equipment. The OT bus stop matches the last entry (because of the unique serial number) and will update it. It will also mark the work order as RUNNING (R).
Update Does Not Match Work Order
A machine sends an update work order because it wants to update the temperature. It does not supply the order number, only a serial number. There is no work order queued so the OT bus stop can’t find one. The OT bus stop will now create a new work order with order ID "UNKNOWN" and mark it as RUNNING (R).
