Processing Magazine

When specifying thermal components, it’s essential to take a systems approach

July 23, 2007

A common mistake made when specifying a heater or other component of a thermal system is to not adequately consider how that component interacts with its environment and with other components in the system. For example, engineers often request heaters with very specific temperature uniformity, without understanding that temperature uniformity is not a heater component attribute (power dissipation is a heater attribute). Similarly, when it is found that a new thermal system design does not control temperature within desired tolerances it is often concluded that the accuracy or precision of the temperature control unit must be the problem when it is more likely the sensor or heater response is unstable due to mechanical fit or related assembly tolerance problems.

In order to make the best thermal component choice for any given application, and avoid start-up problems during new equipment checkout, it is essential to remember that a system’s performance is not simply the sum of the performance of each individual component. Even for very simple thermal systems, taking the time to develop a complete system description before starting detailed design or component selection can dramatically reduce design cycle time and development cost by eliminating many of the potential headaches caused by trying to “fix” a thermal system, one component at a time.

In its most basic form, a thermal system consists of the following primary components:

Work Load – Theitem 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 – The item that converts the input power source into heating/cooling energy (e.g. a band heater or chiller unit)

Process Temperature Sensor – The item that indicates the temperature of the work load. (e.g. a thermocouple or infrared pyrometer)

Process Temperature Control – The item that regulates the temperature of the work load (e.g. a thermostat or electronic control)

Power Control – The item that connects/disconnects input power to the heat/cool source as determined by the process temperature control (e.g. a thermostat or solid-state relay)

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 will include the following secondary components:

Limit Temperature Sensor – Anitem that 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 – An item that prevents the temperature of the work load from reaching a hazardous level.

Safety Contactor – An item that provides 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 surrounding the specific characteristics of one particular item with little effort spent understanding the interrelationship or interfaces between the items. 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, provided the heat/cool source is 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.

All 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 and 180 °C to prevent it from condensing or degrading.”

Once the need has been clearly established, a system description begins by defining the behavior of the system intended to fulfill that need. Behavior can be described in “what it does” terms or the activities needed to be performed. 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.

· resources- what is required for pursuit of mission and maintenance of viability.

Next, it is helpful to describe the system’s structure – specifically, how it is built and how each component interconnects with others. That chili needs to be competition chili, not eatin’ chili, so 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 and maybe some fresh peppers, but 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 PID controls. The heater jackets can be custom fitted to the tubing and the applied heat can be zoned to account 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 in order to create a complete system development specification. However, it is 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.

· 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 is not necessarily the best available combination of behavior and structure. To achieve the best solution, a definition of effectiveness is required.

Effectiveness is the measure of how well the system satisfies the statement of need. Without defined measures of effectiveness, there is 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? And regarding 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:

· Performance - the minimum acceptable limits for characteristics such as stability, responsiveness and uniformity.

· Availability (of performance) – the ability of the system to continue to perform under normal conditions.

· Survivability - the ability of the system to restore performance following abnormal conditions.

Techniques such as solution cost/benefit analysis, quality function deployment (QFD), production, preparation, process (3P) and object modeling/simulation are examples of process tools intended to assist the system engineer in understanding effectiveness. Regardless of the specific method, once an effectiveness filter is in place, the process of optimization can be employed to determine which behavior/structure combination best fits the system. 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 temperature control range requirement for the gas line, the process of optimization can be used to determine the degree of difficulty (and cost) associated with achieving the required performance with a given construction. Optimization will either determine that a flexible heater jacket can be controlled to the required temperature range, or reveal that a different method (structure) should be considered such as model-based control, convectively heating the gas delivery line by surrounding it with a heated box to create a mini environment, or perhaps even controlling the internal temperature of the equipment or room the line is mounted in. That is presuming that does not 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 those 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 as suggested in the introduction to this article. In fact, leading providers of software and tools to support the requirements definition and management process report that as much as 70 percent 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 their own opinion or definition of what a “requirement” is. 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 to be wrapped at 100 percent 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 percent coverage). One hundred percent wrapping of the lines is a design implementation. Requirement documents should not state implementation. Stating implementation may force a design solution that is not really intended, may be unnecessary or even worse, 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 percent wrapping will be the design solution selected, so it does not 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.

At each level of development (particularly in a complex system) the problem of “what” verses “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 fromrequirement to design implementation occurs?” This is a problem particularly in software development where 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 requirements process 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. However, even if there is a lack of reasonable alternatives, when the one stated is not 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 is dependent upon understanding of the implementation context so it cannot stand alone as a true design solution.

In summary, if the risk associated with achieving a specification is high, attempting to fulfill the specification through the selection of individual components without a substantial understanding of the system is ill advised. Often, a numerical computer model of the system that can account for the multitude of factors affecting the interfaces between components is needed in order to arrive at an effective solution.

As a minimum, careful conversion of the information and understanding gained from development of a system description into appropriate requirement statements is essential. Investing in this up front effort can make all 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.