Validating Requirements and Improving Specifications with Telematics Data
Field failures cause high warranty expenses, perhaps the highest quality cost. Failures occur when new designs are introduced, existing products are sold in new markets, and product specifications don’t reflect actual product usage. Any mistake in product specifications affects the entire product development process and cascades through the supply chain.
New product requirements are developed using prior requirements, rely on customer surveys, use “expert” opinion, or are the result of compromises to meet timing or management direction. The resulting requirements may be excessive or insufficient. If excessive, then verification testing costs are too high; if insufficient, then product verification is inadequate.
This seminar teaches the student how to analyze development and field usage data with a focus on projecting to design life targets. Data needs to be collected from the customer. Today’s availability of wireless services makes this relatively easy and tomorrow’s internet of things (IOT) can provide the raw data for analysis. This seminar uses selected automotive telematics data collected by special modules installed in development, fleet, and retail vehicles.
What Will You Learn
- Define different types of data in Telematics.
- Determine the need and ways to standardize data metrics
- Determine the best probability distributions to describe counting or continuous data for a group of vehicles
- Apply cumulative distributions to determine population percentiles and project data metrics to design life targets. Examples: Engine start/stop events and vehicle speeds
- Analyze state transitions for product that operate in a finite number of states.
- Analyze two-dimensional multivariate data. (Engine Speed vs. Engine Torque)
- Make comparisons of different vehicle categories. (Police vehicles vs. retail vehicles)
Is This Course For You
The course is designed for more senior personnel who validate requirements, develop test plans and verify conformance to requirements. These analytic methods will be useful to information technologists, reliability engineers, product engineers, quality engineers and management.
- Greeting and Introduction
- Tools: Laptop (or desktop); MS Office, Minitab
- Need for company software to store, retrieve, and provide analytic tools.
- Privacy/Security Issues
- People are concerned about their privacy; afraid of Big Brother, Corporations
- A new threat: Hacking
- Who has access to the data? What type of data is available?
- Could data be subpoenaed for crash information? Could GPS and time information be used in trials?
- Engineers use data to understand events around fault codes, part interactions
- Use to define mission profiles and lifetime usage
- The Cost of Quality
- Prevention Costs to prevent problems from occurring – Specifications, Requirements Validation, Product Verification, SPC
- Appraisal Costs – Testing,
- External Failure Costs – warranty, litigation, customer satisfaction, breach of contracts
- Internal Failure Costs – scrap, rework, material costs
- Review common requirement sources: Prior similar product, expert opinion, customer surveys, management direction, program timing limitations, data driven requirements
- Systems Approach
- An interdisciplinary approach to System Requirements Definition; Product Development; Verification; Life Cycle; Project Management; and the technical disciplines (electrical, mechanical…)
- Define the Mission, operating concept, or functional improvement/changes
- Define Requirements from multiple sources (customers, House of Quality
- P-diagram focuses on inputs/outputs to system element
- Define interfaces and interactions between system elements (functions, faults)
- Telematics Analysis will assist to
- Define the Product Life
- Develop Valid Requirements and a Verification Plan to meet product requirements
- Review / Recap / Questions
- Data Review
- Millions of data records and missing channels
- Intermittent data prevents time series analysis (graphic example)
- Suggest a statistical approach
- Count Events
- Continuous Variables
- State Variables
- Transmission Example
- The analysis of event counts, across a vehicle population, develops validated targets for different vehicle usage parameters
- Count Examples: engine starts, vehicle start/stop cycles, trip count, operating days, door open/close cycles
- Equally weight vehicle with standard metrics: trips/day, miles/day, events/day, events/mile
- Projection to different design targets expressed as years, miles, cycles
- Examples: Trip and Operating days data, Histogram of Trips or Days, Scatter Plot of Trips vs. Days, Standardize Trips/day, Median Rank Plot
- From the probability distribution plot project the 5th, 50th and 95th percentiles for engineering validated requirements
- Comparison of continuous variables by determining high stress usage patterns and low stress usage patterns
- Vehicle speed, engine torque, engine speed, voltage, accelerometer readings, engine temperature, brake pressures, accelerator pedal position
- Data issues
- CAN data was highly intermittent, preventing time series analysis of the data. The solution was to consider each reading as a statistical sample
- Compare how different vehicles may have very different total usage by using a percentile histogram. Examples include histogram plot issues, median rank plots, cumulative distributions, Minitab distribution ID Plot, distribution analysis, overlay of CDFs and percentile analysis
- Review state variables such as door open/closed/locked, transmission gear state, PRNDL position, switch state ◦
- Transmission Example:
- Markov analysis and model discussion
- Review frequently encountered multi-variable problem
- Define torque and rpm intervals to bin the data into cells
- Raw data is the number of 1-second counts in an array of torque-rpm cells
- Standardize the data by dividing the count in each cell by the total counts
- A contour plot is useful for displaying the usage pattern for a vehicle or the average across a fleet.
- Compare contour plots for different fleets, dynamometer tests
- Extend the data to components
- Engineering design information required to perform a cumulative damage analysis for an individual vehicle
- Comparison of cumulative damage across a fleet of vehicles to determine percentiles of the distribution
- Extend the comparison to vehicle dynamometer testing
- For practical work use a 3-parameter model gear x engine torque x engine speed
- Use public data to calculate torque x speed for each gear state
- Gear design information is needed to calculate fatigue damage – stress levels, cycles, gear profile
- Develop equation to calculate time at torque x rpm for each gear
- Design engineer can combine the usage and design information to estimate cumulative damage over 150,000 miles or another target
- Combine vehicle damage results for a fleet
- Compare the 95th percentile to dynamometer tests