Additional Automation Information (Operation KPI Building Block)
Keep in mind the following information while working with data automation and the operation KPI building block.
Batch Processing of Automation Events
Every 5 minutes, a timer event for the PTC.OperationKPI.AutomationEventProcessor_TI timer entity is run, and each pacemaker's subscription on the event executes the main automation event processing service: ProcessPTCAutomationEvents. Multi-batch processing is then exercised until there are no more events to process for that pacemaker.
The batch processing happens for each pacemaker. The main operations that occur, in order, are:
1. Querying the value stream for event data that is not yet processed. The query returns entries for all events which have a timestamp that occurs after the current PTCLastProcessedEventTimestamp property value and which have GOOD data quality.
2. Processing the queried events for each timestamp, in the order of event type: job order (PTCJobOrderID), material master (PTCMaterialMasterID), target quantity (PTCTargetQuantity), availability (PTCAvailabilityEventFaultCode), and finally, production count (PTCProductionCount) and scrap count (PTCScrapCount).
3. Buffering of production count and scrap count events to consolidate the written database entries.
4. Insertion of the buffered production counts and scrap counts into DPM database.
The PTCLastProcessedEventTimestamp property is updated after each event is successfully processed. For production counts and scrap counts, the PTCLastProcessedEventTimestamp property is not updated until all of the grouped counts have been inserted into the database. The latest timestamp from all of the buffered groups is set as the PTCLastProcessedEventTimestamp property value.
 |
In High Availability (HA) systems, the Distributed checkbox is enabled by default for the PTCAutomationEventProcessingTimerSubscription subscription on the PTC.OperationKPI.AutomationEventsModelLogic_TS Thing Shape. This improves performance by distributing the processing of automated data across the HA clusters. This can be disabled by clearing the Distributed checkbox on the PTCAutomationEventProcessingTimerSubscription on individual pacemakers.
For more information, see "Distributed Subscriptions" in Thing Subscriptions and ThingWorx High Availability in the ThingWorx Platform Help Center.
|
Buffering of Production Count and Scrap Count Events
During the batch processing, production count and scrap count events are buffered and organized in memory. Each entry is organized into a specific group, built as described below. Each value processed will increment a count value in the entry for that specific group.
• Scrap count events are grouped by machine code, job order ID, shift, and production block ID. When the shift is unknown, the value UNKNOWNSHIFT is used instead of the shift number.
• Production count events are grouped by job order ID, shift, and production block. When the production block is unknown, the value UNKNOWNPB is used instead of the production block number.
The counts are buffered until a non-count event is processed or the end of the query results is reached. At that point, the counts are inserted into the DPM database. The PTCLastProcessedEventTimestamp property is set to the latest event timestamp from among all of the buffered count groups.
Scheduled Data Purge
The PTC.OperationKPI.AutomationPurgeScheduler scheduler entity controls the purging of value stream data for each pacemaker. Two properties on the scheduler control how the data is purged.
• dataAgeInHours—Determines the time range of the data that is purged. The end time of this time range is the current time minus the dataAgeInHours value, or minus the timestamp of the PTCLastProcessedEventTimestamp property for the pacemaker, whichever is most recent. The start time is determined by timestamp for the oldest value stream entry for any of the remote properties.
For example, if the dataAgeInHours value is 24 (the default), and the PTCLastProcessedEventTimestamp property value on Pacemaker A is not more recent than 24 hours before the current time, the end time of the time range is 24 hours before the current time. This means that when the PTC.OperationKPI.AutomationPurgeScheduler entity purges data for Pacemaker A, all value stream entries older than 24 hours are purged.
If, however, the PTCLastProcessedEventTimestamp property value for Pacemaker A is 3 hours before the current time, more recent than the 24 hour dataAgeInHours value, then all value stream data entries older than 3 hours are purged.
• purgeChunkDurationInMinutes—Divides the time range of the data to be purged into chunks of the specified number of minutes. This results in multiple smaller calls to purge the data instead of a single large call.
When the value stream table cannot be accessed for any reason, ThingWorx uses the value stream queue to store data. Entries from the queue are written to the value stream table when it becomes available. While purging older rows, the value stream table can be subjected to a table lock due to the MSSQL server lock escalation policy. While the value stream table is locked, no inserts into the table are possible. Incoming event data is temporarily added to the value stream queue while the value stream table is locked. As long as the value stream queue has sufficient space to hold event data while the value stream table is locked, no data loss occurs. The duration of the lock increases or decreases based on the number of rows affected by the delete query. Multiple delete queries for smaller periods of time (for example, 15 minutes) reduces the lock duration compared to a single delete query for a longer period of time, such as 24 hours.
For example, if the purgeChunkDurationInMinutes value is 15 (the default), then the time frame of the data to be purged, which is determined by the dataAgeInHours value, is divided into chunks of 15 minutes worth of data. These smaller chunks are purged individually.
Pacemaker Disconnectivity
When the pacemaker is disconnected from DPM longer than the value of the PTCMaxTimeAllowedDisconnected property, data older than that time in minutes is ignored.
If the PTCEnableAutoSetMachineStatusToRunning property is set to true, and the entity has been disconnected longer than that maximum time specified by the PTCMaxTimeAllowedDisconnected property, the batch processing attempts to set the pacemaker to an availability status of Running if it was previously down before the disconnect. This happens as the final action of the batch processing, by calling the SetPTCMachineStatusToRunningIfDisconnectedMoreThanAllowed service, after all events have been processed.
|
|
Setting a pacemaker to Running state means that an availability event with the corresponding running reason information is inserted into the DPM database.
|
The PTCLastTimeConnected property is used to represent the timestamp when a disconnectivity event last occurred, that is, when the isConnected property was set to false. This property is only updated when a disconnect event occurs.
PTC.MfgModel.WorkunitModelLogic_TS Thing Shape
The PTC.MfgModel.WorkunitModelLogic_TS Thing Shape in the manufacturing model building block also contains services and properties that are used by data automation.
The IsPTCAutomationWorkUnit service validates whether the work unit supports data automation.
The PTCDisconnectivitySupported property is a Boolean property used to indicate if remote devices are establishing a connection with ThingWorx, and if the pacemaker should be set back to a Running availability state using the SetPTCMachineStatusToRunningIfDisconnectedMoreThanAllowed service.
The IsPTCDisconnectivitySupported property is a Boolean property that is checked by the Production Dashboard. If the property value is true, then the system evaluates the device's connected status to determine when disconnection messages should be displayed.
Automation Messages
Messages are automatically generated during normal data automation processing and are added to the PTCAutomationMessage infotable property for future reference. These messages are displayed by the Production Dashboard when a new message is added.
The PTCMaxNumberOfAutomationMessages property governs how many messages are stored in the PTCAutomationMessage property. The number of messages stored by default is 10.
Customizations
All services are written in JavaScript code with the intent that they can be customized to fit the specific needs of any given application.
There are a variety of configuration properties available that will fine tune the application. For more information, see Key Properties (Operation KPI Building Block).