Predictive Quality sample data
Business Scenario for Inspection (Attribute Analysis)
Normally, in qualitative analysis techniques, a product, part, or material is run through a series of quality checks. The outcomes of the checks are tabulated, and based on the business guidelines they are labeled at different levels and sold in the market. Products, parts, or materials that do not succeed in the checks are labeled as flawed and are sent for further analysis. By using this practice, companies are in a reactive mode to analyze the cause before the flaw is propagated in the manufacturing line. This process is characterized by noise, turbulence, and loss. A potential consequence of quality gaps is a damaged reputation to the manufacturing company or unit.
This kind of scenario can be avoided if a mechanism is in place to identify product flaws long before they creep into large-scale distribution and subsequent recall. Such a system is called an early warning system, which identifies flaws much sooner so that there is enough time to take remedial measures.
IBM® Predictive Quality offers an explicit early warning system through Inspection or Attribute analysis, when compared to normal statistical process control systems. This warning system takes the quantity inspected and the quantity failed as the major inputs, along with other inputs (called parameters) to control the analysis. The warning system prepares an evidence curve, which provides an early warning that is based on quality issues that are seen.
Sub Use Cases in Inspection
ProductInspection use case (ProductInspectionEvent) – The inspection or attribute analysis is carried out on a specific product, given the input data about the ratio of failed to tested products.
MaterialInspection use case (MaterialInspectionEvent) – The focus is on the raw material that is procured from a vendor, given the input data about the ratio of failed to tested materials.
Business Scenario for Parametric (Variable Analysis)
The business challenges lie in identifying the rules to set up the quality norms for an end product or a raw material. Rules that fail to identify a product or material flaw cause noise and loss of confidence in quality. The more quality-related issues, the more damage to the business and costs incurred in replacements and servicing.
Applying complex statistical computation is a difficult task and it is hard to implement with available software. Normally, in a quality inspection process, quality is defined by a set of rules. Often those rules cannot identify subtle variations that occur during the manufacturing process. However, such variations are well handled by the Parametric or Variable analysis, where each and every measurement or observation is analyzed against its ideal value by defining the allowed level of deviation and drift. Whenever the observed deviation goes beyond the acceptable level or unacceptable level, it is flagged immediately. This helps in remediation of the flaw and improves the quality of the deliverables.
Sub Use Cases in Parametric
The Parametric Quality algorithm handles various master data sets, from raw materials to manufacturing machinery to end products, and environment or location-specific data. The following categories of analysis can be used on each of the master entities. Categories of analysis can be a combination of different masters or a lone entity.
Process Resource Validation (Unpreventable) - Process Resource Validation is the default Parametric use case, in which the process, and the resource that takes part in process, are monitored based on a defined set of measurement types (variables). These variables are compared against target values, acceptable limits, unacceptable limits, standard deviation, false alarm rates, and unacceptable factors.
Resource Validation (RVariableEvent) - In the Resource Validation use case, a resource is monitored based on the standard operation limits across several measurement types (variables). This kind of health check is essential in identifying issues in the resource and to remediate to improve performance and throughput.
Product Validation (PBVariableEvent) - In the Product Validation use case, given a set of variables whose targets are set for the product to meet, any deviation or drift beyond the allowed deviation highlights flaws in the product.
Material Validation (MVariableEvent) - In the Material Validation use case, raw materials that are purchased from a vendor are monitored for a defined set of guidelines and are validated to check the quality of the procured material.
Location Conduce-ability (LVariableEvent) - In the Location Conduceability use case, a location can be analyzed for its suitability to a particular operation. Time slide values (that is, observations that were recorded at specific time intervals) are considered for variables like pressure, temperature, and humidity.
Input Files for Predictive Quality
- Configuration files
Logical model files
Orchestration files
Solution definition files
Master CSV files
Event CSV files
Configuration files
The Quality logical model xml file (in the logicalmodel folder) contains the way in which the CSV files must be structured. This xml file defines the structure for each Master data entity and event data entity. The triggering mechanisms are common for both the Quality use cases (Inspection and Parametric). Master and Event data entities are mapped to the appropriate Master table that is defined in the Predictive Quality data model.
For example, the master entity Product (of the Inspection use case) is defined as follows:
<entity code="Product" description="Represents a product" displayName="Product" extendable="false" id="" version="1.0" author="IBM">
<instanceTableMap instanceTableCode="MASTER_PRODUCT" />
<attribute code="ProductCode" displayName="Product Code" columnCode="PRODUCT_CD" dataType="string" isKey="true" isRequired="true" description=""/>
<attribute code="ProductName" displayName="Product Name" columnCode="PRODUCT_NAME" dataType="string" isKey="false" isRequired="true" description=""/>
<attribute code="ProductTypeCode" displayName="Product Type Code" columnCode="PRODUCT_TYPE_CD" dataType="string" isKey="true" isRequired="true" description=""/>
<attribute code="ProductTypeName" displayName="Product Type Name" columnCode="PRODUCT_TYPE_NAME" dataType="string" isKey="false" isRequired="true" description=""/>
<attribute code="IsActive" displayName="Is Active" columnCode="IS_ACTIVE" dataType="boolean" isKey="false" isRequired="true" description=""/>
<selfReference columnCode="PARENT_PRODUCT_ID">
<attribute code="ParentProductCode" dataType="string" description="Parent Product Code" displayName="Parent Product Code" attributeRef="ProductCode"/>
<attribute code="ParentProductTypeCode" dataType="string" description="Parent Product Type Code" displayName="Parent Product Type Code" attributeRef="ProductTypeCode" />
</selfReference>
</entity>
The columns for the master entity Product appear as attributes and those cyclic references or self references are defined for the product itself. The mapping to the table MASTER_PRODUCT is in the instanceTableMap tag.
The master_parameter_grain table provides a grain identity for a unique combination of location, product, production batch, resource, process, material, and measurement type. Measurement type (such as temperature, pressure, or humidity) is tightly coupled to event type, so when an event type is defined, a measurement type is also defined as its attribute.
The master_parameter table contains the parameters, such as LAM0, LAM1, and PROB0. The master_parameter and master_parameter_grain tables are joined in the master_parameter_value table. The value for each event's measurement type is loaded in the master_parameter_value table.
The following example shows the definition of the parameter grain in the logical model, and the parameters that are used for the Parametric use case:
<entity code="Parameter" description="Parameter" displayName="Parameter" extendable="true" id="" version="1.0" author="IBM">
<typeTableMap typeTableCode="MASTER_MODEL_TYPE" typeCodeColumnRef="MODEL_TYPE_CD" typeParentCodeColumnRef="PARENT_MODEL_TYPE_ID" typeNameColumnRef="MODEL_TYPE_NAME"></typeTableMap>
<attributeTableMap attributeTableCode="MASTER_PARAMETER" attributeCodeColumnRef="PARAMETER_CD" attributeNameColumnRef="PARAMETER_NAME" attributeDataTypeColumnRef="PARAMETER_DATA_TYPE" typeCodeColumnRef="MODEL_TYPE_ID"/>
<instanceTableMap instanceTableCode="MASTER_PARAMETER_GRAIN"/>
<attributeValueTableMap attributeValueTableCode="MASTER_PARAMETER_VALUE" attributeCodeColumnRef="PARAMETER_ID" attributeTextValueColumnRef="PARAMETER_TEXT_VALUE" attributeNumberValueColumnRef="PARAMETER_NUMBER_VALUE" instanceColumnRef="PARAMETER_GRAIN_ID"/>
<reference entityRef="Location" isRequired="true" columnCode="LOCATION_ID" isKey="true">
<attribute code="Location" description="Location" displayName="Location" dataType="string" attributeRef="LocationCode"/>
</reference>
<reference entityRef="Resource" isRequired="true" columnCode="RESOURCE_ID" isKey="true">
<attribute code="ResourceCd1" description="Resource Code 1" displayName="Resource Code 1" dataType="string" attributeRef="ResourceCd1"/>
<attribute code="ResourceCd2" description="Resource Code 2" displayName="Resource Code 2" dataType="string" attributeRef="ResourceCd2"/>
</reference>
<reference entityRef="Product" isRequired="true" columnCode="PRODUCT_ID" isKey="true">
<attribute code="ProductCode" description="Product Code" displayName="Product Code" dataType="string" attributeRef="ProductCode"/>
<attribute code="ProductTypeCode" description="Product Type Code" displayName="Product Type Code" dataType="string" attributeRef="ProductTypeCode"/>
</reference>
<reference entityRef="Process" isRequired="true" columnCode="PROCESS_ID" isKey="true">
<attribute code="ProcessCode" description="Process Code" displayName="Process Code" dataType="string" attributeRef="ProcessCode"/>
</reference>
<reference entityRef="ProductionBatch" isRequired="true" columnCode="PRODUCTION_BATCH_ID" isKey="true">
<attribute code="ProductionBatchCode" description="Production Batch Code" displayName="Production Batch Code" dataType="string" attributeRef="ProductionBatchCode"/>
</reference>
<reference entityRef="Material" isRequired="true" columnCode="MATERIAL_ID" isKey="true">
<attribute code="MaterialCode" description="Material Code" displayName="Material Code" dataType="string" attributeRef="MaterialCode"/>
</reference>
<reference entityRef="MeasurementType" isRequired="true" columnCode="MEASUREMENT_TYPE_ID" isKey="true">
<attribute code="MeasurementTypeCode" description="Measurement Type Code" displayName="Measurement Type Code" dataType="string" attributeRef="MeasurementTypeCode"/>
<attribute dataType="string" code="EventTypeCode" description="Event Type Code" attributeRef="EventTypeCode"/>
</reference>
</entity>
The following xml definition extends the Parameter definition. The CSV file for Inspection parameters is defined such that the first set of columns carries all the master entity references for defining a parameter grain, and the next extended part carries the parameters (as attributes) as column names (LAM0, LAM1, PROB0). This defines a parameter grain and parameters to the grain in one row of the CSV file.
<entitySubType code="Inspection" description="Inspection" displayName="Inspection" extends="Parameter" id="" version="1.0" author="IBM">
<attribute code="LAM0" displayName="LAM 0" dataType="double" description="LAM 0" isRequired="true"/>
<attribute code="LAM1" displayName="LAM 1" dataType="double" description="LAM 1" isRequired="true"/>
<attribute code="PROB0" displayName="PROB 0" dataType="double" description="PROB 0" isRequired="true"/>
<attribute code="INSPECT_NO_DAYS" displayName="Number of days" dataType="double" description="Number of days" isRequired="true"/>
</entitySubType>
Event entities are defined in a similar way. The master reference grains under QualityEvent and this entity type are extended by ProductInspectionEvent and MaterialInspectionEvent. Both the ProductInspectionEvent and MaterialInspectionEvent carry attributes for quantity produced (QTY), quantity inspected (INSPECT), and the quantity failed (FAIL). This appears in the CSV following the event structure that was inherited.
<eventSubType code="ProductInspectionEvent" description="Represents a inspection event for Product in PMQ" displayName="Product Inspection Event" extends="QualityEvent" id="" version="1.0" author="IBM" >
<attribute code="QTY" displayName="Quantity Produced" dataType="double" description="Quantity Produced"/>
<attribute code="INSPECT" displayName="Number of Inspected Quantity" dataType="double" description="Number of Inspected Quantity"/>
<attribute code="FAIL" displayName="Number of Fail Quantity" dataType="double" description="Number of Fail Quantity"/>
</eventSubType>
Orchestration files (in the orchestration folder) are also important to configuration. There are three orchestration files: one for handling Inspection related event data persistence to the Predictive Quality Event store; one for handling Parametric events data persistence to the Predictive Quality Event store; and one for triggering the Quality analysis. Inspection and Parametric are handled in sequence.
The final configuration file is the solution definition xml file. This file defines all the table structures that are part of the Predictive Quality and Predictive Warranty data store.
Master CSV files
The Master CSV files carry all the master data set or entity data set whose various observations or measurements are recorded and analyzed. For the sake of Predictive Quality, the following are the required Master data sets that must be loaded before any fact data is loaded.
- Master_Value_type - The Value type offers only three values: ACTUAL, PLAN, and FORECAST.
Normally, the data associated with inspection or parametric events are only ACTUAL.
Figure 1. Master_Value_type - Master_Location - The Location data holds information that is specific to the geography
of the location where the event is produced, or the resource that produces the events.
Figure 2. Master_Location - Master product - This table forms the core data for the inspection use case. This table
stores product-related information along with the information of what product_type it is.
Figure 3. Master_Product - Master_ProductionBatch - This table maintains information about each production batch that is
used to produce the desired products. It maintains details like which product is produced, at what
date it is produced, and the batch information.
Figure 4. Master production batch - ProductInspectionParameter CSV - This CSV file contains all the master entity grains for
which parameters must be defined. A sample of the product parameters snapshot is shown below.
Figure 5. Product inspection parameter Similarly, sample parameter data for Parametric (for location use case) based snapshot is shown below.
Figure 6. Sample parameter data for Parametric - Master Resource - Master Resource must be loaded if you have to carry out a granular analysis
of Inspection or a parametric use case of Resource Validation or Process Resource Validation.
Figure 7. Master resource - Master Process - Master Process CSV file is for any granular approach of inspection or
parametric.
Figure 8. Master process - Master Material Type - Master material type is required for loading the material data and it
is required for Inspection or Parametric analysis.
Figure 9. Master material type - Master Material - Master Material is required for inspection or parametric analysis.
Figure 10. Master material The event types and measurement types are inserted as a part of logical model.xml. Normally, when the logical model is defined, it covers all the event types, and each measurement type acts as an attribute to it. Therefore, they are loaded by the foundation system without any explicit use of CSV.
Event CSV files
These fact data sets carry the list of observations done for any particular event that requires significant attention for further analysis or scoring or training. For Predictive Quality, there is one event data set file for Inspection and one for each use case of Parametric.
For Inspection, there are two sub use cases like ProductInspectionEvent and MaterialInspectionEvent. Both have a similar structure; the only thing that differentiates them are the entity that gains focus. ProductInspectionEvent, focuses on the production batch that is being used, while MaterialInspectionEvent focuses on the Material entity under consideration. The snapshots for both are shown below.



