ABOUT THE AUTHORS
PETER KANEFSKY
Peter Kanefsky is the Supervisor of Vehicle Cooling Technology, Research & Vehicle Technology, Ford Motor Company. He has worked in the automotive industry 26 years and has 23 years experience in cooling system design and development.
Mr. Kanefsky began his career as a student apprentice with British Leyland Truck and Bus Division, England in 1973. After graduating from University of Manchester Institute of Science and Technology with a Bachelors Degree 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 car programs, where he worked on the development of computational techniques for system performance optimization. In 1989, after completing a Masters Degree in Advanced Automotive Engineering at Loughborough University, Mr. Kanefsky, began an International Service assignment with Ford’s Alpha Simultaneous Engineering group in the U.S. where he worked on the development of Computational Fluid Dynamics techniques for cooling system airflow analysis.
In 1991, Mr. Kanefsky returned to Europe as a Technical Specialist where he worked on the deployment of the tools and methodologies previously developed in the U.S. In 1994, he co-authored a cooling system design guide for use internally within Ford, and as a “subject matter 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 and Aerodynamic Systems Engineering group. In 1997, Mr.Kanefsky took his current assignment where he has responsibility for core and advanced vehicle cooling technology.
VALERIE NELSON
Valerie Nelson P.E., is a Technical Specialist in engine cooling systems for Ford. She has 17 years experience in engine cooling system design.
Ms. Nelson began her career in 1982 at Buick Motor Division, responsible for engine cooling design and development for the full size Buicks. After 5 years Ms. Nelson moved to Ford to work on the cooling system for the Ford Probe. While at Ford, she has pioneered the use of 1-D CAE tools in the development of the cooling system hydraulic circuit, and has authored an SAE paper "A Model to Simulate the Behavior of an Automotive Thermostat". In 1996, she acquired a Masters Degree from the University of Michigan-Dearborn in Mechanical Engineering with a specialization in heat transfer and fluid flow.
Ms. Nelson was appointed Technical Specialist - Cooling Systems in 1996. As a Technical Specialist, she provides subject matter expertise to vehicle programs, develops new tools and methodology, leads the deployment of new design concepts and provides technical mentoring to over 60 cooling design engineers worldwide. As part of the technical mentoring, she has developed cooling system design guides, conducted technical seminars and has recently written a self-guided web-based cooling design course.
Ms. Nelson is a licensed professional engineer (State of Michigan, 1992), an 18 year member of SAE, and an active member of the SAE cooling standards committee.
MARY RANGER
Mary Ranger is a Senior Product Design Engineer at Ford, where she has 16 years experience, including three years 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 of Arts degree in French from Lehigh University. She is currently working on a Masters degree in Quality Engineering, at Eastern Michigan University.
Ms. Ranger began her career at Ford’s heat exchanger manufacturing facility in Connersville, Indiana in 1983, where she held positions as manufacturing engineer, production supervisor and plant metallurgist. As plant metallurgist, Ms. Ranger was involved with evaluating the effect of engine coolant on the corrosion resistance of brazed aluminum radiators. In 1995, she moved to Dearborn, Michigan where she held positions as a Materials Engineer and as a Product Design Engineer, within Ford’s Climate Control Division.
Throughout this period Ms. Ranger continued to provide technical expertise in the field of engine coolant technology and corrosion protection. Her expertise in this area was recently acknowledged when transferred to Ford’s Research & Vehicle Technology group, where she has responsibility for the development and deployment of engine coolant technology.
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
1999-01-3780
A Systems Engineering Approach to Engine Cooling Design
Peter Kanefsky
Valerie Nelson
Mary Ranger
Ford Motor CompanyCopyright © 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 complex system can be made easier by the application of Systems Engineering principles. (This part is self contained and may
be of general interest to those who have no special interest in 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 human memory is no longer relied on for important decisions.
• 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 the way down to components.
• Ensures that manufacturing and service issues are addressed up-front in the design process.
• Defines the interactions between the OEM's and the Suppliers
In part 2, we examine cooling system design using System Engineering principles.
INTRODUCTION - PART 1
Systems Engineering has been extensively used in the aviation and aerospace industries for many years. Its use in the automotive industry is relatively new and derives largely from the increased complexity of the vehicle being designed.
EARLY VEHICLE DESIGN
Engineers have successfully designed and built vehicles for both commercial and personal use for over 100 years. Initially, these vehicles were highly individualistic, custom built and assembled by craftsmen, with individual components being tailored to fit. As time progressed, the dimensions and specifications of individual components became standardized, allowing parts to be fitted together without adjustment. This standardization ultimately led to mass production techniques.
Over time vehicles were refined; shapes changed, performance increased, but there was little functional difference between a vehicle of the 1970’s and one built 50 years earlier*.
MODERN VEHICLE DESIGN
Within the last 20 years, the picture has changed significantly. Economic, environmental and social conditions have combined with technological advances, driven by the computer and electronics revolution, to dramatically change the modern vehicle and the process by which it is designed.
There can be little doubt that today’s vehicle is a more sophisticated and complex product than its counterpart of the late 1970’s. 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.
• 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 have by necessity, become more technically qualified than an engineer was 20 years ago. As the human mind is knowledge limited, there is a tendency to specialize. With this increased specialization has come an inevitable narrowing, in knowledge breadth.
Engineering Teams
To compensate for the narrowing in knowledge, we leverage the skills of these engineer through the use of design teams, in which each member brings a different perspective and specialized skill to the problem. As the problems become more complex, the number of teams increases and the scope of their work narrows.
For these teams to be effective they must be able to see their work in context, so that components and subsystems are not optimized at the expense of the overall product. In Part 1 of this paper we will show how Systems Engineering provides a consistent and structured framework where information and knowledge can be exchanged in a coordinated manner.
Full Service Suppliers
As the level of design complexity increases, the vehicle manufacturers are increasingly delegating the design task to specialized suppliers. These suppliers are frequently required to take total responsibility for the design, including warranty.
For a supplier to accept such responsibility, they must be sure that all of the information that they require to complete the design, is both accurate and available in a timely manner.
Systems Engineering provides the mechanism for unambiguously communicating design information.
Compromise and Trade-Off Among Teams
Even when good team management occurs, compromise and trade-off decisions are necessary. The design objectives of each of the sub-teams will almost certainly depend on another team's outcome, or may even be mutually incompatible with another team’s objectives.
Throughout the design and development of a product as complex as a vehicle, these trade-off decisions are made on a daily basis. Such decisions number in the thousands before the product is finally sold to a customer.
In this paper we will show how Systems Engineering can be used to manage this trade-off process and ensure that the final product will meet the needs of the customer, throughout the product’s life cycle.
OVERVIEW
The purpose of this section is to introduce the reader to the fundamental concepts of Systems Engineering. Systems Engineering provides a framework for managing and integrating the effort of many specialized engineers working on different parts of a complex product, into a single 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 system’s 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 the
realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem …
…Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.” [4]
Encapsulated in the previous definition are some key concepts:
• System Engineering is a requirements driven process, in which the voice of the customer is paramount. (A customer can be defined as anybody downstream of the process that has equity in its outcome).
• Systems Engineering requires that, before we start designing the physical hardware, we must first understand all the functions that the design must perform, i.e. “form-follows-function”
• Systems Engineering does not rely on the memory or knowledge of an individual:
• knowledge is documented • detailed specifications are written • decisions are tracked
• Systems Engineering is team oriented and interdisciplinary: - Design, Manufacturing, Marketing, Sales, Service, Finance etc. are an integral part of the system and their requirements must be considered simultaneously.
• Systems Engineering institutionalizes quality into the design process, by continuously validating functional performance.
• Quality is determined by the product as a whole, not by any single part of the product, no matter how good that part may be.
WHAT CONSTITUTES A SYSTEM
A system is a collection of interdependent functional elements that, when brought together as a single unit, combine to meet a set of common objectives. As shown in Figure 1
Figure 1, Example of System Hierarchy
A system has both internal structure and context.
Product Subsystem System System System Assembly Component Component Subsystem
Assembly Assembly Assembly
Part 1
• Internal structure - System may contain, or be contained by, other systems. As Jonathan Swift eloquently said, some 300 years ago:
Big fleas have little fleas Upon their back to bite 'em And little fleas have lesser fleas And so ad infinitum.
• Context – Systems are characteristically interwoven with and affected by other systems. Frequently they only have value because of relationships to another system. Systems have boundaries and interfaces with other systems
Systems can have two types of interfaces physical or
functional
• Physical interfaces – We deal with physical interfaces every day. When we look at an object, we have become accustomed to constructing a hierarchy of physical interfaces within our mind's eye. What child did not learn that:-”the hipbone is connected to the thighbone, the thighbone is connected to the” … well you know the rest.
• Functional interfaces – These interfaces while sometimes less obvious are equally important as they deal with the interdependency of performance characteristics.
For example, the fan of a truck cooling system may be physically connected to the engine, but it is functionally connected to the radiator, through which it induces airflow.
The concept of physical and functional interfaces is central to the implementation of systems engineering.
SYSTEMS ENGINEERING PROCESS MODELS
A key strength of Systems Engineering is that it recognizes that all design problems are not the same. There are several ways to manage the design process, depending on the nature and complexity of the task to be performed. Each of three commonly used process models have different strengths:
• Waterfall Sequential Model • Spiral Sequence Model • V” Sequence Model
WATERFALL SEQUENTIAL MODEL
The waterfall model is perhaps the oldest and most commonly used model and is typically used for simple
systems. Deriving its name from the Gantt chart, it is characterized by a development process in which each task is performed sequentially, as shown in figure 2.
Figure 2, Waterfall Sequential Model
Although it is traditional to complete each task before moving on to the next one, it is not absolutely necessary. There is frequently enough information to begin a task before completing the preceding activity. If you advance a task too much however, you risk having to repeat it, in the light of improved information from a preceding task.
The Waterfall Sequential Model is generally suitable for simple products having clear and well defined requirements immediately available at the start of the project, and a single phase of prototype verification.
SPIRAL SEQUENCE MODEL
The spiral sequence model, figure 3, assumes an incomplete understanding of the customer’s requirements at the start of the project. It further assumes that several iterations are required through the design process before a product of sufficient maturity is ready for the customer. This type of model is ideally suited to a process using multiple phases of prototype to gain user feedback, before the final product is committed to production. The Spiral Sequence Model is used extensively in the computer software industry, and is somewhat similar to a traditional hardware based vehicle development process.
The spiral sequence model is generally slower than the V sequence model because it limits the degree of concurrency that is possible in the process. There are circumstances however, where a rapid prototype built from an imperfect set of requirements, may be faster than waiting for an exhaustive set of requirements, especially if analytical methods are not available for target setting or verification. Requirements Design/ Synthesis Verification Production
Figure 3, Spiral Sequence Model[5]
Unlike the other models, spiral sequence model does capture 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 with products which do not require large capital investment to make changes, i.e., computer software. It is similar to the automotive industry’s practice of model year changes, to introduce both major and minor product freshening.
“V” SEQUENCE MODEL
The V Sequence Model, figure 4, extends the waterfall model by subdividing the requirements and verification phases. This approach allows for a more complex system, consisting of end-items, sub-systems and components, to be studied in greater depth. Rearranging the model sequence into a “V”, clearly identifies the relationship between the “downstroke” requirement phase and the “upstroke” verification phase of the project.
The top-down decomposition of requirements and their associated targets, begins with the customers needs for the system, 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 hardware solution, starts with components, and integrates through the various assemblies and subsystems back to the full product.
Analytical tools are key to the successful implementation of this type of model. They enable the decomposed requirement targets to be validated and checked for compatibility before they are cascaded to the next level down. Similarly, test and analytical methods must exist to enable verification at the appropriate design level, instead of delaying verification until the complete system level.
Modified V Sequence Model
In a large complex system with many requirements and multiple interactions, it may not be possible or desirable to complete the requirements cascade process in a single pass. Requirements may need modification or reprioritization in a trade-off process designed to balance functional performance, robustness, affordability and value. Under these circumstances, an iterative loop may be embedded within each level of the requirement cascade contained in the “V” sequence model’s downstroke. This loop is typically comprised of analysis, synthesis and verification phases but omits the production phase. As shown in figure 5. Requirements Analysis Design / Synthesis Verification Production Prototype Prototype Prototype Production (Mk 1) Production (Mk 2) Customer Requirements TIME & DETAIL System Requirements Component Requirements Subsystem Requirements End Item Requirements Design / Synthesis Component Verification End Item Verification System Verification Subsystem Verification Customer Needs Product T es t re q u ir em en ts m ap w it h in t h e sa m e leve l TIME
Figure 5, Analysis, Synthesis and Verification Loop
The modified version of the V sequence process model, shown in figure 6, is ideally suited to automotive industry needs. It provides the mechanism to implement a strong customer focus in the design and development of new vehicles.
Figure 6, V Sequence Model with embedded Subsystem process
This is the process model used at Ford Motor Company and it represents an evolutionary rather than revolutionary change in the way engineers work. It facilitates:
• More up-front planning.
• Increased verification at the component and subsystem level.
• 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 into simplified and manageable pieces. Partitions may be based on any convenient grouping. Typical groupings include:
• Function • Technology • Physical location. • Product attribute
• Reusability and complexity
Whatever the choice of grouping the objective is to minimize the number of interfaces across the partition boundaries.
As discussed earlier there are two primary types of interfaces in every system: physical and functional. These interfaces can be sub-divided into two additional categories: external and internal.
• External interfaces are those that deal with the interaction between elements within a partition and those in any other partition, or any interaction with the external environment.
• Internal interfaces are those that exist between design elements within a partition.
Whether the interfaces occur at system, subsystem or component level, if the interface has different people or activities responsible for the interaction end-points, there is a potential for communications to breakdown. Partition
Requirements Analysis Design / Synthesis Verification R equ irem ents F ea sib ility D es ig n G ap s Des ign
Requirement Gap
Iterate for Compatibility Verification Requirements System Requirements Component Requirements Subsystem Requirements End Item Requirements Design / Synthesis Component Verification End Item Verification System Verification Subsystem Verification Custommer Needs Product Te s t Re qui re m e nt s Ma p W it h in Th e S a m e Le v e l
boundaries are therefore carefully selected to minimize the number of requirements with cross-partition interfaces. Having partitioned the system into a number of semi-autonomous system or subsystems, each is assigned its own design specification. A Program Development Team (PDT) is then given the responsibility to deliver all of the requirements contained within the specification.
When cross-partition interfaces occur, a formal mechanism for managing the “requirement end points” is essential. The responsibilities may be divided but they are not shared. The notation “required of” and “required by” is often used to eliminate 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 an engine mounted cooling fan is “required of” the cooling design team and “required by” the accessory drive design team, who would set the target at a level compatible with the mounting system.
Vehicle partitioning, based on physical architecture has been found to give the fewest external interfaces. It is therefore 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 of levels employed depends on the complexity of the physical system. The lowest level is determined by the level where you can make the decision to make, buy, or reuse an existing element.
Each element within the hierarchical structure has its own design specification. This specification should contain: • A non-technical description of the element
• A non-technical statement of element’s function • A schematic diagram of the element
• A complete list of the functional requirements and associated targets for that element.
• A description of the methodology to be used to verify the target has been met.
• An interface specification, that describes how that element interacts with other elements
• A history of document revisions
Partitioning based on physical architecture alone, may be insufficient in large complex systems, as there are certain customer requirements that do not map well into a hardware-based specification.
Figure 7, Example Specification Tree
For example, if a customer states - “I want the highest
payload for a truck in this class”. It is not clear who
would be responsible for delivering that improvement to the customer, because many of the vehicle’s systems could be affected.
Clearly, if the “voice of the customer” is to be one of the primary drivers of product design, we need a method and process that can map these customer requirements, from the functional domain into the physical domain.
One method of doing this is to group similar customer requirements together into customer attributes.
For example, commonly recognized customer attributes might include the following:
• Cost of Ownership • Customer Life Cycle • Emissions Vehicle Body Cooling System Climate Control Chassis Powertrain Electrical Temperature Contol Subsystem Heat Dissipation Subsystem Internal Flow Subsystem Heater Subsystem Pressure Control Subsystem Coolant Fill, Drain &
Deaeration Subsystem Containment & Sealing Subsystem External Flow Subsystem Hoses Clamps Rigid Pipes Airflow Subsystem
• Interior Comfort
• Noise, Vibration & Harshness • Package & Ergonomics • Performance & Economy • Safety
• Security
• Styling & Appearance • Vehicle Dynamics
Those who have responsibility fore delivering these customer attributes would have following responsibility: • Gathering customer, corporate and external wants.
(Requirements analysis)
• Converting those wants into functional requirements and targets. (Functional analysis)
• Developing those requirements into a specification for the overall product.
DESIGN MANAGEMENT
With so many empowered teams, we need a method for managing the design process. Typically, this is achieved by the use of a matrix management structure of the type shown in figure 8. Program Integration Teams have lead responsibility for product related decisions (function), and the Program Development Teams, have lead responsibility for technology related decisions (hardware).
Figure 8, Generic matrix organization
REQUIREMENTS ANALYSIS Terms & Definitions
Requirement: - “A statement identifying a capability, physical characteristic, or quality factor that bounds a product or process need.” [6] Goal: - A desired capability, characteristic or quality
factor
Target: - A quantitative measure of the functional performance necessary to satisfy a requirement
Tracability: - The ability to track a cascaded requirement back to its original source
The Requirements Analysis process establishes the overall objectives of the system, through compiling and analyzing requirements that define:
• How well the product must perform in quantitative terms
• 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 the customer, rather than a technical or scientific language. Each requirement has an associated quantitative measure of desired performance, including where appropriate, an assessment of the customer’s expectations for performance at high mileage/time-in-service. Early in the design process, these measures may be subjective, (e.g. 1-10 scale) or relative, (best-in-class). The measures must be quantitative and never qualitative (e.g. improve fuel economy, reduce noise).
These high level requirements usually come from one of three basic sources:
• Customer expectations • Project / corporate constraints • External constraints Product Developement Team Product Developement Team Product Developement Team Product Developement Team T ec h n o lo g y L ea d er sh ip Product Integration Team Product Integration Team Product Integration Team Product Integration Team
CUSTOMER EXPECTATIONS Customer expectations include:
• What the customer wants to be able to do with the vehicle.
• How well each function the vehicle performs must be accomplished
• Details of the natural and induced environment in which the vehicle will be operated.
• Constraints that the customer will be placing on the vehicle:
• 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 divided into three categories of wants:
• Basic wants • Performance wants
• Features that cause excitement
The level to which these requirements are achieved, will determine the degree of satisfaction that the customer will have with the product.
Basic Wants are typically unspoken by the customer. They
represent the minimum expected for the vehicle. Successful delivery of these requirements will, at best produce a neutral response from the customer, while failure to deliver will cause dissatisfaction. These requirements are generally regarded as the “price of admission” to the marketplace
Performance Wants are spoken wants. They are desirable
performance features that the customer is willing to pay more money to obtain. Better product performance will yield a greater level of customer satisfaction.
Excitement Wants surprise and delight the customer when
they are first introduced to a new product. They can be used in advertisements to distinguish the product from its competitors. Customers do not ask for things that they have never experienced, so these requirements are unspoken. The presence of these features may increase customer satisfaction, but their absence will have no impact.
A useful tool for understanding and measuring customer appeal 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 often become so readily expected by the customer, that they cease to be excitement and performance wants and become basic wants, shown in Figure 10.
Examples of performance wants that have over time become basic wants, include:
• Seat belts • Air-bags
• Anti-theft immobilization devices • Intermittent screen wipers
Similarly, when first introduced the cup holder was a surprise and delight feature. Today, we have become so used to their presence that a vehicle without one is a source of annoyance.
Figure 10, The effect of rising customer expectations
Completely Satisfied Completely Dissatisfied Did Not Achieve Fully Achieved Perf orman ce (S poke n wan ts) Basic Want
(Unspoken unless violated) Excitement
(Unspoken Want)
Excitement
Performance
PROJECT AND CORPORATE CONSTRAINTS
Project and corporate constraints should include any internal requirements that will impact or limit potential design solutions. Project and corporate constraints may include:
• 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 or limit 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 or absolute priority using at least one of the classifications shown in table 1. These priorities are used for subsequent target trade studies.
For example:
• Meeting the U.S Government emission standards is a given. It is non-negotiable
• A fuel economy requirement might state that the performance must be at least 8.2 MPG, but also, want 8.5 MPG for highway driving.
While the “must” is a requirement as it defines the minimum competitive position of the product. (In this context “minimum” may not be simply a neutral customer response, the image of the product may dictate that the “minimum” may in fact be “best-in-class”). The “want” by
contrast is a goal which if met, will increase customer satisfaction.
Table 1: Prioritization of wants
REQUIREMENTS ARE CONSTRAINTS
All requirements place constraints on the system. As constraints they have the potential to limit design alternatives and adversely impact cost, quality, function and weight. Therefore, it is essential to validate each requirement to ensure that it adds value to the product, before accepting it as part of the product’s baseline requirements. It is not necessary to conduct verification* at this stage, as we are working in the customer domain rather than the engineering domain. A simple check for discrepancies and conflicts will be adequate if the list of requirement is complete.
Look for discrepancies and conflicts in the wording of the requirement and the performance objective. Do not attempt to resolve any conflict, but simply prioritize the importance of any apparently conflicting requirements. The resolution of conflict only begins after technical engineering targets are assigned and we start to select design concepts, determine value and affordability.
After validation the requirements are added to the
Validated Requirements Baseline document for the
product. All subsequent steps in the design process use the Validated Requirements Baseline as the authoritative source in any requirement conflict, or audit of functional requirement traceability.
Classification: Description:
Given A mandatory requirement Must A requirement that defines the
minimum competitiveness Want A desirable requirement that
potentially differentiates the vehicle from others
Not Required The presence or absence of this requirement has no impact on the vehicle
Not Wanted The presence of this requirement detracts from the vehicle
*. 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.
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 Validated Requirements Baseline from the “customer domain” to the “engineering domain” (figure 11). In the engineering domain they are converted to detailed technical functional requirements. Working on the principle that “form-follows-function”, these requirements are generic and should state
what is needed, rather than how to accomplish it.
The process of translating the voice of the customer uses top-down Functional Decomposition, which takes each requirement in the Validated Requirements Baseline and asks the question: “What function is needed to satisfy this
requirement?” This question may be asked several times to
separate multiple engineering functions contained within a single customer requirement.
Each engineering function is examined to determine what factors directly influence the successful delivery of that requirement. These factors can be divided into two categories; control factors and noise factors.
Control factors are those parameters of a design concept that can be adjusted to optimize the function of that design. Noise factors are the sources of variability that degrade the functional performance of the design.
As each functional requirement is identified, the subjective and relative performance targets from the Validated Requirements Baseline are converted into objective and absolute targets for performance and reliability. This conversion may not be possible in all cases due to a lack of
specific knowledge at this point in time. (This process of target setting will be covered in detail later in this part).
REQUIREMENT VALIDATION
Before each functional requirement is accepted, it is validated using the following fundamental principles to confirm that the requirement is properly defined[8][9][10]. A requirement must be:
Necessary: Deletion of the requirement should create a deficiency that cannot be fulfilled by other capabilities of the product.
Verifiable: The target associated with the requirements should be quantified in a manner that can be verified by inspection, analysis, demonstration or test.
Attainable: The requirement should be capable of being achieved by one or more design concept that has been proven viable, within the constraints of the project.
Concise: The requirement statement should contain only one requirement.
Complete: The requirement should not need further elaboration.
Consistent: A requirement should not contradict or duplicate another requirement.
Unambiguous: The requirement should not be open to alternative interpretation.
Implementation Free: The requirement should state WHAT is needed, not HOW it is to be accomplished. Standard Construct: Requirements should used standard terminology and avoid subjective or relative expressions.
For example, a poorly written requirement might state:
The requirement is poor for a number of reasons:
• The word minimum is ambiguous and cannot be verified. The expression “not less than” used in conjunction with a number would remove the ambiguity.
• The requirement is not implementation free, as it assumes that a “thermo-viscous fan clutch” is the chosen method for driving the fan.
CUSTOMER DOMAIN Voice of the Customer Signal Response Noise Controls ENGINEERING DOMAIN Customer Intent Perceived Results System
(made up from sub-systems)
“Cycling of the thermo-viscous fan clutch should be kept to a minimum”
• The requirement is incomplete as it not clear what represents “cycling”. Does it mean moving from fully disengaged, to fully engaged, and then back to fully disengaged, or does it mean any reversal in the state of clutch engagement?
• The word “should”, has a special meaning in the standard nomenclature of specification writing and is used to denote a goal rather than a requirement. The word “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 to determine if deletion of the requirement will have any impact on the product.
In contrast, a well-written requirement might state:
Once all the functional requirements at the system-level have been identified, they are documented in a system-level functional specification. (In a large complex system it may be necessary to sub-divide the requirements into more manageable groupings based on either a physical or functional partitioning of the system, as described earlier).
FUNCTIONAL INTERFACES
The next step in the process is to establish the functional interfaces between the requirements and document them on an interface diagram, which is added to functional specification. Each requirement is examined for any interaction that it might have with other requirements. Relationships are assigned one of the following classifications:
Independent: The functions are not linked in any way. (E.g. coolant temperature is independent of door closing effort).
Dependent: The functions are linked such that if one is changed, the other is automatically changed. (E.g. Waterpump speed is dependent on engine speed).
Correlated: The functions are linked such that if one changes, a change in the other is implied. (E.g Radiator heat dissipation is correlated to fan airflow rate).
Following validation, a Functional or Concept FMEA (Failure Mode Effect Analysis) is performed on each requirement to identify the consequences of not meeting the functional requirement. Standard FMEA techniques are used to determine the severity of risk associated with each potential failure mode. A design verification plan is
developed that will be used later in the product verification phase of the design process to manage failure risk. NOTE: It is important to recognize that at this point in the process we are validating failure to meet functional targets and not the mechanical failure modes of a specific design solution.
After the system-level requirements are established the process is repeated. Functional Decomposition is applied to each system level functional requirement, to obtain the subsystem functional requirements. This process is recursively applied until all of the requirements necessary to either make or buy the design have been identified. (The depth of this process depends on each individual design element and could be anything from a complete system to an individual part.)
The process of cascading requirements and targets from the top-down is relatively straightforward, if the product being designed begins with a clean sheet of paper. Realistically, most new products are refinements of existing products or make use of existing design elements.
REENGINEERED PRODUCTS
In a reengineered product, the idealized top-down approach must be modified. Each element of the product that is to be reused already has a predetermined functional performance and set of interface constraints. The approach varies for reused design elements:
• If it is a component that is to be reused, then the cascade will be from the bottom-up
• If it is a sub-system, then the cascade will most likely be middle-out, with the cascade being performed in both directions, as shown in figure 12.
The desire to reuse an existing design element may occur for a number of reasons: capital investment, product timing, manufacturing complexity etc. Elements should not be reused before demonstrating that they can satisfy the requirements contained in the Validated Requirements
Baseline.
Conduct a top-down Functional Decomposition of the high-level requirements to identify those which impact the element to be reused. Divide these requirements into two categories, those that impact primary functions and those that create secondary constraints, such as unwanted side effects and potential failure modes, as shown in the figure 13.
For example, the primary function of a cooling fan is to move air. Secondary constraints might include aerodynamic noise, power consumption, dynamic imbalance etc.
“When tested in accordance with key life test procedure KLT-8K616, the fan drive mechanism shall, at a 95% confidence level, have a B5 life of not less than 250k miles.”
Figure 12, Requirements Cascade
A capability study, (ignoring secondary effects), is performed on the design element to determine if reuse is feasible. If design control factors can be adjusted to give a functional performance greater than that required by the cascaded functional target, then the element has the potential to be reused and a more extensive study is warranted. If, however, adjusting the control factors cannot yield an output that satisfies the functional target, (even in the absence of constraints), then either the customer-level assumption must be changed, or the element cannot be reused.
Figure 13, P-Diagram showing side effects and failure modes
If the primary functional targets can be achieved, the impact of the secondary effects is investigated. This
process starts with identification of design specific failure modes for the reused element. Using historical reliability data, a design Failure Mode Analysis (FMA) is performed to identify existing failure modes. When the FMA is complete, a potential FMEA is performed, to identify any new design failure modes. (The fact that the design functioned satisfactorily in the past does not mean that with different boundary conditions, it will continue to do so in the future). As each failure mode is identified it is translated into a functional requirement and added to the high-level requirements that were cascaded by Functional Decomposition.
These functional requirements are fed into a bottom-up
Functional Composition process in which the question:
“What is the importance of this sub-function to the function
of the system?” is repeatedly asked, until all of the related
higher-level design functions are identified. Additional requirements and functional dependencies not previously identified during Functional Decomposition are added to the appropriate interface diagram and functional specification.
Primary functional targets are assigned to the reused element, at the minimum level necessary to satisfy the system-level functional objectives. Targets for dependent or correlated secondary design function, are calculated and added to the various functional specifications. If the imposition of these secondary functional targets does not violate 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 solution has been reached. Greater value may still be achieved by adopting a new design.
For example, the reuse of an existing radiator might require an increase in fan airflow, which is achieved by increasing the fan’s speed of rotation. This increase, however, might also generate so much aerodynamic noise that extra sound insulation is required. The incremental cost associated with the extra insulation might be greater than that saved by reuse of the radiator.
This process of determining the value of reusing existing design elements is a key part of the trade-off process, which is central to the development of robust product targets.
TARGET SETTING
TARGET SETTING BACKGROUND
Before we discuss the target setting process in detail we will first look at some of the important concepts that influence the way targets are set.
System Requirements Component Requirements Assembly Requirements Subsystem Requirements Design / Synthesis Custommer Needs Middle-out Top-down Bottom-up Function
Signal Primary Function
Side effects Failure modes Noise Factors Secondary Constraints Control Factors
To obtain a robust design that satisfies the customer’s requirements we must take into consideration the effect of variability when setting the target level for a functional requirement.
This variability generally referred to as noise, can be split into 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 the manufacturing processes used to make and assemble the product. Problems related to this type of noise are typically seen early in the product life cycle and are frequently referred to as “infant mortality” failures. Examples of unit-to-unit variability include:
• Raw and processed material variations due to thickness, hardness, chemical composition etc.
• Dimensional variations due to forming or machining operations.
• Fabrication or assembly variations due to weld quality/ location, bolt torque etc.
• Product surface finish. • Product handling damage.
Units that meet the minimum acceptable performance suffer from a loss of function that may cause subsequent failure in the presence of other noise sources.
Environmental noise is generated by sources that are external to the product. Sources of this type of noise include the following:
• Climatic variations (temperature, humidity, rain, wind etc.)
• 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. When applied to units with marginal functional performance, it is responsible for the apparently “random” failures that occur throughout the product’s life.
Deterioration noise comes from within the product and is associated with functional deterioration of the product due to 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 functional variability due to noise, can be combined to produce a graph commonly referred to as the “bathtub curve”, (figure 14).
Figure 14, Reliability “bathtub curve”
Customer usage variation is due to the ways the customer may use the product.
• Accidental misuse of the product. • Intentional misuse of the product
It is important for the designer to remember that the customer will always find ways to use the vehicle that were never intended, when the specification was written.
ON-TARGET ENGINEERING
Conformance to specification has traditionally been the primary method of assessing the quality of a product. Anything within specification is viewed as good, while anything outside specification is bad. In this approach, variation within the specification is both acceptable and unimportant.
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 critical characteristic to be controlled within a range m ± ∆0 which
Time in service In s ta n te o u s F a il u re R a te Environmental
Unit to Unit Deterioration
Infant
mortality Wear-out
Limit of useful life
is shown as an Upper and Lower Specification Limit, (USL / LSL)
Sample “A” represents the initial random population sample taken from production. On examination, it was found that variability was causing some samples to fall outside the specification limits generating a process Capability Index, Cpk of less than 1. Production was halted and the equipment adjusted.
Sample “B” represents the population distribution after adjustment. The sample indicates that variability was halved and process capability reestablished with a Cpk index of 1.4.
Figure 15, Variation of Functional Performance for two production samples
Viewed from a manufacturing perspective, the equipment setup used to produce sample “B” delivers significantly better quality, since all units produced meet specification. However, from the customer’s perspective, sample “A” has more units with on-target performance and would have produced greater customer satisfaction.
This apparent contradiction, where “worse” quality produces greater overall customer satisfaction, comes about because “within-specification” and “on-target” are not the same thing.
The difference between two individual samples, one just inside specification and one just outside specification, may be very small and functionally insignificant. Whereas, the
difference between two samples, one on-target and one just inside specification, may be very large and highly significant.
The traditional view of quality, where samples are viewed as either pass or fail, does not recognize that in most cases, loss of functional performance is a continuum, rather than a discrete event.
It is important to recognize that two questions need to be answered when setting the targets and tolerances for a design:
-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 decision not to purchase another product). Dr. Genichi Taguchi is generally acknowledged as the first to develop methodology for evaluating this financial impact, which he quantified 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 to society after being shipped, other than any loss caused by its 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 prior to shipment is deliberately excluded from this view of quality, as they represent a cost to the manufacturer, but not a quality loss.
From his studies, Taguchi concluded that the loss of quality for a product, due to deviation from target, could be approximated by a function, which increased quadratically with deviation from target. The approach was found applicable to the four types of targets listed below:
Nominal is best: The target has an optimal value ± a tolerance. Quality Loss Function is proportional to the magnitude of the deviation. (E.g. the alignment of a rubber isolator)
Smaller is better: The target response is ideally equal to zero, 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.)
F re qu e n c e LSL USL Nominal Target Sample A Sample B Functional Performance m + ∆∆∆∆0000 m m - ∆∆∆∆0000
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 are expressed only as a lower limit. (E.g. weld strength, corrosion resistance, light bulb life, etc.)
Asymmetric Nominal is Best: The target has an optimal value but is subject to asymmetric tolerances. Loss of function varies with the direction of deviation. (E.g. hose joint clearance, fan tip clearance, etc.)
Figure 16 shows a comparison between the Quadratic Quality Loss Function and a traditional Loss Function for a “nominal-is-best” function.
Expressed mathematically the Quality Loss Function is intended to represent the loss experienced by an average customer, (rather than a specific customer), and is defined as: (1) (2) Where: y = measured response m = target value
k = Quality Loss Coefficient (an economic factor) A = Cost to society if tolerance is exceeded D0 = Customer functional tolerance
Customer Functional Tolerance ∆0, is the point at which the product either fails, or 50% of the customers would decide that the functional performance was unacceptable and take an economically measurable action.
The cost of this action, typically a repair, should include consideration of all related costs, some of which are listed below:
• The cost of parts, labor and special tooling needed to make the repair, whether it is repaired under warranty, or at the customer’s expense.
• The cost associated with loss of use, including lost earnings and/or the hire of a replacement product. • The cost of transporting the product to the point of
repair.
• 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 obtain accurate data for either the Customer Functional Tolerance or the Cost to Society. However, exact data is not required and it should be possible to make approximations that are close enough to evaluate the relative merits of different targets and design concepts.
Cost, is not the only consideration in developing a mathematical relationship to express a value for loss of function. Safety and security issues may also be involved. Severity of Failure: Not all failures have a benign outcome, so it is necessary to consider the severity of failure when setting functional targets. The severity of a failure 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 the customer'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 on the target directly, but may influence it indirectly through the following:
• 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 E q u al ly B ad E q u al ly B ad Specification Limits 0 0 Loss Loss Best Target Target Poor Poor Loss L y, ( ) = k y m( – )2 k A ∆02 ---=
Cost: When using cost to calculate the value associated with a functional requirement, it is important to use the total cost of design. Total cost has three elements; Unit Manufacturing Cost, Life Cycle Cost and Quality Loss Cost: Unit Manufacturing Cost: A combination of all of the cost related to manufacturing the design element and includes variable cost, fixed cost, tooling costs and the costs associated with reworking or scrapping defective parts Life Cycle Cost: The summation of costs related to operating the product that are directly attributable to the design element under investigation. In addition to the cost of repairs and routine maintenance, it should also include the cost of energy required to operate the design
Quality Loss Cost: the cost associated with the Quality Loss Function
Figure 17, Target Setting Process
TARGET SETTING PROCESS
After identifying all of the functional requirements for the entire system, we have to decide on the performance and importance in relative and absolute terms for each of the requirements. (Even in a very simple system, it is unreasonable to expect that every requirement could be fully satisfied). Target setting is by definition an iterative process, and involves trade-off decisions at every level of the product.
Figure 17 shows an over view of the target setting process beginning with a review of the Validated Requirements Baseline.
Develop Product Strategy
We develop an outline Product Strategy using the quantitative measure of desired performance, and the requirement priority, that was assigned by the customer during the Requirements Analysis phase. The overall product requirements are prioritized, using the previously defined 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 product that most closely matches the product to be developed. For reengineered products, the product being replace would most likely be chosen. while the closest available product should 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. This benchmark phase should also include a review of all significant technologies on the competitor vehicles, or available internally or from suppliers.
After gathering the information from the previous three steps, the initial process of target setting can begin.
Target Ranges
At the early stages of the design process, targets are not expressed as “point” targets but as a “ranges” in which the target is bounded on at least one side, by a value that is traceable back to the voice of the customer, through the Validated Requirements Baseline document. This range is
Validated Requirements Baseline Develop Product Strategy Select Comparitor Product Review Bechmark & Technology Bookshelf Set Futured Functional Targets Compare product capabilities
Define Gaps Select Design Concepts Trade-off Studies
Modify Product Strategy Set Product
Target Ranges
Classification: Description:
Given A mandatory requirement Must A requirement that defines the
minimum competitiveness Want A desirable requirement that
potentially differentiates the vehicle from others
Not Required The presence or absence of this requirement has no impact on the vehicle
Not Wanted The presence of this requirement detracts from the vehicle
generally created by the need to keep risk low, in the face of uncertain technological capability.
Using the Validated Requirements Baseline, competitive benchmarking and comparator product data, target ranges are established for each of the customer requirements.
For example:
• All functional requirements that are traceable back to a requirement designated as a given are assigned a non-negotiable target (Minimum or maximum value of the target range is set at the level specified in the Validated Requirements Baseline)
• All functional requirements that are traceable back to a requirement designated as a must are assigned a target established through benchmarking to be competitive (This target may include a margin that accounts for any shift in the competitive position, which may take place before the product is launched)
Define Gaps
System analysis is performed on carry-over, new or alternative design concepts throughout the target setting process to confirm the technical feasibility of satisfying the required target. Gaps in the required performance are noted, 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 is performed to provide data that can be used in cross-functional optimization studies.
Where
(3)
And
Cost = A universal currency of negotiation (e.g. $. weight, quality etc.) Trade-off Studies
Trade-off optimization studies can range from simple Pareto charts, through to a multi-dimensional simulation, depending on the magnitude and complexity of the functional gaps.
If all of the gaps cannot be closed, even when a reasonable amount of “stretch” is applied to the target then it may be necessary to go back and modify the initial Product Strategy.
When all these steps are completed, then the product will have a set of “compatible” targets at the system level.
Conclusion
The target setting process is repeated continuously, progressively narrowing the safety margins, until the ranges become point targets and the point targets become firm product objectives. This process is repeated at each level of the design cascade.
Value Function
Cost
---=
PART 2
ENGINE COOLING DESIGN FROM A
SYSTEMS ENGINEERING PERSPECTIVE
INTRODUCTION
In this section, we will discuss the design of vehicle cooling systems in detail. Requirements will be developed using System Engineering principles to show how a systemic approach 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 numerous subsystems, assemblies and components the number of functional requirements is considerable. Within Ford we have formally identified over 150 cooling requirements at or above subsystem level, never mind all of the individual component requirements. For practical purposes not all of these will be discussed in this paper.
What we hope to do is construct a framework that will encourage the reader to use their experience and imagination to develop functional requirements that match their own needs.
In this paper we will not be discussing Ford’s detail design targets. While some of that information is confidential, the main reason for excluding the detail is that targets are product and market specific, and may only serve to mislead the reader. Generalised or “rule-of-thumb” targets should always be critically questioned, as they are often non-value added constraints that simply drive cost up.
While requirements are often generic in nature, targets must be developed to match the customer expectations for that specific product and must be set at a level that adds value to the product.
In Part 1 of this paper, we made a particular point of explaining what makes a good or bad requirement. In this part of the paper however, we have not necessarily followed our own “rules”. In such cases we leave the reader to decide how the requirement should be worded.
Although this paper is not intended to be a definitive or comprehensive design guide for the cooling system, alternative design concepts will be discussed. Where appropriate, the underlying principles will be explained so
that the reader may better understand the requirement being discussed.
For each major functional requirement, a Parameter Diagram has been constructed to help the reader understand the relationship between the following:
-• The Ideal Function of the design element, i.e. the
requirement and its associated target.
• Control Factors, which can be used to adjust the
element’s functional performance. (These in turn, become the functional requirements for the next level down).
• The Noise Factors, which introduce uncontrollable variability and potential failure modes, into the elements functional performance. (If the signal/noise ratio becomes too great, then it may be necessary change the design and make the noise factor a control factor).
• Side Effects, which are secondary and unintended
outputs of the design element. These frequently create undesirable external interfaces to the system and place constraints on the tunable range of the control factors. • Potential Failure Modes, which place constraints on the
tunable range of the control factors and introduce additional functional requirements.
In general the failure modes identified and discussed in this paper are “common cause” failures, inherent to the design concepts or requirement targets, rather than “special cause” failures that result from defects in an individual component.
VEHICLE LEVEL REQUIREMENTS
OBJECTIVEThe purpose of the vehicle cooling system is to provide reliable powertrain operation under all vehicle operating conditions.
In this section we will discuss the relationship of the cooling system 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 text they are boxed with double lines like this.
To distinguish GOALS from the text they are boxed with single lines like this.