Setting Up Data Automation
The DPM automation integration allows data from connected pacemakers to be received by DPM in near real-time. A pacemaker is the work unit that sets the production pace for a work center. Receiving data from the connected pacemaker results in property changes in ThingWorx. All property changes are stored in a value stream. Every 5 minutes, transactions with good quality data are retrieved in chronological order and are written to the appropriate event tables in the DPM database.
The DPM automation integration supports job order changes (starting production, stopping production, or changing the job order), production and scrap counts, and down-type availability events resulting from machine codes being mapped to reason codes within DPM. Performance loss events, such as speed loss or small stops, are not supported for data automation.
For example, when all data automation properties are configured, DPM can receive data that starts production on a job order. While the job order is in production, data can be received to add production count and scrap count for the job order, to log downtime events for the machine such as breaks or power outages, and to log when the machine returns to a running state. DPM can then receive data that completes the first job order and starts production on the next job order.
If the system is disconnected from the pacemaker for less than 15 minutes, events that occurred during that time are captured. If the system is disconnected for longer than 15 minutes, events more than 15 minutes old are ignored. This is to avoid duplication of data, as operators may have manually entered data for that time. For more information, see Manual Data Entry and Automated Data Entry.
 |
Ensure the system clocks (the "Date & time settings" on Windows OS) on the Kepware server and the ThingWorx server are synchronized within 5 seconds and that this synchronization is maintained over time.
|
|
|
In some rare situations, the DPM database or ThingWorx database becoming unavailable can result in data loss or data duplication. For more information, see Database Availability Loss and Its Implications.
|
Setting Up Data Automation
To set up data automation for DPM, complete the following steps:
1. Install and connect your data source to ThingWorx.
◦ For more information on Kepware, see KEPServerEX Version 6 Install Guide.
◦ For more information on Azure IoT Hub, see Azure IoT Hub Connector Help Center.
2. In ThingWorx Composer, create or use an Industrial Connection. To create a new Industrial Connection, create a new Thing with the IndustrialGateway Thing Template as its Base Thing Template.
3. Data automation can be configured on the pacemaker for each work center. Other equipment types (enterprise, region, site, area, or work center) cannot be automated.
On the work unit Thing for a pacemaker, complete the following steps:
a. Add the following Thing Shapes to the Implemented Shapes field:
▪ PTC.OperationKPI.AutomationEventsModelLogic_TS
▪ IndustrialThingShape
b. Set the Value Stream field to PTC.OperationKPI.Automation_VS.
c. Under Properties and Alerts, set the IndustrialThing property to the Industrial Connection from step 2.
d. Set the properties for the data automation activities that you want to use. Information on each of these properties is provided in the linked sections:
e. Click Save to save the changes to the work unit Thing.
4. Repeat step 3 for each pacemaker that you want to automate.
|
|
The PTC.OperationKPI.AutomationEventProcessor_TI timer is enabled by default when DPM is deployed. This means that as data automation properties are configured, they will be included when the timer triggers the batch processing. You can choose to disable the timer to stop batch processing while setting up data automation but be aware that this stops batch processing for all pacemakers until the timer is re-enabled.
|
Starting Existing Job Orders
To start existing job orders using data automation, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCJobOrderID property to the appropriate tag. This property accepts STRING values.
2. Click Save to save the changes to the Thing.
Whenever the PTCJobOrderID property value changes, the specified job order starts. If a job order is currently running when the property changes, that job order is completed, and the new job order is started. If the job order with that ID does not exist, an error is displayed for the operator. Job orders are created on the Job Orders page in Administration. For more information, see Creating a Job Order.
When the PTCJobOrderID property receives a value of 0 (the default value for the PTCJobOrderIDNullValue property), the currently running job order is completed, and no new job order is started.
If an operator manually changes the status of a job order in the Production Dashboard by starting production or stopping production at a time after the timestamp for the PTCJobOrderID property change, the property change is ignored, and an error is shown to the operator. Automated events are processed after they occur, and the operator is assumed to be aware of what is happening on the equipment in real time.
Creating Job Orders Based On Specified Material
To create job orders based on a specified material using data automation, also referred to as a material run, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCMaterialMasterID property to the appropriate tag. This property accepts STRING values.
2. Click Save to save the changes to the Thing.
Whenever the PTCMaterialMasterID property value changes, a job order is created for the specified material with a default target quantity of 1. If a job order is currently running when this property changes, that job order is completed, and the newly created job order is started. If the material matching the material master ID does not exist, an error is thrown.
If an operator manually changes the status of a job order in the Production Dashboard by starting production or stopping production at a time after the timestamp for the PTCMaterialMasterID property change, the property change is ignored, and an error is displayed to the operator. Automated events are processed after they occur and it is assumed that the operator is aware of what is happening on the equipment in real time.
When the PTCMaterialMasterID property receives a value of 0 (the default value for the PTCMaterialMasterIDNullValue property), the currently running job order is completed, and no new job order is started.
Updating the Target Quantity for Job Orders
The PTCTargetQuantity property is used to set the target quantity for job orders created using the PTCMaterialMasterID property. This property should always be set after the PTCMaterialMasterID property is set. When this property value changes, the target quantity for the currently running job order is updated.
|
|
When there are two subsequent materials being run with the same target quantity, reset the PTCTargetQuantity property before sending the second target quantity value by sending a value of -1 (the default value for the PTCTargetQuantityResetValue property). The system does not recognize receiving the same value again as a data change. The property value must be reset for the target quantity of the second job order to be updated to the same value as was set for the first job order.
|
To update the target quantity for job orders using data automation, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCTargetQuantity property to the appropriate tag.
2. Click Save to save the changes to the work unit Thing.
Logging Production Counts
The production counter records the good production count that is happening on the pacemaker. The total production count is calculated as the good production count plus the scrap count.
To log production counts using data automation, complete the following steps in ThingWorx Composer:
1. On the work unit Thing for a pacemaker, under Properties and Alerts, bind the PTCProductionCount property to the appropriate tag. This property accepts numeric values only.
2. Both absolute and rollover production counters are supported. By default, the production counter is absolute. To make the production counter a rollover counter, set the following properties:
◦ PTCIsProductionCountRollover—TRUE.
◦ PTCProductionNormalResetValue—The rollover value for the counter. Can include decimal points.
◦ PTCMaxProductionMachineRate—The maximum production output possible for the pacemaker. This value is used by DPM to determine if new counts received by the counter are valid data. The value defined for the maximum machine rate should represent a value that is impossible for the machine to produce, so that valid data is not discarded. If no value is specified for this property, DPM calculates the maximum machine rate as 3 times the ideal cycle time for the material that is being produced. If the PTCIsProductionCountRollover property on the work unit Thing is FALSE, this property is ignored.
|
|
An absolute counter records new counts as they are received. For example, if counts of 3, 5, and 2 are received, a total of 10 is recorded.
A rollover counter records the difference between the previous count and the new count until a designated rollover number is reached and the counter resets. For more information on rollover counter behavior in DPM, see Rollover Counters.
|
3. By default, the production counter starts at 0. If you want the production counter to start at a different number, add a row to the PTCLastAutomationProcessedValues infotable property with the following values:
◦ propertyName—PTCProductionCount
◦ value—The value at which you want the production counter to start.
◦ jobOrderUid—This field is ignored by DPM.
4. Click Save to save the changes to the work unit Thing.
|
|
For an absolute counter, when there are two subsequent production counts with the same number, reset the PTCProductionCount property before sending the second production count value by sending a value of -1 (the default value for the PTC.ProductionCountResetValue property). The system does not recognize receiving the same value again as a data change. The property value must be reset for the second production count of the same value to be recognized as a new production count.
|
Logging Scrap Counts
Scrap counters record the scrapped production that has happened on the pacemaker. There can be multiple scrap counters for a single pacemaker. The total scrap count for a pacemaker is calculated from the values of all of its scrap counters.
Each scrap counter in DPM is mapped to a single scrap machine code generated by the pacemaker. Each scrap machine code is mapped to a scrap reason code in DPM. If your pacemaker has a single scrap counter which can generate different machine codes for different counts, you need to create a unique scrap counter tag in your data source for each machine code you want counted.
To log scrap counts using data automation, complete the following steps:
1. Validate that the scrap machine codes are present on each pacemaker and are assigned to the appropriate scrap reason codes. You can view machine codes and their assigned reason codes on the Machine Code Settings tab for the work unit in the Equipment List.
|
|
If a machine code is not present on the pacemaker or is not mapped to a reason code, then any events received through data automation for that machine code are logged with an event category (eventCategory) and loss category (reasonCategory) value of Invalid. These invalid events do not appear in the Production Dashboard event logs, do not add to the scrap count, and are not considered in any data calculations.
|
2. In ThingWorx Composer, on the work unit Thing for a pacemaker, under Properties and Alerts, create a property for each scrap machine code for which you want to keep count. Each scrap property is considered to be a scrap counter in DPM. Ensure that the Log checkbox is selected for each of these scrap properties.
3. Both absolute and rollover scrap counters are supported. By default, the scrap counters are absolute. To make the scrap counters on the pacemaker into rollover counters, set the PTCIsScrapCountRollover property on the work unit Thing to TRUE.
|
|
An absolute counter records new counts as they are received. For example, if counts of 3, 5, and 2 are received, a total of 10 is recorded.
A rollover counter records the difference between the previous count and the new count until a designated rollover number is reached and the counter resets. For more information on rollover counter behavior in DPM, see Rollover Counters.
|
4. Update the PTCScrapEventProperties property to include each scrap property that you created in step 2. The value for the PTCScrapEventProperties property is an infotable. For each scrap property, add a row to the infotable with the following information:
◦ propertyName—The name of the scrap property.
◦ machineCode—The machine code associated with the scrap property.
◦ normalResetValue—The rollover value for the counter. Can include decimal points. If the PTCIsScrapCountRollover property on the work unit Thing is FALSE, this property is ignored.
◦ maxMachineRate—The maximum production output possible for the pacemaker. This value is used by DPM to determine if new counts received by the counter are valid data. The value defined for the maximum machine rate should represent a value that is impossible for the machine to produce, so that valid data is not discarded. If no value is specified for this property, DPM calculates the maximum machine rate as 3 times the ideal cycle time for the material that is being produced. If the PTCIsScrapCountRollover property on the work unit Thing is FALSE, this property is ignored.
◦ reallocateFromGoodCount—Select the checkbox (TRUE) if the scrap count received for this property needs to be reallocated from the good count that has already been recorded. If the scrap count received for this property does not need to be reallocated from the good count, do not select the checkbox (FALSE).
Consider the scrap counter’s position when determining whether or not the scrap counts reported by the scrap counter need to be reallocated from the good production count. Scrap counts can be recorded both before and after good counts are recorded, depending on where a scrap counter is physically located in relation to the production counter. The following image shows a simple example where a pacemaker has two scrap counters: scrap counter 1 is positioned in front of the production counter, and scrap counter 2 is positioned after the production counter.
When a scrap count is recorded from scrap counter 1, the good count has not yet been recorded by the production counter. As a result, the scrap count does not need to be reallocated from the good count. This assumes that any scrapped product which is counted by scrap counter 1 will not be included in the good count recorded by the production counter. Set reallocateFromGoodCount to FALSE for this scrap counter.
When a scrap count is recorded from scrap counter 2, the good count has already been recorded by the production counter. Any product that is now being scrapped needs to be reallocated from the good count, as it was included in the good count recorded by the production counter. Set reallocateFromGoodCount to TRUE for this scrap counter.
| | If the scrap property and machine code are not properly mapped in the PTCScrapEventProperties infotable, then any data received for that scrap property is logged as an event with an event category (eventCategory) and loss category (reasonCategory) value of Invalid. These invalid events do not appear in the Production Dashboard event logs, do not add to the scrap count, and are not considered in any data calculations. |
5. By default, each scrap counter starts at 0. If you want a scrap counter to start at a different number, add a row to the PTCLastAutomationProcessedValues infotable property with the following values:
◦ propertyName—The name of the scrap property.
◦ value—The value at which you want the scrap counter to start.
◦ jobOrderUid—This field is ignored by DPM.
6. Click Save to save the changes to the work unit Thing.
| | For an absolute counter, when there are two subsequent scrap counts with the same number for a given scrap property, reset the scrap property before sending the second scrap count value by sending a value of -1 (the default value for the PTC.ScrapCountResetValue property). The system does not recognize receiving the same value again as a data change. The property value must be reset for the second scrap count of the same value for the same scrap property to be recognized as a new scrap count. |
| | If a scrap count property is deleted from the work unit Thing for a pacemaker, you must also delete it from the PTCScrapEventProperties property. A non-existent scrap count property that is listed in the PTCScrapEventProperties property prevents all events in the value stream from being processed for that Thing. |
Logging Availability Events
Availability events record the state that the machine is currently in by accepting machine codes from the machine that are mapped to reason codes.
| | Only down-type availability events are supported by data automation. Performance loss events, such as speed loss or small stops, are not supported. |
To log availability events using data automation, complete the following steps:
1. Validate that the fault machine codes are present on each pacemaker and are assigned to the appropriate reasons. This includes a Running machine code that is assigned a reason code from the Running reason tree. Machine codes and their assigned reason codes can be viewed in Administration on the Machine Code Settings tab for the work unit in the Equipment List.
| | If a machine code is not present on the pacemaker or does not map to a reason code from a reason tree that is assigned to the pacemaker, the event is recorded with an Unknown reason code. |
2. In ThingWorx Composer, on the work unit Thing for each pacemaker, under Properties and Alerts, bind the PTCAvailabilityEventFaultCode property to the appropriate tag. Do not bind this property to any scrap tags.
3. Click Save to save the changes to the work unit Thing.