Arguments passed while triggering the Quality Analysis
Quality Analysis triggers Inspection and Parametric analysis in sequence. Both analyses have similar arguments.
- INSPECTION_RUNDATE – This is the date up to which to process information in the subusecase. The value can be today's date or a prior date.
- INSPECTION_SUBUSECASE – This is a sub use case of Inspection, where either it could be ProductInspectionEvent or MaterialInspectionEvent.
- PARAMETRIC_RUNDATE – This is the date up to which to process information in the subusecase. The value can be today's date or a prior date.
- PARAMETRIC_SUBUSECASE – This can take either of the values in LVARIABLE, RVARIABLE, MVARIABE, PBVARIABLE, or PRVARIABLE.
Interpreting the Inspection chart
There are two charts shown by the reports.
The first chart is called the Failure Rate Chart or a Statistical Process Control chart. The chart has a dual-scale X axis. The bottom scale is the Vintage number. The top scale is the cumulative quantity that is tested. The Y axis scale is Failure rate per 100 units. The orange line graph represents the association of failure rate against the Vintage number or the tested quantity. The white dotted line that is parallel to the X axis is the acceptable mean of failure. As per statistical norms, whenever the line graph climbs over the acceptable mean of failure, it signifies that the quality of the product or the entity under consideration is going out of the accepted tolerance level. This is a reactive mechanism, where measures of remediation can only take place when the first instance when the curve crosses the acceptance level.
The second chart is called the Evidence Chart. The Evidence chart is proprietary to IBM Research. In the Evidence chart, the X axis shares the same scales as SPC charts. The Y axis scale is Cumulative sum (cusum) of failures. The blue line graph represents the cusum curve that is plotted relating the cusum of failure rates with the vintage number or the tested quantity. The thick white line that is parallel to the X axis is the Threshold of acceptance, which is built on cusum of failure rates. The line graph has triangle markings once it crosses the threshold line. The first instance where the line crosses the threshold is called the first alarm signal. On the right side of the chart there is a blue dotted vertical line, parallel to the Y axis. This line denotes the highest unacceptable level that the vintage has reached. The gap in the X axis between the last vintage to this highest unacceptable level is called the RCUN (return code for unacceptable condition) value. A descent of the curve after the highest unacceptable condition is called forgiveness factor. The forgiveness factor enables the possibility for the curve to return to normalcy. If the highest unacceptable condition occurred at the date when the analysis was run, then there is no forgiveness factor because the condition might continue to worsen after that date.




