Specifying thermal components systematically

Figure 1. A system scheme for temperature control.

• Work load — the fluid, to be heated or cooled (e.g., a liquid or gas);
• Heat transfer medium — the materials and environment that must transfer heat to and from the work load (e.g., a vessel or pipeline);
• Heat/cool source — a device that changes the input power source into heating/cooling energy (e.g., a band heater or chiller unit);
• Process temperature sensor — an instrument that indicates the temperature of the work load (e.g., a thermocouple or infrared pyrometer);
• Process temperature control — manages the temperature of the work load (e.g., a thermostat or electronic control); and
• Power control — connects/disconnects input power to the heat/cool source as determined by the process temperature control (e.g., a thermostat or solid-state relay).

Some thermal systems require additional safeguards. If the system or process is not “inherently safe” (meaning it is capable of posing a hazard to people, equipment or the environment in the event of a malfunction), good thermal system design must  include the following secondary components, also shown in Figure 1:

• Limit temperature sensor — provides a redundant or back-up indication of the temperature of the work load, the temperature of the heat/cool source, or both;
• Limit temperature control — prevents the temperature of the work load from reaching a hazardous level; and
• Safety contactor — an independent means of removing or disconnecting input power from the heat/cool source in the event a hazardous condition occurs.

When schedules are short, design engineers frequently dive right into the details. A specification of a particular component is generated with little effort spent understanding the relationship between other parts. Just as it is the interplay of ingredients that gives “richness” to the flavor of a great bowl of chili, power dissipation across a heater surface is just one ingredient that adds up to temperature uniformity in a thermal system. A heat/cool source can be designed such that the system attribute of temperature uniformity emerges. To do so requires that the heat/cool source be combined with the other system components in a very specific and controlled manner. Defining the relationship of system components such that the desired system performance emerges is the primary challenge when describing a thermal system.

Describing the system

Many different methods have been developed for describing a system or defining system relationships. The important aspects of the most effective approaches are summarized in Figure 2.

Figure 2. Describing the system.

System development should start with a clear statement of need — from the user’s perspective. In the case of a bowl of chili, the corresponding statement of need might be “I want to win the chili cook-off championship.” More relevant to thermal systems, this statement of need might be “I want to maintain the temperature of the reactant flowing in my stainless steel gas delivery line between 170°C and 180°C to prevent it from condensing or degrading.”

Once the need has been clearly established, begin the system description. This document defines how the system will fulfill the need, its behavior: “what it does.” For our cook-off need, one characteristic of behavior is taste — in this case award-winning. For our gas line heating need, one characteristic of behavior is temperature control range — in this case 175 + 5°C. Often behavior is referred to as function and is defined in a functional specification describing the following:

• Mission — objectives to be fulfilled, information to be collected or received, plan or process to be followed and degree of cooperation with others in the environment;
• Viability — the extent the system is able to maintain a separate existence in the environment; and
• Resources — what is required for pursuit of mission and maintenance of viability.

Next, it’s helpful to describe the system’s structure — specifically, how it’s built and how each component interconnects with others. That chili needs to be competition chili, not eatin’ chili. It’s going to need good fresh spices, and lots of them. Some good lean beef cut into cubes will be a good host for the spices. Maybe adding some fresh peppers instead of dried peppers will improve the flavor — let’s skip the beans to avoid distractions. Yes, Texas Style is potentially a good structural solution for our chili. But let’s not forget about that gas delivery line. The 175 + 5°C temperature control range is a very tight tolerance and is going to require knowledge of the flow rates involved and consideration of the specific physical geometry of the line.

A potentially good structural solution is to heat the steel tubing by conduction using insulated heater jackets with integrated PIDcontrols. Heater jackets can be custom-fitted to the tubing. Heat can be applied in zones accounting for the different losses that result from the changing line geometry and process conditions. Often, structure is referred to as form and is added to a functional specification to create a complete system development specification. However, it’s important to avoid defining a system’s structure until its behavior is well defined. Quite literally, form should follow function to arrive at the best solution. For a structure definition to be complete, it should address the following:

