a systems engineering approach to engine cooling design

iABOUT THE AUTHORS

PETER KANEFSKY

Peter Kanefsky is the Supervisor of Vehicle Cooling Technology, Research & Vehicle Technology, Ford MotorCompany. He has worked in the automotive industry 26 years and has 23 years experience in cooling systemdesign and development.

Mr. Kanefsky began his career as a student apprentice with British Leyland Truck and Bus Division, England in1973. After graduating from University of Manchester Institute of Science and Technology with a BachelorsDegree in Mechanical Engineering in 1977, began working on heavy truck cooling systems.

In 1980, Mr. Kanefsky joined Ford of Britain and worked as a cooling system development engineer on carprograms, where he worked on the development of computational techniques for system performanceoptimization. In 1989, after completing a Masters Degree in Advanced Automotive Engineering atLoughborough University, Mr. Kanefsky, began an International Service assignment with Fords Alpha

Simultaneous Engineering group in the U.S. where he worked on the development of Computational Fluid Dynamics techniques forcooling system airflow analysis.

In 1991, Mr. Kanefsky returned to Europe as a Technical Specialist where he worked on the deployment of the tools and methodologiespreviously developed in the U.S. In 1994, he co-authored a cooling system design guide for use internally within Ford, and as a subjectmatter expert was key member of a Ford2000 global re-engineering team for Cooling, Thermal Management and Aerodynamics.

In 1995, Mr. Kanefsky returned to the U.S. and become Supervisor of CAE tools and methodology within a newly formed Thermal andAerodynamic Systems Engineering group. In 1997, Mr.Kanefsky took his current assignment where he has responsibility for core andadvanced vehicle cooling technology.

VALERIE NELSON

Valerie Nelson P.E., is a Technical Specialist in engine cooling systems for Ford. She has 17 years experiencein engine cooling system design.

Ms. Nelson began her career in 1982 at Buick Motor Division, responsible for engine cooling design anddevelopment for the full size Buicks. After 5 years Ms. Nelson moved to Ford to work on the cooling system forthe Ford Probe. While at Ford, she has pioneered the use of 1-D CAE tools in the development of the coolingsystem hydraulic circuit, and has authored an SAE paper "A Model to Simulate the Behavior of an AutomotiveThermostat". In 1996, she acquired a Masters Degree from the University of Michigan-Dearborn in MechanicalEngineering with a specialization in heat transfer and fluid flow.

Ms. Nelson was appointed Technical Specialist - Cooling Systems in 1996. As a Technical Specialist, sheprovides subject matter expertise to vehicle programs, develops new tools and methodology, leads the deployment of new designconcepts and provides technical mentoring to over 60 cooling design engineers worldwide. As part of the technical mentoring, she hasdeveloped cooling system design guides, conducted technical seminars and has recently written a self-guided web-based cooling designcourse.

Ms. Nelson is a licensed professional engineer (State of Michigan, 1992), an 18 year member of SAE, and an active member of the SAEcooling standards committee.

MARY RANGER

Mary Ranger is a Senior Product Design Engineer at Ford, where she has 16 years experience, including threeyears as a subject matter expert in engine coolant technology.

Ms. Ranger has a Bachelor of Science degree in Metallurgy and Materials Science Engineering and Bachelor ofArts degree in French from Lehigh University. She is currently working on a Masters degree in QualityEngineering, at Eastern Michigan University.

Ms. Ranger began her career at Fords heat exchanger manufacturing facility in Connersville, Indiana in 1983,where she held positions as manufacturing engineer, production supervisor and plant metallurgist. As plantmetallurgist, Ms. Ranger was involved with evaluating the effect of engine coolant on the corrosion resistance ofbrazed aluminum radiators. In 1995, she moved to Dearborn, Michigan where she held positions as a Materials

Engineer and as a Product Design Engineer, within Fords Climate Control Division.

Throughout this period Ms. Ranger continued to provide technical expertise in the field of engine coolant technology and corrosionprotection. Her expertise in this area was recently acknowledged when transferred to Fords Research & Vehicle Technology group,where she has responsibility for the development and deployment of engine coolant technology.

Ms. Ranger is a member of SAE and the ASTM D-15 subcommittee on engine coolants.

Downloaded from SAE International by Automotive Research Association of India, Friday, August 01, 2014

ii

Table of Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Part 1 - Systems Engineering Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . .3

Part 2 - Engine Cooling Design from a Systems Engineering Perspective

Section 1 - Vehicle and System Level Requirements. . . . . . . . . . . . . . . .21

Section 2 - Engine Internal Flow Subsystem . . . . . . . . . . . . . . . . . . . . . .29

Section 3 - External Flow Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Section 4 - Heat Dissipation Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . .39

Section 5 - Airflow Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Section 6 - Pressure Control Subsystem . . . . . . . . . . . . . . . . . . . . . . . . .79

Section 7 - Temperature Control Subsystem . . . . . . . . . . . . . . . . . . . . . .83

Section 8 - Coolant Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Section 9 - Coolant Fill and Drain Subsystem . . . . . . . . . . . . . . . . . . . . .99

Section 10 - Deaeration Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . .103

Section 11 - Coolant Containment & Sealing Subsystem . . . . . . . . . . .105

Section 12 - Heater Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116

Appendix A - The Making of An Automobilist, by H.A. Grant - 1906. . . . . .118


11999-01-3780

A Systems Engineering Approach to Engine Cooling Design

Peter KanefskyValerie Nelson

Mary RangerFord Motor Company

Copyright 1998 Society of Automotive Engineers, Inc.

ABSTRACT

This paper is divided into two parts:

Part 1 - Systems engineering fundamentals Part 2 - Engine cooling design from a systems

engineering perspective

In Part 1, we explain how the task of designing a complexsystem can be made easier by the application of SystemsEngineering principles. (This part is self contained and maybe of general interest to those who have no special interestin engine cooling).

Systems Engineering provides three key benefits:

It facilitates communication: Requirements define the problem, they allow team

members to see their own work in context Key information is standardized and made easier

to visualize and verify. An audit trail is maintained ensuring that

important information is documented, and humanmemory is no longer relied on for importantdecisions.

Translates requirements into design. Ensures that all requirements are specified in

common terms and none are missed Ensures that requirements are consistent and

linked from the customer to the vehicle and all theway down to components.

Ensures that manufacturing and service issues areaddressed up-front in the design process.

Defines the interactions between the OEM's and theSuppliers

In part 2, we examine cooling system design using SystemEngineering principles.

INTRODUCTION - PART 1

Systems Engineering has been extensively used in theaviation and aerospace industries for many years. Its use inthe automotive industry is relatively new and deriveslargely from the increased complexity of the vehicle beingdesigned.

EARLY VEHICLE DESIGN

Engineers have successfully designed and built vehiclesfor both commercial and personal use for over 100 years.Initially, these vehicles were highly individualistic, custombuilt and assembled by craftsmen, with individualcomponents being tailored to fit. As time progressed, thedimensions and specifications of individual componentsbecame standardized, allowing parts to be fitted togetherwithout adjustment. This standardization ultimately led tomass production techniques.

Over time vehicles were refined; shapes changed,performance increased, but there was little functionaldifference between a vehicle of the 1970s and one built 50years earlier*.

MODERN VEHICLE DESIGN

Within the last 20 years, the picture has changedsignificantly. Economic, environmental and socialconditions have combined with technological advances,driven by the computer and electronics revolution, todramatically change the modern vehicle and the processby which it is designed.

There can be little doubt that todays vehicle is a moresophisticated and complex product than its counterpart ofthe late 1970s. It contains such innovations as:

*. Appendix A, reproduces the text and illustrations of a book entitled The Making of An Automobilist published in 1906. Readers may find it interesting to see how little has changed with time.


2 Electronic engine management Emission control system Anti-lock braking system Energy absorbing structures Automatic temperature control Extensive use of plastics Light weight, high strength alloys Composites and other materials that would have been

considered exotic in the past

Specialization

To meet the challenge of new technology, engineers haveby necessity, become more technically qualified than anengineer was 20 years ago. As the human mind isknowledge limited, there is a tendency to specialize. Withthis increased specialization has come an inevitablenarrowing, in knowledge breadth.

Engineering Teams

