Predictive Warranty sample data

Business scenario for Lifetime or Warranty analysis

The warranty data and analytics can be used in a manufacturing company in several ways. Some of the common uses are identifying conditions leading to accelerated replacement or wear of parts (process, vendorquality, parts quality, service condition), warranty pricing analytics (including extended warranty pricing), strategic vendor identification, and so on.

All other use cases are dependent upon primary warranty use case. For example, to implement warranty pricing analytics, you first must understand the factors that affect the wear and replacement rates of a given part under warranty.

If a company can identify the points of occurrence of accelerated wear earlier, it can realize savings by not only fixing the causes earlier, but also preventing parts that may demonstrate similar phenomena from being sold and thereby leading to more claims and related losses.

IBM® Predictive Warranty is an implementation of the IBM QEWSL (Quality Early Warning System - for Lifetime applications) algorithm, which has proven capabilities to give early warning signals of accelerated wear and replacement for a part, with minimal false alarms.

Predictive Warranty uses the core QEWSL algorithm in three use cases: Sales, Production, and Manufacturing. These use cases differ in terms of data loading and SPSS data transformation. The operational and other steps are common to all of the use cases.

SALES Use Case

This use case is useful in identifying the variation in replacement and wear rates while they are aggregated on their respective sales date. The sales date might signify different in-service conditions, atypical to a given pattern of climatic differences, or they might represent sales to a common customer, or other similar occurrences that may be linked to the date/ period of their sales.

For example, for parts carrying a common one year warranty, if they were suffering brittle failure under cold climates at a given location, the parts which went in service during winters will have a rapid wear during their initial service months, followed by a delayed wear during later service at the end of their warranty period. The case may be reversed for the parts that were sold during summers. These variations will, in turn, affect their wear rates and weighted replacement rates, which might be captured very early by the QEWSL algorithm.

PROD (Production) use case

This use case is useful in identifying the variation in replacement and wear rates of a given part type fitted in a resource while they are aggregated on the part's respective production date. The production date based anomaly similarity may in turn correspond to the quality of parts, or some process related issues during the production.

For example, if there are some batches of a part produced on a given date, or in a similar period, then the resources in which these parts were fitted may suffer rapid wear or replacements for these parts, which may not be related or identified by the resource manufacturing or assembly or sales date. Once such occurrences are using the production use case of IBM PMQ warranty feature, such phenomena might be easier and faster to identify and understand.

MFG (Manufacturing) use case

This use case is useful in identifying the variation in replacement and wear rates of a given part type fitted in a resource while they are aggregated on the resource's respective manufacturing or assembly date. The manufacturing date based anomaly similarity may in-turn correspond to compromised manufacturing batches or assembly issues due to some reasons on a given date or period.

For example, if there are some manufactured or assembled batches of a resource whose parts fail prematurely due to process issues on the manufacturing lot or assembly line, it may be easier and faster to identify and understand such issues using the manufacturing use case.

Input Files for Predictive Warranty

There are three major types of input files:
  • Configuration files
    • Logical model files

    • Orchestration files

    • Solution definition files

  • Master CSV files

  • Event CSV files

Configuration files

The Warranty 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, event data entity, and the triggering mechanism for the Warranty use case. Master and Event data entities are mapped to the appropriate Master table that is defined in the Predictive Warranty datamodel.