• Configuration — identification of each physical element that makes up the system and its position, properties, materials and characteristics;
• Context — the environment acting on the system including what holds it together and works to break it apart; and
• Capability — the level of achievement that can be expected based on internal features.

While a clear definition of behavior and structure represents a complete system description, it isn’t necessarily the best available combination of behavior and structure. To achieve the best solution, effectiveness should be defined. Effectiveness is the measure of how well the system satisfies the statement of need. Without defined measures of effectiveness, there’s no specific way to determine whether one particular system description is better than another, or even if a given system description is feasible. This is sometimes referred to as “fit.” What makes one chili recipe award winning over another? When you said lots of spices, did you mean a-few-beads-of-sweat-on-the-forehead spicy, or tongue-curling-inferno spicy? As for that gas delivery line, over what range of gas flow rates and external ambient conditions must the temperature range be maintained? Did that temperature range need to be maintained while changing flow rates? A good definition of “fit” or effectiveness measures for a system will address three areas:

1. Performance — the minimum acceptable limits for characteristics such as stability, responsiveness and uniformity;
2. Availability (of performance) — the ability of the system to continue to perform under normal conditions; and
3. Survivability — the ability of the system to restore performance following abnormal conditions.

A variety of tools are available to assist the system engineer in understanding and defining effectiveness. These tools are often called requirement management software. Some examples include: cost/benefit analysis, quality function deployment (QFD), production, preparation, process (3P) and object modeling/simulation. Regardless of the specific method, once an effectiveness filter is in place, optimization can begin.

This process defines which behavior/structure combination best fits the system and meets the need statement. Is the richness of flavor in our chili better achieved with cascabel peppers or guajillo peppers? Should we use prepared powders or boil and puree the peppers ourselves? In striving to achieve the requirements for temperature control with the gas line, the degree of difficulty (and cost) associated with achieving the required performance with a given construction will be evaluated.

Optimization means commitment to one of many alternatives. One could be that a flexible heater jacket can be controlled to the required temperature range. Or, it could be revealed that a different method (structure) should be considered such as model-based control. Perhaps convectively heating the gas delivery line by surrounding it with a heated box to create a mini environment is an alternative. Maybe controlling the internal temperature of the equipment or room the line is mounted in is the best choice — that is presuming that doesn’t create a problem for other items in the same area.

Through optimization, a clear description of the critical characteristics of the system will emerge. If the process of describing the system, defining effectiveness and optimization are successful, the emergent properties that result should closely align with the original statement of need.

Stating requirements

Engineers make detailed design decisions based on their understanding of the requirements driving the design — whether these requirements are very well defined or even written down. Often, the characteristics of a hastily chosen component can end up constraining an entire system, with very unsatisfactory results. In fact, leading providers of optimization tools report that as much as 70% of product development projects fail because of bad requirements. While the process of describing the system, defining effectiveness and optimization is intended to provide a more complete basis for setting and understanding requirements, it can still muddy the important distinction between requirements and design implementation.

Any organization or individual involved in the process of transforming need into product will likely have an opinion or definition of what a “requirement.” For the purpose of this discussion, here is a relatively short one: If it mandates that something must be accomplished, transformed, produced, or provided, it is a requirement.

The key here is to emphasize the what (need) and avoid the how (implementation). This distinction is a common problem when trying to state clear requirements. Continuing with our heated gas delivery line example, a specification was written that included the requirement: Gas lines must be wrapped at 100% coverage of heater, insulation and outer tape over insulation to minimize heat losses and improve temperature uniformity.