To compensate for the narrowing in knowledge, weleverage the skills of these engineer through the use ofdesign teams, in which each member brings a differentperspective and specialized skill to the problem. As theproblems become more complex, the number of teamsincreases and the scope of their work narrows.

For these teams to be effective they must be able to seetheir work in context, so that components and subsystemsare not optimized at the expense of the overall product.

In Part 1 of this paper we will show how SystemsEngineering provides a consistent and structuredframework where information and knowledge can beexchanged in a coordinated manner.

Full Service Suppliers

As the level of design complexity increases, the vehiclemanufacturers are increasingly delegating the design taskto specialized suppliers. These suppliers are frequentlyrequired to take total responsibility for the design, includingwarranty.

For a supplier to accept such responsibility, they must besure that all of the information that they require to completethe design, is both accurate and available in a timelymanner.

Systems Engineering provides the mechanism forunambiguously communicating design information.

Compromise and Trade-Off Among Teams

Even when good team management occurs, compromiseand trade-off decisions are necessary. The designobjectives of each of the sub-teams will almost certainlydepend on another team's outcome, or may even bemutually incompatible with another teams objectives.

Throughout the design and development of a product ascomplex as a vehicle, these trade-off decisions are madeon a daily basis. Such decisions number in the thousandsbefore the product is finally sold to a customer.

In this paper we will show how Systems Engineering canbe used to manage this trade-off process and ensure thatthe final product will meet the needs of the customer,throughout the products life cycle.


3OVERVIEW

The purpose of this section is to introduce the reader to thefundamental concepts of Systems Engineering. SystemsEngineering provides a framework for managing andintegrating the effort of many specialized engineersworking on different parts of a complex product, into asingle design team with shared objectives.

A systemic approach embrace the following concepts:

The system is greater than the sum of the parts. Optimizing the parts does not optimize the whole. Interactions determine systems performance. A system cannot be fully understood by breaking it

down and analyzing its parts.

WHAT IS SYSTEMS ENGINEERING

The International Council on Systems Engineering(INCOSE) defines System Engineering as:

an interdisciplinary approach and means to enable therealization of successful systems. It focuses on definingcustomer needs and required functionality early in thedevelopment cycle, documenting requirements, thenproceeding with design synthesis and system validationwhile considering the complete problem

Systems Engineering integrates all the disciplines andspecialty groups into a team effort forming a structureddevelopment process that proceeds from concept toproduction to operation. Systems Engineering considersboth the business and the technical needs of all customerswith the goal of providing a quality product that meets theuser needs. [4]

Encapsulated in the previous definition are some keyconcepts:

System Engineering is a requirements driven process,in which the voice of the customer is paramount. (Acustomer can be defined as anybody downstream ofthe process that has equity in its outcome).

Systems Engineering requires that, before we startdesigning the physical hardware, we must firstunderstand all the functions that the design mustperform, i.e. form-follows-function

Systems Engineering does not rely on the memory orknowledge of an individual:

knowledge is documented detailed specifications are written decisions are tracked

Systems Engineering is team oriented andinterdisciplinary: - Design, Manufacturing, Marketing,Sales, Service, Finance etc. are an integral part of thesystem and their requirements must be consideredsimultaneously.

Systems Engineering institutionalizes quality into thedesign process, by continuously validating functionalperformance.

Quality is determined by the product as a whole, not byany single part of the product, no matter how good thatpart may be.

WHAT CONSTITUTES A SYSTEM

A system is a collection of interdependent functionalelements that, when brought together as a single unit,combine to meet a set of common objectives. As shown inFigure 1

Figure 1, Example of System Hierarchy

A system has both internal structure and context.

Product

Subsystem

SystemSystemSystem

Assembly

ComponentComponent

Subsystem

Assembly Assembly Assembly

Part 1Systems Engineering Fundamentals


4 Internal structure - System may contain, or becontained by, other systems. As Jonathan Swifteloquently said, some 300 years ago:

Big fleas have little fleasUpon their back to bite 'emAnd little fleas have lesser fleasAnd so ad infinitum.

Context Systems are characteristically interwovenwith and affected by other systems. Frequently theyonly have value because of relationships to anothersystem. Systems have boundaries and interfaces withother systems

Systems can have two types of interfaces physical orfunctional

Physical interfaces We deal with physical interfacesevery day. When we look at an object, we havebecome accustomed to constructing a hierarchy ofphysical interfaces within our mind's eye. What childdid not learn that:-the hipbone is connected to thethighbone, the thighbone is connected to the wellyou know the rest.

Functional interfaces These interfaces whilesometimes less obvious are equally important as theydeal with the interdependency of performancecharacteristics.

For example, the fan of a truck cooling system may bephysically connected to the engine, but it is functionallyconnected to the radiator, through which it inducesairflow.

The concept of physical and functional interfaces is centralto the implementation of systems engineering.

SYSTEMS ENGINEERING PROCESS MODELS

A key strength of Systems Engineering is that it recognizesthat all design problems are not the same. There areseveral ways to manage the design process, depending onthe nature and complexity of the task to be performed.Each of three commonly used process models havedifferent strengths:

Waterfall Sequential Model Spiral Sequence Model V Sequence Model

WATERFALL SEQUENTIAL MODEL

The waterfall model is perhaps the oldest and mostcommonly used model and is typically used for simple

systems. Deriving its name from the Gantt chart, it ischaracterized by a development process in which eachtask is performed sequentially, as shown in figure 2.

Figure 2, Waterfall Sequential Model

Although it is traditional to complete each task beforemoving on to the next one, it is not absolutely necessary.There is frequently enough information to begin a taskbefore completing the preceding activity. If you advance atask too much however, you risk having to repeat it, in thelight of improved information from a preceding task.

The Waterfall Sequential Model is generally suitable forsimple products having clear and well defined requirementsimmediately available at the start of the project, and asingle phase of prototype verification.

SPIRAL SEQUENCE MODEL

The spiral sequence model, figure 3, assumes anincomplete understanding of the customers requirementsat the start of the project. It further assumes that severaliterations are required through the design process before aproduct of sufficient maturity is ready for the customer.

This type of model is ideally suited to a process usingmultiple phases of prototype to gain user feedback, beforethe final product is committed to production. The SpiralSequence Model is used extensively in the computersoftware industry, and is somewhat similar to a traditionalhardware based vehicle development process.

The spiral sequence model is generally slower than the Vsequence model because it limits the degree ofconcurrency that is possible in the process. There arecircumstances however, where a rapid prototype built froman imperfect set of requirements, may be faster thanwaiting for an exhaustive set of requirements, especially ifanalytical methods are not available for target setting orverification.

Requirements

Design/Synthesis

Verification

Production


5Figure 3, Spiral Sequence Model[5]

Unlike the other models, spiral sequence model doescapture two important concepts:

The importance of continuous improvement A product development cycle can loop indefinitely, with

periodic launches of improved versions of the product

Although these features are normally associated withproducts which do not require large capital investment tomake changes, i.e., computer software. It is similar to theautomotive industrys practice of model year changes, tointroduce both major and minor product freshening.

V SEQUENCE MODEL

The V Sequence Model, figure 4, extends the waterfallmodel by subdividing the requirements and verificationphases. This approach allows for a more complex system,consisting of end-items, sub-systems and components, tobe studied in greater depth. Rearranging the modelsequence into a V, clearly identifies the relationshipbetween the downstroke requirement phase and theupstroke verification phase of the project.

The top-down decomposition of requirements and theirassociated targets, begins with the customers needs for thesystem, and cascades through the various design layers,down to requirements for individual components.

Figure 4, V Sequence Model

Similarly, the bottom-up verification of the hardwaresolution, starts with components, and integrates throughthe various assemblies and subsystems back to the fullproduct.

Analytical tools are key to the successful implementation ofthis type of model. They enable the decomposedrequirement targets to be validated and checked forcompatibility before they are cascaded to the next leveldown. Similarly, test and analytical methods must exist toenable verification at the appropriate design level, insteadof delaying verification until the complete system level.

Modified V Sequence Model

In a large complex system with many requirements andmultiple interactions, it may not be possible or desirable tocomplete the requirements cascade process in a singlepass. Requirements may need modification orreprioritization in a trade-off process designed to balancefunctional performance, robustness, affordability and value.