For example, the master entity Product (of the Warranty 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.

Parameters (ie LAM0, LAM1, CW0, CW1, PROB0 and PROBW0) are under Master, where an entity called master_parameter_grain table is defined, which provides a grain identity for a unique combination of location, product, production batch, resource, process, material and measurement type. Measurement type is tightly coupled to event type, which means that when we define an event type we define measurement type as its attributes.

The master_parameter table contains the parameters as such - LAM0, LAM1, etc. The master parameter and parameter grain are joined in a parameter value table and its value respective to each measurement type par event type is loaded here.

The following example shows the definition of the parameter grain in the logical model, and the parameters that are used for the Warranty 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 Warranty 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="Warranty" description="Warranty" displayName="Warranty" 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="CW0" displayName="CW 0" dataType="double" description="CW 0" isRequired="true"/>
    <attribute code="CW1" displayName="CW 1" dataType="double" description="CW 1" isRequired="true"/>
    <attribute code="PROBW0" displayName="PROB W0" dataType="double" description="PROB W0" isRequired="true"/>
  </entitySubType>

Event entities are defined in a similar way. The master reference grains under QualityEvent and this entity type are extended by SalesEvent and WarrantyEvent. The SalesEvent carries the attribute of WarrantyPeriod (in months), while the WarrantyEvent carries the attribute of WarrantyIndicator (a measurement flag which says whether the fact data is covered under warranty or not). The CSV for these two event types has the QualityEvent attribute, which covers the multi-grain entities and the measurement or observations respective to that sub entity type.

SalesEvent logical model structure:

<eventSubType code="SalesEvent" description="Represents a sales event in PMQ" displayName="Sales Event" extends="QualityEvent" id="" version="1.0" author="IBM"> 
	<attribute code="WarrantyPeriod" displayName="Warranty Period" dataType="double" description="Warranty Period">
		<typePropertyValue propertyRef="UnitOfMeasure" value="months"/>
	</attribute>
</eventSubType>

WarrantyEvent logical model structure:

<eventSubType code="WarrantyEvent" description="Represents a warranty event in PMQ" displayName="Warranty Event" extends="QualityEvent" id="" version="1.0" author="IBM">     
	<attribute code="WarrantyIndicator" displayName="Warranty Indicator" dataType="string" description="Warranty Indicator"/>
</eventSubType>

Orchestration files (in the orchestration folder) are also important to configuration. There are two orchestration files: one for handling Warranty related event data persistence to the Predictive Warranty Event store; the other one for triggering Warranty analysis.

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 Warranty, the following are the required Master data sets that must be loaded before any fact data is loaded.

The list of CSV files to be loaded in sequence is:
  1. 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_Value_type
  2. 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_Location
  3. Master product - This table forms the core data for the warranty use case. This table stores product-related information along with the information of what product_type it is.
    Figure 3. Master_Product
    Master_Product
  4. 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
    Master production batch
  5. Master Resource - Master Resource must be loaded if you have to carry out a granular analysis of warranty use case. It stores the resource information and the date on which the resource was assembled or manufactured, the MFG use case of warranty.
    Figure 5. Master resource
    Master resource
  6. Master Resource Production Batch - In the lifetime or warranty analysis, this table maintains the ratio of how many items or products from a particular production batch participated in the resource. g_master_resource_production_batch.jpg
    Figure 6. Master resource production batch
    Master resource production batch

Event CSV files

The event csv files carry contain the fact data of Warranty analysis. Every time a resource is sold, that inventory is loaded through the SalesEvent event type, while every time a part is replaced it is loaded through WarrantyEvent event type.

Figure 7. Sales event
Sales event
Figure 8. Warranty event
Warranty event

Arguments passed while triggering the Warranty Analysis

Warranty Analysis is triggered with the following set of arguments:
  1. WARRANTY_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.
  2. WARRANTY_SUBUSECASE – The allowed sub use case values are MFG (for Manufacturing), PROD (for Production use case), or SALES (the use case where SALES date becomes the warranty startdate).

Interpreting the Warranty charts

There are two charts shown by the reports.

The first chart is called the Replacement / Wearout Rate Chart or a Statistical Process Control chart. This 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 also has a dual scale. The scale on the left side shows the replacement rate per 100 units; the scale on the right side shows the monthly wearout rate. The orange line graph represents the association of replacement rate against the Vintage number or the tested quantity. The pink dotted line graph represents the association of wearout against the vintage number or tested quantity. The white dotted line that is parallel to the X axis is the acceptable mean of replacement. As per statistical norms, whenever the line graph of replacement rate climbs over the acceptable mean of replacements, it signifies that the quality of the product or the entity under consideration is going out the accepted tolerance level. The same applies to Wear out, but the acceptance level is not plotted. This is a reactive mechanism, where measures of remediation can only take place at 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 replacements. The blue line graph represents the cusum curve that is plotted relating the cusum of replacement 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 Value. After the curve reaches the highest unacceptable condition, the curve descends down and the point of descent is called the forgiveness factor. The forgiveness factor provides a level where, based on the current trend, it would factor out whether the curve returns to normalcy. Similarly, the pink line graph depicts the cusum of the wear out rates. Here, instead of triangles there are thick dots that signify that the curve has crossed the Threshold of Wear out. The Threshold of Wear out is drawn as a pink dotted line parallel to the X Axis.

Figure 9. Warranty chart 1
Warranty chart 1
Figure 10. Warranty chart 2
Warranty chart 2
In addition to the above chart the report also shows a summary table.
Figure 11. Warranty summary table
Warranty summary table