This statement includes both a what (minimize heat losses and improve temperature uniformity) and a how (lines to be wrapped at 100% coverage). The 100% wrapping of the lines is a design implementation. Requirement documents shouldn’t state implementation. Stating implementation may force a design solution that isn’t really intended, may be unnecessary or, even worse; you may actually interfere with the desired result. In this case, if the heat loss and temperature uniformity cannot be achieved another more effective way, 100% wrapping will be the design solution selected, so it doesn’t need to be stated. The best way to avoid the implementation trap when writing requirements is to ask yourself why you need the requirement. Applying the why question to our gas line, the real requirement was revealed: Provide the capability to maintain the gas temperature within +5°C of set-point.
Maintain a touch-safe temperature on external surfaces.

Studying this requirement further proved a useful exercise. Asking why revealed an additional very important requirement that might otherwise have remained unstated — the need for the solution to be thermally touch-safe. At each level of development (particularly in a complex system) the problem of “what” versus “how” will occur. Our process began with statements of user need about a chili cook-off and about keeping a gas at the right temperature. This top level “what” allows “how” statements of behavior, structure and effectiveness to be derived, which in turn become the “what” for the next level of development and so on down to the component, part or material level.

So the logical question becomes, “How do I know when the transition from requirement to design implementation occurs?” This is a problem particularly in software development Most programmers view the whole process from customer need to finished code as a requirements process — not as a transition from requirement to design to product. The same problem occurs in hardware development as the effort of developing requirements progresses to lower and lower levels. Ultimately the question: “Is this a requirement or a design solution?” cannot be avoided. Unfortunately there is no black and white answer. Fortunately there are a couple of guidelines that can help:

1. If there are no reasonable alternatives that can be considered, other than the one stated it’s highly likely the statement is actually a design solution, not a requirement. In effect, it’s forcing a design solution as discussed above. If this is the case, it should be removed from the requirements document and be included in the drawing package or other detailed design documentation.
2. Sometimes, there is a lack of reasonable alternatives. When the one stated isn’t a feasible design solution without further customer interaction or external input, it should be treated as a requirement. In this case, its reasonableness as a design solution depends upon understanding of the implementation context, so it cannot stand alone as a true design solution.

Additional caveats

While stating design implementation instead of requirements may be a leading cause of “bad requirements,” there are a few other common problem areas to watch out for:

1. Bad assumptions: these result from either unknown information or information that simply does not exist. Developing a complete system description is one of the best ways to resolve this, but capturing project-related information such as the names of the stakeholders, the budget, and schedule and who is responsible for accomplishing the project are also key. If you don’t know all of this, indicate what you don’t know. Make sure this information is available to everybody who is defining requirements for the project. To safeguard against nonexistent information, make sure you write down any assumptions at the same time that you write down a requirement (similar to stating what you don’t know). It is often helpful to create a requirements matrix using a simple spreadsheet to list each requirement and its assumptions. Categorizing the source of the requirement can also be useful:

• Customer — needs stated on behalf of the end-user;
• Regulatory — fiats from government bodies;
• Internal — limits of your capabilities; and
• Project — standards based on the business environment.

• Requirements always use shall;
• Statements of fact always use will;
• Goals always use should; it never hurts to actually use the word “goal” in the statement if it is a goal, e.g., “As a goal, the item should …;”
   Most requirements can be written in a pretty simple format:
• The item shall provide …;
• The item shall be capable of …;
• The item shall contain …;
• The item shall weigh …;
• And lastly, avoid ambiguous terms — unless you are a lawyer;
• Maximize or minimize (you never know when you are done);
• Support (unless you are talking about a structural requirement for supporting a weight);
• But not limited to (supposes other things are acceptable without saying what they are);
• Etc. (depends on who you ask);
• And/or (either you need both or either are acceptable).

Taste success

In summary, attempting to fulfill product requirements by selecting components without a substantial understanding of the system is ill advised. It is essential to carefully convert the understanding gained from developing a system description into workable requirements. Investing in a description up front can make the difference between a system that requires endless tweaking in pursuit of minimally acceptable performance or a system that is surprisingly painless to get running. Just as many good dishes are associated with one particular spice, relying on chili pepper alone will not result in a first place cook-off championship.

Christopher C. Lanham is director of engineering at Watlow in St. Louis, Mo. Email him at: [email protected].