Under these circumstances, an iterative loop may beembedded within each level of the requirement cascadecontained in the V sequence models downstroke. Thisloop is typically comprised of analysis, synthesis andverification phases but omits the production phase. Asshown in figure 5.

RequirementsAnalysis

Design / Synthesis

VerificationProduction

Prototype

Prototype

Prototype

Production(Mk 1)

Production(Mk 2)

Customer Requirements TIME

&DETAIL

System Requirements

ComponentRequirements

Subsystem Requirements

End Item Requirements

Design /Synthesis

ComponentVerification

End Item Verification

System Verification

Subsystem Verification

CustomerNeeds Product

Test

r equ

irem

ents

map

with

in th

e sa

me

leve

l

TIME


6Figure 5, Analysis, Synthesis and Verification Loop

The modified version of the V sequence process model,shown in figure 6, is ideally suited to automotive industryneeds. It provides the mechanism to implement a strongcustomer focus in the design and development of newvehicles.

Figure 6, V Sequence Model with embedded Subsystem process

This is the process model used at Ford Motor Companyand it represents an evolutionary rather than revolutionarychange in the way engineers work. It facilitates:

More up-front planning.

Increased verification at the component and subsystemlevel.

Fewer phases of prototype vehicles. Fewer downstream changes. Shorter product development time.

SYSTEM PARTITIONING

Terms & Definitions:Product: What the customer purchases

System: A group of two or more systems & subsystem

Subsystem: A group of two or more assemblies

Assembly: A group of two or more components

Component: A group of individual part

Element: A generic term for any of the above

System partitioning is a method for dividing a system intosimplified and manageable pieces. Partitions may bebased on any convenient grouping. Typical groupingsinclude:

Function Technology Physical location. Product attribute Reusability and complexity

Whatever the choice of grouping the objective is tominimize the number of interfaces across the partitionboundaries.

As discussed earlier there are two primary types ofinterfaces in every system: physical and functional. Theseinterfaces can be sub-divided into two additionalcategories: external and internal.

External interfaces are those that deal with theinteraction between elements within a partition andthose in any other partition, or any interaction with theexternal environment.

Internal interfaces are those that exist between designelements within a partition.

Whether the interfaces occur at system, subsystem orcomponent level, if the interface has different people oractivities responsible for the interaction end-points, there isa potential for communications to breakdown. Partition

RequirementsAnalysis

Design /Synthesis

Verification

Requirem

entsFeasibility

Design Gaps

Desi

gn

Requirement Gap

Iterate forCompatibility

Verification

Requirements

System Requirements


Subsystem Requirements

End Item Requirements

Design /Synthesis

ComponentVerification

End Item Verification

System Verification

Subsystem Verification

CustommerNeeds Product

Test

Req

uire

men

ts M

ap

With

in T

he S

ame

Leve

l


7boundaries are therefore carefully selected to minimize thenumber of requirements with cross-partition interfaces.

Having partitioned the system into a number of semi-autonomous system or subsystems, each is assigned itsown design specification. A Program Development Team(PDT) is then given the responsibility to deliver all of therequirements contained within the specification.

When cross-partition interfaces occur, a formal mechanismfor managing the requirement end points is essential. Theresponsibilities may be divided but they are not shared.The notation required of and required by is often used toeliminate any ambiguity:

The required by activity is responsible for:

Defining the requirement objectives. Setting the functional target level. Ensuring the target affordability and value. Confirming that the target is met.

The required of activity is responsible for:

Agreeing that the target is technical feasible. Cascading the requirements to the next level down. Developing a design that meets the target. Performing target verification.

For example, A target for the dynamic balance of anengine mounted cooling fan is required of the coolingdesign team and required by the accessory drivedesign team, who would set the target at a levelcompatible with the mounting system.

Vehicle partitioning, based on physical architecture hasbeen found to give the fewest external interfaces. It istherefore the model used within Ford.

DESIGN SPECIFICATIONS

Based on this partitioning a specification tree is developed,from the top down, as shown in Figure 7. The number oflevels employed depends on the complexity of the physicalsystem. The lowest level is determined by the level whereyou can make the decision to make, buy, or reuse anexisting element.

Each element within the hierarchical structure has its owndesign specification. This specification should contain:

A non-technical description of the element A non-technical statement of elements function A schematic diagram of the element

A complete list of the functional requirements andassociated targets for that element.

A description of the methodology to be used to verifythe target has been met.

An interface specification, that describes how thatelement interacts with other elements

A history of document revisions

Partitioning based on physical architecture alone, may beinsufficient in large complex systems, as there are certaincustomer requirements that do not map well into ahardware-based specification.

Figure 7, Example Specification Tree

For example, if a customer states - I want the highestpayload for a truck in this class. It is not clear whowould be responsible for delivering that improvementto the customer, because many of the vehiclessystems could be affected.

Clearly, if the voice of the customer is to be one of theprimary drivers of product design, we need a method andprocess that can map these customer requirements, fromthe functional domain into the physical domain.

One method of doing this is to group similar customerrequirements together into customer attributes.

For example, commonly recognized customer attributesmight include the following:

Cost of Ownership Customer Life Cycle Emissions

Vehicle

Body

Cooling System

Climate ControlChassisPowertrainElectrical

Temperature Contol

Subsystem

Heat DissipationSubsystem

Internal Flow Subsystem

HeaterSubsystem

Pressure ControlSubsystem

Coolant

Fill, Drain & DeaerationSubsystem

Containment & Sealing

Subsystem

External Flow Subsystem

Hoses ClampsRigid Pipes

Airflow Subsystem


8 Interior Comfort Noise, Vibration & Harshness Package & Ergonomics Performance & Economy Safety Security Styling & Appearance Vehicle Dynamics

Those who have responsibility fore delivering thesecustomer attributes would have following responsibility:

Gathering customer, corporate and external wants.(Requirements analysis)

Converting those wants into functional requirementsand targets. (Functional analysis)

Developing those requirements into a specification forthe overall product.

DESIGN MANAGEMENT

With so many empowered teams, we need a method formanaging the design process. Typically, this is achieved bythe use of a matrix management structure of the typeshown in figure 8. Program Integration Teams have leadresponsibility for product related decisions (function), andthe Program Development Teams, have lead responsibilityfor technology related decisions (hardware).

Figure 8, Generic matrix organization

REQUIREMENTS ANALYSIS

Terms & DefinitionsRequirement: - A statement identifying a capability,

physical characteristic, or quality factor thatbounds a product or process need. [6]

Goal: - A desired capability, characteristic or qualityfactor

Target: - A quantitative measure of the functionalperformance necessary to satisfy arequirement

Tracability: - The ability to track a cascaded requirementback to its original source

The Requirements Analysis process establishes the overallobjectives of the system, through compiling and analyzingrequirements that define:

How well the product must perform in quantitativeterms

Direct communication with the customer Market analysis Purchase reasons Customer likes/dislikes Quality surveys Customer satisfaction measures The physical environment in which the product will

operate Any constraints that will affect the design solution

Requirements are written using the language of thecustomer, rather than a technical or scientific language.Each requirement has an associated quantitative measureof desired performance, including where appropriate, anassessment of the customers expectations forperformance at high mileage/time-in-service. Early in thedesign process, these measures may be subjective, (e.g.1-10 scale) or relative, (best-in-class). The measures mustbe quantitative and never qualitative (e.g. improve fueleconomy, reduce noise).

These high level requirements usually come from one ofthree basic sources:

Customer expectations Project / corporate constraints External constraints

Product Developement

Team


Team


Team


Team

Tech

nolo

gy L

e ade

rshi

p

ProductIntegration

Team

ProductIntegration

Team

ProductIntegration

Team

ProductIntegration

Team

Customer Attribute Leadership


9CUSTOMER EXPECTATIONS

Customer expectations include:

What the customer wants to be able to do with thevehicle.

How well each function the vehicle performs must beaccomplished

Details of the natural and induced environment inwhich the vehicle will be operated.

Constraints that the customer will be placing on thevehicle: Purchase cost Operating cost How the vehicle will be serviced Frequency of use Hours of use per day