Interpreting the Parametric Chart
The first chart is called the Variable value Rate Chart, which is a Statistical Process Control chart. The X axis has the time slice number in the scale. The Y Axis has the variable values in the scale. The orange line graph represents the association of variable value rate against the Vintage number. A thick white line that is parallel to the X axis indicates the target value for the Variable under analysis. A blue dotted line, similar to the Target line, notifies the unacceptable mean or deviation. If the Type of Control is 1, then the Unacceptable deviation appears either above or below the Target line; the position depends on whether the deviation is on the higher side or the lower side of the Target. If the Type of Control is 2, then the unacceptable deviation appears on both upper and lower sides, encasing the Target line. If the line graph crosses over the unacceptable deviation line, the variable value is not meeting the expected standard or guidelines and this may have impact on the process, product, material, location, or resource (any entity) under consideration. This is a reactive mechanism, where measures of remediation can only take place when the first instance when the curve crosses the acceptance level.
The second chart is called the Evidence Chart. The Evidence chart is proprietary to IBM Research. The X axis shares the same scales as the Variable Value Rate Chart. The Y axis scale is Cumulative sum (cusum) of variable value rates. The blue line graph represents the cusum curve that is plotted relating the cusum of variable value rates with the vintage number or time window. The thick white line that is parallel to the X axis is the Threshold of acceptance, which is built on cusum of variable value rates. The line graph has triangle markings once it crosses the threshold line. The first instance where the line crosses the threshold is called the first alarm signal. If the type of control is 1, then there is one threshold line; the line can be above the Target (that is, an upper threshold) or below the Target (that is, a lower threshold). If the Type of control is 2, then there are upper and lower thresholds. If the line graph crosses over a threshold, it represents an alarm condition and the process is out of control.