These customer expectations and desires can be dividedinto three categories of wants:

Basic wants Performance wants Features that cause excitement

The level to which these requirements are achieved, willdetermine the degree of satisfaction that the customer willhave with the product.

Basic Wants are typically unspoken by the customer. Theyrepresent the minimum expected for the vehicle.Successful delivery of these requirements will, at bestproduce a neutral response from the customer, while failureto deliver will cause dissatisfaction. These requirementsare generally regarded as the price of admission to themarketplace

Performance Wants are spoken wants. They are desirableperformance features that the customer is willing to paymore money to obtain. Better product performance willyield a greater level of customer satisfaction.

Excitement Wants surprise and delight the customer whenthey are first introduced to a new product. They can beused in advertisements to distinguish the product from itscompetitors. Customers do not ask for things that theyhave never experienced, so these requirements areunspoken. The presence of these features may increasecustomer satisfaction, but their absence will have noimpact.

A useful tool for understanding and measuring customerappeal is the Kano model[7], which is shown in figure 9.

Figure 9, Kano Model of quality, customer satisfaction and performance

Over-time, excitement and performance wants oftenbecome so readily expected by the customer, that theycease to be excitement and performance wants andbecome basic wants, shown in Figure 10.

Examples of performance wants that have over timebecome basic wants, include:

Seat belts Air-bags Anti-theft immobilization devices Intermittent screen wipers

Similarly, when first introduced the cup holder was asurprise and delight feature. Today, we have become soused to their presence that a vehicle without one is asource of annoyance.

Figure 10, The effect of rising customer expectations

Completely Satisfied

Completely Dissatisfied

Did NotAchieve

FullyAchieved

Perfo

rmance

(Spoke

n want

s)

Basic Want(Unspoken unless violated)

Excitement(Unspoken Want)

Excitement

Performance

Basic


10

PROJECT AND CORPORATE CONSTRAINTS

Project and corporate constraints should include anyinternal requirements that will impact or limit potentialdesign solutions. Project and corporate constraints mayinclude:

Financial constraints on investment and variable cost. Project timing. Technology availability and maturity. Market trends and futuring. Reuse of design elements. Facilities for design, test and manufacture. Human resource allocation and skills. Corporate specifications, standards, guidelines and

best practices. Policies and procedures. Product and manufacturing complexity. Established product and process life cycle objectives

EXTERNAL CONSTRAINTS

External constraints include requirements that will impact orlimit potential design solutions.

Local and international laws and regulations. Social, political and economic requirements. The technical capability of the supply base. Industry, international and general specifications,

standards and guidelines Competitor product capability

REQUIREMENT PRIORITIZATION

Each requirement should be assigned a relative orabsolute priority using at least one of the classificationsshown in table 1. These priorities are used for subsequenttarget trade studies.

For example:

Meeting the U.S Government emission standards is agiven. It is non-negotiable

A fuel economy requirement might state that theperformance must be at least 8.2 MPG, but also, want8.5 MPG for highway driving.

While the must is a requirement as it defines theminimum competitive position of the product. (In thiscontext minimum may not be simply a neutral customerresponse, the image of the product may dictate that theminimum may in fact be best-in-class). The want by

contrast is a goal which if met, will increase customersatisfaction.

Table 1: Prioritization of wants

REQUIREMENTS ARE CONSTRAINTS

All requirements place constraints on the system. Asconstraints they have the potential to limit designalternatives and adversely impact cost, quality, functionand weight. Therefore, it is essential to validate eachrequirement to ensure that it adds value to the product,before accepting it as part of the products baselinerequirements. It is not necessary to conduct verification* atthis stage, as we are working in the customer domainrather than the engineering domain. A simple check fordiscrepancies and conflicts will be adequate if the list ofrequirement is complete.

Look for discrepancies and conflicts in the wording of therequirement and the performance objective. Do not attemptto resolve any conflict, but simply prioritize the importanceof any apparently conflicting requirements. The resolutionof conflict only begins after technical engineering targetsare assigned and we start to select design concepts,determine value and affordability.

After validation the requirements are added to theValidated Requirements Baseline document for theproduct. All subsequent steps in the design process usethe Validated Requirements Baseline as the authoritativesource in any requirement conflict, or audit of functionalrequirement traceability.

Classification: Description:

Given A mandatory requirement

Must A requirement that defines theminimum competitiveness

Want A desirable requirement thatpotentially differentiates thevehicle from others

Not Required The presence or absence of thisrequirement has no impact onthe vehicle

Not Wanted The presence of thisrequirement detracts from thevehicle

*. While validate and verify are sometimes used interchangeably, Merriam-Webster offers the following opinion: validate implies establishing validity by authoritative affirmation, whereas verify implies the establishing of correspondence of actual facts.


11

Figure 11, Translation of requirements from the Customer to Engineering Domain

FUNCTIONAL ANALYSIS

The Functional Analysis process translates high level, non-technical requirements contained in the ValidatedRequirements Baseline from the customer domain to theengineering domain (figure 11). In the engineeringdomain they are converted to detailed technical functionalrequirements. Working on the principle that form-follows-function, these requirements are generic and should statewhat is needed, rather than how to accomplish it.

The process of translating the voice of the customer usestop-down Functional Decomposition, which takes eachrequirement in the Validated Requirements Baseline andasks the question: What function is needed to satisfy thisrequirement? This question may be asked several times toseparate multiple engineering functions contained within asingle customer requirement.

Each engineering function is examined to determine whatfactors directly influence the successful delivery of thatrequirement. These factors can be divided into twocategories; control factors and noise factors.

Control factors are those parameters of a design conceptthat can be adjusted to optimize the function of that design.

Noise factors are the sources of variability that degradethe functional performance of the design.

As each functional requirement is identified, the subjectiveand relative performance targets from the ValidatedRequirements Baseline are converted into objective andabsolute targets for performance and reliability. Thisconversion may not be possible in all cases due to a lack of

specific knowledge at this point in time. (This process oftarget setting will be covered in detail later in this part).

REQUIREMENT VALIDATION

Before each functional requirement is accepted, it isvalidated using the following fundamental principles toconfirm that the requirement is properly defined[8][9][10]. Arequirement must be:

Necessary: Deletion of the requirement should create adeficiency that cannot be fulfilled by other capabilities of theproduct.

Verifiable: The target associated with the requirementsshould be quantified in a manner that can be verified byinspection, analysis, demonstration or test.

Attainable: The requirement should be capable of beingachieved by one or more design concept that has beenproven viable, within the constraints of the project.

Concise: The requirement statement should contain onlyone requirement.

Complete: The requirement should not need furtherelaboration.

Consistent: A requirement should not contradict orduplicate another requirement.

Unambiguous: The requirement should not be open toalternative interpretation.

Implementation Free: The requirement should stateWHAT is needed, not HOW it is to be accomplished.

Standard Construct: Requirements should used standardterminology and avoid subjective or relative expressions.

For example, a poorly written requirement mightstate:

The requirement is poor for a number of reasons:

The word minimum is ambiguous and cannot beverified. The expression not less than used inconjunction with a number would remove theambiguity.

The requirement is not implementation free, as itassumes that a thermo-viscous fan clutch is thechosen method for driving the fan.

CUSTOMER DOMAIN

Voice of the Customer

Signal Response

Noise

ControlsENGINEERING DOMAIN

Customer Intent

PerceivedResults

System(made up from sub-systems)

Cycling of the thermo-viscous fan clutch shouldbe kept to a minimum


12

The requirement is incomplete as it not clear whatrepresents cycling. Does it mean moving from fullydisengaged, to fully engaged, and then back to fullydisengaged, or does it mean any reversal in the stateof clutch engagement?

The word should, has a special meaning in thestandard nomenclature of specification writing and isused to denote a goal rather than a requirement. Theword shall is used to denote a requirement.

Finally, it is unclear that the requirement is necessary,since its wording is so vague that it is impossible todetermine if deletion of the requirement will have anyimpact on the product.

In contrast, a well-written requirement might state:

Once all the functional requirements at the system-levelhave been identified, they are documented in a system-level functional specification. (In a large complex system itmay be necessary to sub-divide the requirements into moremanageable groupings based on either a physical orfunctional partitioning of the system, as described earlier).

FUNCTIONAL INTERFACES

The next step in the process is to establish the functionalinterfaces between the requirements and document themon an interface diagram, which is added to functionalspecification. Each requirement is examined for anyinteraction that it might have with other requirements.Relationships are assigned one of the followingclassifications:

Independent: The functions are not linked in any way.(E.g. coolant temperature is independent of door closingeffort).

Dependent: The functions are linked such that if one ischanged, the other is automatically changed. (E.g.Waterpump speed is dependent on engine speed).

Correlated: The functions are linked such that if onechanges, a change in the other is implied. (E.g Radiatorheat dissipation is correlated to fan airflow rate).

Following validation, a Functional or Concept FMEA(Failure Mode Effect Analysis) is performed on eachrequirement to identify the consequences of not meetingthe functional requirement. Standard FMEA techniques areused to determine the severity of risk associated with eachpotential failure mode. A design verification plan is

developed that will be used later in the product verificationphase of the design process to manage failure risk.

NOTE: It is important to recognize that at this point in theprocess we are validating failure to meet functional targetsand not the mechanical failure modes of a specific designsolution.

After the system-level requirements are established theprocess is repeated. Functional Decomposition is appliedto each system level functional requirement, to obtain thesubsystem functional requirements. This process isrecursively applied until all of the requirements necessaryto either make or buy the design have been identified. (Thedepth of this process depends on each individual designelement and could be anything from a complete system toan individual part.)

The process of cascading requirements and targets fromthe top-down is relatively straightforward, if the productbeing designed begins with a clean sheet of paper.Realistically, most new products are refinements of existingproducts or make use of existing design elements.

REENGINEERED PRODUCTS

In a reengineered product, the idealized top-downapproach must be modified. Each element of the productthat is to be reused already has a predetermined functionalperformance and set of interface constraints. The approachvaries for reused design elements:

If it is a component that is to be reused, then thecascade will be from the bottom-up

If it is a sub-system, then the cascade will most likelybe middle-out, with the cascade being performed inboth directions, as shown in figure 12.

The desire to reuse an existing design element may occurfor a number of reasons: capital investment, product timing,manufacturing complexity etc. Elements should not bereused before demonstrating that they can satisfy therequirements contained in the Validated RequirementsBaseline.

Conduct a top-down Functional Decomposition of the high-level requirements to identify those which impact theelement to be reused. Divide these requirements into twocategories, those that impact primary functions and thosethat create secondary constraints, such as unwanted sideeffects and potential failure modes, as shown in the figure13.

For example, the primary function of a cooling fanis to move air. Secondary constraints might includeaerodynamic noise, power consumption, dynamicimbalance etc.

When tested in accordance with key life testprocedure KLT-8K616, the fan drive mechanismshall, at a 95% confidence level, have a B5 life ofnot less than 250k miles.


13

Figure 12, Requirements Cascade

A capability study, (ignoring secondary effects), isperformed on the design element to determine if reuse isfeasible. If design control factors can be adjusted to give afunctional performance greater than that required by thecascaded functional target, then the element has thepotential to be reused and a more extensive study iswarranted. If, however, adjusting the control factors cannotyield an output that satisfies the functional target, (even inthe absence of constraints), then either the customer-levelassumption must be changed, or the element cannot bereused.

Figure 13, P-Diagram showing side effects and failure modes

If the primary functional targets can be achieved, theimpact of the secondary effects is investigated. This

process starts with identification of design specific failuremodes for the reused element. Using historical reliabilitydata, a design Failure Mode Analysis (FMA) is performedto identify existing failure modes. When the FMA iscomplete, a potential FMEA is performed, to identify anynew design failure modes. (The fact that the designfunctioned satisfactorily in the past does not mean that withdifferent boundary conditions, it will continue to do so in thefuture). As each failure mode is identified it is translatedinto a functional requirement and added to the high-levelrequirements that were cascaded by FunctionalDecomposition.

These functional requirements are fed into a bottom-upFunctional Composition process in which the question:What is the importance of this sub-function to the functionof the system? is repeatedly asked, until all of the relatedhigher-level design functions are identified. Additionalrequirements and functional dependencies not previouslyidentified during Functional Decomposition are added tothe appropriate interface diagram and functionalspecification.

Primary functional targets are assigned to the reusedelement, at the minimum level necessary to satisfy thesystem-level functional objectives. Targets for dependent orcorrelated secondary design function, are calculated andadded to the various functional specifications. If theimposition of these secondary functional targets does notviolate any primary design target for the entire product,then the reuse of the design element is feasible.

These targets are said to be compatible. Compatibility,however, does not imply that an optimum design solutionhas been reached. Greater value may still be achieved byadopting a new design.

For example, the reuse of an existing radiator mightrequire an increase in fan airflow, which is achieved byincreasing the fans speed of rotation. This increase,however, might also generate so much aerodynamicnoise that extra sound insulation is required. Theincremental cost associated with the extra insulationmight be greater than that saved by reuse of theradiator.

This process of determining the value of reusing existingdesign elements is a key part of the trade-off process,which is central to the development of robust producttargets.

TARGET SETTING

TARGET SETTING BACKGROUND

Before we discuss the target setting process in detail wewill first look at some of the important concepts thatinfluence the way targets are set.

System Requirements


Assembly Requirements

SubsystemRequirements

Design /Synthesis

CustommerNeeds

Middle-out

Top-down

Bottom-up

FunctionSignal Primary Function Side effects

Failure modes

Noise Factors

Secondary Constraints

Control Factors


14

To obtain a robust design that satisfies the customersrequirements we must take into consideration the effect ofvariability when setting the target level for a functionalrequirement.

This variability generally referred to as noise, can be splitinto three basic categories:

Unit to unit noise. Environmental (external) noise. Deterioration (internal) noise. Customer usage

Unit to unit noise is due to inherent variability in themanufacturing processes used to make and assemble theproduct. Problems related to this type of noise are typicallyseen early in the product life cycle and are frequentlyreferred to as infant mortality failures. Examples of unit-to-unit variability include:

Raw and processed material variations due tothickness, hardness, chemical composition etc.

Dimensional variations due to forming or machiningoperations.

Fabrication or assembly variations due to weld quality/location, bolt torque etc.

Product surface finish. Product handling damage.

Units that meet the minimum acceptable performancesuffer from a loss of function that may cause subsequentfailure in the presence of other noise sources.

Environmental noise is generated by sources that areexternal to the product. Sources of this type of noiseinclude the following:

Climatic variations (temperature, humidity, rain, windetc.)

Misuse of the product. (accidental or intentional) Unintentional energy input (heat, vibration, radiation

etc.) Dust in the environment. Chemical attack (corrosion, ozone, gasoline, etc.) Electromagnetic interference.

This type of noise is always present, to some extent. Whenapplied to units with marginal functional performance, it isresponsible for the apparently random failures that occurthroughout the products life.

Deterioration noise comes from within the product and isassociated with functional deterioration of the product dueto age or use. The combined effect of environmental noise

and deterioration noise is typically called wear-out.Examples of deterioration noise include the following:

Wear due to friction Changes in material properties such as: compression

set, creep, work hardening, fatigue, etc. Erosion due to fluid flow Internal corrosion

Three distinct failure modes, that characterize functionalvariability due to noise, can be combined to produce agraph commonly referred to as the bathtub curve, (figure14).

Figure 14, Reliability bathtub curve

Customer usage variation is due to the ways the customermay use the product.

Accidental misuse of the product. Intentional misuse of the product

It is important for the designer to remember that thecustomer will always find ways to use the vehicle that werenever intended, when the specification was written.

ON-TARGET ENGINEERING

Conformance to specification has traditionally been theprimary method of assessing the quality of a product.Anything within specification is viewed as good, whileanything outside specification is bad. In this approach,variation within the specification is both acceptable andunimportant.

Consider the example shown in figure 15, in which the unit-to-unit variations of a single design are compared.

The specification set by the designer called for a criticalcharacteristic to be controlled within a range m 0 which

Time in serviceIn

stan

teou

s Fa

ilure

Rat

e

Environmental

Unit to Unit Deterioration

Infantmortality Wear-out

Limit ofuseful life


15

is shown as an Upper and Lower Specification Limit, (USL /LSL)

Sample A represents the initial random populationsample taken from production. On examination, it wasfound that variability was causing some samples to falloutside the specification limits generating a processCapability Index, Cpk of less than 1. Production was haltedand the equipment adjusted.

Sample B represents the population distribution afteradjustment. The sample indicates that variability washalved and process capability reestablished with a Cpkindex of 1.4.

Figure 15, Variation of Functional Performance for two production samples

Viewed from a manufacturing perspective, the equipmentsetup used to produce sample B delivers significantlybetter quality, since all units produced meet specification.However, from the customers perspective, sample A hasmore units with on-target performance and would haveproduced greater customer satisfaction.

This apparent contradiction, where worse qualityproduces greater overall customer satisfaction, comesabout because within-specification and on-target are notthe same thing.

The difference between two individual samples, one justinside specification and one just outside specification, maybe very small and functionally insignificant. Whereas, the

difference between two samples, one on-target and onejust inside specification, may be very large and highlysignificant.

The traditional view of quality, where samples are viewedas either pass or fail, does not recognize that in mostcases, loss of functional performance is a continuum,rather than a discrete event.

It is important to recognize that two questions need to beanswered when setting the targets and tolerances for adesign: -

How far from the target, can functional performance deviate, before a customer perceived a loss of function that would cause them to act?How far from the target, can a dimensional or physical characteristic of the design deviate, before manufactur-ing should reject the unit?

In both cases an economically measurable action occurs.(the customer action might be delayed, such as a decisionnot to purchase another product). Dr. Genichi Taguchi isgenerally acknowledged as the first to developmethodology for evaluating this financial impact, which hequantified in a Quality Loss Function.

QUALITY LOSS FUNCTION

In developing an expression to quantify loss, Taguchi[11]defines quality loss as: the loss a product causes tosociety after being shipped, other than any loss caused byits intrinsic functions. This loss is made up from two parts:

Loss caused by functional variability. Loss caused by harmful side effects.

The cost associated with scrap or reworked products priorto shipment is deliberately excluded from this view ofquality, as they represent a cost to the manufacturer, butnot a quality loss.

From his studies, Taguchi concluded that the loss of qualityfor a product, due to deviation from target, could beapproximated by a function, which increased quadraticallywith deviation from target. The approach was foundapplicable to the four types of targets listed below:

Nominal is best: The target has an optimal value atolerance. Quality Loss Function is proportional to themagnitude of the deviation. (E.g. the alignment of a rubberisolator)

Smaller is better: The target response is ideally equal tozero, when the Quality Loss Function will also be zero.Tolerances are expressed only as an upper limit. (E.g.engine noise, aerodynamic drag, breaking distance, etc.)

Freq

uenc

e

LSL USL

NominalTarget

Sample A

Sample B

Functional Performancem + 0000mm - 0000


16

Figure 16, Comparison of traditional and quadratic Quality Loss Function

Larger is better: The target response is ideally infinity,when the Quality Loss Function will be zero. Tolerances areexpressed only as a lower limit. (E.g. weld strength,corrosion resistance, light bulb life, etc.)

Asymmetric Nominal is Best: The target has an optimalvalue but is subject to asymmetric tolerances. Loss offunction varies with the direction of deviation. (E.g. hosejoint clearance, fan tip clearance, etc.)

Figure 16 shows a comparison between the QuadraticQuality Loss Function and a traditional Loss Function for anominal-is-best function.

Expressed mathematically the Quality Loss Function isintended to represent the loss experienced by an averagecustomer, (rather than a specific customer), and is definedas:

(1)

(2)

Where:y = measured responsem = target value

k = Quality Loss Coefficient (an economic factor)A = Cost to society if tolerance is exceededD0 = Customer functional tolerance

Customer Functional Tolerance 0, is the point at which theproduct either fails, or 50% of the customers would decidethat the functional performance was unacceptable and takean economically measurable action.

The cost of this action, typically a repair, should includeconsideration of all related costs, some of which are listedbelow:

The cost of parts, labor and special tooling needed tomake the repair, whether it is repaired under warranty,or at the customers expense.

The cost associated with loss of use, including lostearnings and/or the hire of a replacement product.

The cost of transporting the product to the point ofrepair.

The cost for disposal or recycling for failed parts. The cost of spare part inventory. The cost of any reduction in product residual value.

When developing a new product, it may be difficult to obtainaccurate data for either the Customer Functional Toleranceor the Cost to Society. However, exact data is not requiredand it should be possible to make approximations that areclose enough to evaluate the relative merits of differenttargets and design concepts.

Cost, is not the only consideration in developing amathematical relationship to express a value for loss offunction. Safety and security issues may also be involved.

Severity of Failure: Not all failures have a benignoutcome, so it is necessary to consider the severity offailure when setting functional targets. The severity of afailure can be categorized using the following classes:

Safety, security and dependability related concerns,which might strand the customer

Failures and degradation in function which reduce thecustomer's confidence in the product

Failures that cause significant irritation to the customer Failures that cause the cost of ownership to increase

In many cases, the severity of failure will have no impact onthe target directly, but may influence it indirectly through thefollowing:

The level of functional variability permitted The required useful life. The modes by which the design concept is permitted to

fail.

Specification Limits

Good Good

Equally Good

Equa

lly B

ad

Equ a

lly B

ad

Specification Limits

0

0

Loss

Loss

Best

Target

Target

PoorPoor

Loss L y( ), k y m( )2=

k A

02

---------=


17

Cost: When using cost to calculate the value associatedwith a functional requirement, it is important to use the totalcost of design. Total cost has three elements; UnitManufacturing Cost, Life Cycle Cost and Quality Loss Cost:

Unit Manufacturing Cost: A combination of all of the costrelated to manufacturing the design element and includesvariable cost, fixed cost, tooling costs and the costsassociated with reworking or scrapping defective parts

Life Cycle Cost: The summation of costs related tooperating the product that are directly attributable to thedesign element under investigation. In addition to the costof repairs and routine maintenance, it should also includethe cost of energy required to operate the design

Quality Loss Cost: the cost associated with the QualityLoss Function

Figure 17, Target Setting Process

TARGET SETTING PROCESS

After identifying all of the functional requirements for theentire system, we have to decide on the performance andimportance in relative and absolute terms for each of therequirements. (Even in a very simple system, it isunreasonable to expect that every requirement could befully satisfied). Target setting is by definition an iterativeprocess, and involves trade-off decisions at every level ofthe product.

Figure 17 shows an over view of the target setting processbeginning with a review of the Validated RequirementsBaseline.

Develop Product Strategy

We develop an outline Product Strategy using thequantitative measure of desired performance, and therequirement priority, that was assigned by the customerduring the Requirements Analysis phase. The overallproduct requirements are prioritized, using the previouslydefined classifications, which are repeated in table 2.

Table 2: Prioritization of wants

Select Comparator Product

The next step in the process is to select an existing productthat most closely matches the product to be developed. Forreengineered products, the product being replace wouldmost likely be chosen. while the closest available productshould be chosen for a new market segment.

Review Benchmark and Technology Bookshelf

Benchmark data must be reviewed to establish the best-in-class and median performance of competitor products. Thisbenchmark phase should also include a review of allsignificant technologies on the competitor vehicles, oravailable internally or from suppliers.

After gathering the information from the previous threesteps, the initial process of target setting can begin.

Target Ranges

At the early stages of the design process, targets are notexpressed as point targets but as a ranges in which thetarget is bounded on at least one side, by a value that istraceable back to the voice of the customer, through theValidated Requirements Baseline document. This range is

Validated Requirements

Baseline

DevelopProduct Strategy

Select Comparitor

Product

Review Bechmark & TechnologyBookshelf

Set Futured Functional

Targets

Compare product

capabilities

Define Gaps Select Design ConceptsTrade-off Studies

Modify Product Strategy

Set Product Target Ranges

Classification: Description:

Given A mandatory requirement

Must A requirement that defines theminimum competitiveness

Want A desirable requirement thatpotentially differentiates thevehicle from others

Not Required The presence or absence of thisrequirement has no impact onthe vehicle

Not Wanted The presence of thisrequirement detracts from thevehicle


18

generally created by the need to keep risk low, in the faceof uncertain technological capability.

Using the Validated Requirements Baseline, competitivebenchmarking and comparator product data, target rangesare established for each of the customer requirements.

For example:

All functional requirements that are traceable back to arequirement designated as a given are assigned anon-negotiable target (Minimum or maximum value ofthe target range is set at the level specified in theValidated Requirements Baseline)

All functional requirements that are traceable back to arequirement designated as a must are assigned atarget established through benchmarking to becompetitive (This target may include a margin thataccounts for any shift in the competitive position, whichmay take place before the product is launched)

Define Gaps

System analysis is performed on carry-over, new oralternative design concepts throughout the target settingprocess to confirm the technical feasibility of satisfying therequired target. Gaps in the required performance arenoted, whether they are a shortfall or over achievement.The gaps drive the remainder of the target setting process.

If the target can be achieved, then value analysis isperformed to provide data that can be used in cross-functional optimization studies.

Where

(3)

AndCost = A universal currency of negotiation

(e.g. $. weight, quality etc.)

Trade-off Studies

Trade-off optimization studies can range from simplePareto charts, through to a multi-dimensional simulation,depending on the magnitude and complexity of thefunctional gaps.

If all of the gaps cannot be closed, even when a reasonableamount of stretch is applied to the target then it may benecessary to go back and modify the initial ProductStrategy.

When all these steps are completed, then the product willhave a set of compatible targets at the system level.

Conclusion

The target setting process is repeated continuously,progressively narrowing the safety margins, until theranges become point targets and the point targets becomefirm product objectives. This process is repeated at eachlevel of the design cascade.

Value FunctionCost

------------------------=


19

PART 2

ENGINE COOLING DESIGN FROM A

SYSTEMS ENGINEERING PERSPECTIVE


20


21

INTRODUCTION

In this section, we will discuss the design of vehicle coolingsystems in detail. Requirements will be developed usingSystem Engineering principles to show how a systemicapproach can maximize customer and shareholder value,by improving the function, quality, reliability and time-to-market for a new or redesigned vehicle.

As the cooling system is a complex system with numeroussubsystems, assemblies and components the number offunctional requirements is considerable. Within Ford wehave formally identified over 150 cooling requirements at orabove subsystem level, never mind all of the individualcomponent requirements. For practical purposes not all ofthese will be discussed in this paper.

What we hope to do is construct a framework that willencourage the reader to use their experience andimagination to develop functional requirements that matchtheir own needs.

In this paper we will not be discussing Fords detail designtargets. While some of that information is confidential, themain reason for excluding the detail is that targets areproduct and market specific, and may only serve to misleadthe reader. Generalised or rule-of-thumb targets shouldalways be critically questioned, as they are often non-valueadded constraints that simply drive cost up.

While requirements are often generic in nature, targetsmust be developed to match the customer expectations forthat specific product and must be set at a level that addsvalue to the product.

In Part 1 of this paper, we made a particular point ofexplaining what makes a good or bad requirement. In thispart of the paper however, we have not necessarilyfollowed our own rules. In such cases we leave the readerto decide how the requirement should be worded.

Although this paper is not intended to be a definitive orcomprehensive design guide for the cooling system,alternative design concepts will be discussed. Whereappropriate, the underlying principles will be explained so

that the reader may better understand the requirementbeing discussed.

For each major functional requirement, a ParameterDiagram has been constructed to help the readerunderstand the relationship between the following: -

The Ideal Function of the design element, i.e. therequirement and its associated target.

Control Factors, which can be used to adjust theelements functional performance. (These in turn,become the functional requirements for the next leveldown).

The Noise Factors, which introduce uncontrollablevariability and potential failure modes, into theelements functional performance. (If the signal/noiseratio becomes too great, then it may be necessarychange the design and make the noise factor a controlfactor).

Side Effects, which are secondary and unintendedoutputs of the design element. These frequently createundesirable external interfaces to the system and placeconstraints on the tunable range of the control factors.

Potential Failure Modes, which place constraints on thetunable range of the control factors and introduceadditional functional requirements.

In general the failure modes identified and discussed in thispaper are common cause failures, inherent to the designconcepts or requirement targets, rather than specialcause failures that result from defects in an individualcomponent.

VEHICLE LEVEL REQUIREMENTS

OBJECTIVE

The purpose of the vehicle cooling system is to providereliable powertrain operation under all vehicle operatingconditions.

In this section we will discuss the relationship of the coolingsystem to the customer and the vehicle as a whole.

We will discuss the following: -

Customer requirements/expectations Business and project requirements External requirements

To distinguish REQUIREMENTS from the textthey are boxed with double lines like this.

To distinguish GOALS from the text they areboxed with single lines like this.

Part 2 - Section 1Vehicle and System Level Requirements


22

CUSTOMER REQUIREMENTS/EXPECTATIONS

In part 1 of this paper, we identified the following aspotential sources customer requirements:

What the customer wants to be able to do with thevehicle.

How well each function that the vehicle performs mustbe accomplished.

Details of the natural and induced environment inwhich the vehicle will be operated.

Constraints that the customer will be placing on thevehicle: Purchase cost. Operating cost. How the vehicle will be serviced. Frequency of use. Hours of use per day.

These customer expectations and desires were divided intothree categories:

Basic wants Performance wants Features that cause excitement

From the customers perspective, the vehicle coolingsystem falls into the category of basic wants andaccording to the Kano model, shown in figure 18, it is arequirement that is unspoken unless violated.

Figure 18, Kano model of quality, customer satisfaction and performance.

The customer simply wants a cooling system that alwaysworks regardless of the vehicle operating conditions orambient temperature.

To better understand the customers needs, let us first lookat vehicle operating conditions which can be split into twogeneral categories:

Extreme conditions. Normal conditions.

Traditionally, the focus of the cooling engineer has been onthe extremes of operation; high vehicle load at highambient temperatures and low engine loads at low ambienttemperatures.

While these conditions are important as they test theboundaries of system performance, they do not representthe typical customer concerns, which tend to be durabilityor fuctional degradation related, rather than performancerelated.

In a customer focused cooling system design process theemphasis is shifted away from these severe performancemeasures, towards robustness under normal operatingcondition, cost of ownership and customer life cycle issues.

The effects of customer usage and environmentalconditions are treated as system noise factors rather thansystem design requirements.

What the customer expects of the cooling system isrobustness. Furthermore, that robustness should not justapply to the vehicle the day it leaves the factory. It musthave consistent functional performance for all of itsuseful life.

INTERACTION WITH CUSTOMER ATTRIBUTES

Although there are no direct customer requirements for thevehicle cooling system, the cooling system side-effects andfailure modes interacts with many of the customerattributes shown in figure 19.

Figure 19, Relationship between customer attributes and the cooling system.

Completely Satisfied

Completely Dissatisfied

Did NotAchieve

FullyAchieved

Perfo

rmance

(Spoke

n want

s)

Basic Want(Unspoken unless violated)

Excitement(Unspoken Want)

Customer Attributes (Vehicle Level)

VehicleDynamics

Cost of Ownership

Package &Ergonomics

Safety

EmissionsStylingSecurity

NVH Perfomance& EconomyInteriorComfort

CustomerLife-cycle

Powertrain

Cooling System

ClimateControlBody Electrical Chassis


23

The specific ways in which the cooling system design canbe modified to effect these customer attributes will varywith: -

Vehicle design The target customer The environment in which the vehicle is to be used The intended use of the vehicle.

These effects are product and company specific and areoutside the scope of this paper.

BUSINESS REQUIREMENTS

There are many corporate and project requirements for theentire vehicle that place constraints on the design of thecooling system. These constraints are highly project andcompany specific and are therefore outside the scope ofthis paper.

However, one of these constraints, project timing, is worthyof discussion as it frequently presents major problems tothe cooling system engineer.

PROJECT TIMING

As cooling is one of the major interfaces between thevehicle and the powertrain, it is frequently subject to projecttiming issues that make the designers job more difficult.

Typical powertrain issues include the following: -

The powertrain and the vehicle must have timing plansthat are synchronized, but they are not necessarilyconcurrent. The design of a new powertrain willfrequently start before the vehicle.

The parts of the cooling system internal to the engineare frequently designed without any knowledge of thevehicle installation components.

Engine calibration is frequently one of the last vehicleitems to be frozen. Changes to the calibration strategyand hence heat to coolant, frequently occur long afterthe cooling system has been not only sized, but alsosigned-off.

The engine may be carry-over or externally purchased,with little opportunity for customization or tuning.

In addition to the powertrain issues there are a number ofvehicle related issues that the cooling engineer mustaddress: -

When the initial underhood package is being definedand heat exchanger size fixed, there will frequently beno accurate data for engine heat dissipation or coolantflow rate.

The styling of the vehicle, including front-end openings,will normally be signed-off before verification testing isconducted.

Road based cooling system testing has seasonaldependencies, which can be impacted by projecttiming.

As the design of the cooling system frequently contains asubstantial level of design reuse, particularly parts internalto the engine, much of the process requires bottom-up,rather than top-down approach.

EXTERNAL REQUIREMENTS

At present there are no legislative requirements that applyspecifically to the cooling system, except for some localmarket requirements with regard to coolant usage anddisposal.

SYSTEM LEVEL REQUIREMENTS

SYSTEM PARTITIONING

As explained in Part 1 of this paper, the choice of systempartitioning is somewhat arbitrary. It can be performedusing any convenient criteria. In this paper we have chosento use a partitioning based on the physical hierarchy shownin figure 20.

Figure 20, Relationship between Vehicle Level requirements and the cooling system

Customer Attributes (Vehicle Level)

VehicleDynamics

Cost of Ownership

Package &Ergonomics

Safety

EmissionsStylingSecurity

NVH Perfomance& EconomyInteriorComfort

CustomerLife-cycle

Powertrain

Cooling System

ClimateControlBody Electrical Chassis

Temperature Contol

Subsystem

Heat DissipationSubsystem

Internal Flow Subsystem

HeaterSubsystem

Pressure Control

Subsystem

Coolant

Fill, Drain & DeaerationSubsystem

Containment & Sealing

Subsystem

External Flow Subsystem

Airflow Subsystem


24

As can be seen in figure 20, the cooling system interactswith two of the major vehicle systems the Powertrain andClimate Control system.

POWERTRAIN REQUIREMENTS

Put simply, the primary objective of the powertrain designeris to maximize the quantity of useful work output from theengine, for any given quantity of fuel input.

Whether the vehicle is powered by an internal combustionengine, electric motor, gas turbine or any other source ofpropulsion, it can be said with confidence that theconversion of fuel energy into useful work will not be 100%effective. Heat will always be generated as a side effect ofthe energy conversion process.

This heat can be divided into two components:

Useful heat: - which can be used to warm thepassenger compartment in cold ambient temperaturesand maintain the engine at the optimum temperaturefor combustion and lubrication efficiency.

Unwanted heat: - which must be removed from thesystem once the optimum operating temperature hasbeen reached.

If we examine the mathematics of the combustion processwe find that the temperature of the combustion chamberwalls is one of the factors that controls combustionefficiency and useful work output.

This process can be illustrated by the diagram in figure 21.

If the problem is approached from a theoreticalperspective, it is possible for any given engine design, todetermine an optimum temperature for the combustionchamber wall. However, from a practical perspective thetemperature of the wall varies from point-to-point andmoment-to-moment and we have no direct way to controlthe temperature. The definition of a requirement and targetfor temperature at the wall surface would be meaninglessas the requirement would be unattainable.

Figure 21, Engine combustion process with surface temperature as a control.

Although we cannot control the wall temperature directly,we can control it indirectly, by adjusting the average coolanttemperature and the local heat transfer coefficient, asshown in figure 22.

Figure 22, Heat flow through a plain wall

In giving up control of the engine wall temperature we allowit to become a system noise factor, which increases thevariability of useful work and heat output. The lack of walltemperature control also introduces some potential failuremodes, shown in figure 23, which must be managed by thecooling system.

Figure 23, Engine combustion process using coolant temperature as a control.

Rather than use heat transfer coefficient as a direct controlof combustion, it is used to manage the level of noise thatwall temperature can impose on the system.

CONTROL FACTORS

Although many control factors exist for optimizing thecombustion process and useful work output, in this paperwe will limit discussion to average coolant temperature.

CombustionFuel Useful Work

[Other factors]Engine surface temperature

Control Factors

Noise Factors

Side effects Unwanted heat Useful heat

Tc, Hc

L

k

Twc

Twg

Tg, Hg

LegendT = TemperatureH = Heat transfer coefficientL = Wall thicknessk = Thermal conductivity

Subscriptsc = coolant g = gas w = wall

CombustionFuel Useful Work

[Other factors]Average coolant temperatureLocal heat transfer coefficient

Control Factors

Noise FactorsEngine surface temperature

Side effects Unwanted heat Useful heat

Failure modes Structural failure Combustion pre-ignition Lubrication failure Poor hydrocarbon emissions Poor fuel consumption


25

When discussing the effect of temperature on systemfunction, it is important that we always distinguishbetween:-

Global and local temperature. Time averaged and instantaneous temperature.

Average coolant temperature

As discussed earlier, the average temperature of thecoolant should be set for optimal combustion efficiency. It isthe joint responsibility of the engine designer andcalibration engineer to set the target.

Traditionally, as the temperature control system utilized is amechanical device, with coolant temperature as the onlyfeedback mechanism, it has only been possible to set asingle nominal target, which is then applied to all operatingconditions. Loss functions for engine performance, fueleconomy, emissions and interior comfort should be used todetermine the value of maintaining the temperature within aspecified tolerance band.

For example: -

With the availability of enhanced powertrain electronics, itis now possible to use additional combustion control factorsas feedback signals, which can be used to modify thetemperature control strategy. The improved systemperformance, which is quantified in terms of a reduced lossfunction, must be offset against the increased cost ofsensors, actuators and controller and that is required toimplement a more sophisticated control strategy.

FAILURE MODES

In addition to the requirement created by the use of coolanttemperature as a control function, temperaturerequirements are necessary to prevent the potential failuremodes, shown in the P-Diagram (figure 23), from occurring.

Structural failure

As the heat generated by combustion is neither uniformlydistributed throughout the engine structure, nor in the caseof an internal combustion engine continuously generated,temperature within the engine varies with both location andtime. These variations in temperature cause differentialexpansion of the engine structure, resulting in thermallyinduced stress.

To prevent structural failure we require that a target be setsfor the maximum permitted localized metal temperature foreach different material used within the engine.

In the case of todays internal combustion engines, thethermal conductivity of the combustion chamber materialsand the engine firing frequency combine to make thetemperature, a time averaged requirement.

For example: -

Combustion Efficiency

The efficiency of the combustion process is bounded ontwo sides by temperature.

Firstly, if the combustion walls are too cold, combustion willbe incomplete leading to an increase in hydrocarbonemissions and poor fuel economy. This combustionquenching is a global and time averaged phenomenon.

As both fuel-economy and emissions are evaluated on acumulative rather than instantaneous basis, thetemperature requirement is also a cumulative requirement,which is expressed as a function of time.

For example: -

As the heat used to achieve this functional requirement, isuseful heat, the requirement must compete for itsallocation in a functional trade-off, which will be discussedlater.

Secondly, if the temperature is too high, the charge mayspontaneously ignite or detonate causing noise andpossibly structural damage to the engine. This type offailure and can be triggered by a single hot-spot within anindividual cylinder, on an individual cycle of the engine.

The temperature requirement needed to protect againstthis type of failure has a target value that is both localizedand instantaneous.

For example: -

The nominal operating temperature of the coolingsystem shall be TBDC TBD during any engineoperating conditions.

The time averaged local metal temperature, shallnot exceed TBDC under any engine operatingcondition.

When tested in accordance with drive cycle XYZ,the engine shall achieve an average coolanttemperature of TBDC in not less than TBDminutes.

The instantaneous metal temperature shall notexceed TBDC at any point within the engine,during any engine operating condition.


26

Lubrication Efficiency

Due to the close correlation that exists between enginemetal temperature, lubricating oil temperature and coolingsystem temperature, the cooling system engineerfrequently collaborates in the management of oiltemperature requirements. While it i