DENSO's Intelligent Cooling Update: Turning Control Signals into Clear HVAC Requirements

The technical update

On June 3, 2026, DENSO published an update on the shift from mechanically driven engine cooling toward electronically controlled thermal systems. It discusses electric coolant pumps, PWM control and electronically managed thermostats, alongside the need for system-level diagnosis. This is a technical industry update, not a claim that every vehicle or HVAC controller supports the same electrical or communication interface. [Source]

The subject is directly relevant to OEM HVAC inquiries. Customers often ask whether a system has CAN, RS-232, RS-485 or another interface before explaining the information they actually need. A supplier can answer the interface-name question and still fail to solve the customer's problem.

This article sets out a clearer method for defining control and feedback requirements. It does not specify wiring for a particular product. Any connection, electrical characteristic or protocol must be confirmed for the exact controller and vehicle arrangement through the responsible suppliers.

Begin with the requested outcome

Ask the customer to describe what the vehicle should know or do. Does it need to know whether the air conditioner is running? Must it enable or disable the unit? Does it need to change a temperature setting, read a fault or monitor a measured value? These are separate functions.

A customer requesting only an on/off indication may not need a complete communication protocol. Conversely, a request for remote control may require more than a status output. The project should not add complexity simply because a familiar interface name appears in an early email.

Write the outcome in a short sentence and confirm it with the customer. For example, the vehicle controller needs an indication that the HVAC system is operating, with the exact meaning of operating still to be agreed. That sentence reveals an important next question instead of prematurely selecting a connector or bus.

The supplier can then propose an appropriate signal form and explain its limits. This sequence makes the technical conversation easier for both sides and reduces the chance that a controller is ordered with the wrong capability.

Separate power, command, feedback and diagnostics

Power provides the energy a device needs. A command requests behavior. Feedback reports a state or measurement. Diagnostics provide information useful for identifying or investigating a condition. A single connection arrangement may support several functions, but the specification should keep them distinct.

Confusion often arises when a buyer treats a command as proof of operation. A controller may request cooling while the equipment is waiting for an enabling condition or operating within a protective limit. The requested state and achieved state are not necessarily identical.

Similarly, a power-present signal does not prove that a compressor or fan is running. A fault-free indication does not necessarily prove that the occupied space has reached the desired condition. The meaning of each signal must be stated precisely enough for the receiving controller to use it correctly.

Create a signal list with one row per function. Describe the source, destination, meaning and required behavior. This can be done before choosing the electrical form. It gives the hardware and software teams a shared functional basis for the interface design.

Define what on means

An on/off status request sounds simple until the team asks what on represents. It could mean that the control panel is powered, that a user has enabled the system, that the blower is operating, that the compressor is commanded or that a particular cooling state is active. Those meanings are not interchangeable.

Ask the customer which decision the receiving system will make from the signal. If it only illuminates a status indicator, the required meaning may differ from a signal used to coordinate power allocation or another vehicle function. The consequence of the signal determines how precisely it must be defined.

Also define transitional states. What should the output show during start-up, a temporary pause or a protective stop? A binary signal may be sufficient, but its behavior must still be documented. If a binary representation cannot support the customer's decision, the team may need a richer status description.

The result should be a small state table that both suppliers approve. It is far more useful than an unqualified statement that the unit has an on/off signal. The table prevents later disagreement about whether a technically functioning output is reporting the state the customer intended.

Choose the electrical form after the meaning

Once the function is defined, the controller supplier can identify possible electrical forms. The receiving vehicle system must confirm what it can accept. The two sides should agree the relevant levels, reference, isolation where required and connection arrangement for the actual design.

Do not infer those details from a casual label such as dry contact, voltage signal or communication output. The exact implementation matters. The supplier should provide the technical information needed by the receiving-system engineer and identify any conditions or limitations.

The interface specification should include the connector and pin definition, permitted operating conditions and required protection or isolation arrangements as determined by the responsible designers. It should also state which organization supplies the harness or adapter and verifies the completed connection.

This article does not prescribe electrical values because they must come from the actual equipment. The procurement requirement is to obtain and reconcile those values before installation. Guessing a signal level from a familiar product family can damage equipment or produce misleading behavior.

A protocol name is not a complete agreement

CAN, LIN, RS-232 and RS-485 describe different aspects of communication technology, but an interface name alone does not define the application messages or the behavior expected by the vehicle. The exact protocol and configuration must be confirmed.

For a data interface, ask which commands and status values are supported, how they are represented and how often they are transmitted or requested. Identify the required versions and any configuration needed at either end. The receiving system must interpret the information in the same way the sender intends.

The project should also define how missing, stale or invalid information is handled. A controller that continues to display the last received value without indicating loss of communication can create a misleading impression of current operation. The required behavior belongs in the functional specification.

A supplier can provide a protocol document or another agreed technical interface package. The buyer should then arrange a compatibility test for the requested functions. Similar connectors or a shared bus technology do not replace that test.

Use a state table to expose ambiguity

Consider a hypothetical HVAC system with five states: powered but disabled, enabled and waiting, actively cooling, temporarily limited and faulted. A customer asks for a single signal labeled AC on. The team needs to decide which of those states produces an active indication.

If the customer only wants to know whether the operator enabled the system, the signal may remain active while the unit is waiting. If the customer needs confirmation of active cooling, that same behavior would be unsuitable. The original request used the same words, but the intended decisions are different.

The state table should describe the required output in each state and the timing associated with transitions. It should also identify the behavior when the controller loses power or the connection is interrupted. The responsible engineers determine the appropriate implementation and fallback.

This example is not a specification for any VETHY controller. It demonstrates why functional clarification should precede a promise of compatibility. A short table can prevent a much larger integration problem after hardware has been purchased and installed.

Timing matters even for simple feedback

The receiving system needs to know how quickly a signal follows a change and how temporary conditions are represented. A status that updates slowly may be acceptable for a display but unsuitable for another control purpose. The required timing should follow the actual use case.

Define whether a brief transition should be reported immediately or treated according to an agreed filtering rule. The supplier should explain the behavior of its actual controller. Avoid assuming that an output changes at the same instant as the underlying physical process.

For data interfaces, distinguish transmission timing from the age of the underlying measurement. A frequently transmitted message can still contain a value that has not been refreshed as expected. The interface should provide the information needed to interpret its currency where that matters.

During testing, record commands, reported states and relevant observations with a consistent time basis. This helps the team understand delays and sequence. A screenshot of one value may confirm that a message exists without demonstrating that it behaves correctly through the operating cycle.

Plan for loss of power or communication

Every interface should have defined behavior when the normal information path is unavailable. The correct response depends on the vehicle function and must be determined by the responsible engineers. It should not be improvised by an installer at the point of connection.

Ask what the receiving system sees when the HVAC controller is unpowered, disconnected or restarting. Distinguish those conditions from a valid off state where necessary. A single signal can be ambiguous unless the design accounts for how faults and normal states are represented.

The vehicle controller should also have a defined response to unavailable information. It may need to indicate uncertainty, use an approved fallback or take another action specified by the vehicle design. The key is that the behavior is agreed and tested rather than assumed.

Record the limitations in the customer-facing technical scope. A basic status output may intentionally provide less information than a diagnostic interface. That can be acceptable when it matches the requirement, but the customer should not expect fault detail that the chosen arrangement cannot deliver.

Build a compatibility test around the actual functions

A useful test checks the commands and statuses the customer intends to use. It should include normal operation, relevant transitions and the defined unavailable-information cases. The exact method must be appropriate to the equipment and approved by the responsible teams.

Use the intended controller versions and configuration where practical. If a simulator or temporary interface is used, document how it represents the final vehicle system and what remains to be checked later. A successful bench exchange does not necessarily establish the complete installed behavior.

The test record should identify hardware, software, wiring or connection arrangement and the expected result for each case. Record the observed result and any deviation. This creates evidence that can be reviewed by both suppliers without relying on a verbal statement that communication worked.

When an issue is found, update the interface document or implementation through change control. Retest the affected functions and any related behavior identified by the engineers. Compatibility becomes a controlled project result rather than a one-time demonstration that is difficult to reproduce.

Diagnose the system rather than the most visible component

Electronic thermal control can produce symptoms that require both physical and signal-level investigation. The workshop needs to understand the relationship between a request, the controller's response and the actual equipment behavior. Replacing a component without that context may leave the cause unresolved.

A useful service record includes the requested mode, reported state, relevant supply conditions and fault information available through the approved interface. It should identify the installed controller versions and any recent changes. The data collected should answer a diagnostic question rather than merely accumulate values.

The service team should know which observations come from sensors and which are inferred or commanded states. A displayed pump or compressor request may not be a direct measurement of physical operation. Clear labels help prevent an incorrect conclusion.

The manufacturer or qualified service provider should define the appropriate checks for the system. This article does not replace those procedures. Its practical point is that the interface specification and diagnostic documentation should be developed together, because both depend on a shared understanding of state and responsibility.

Keep controller customization within a defined scope

If a requested interface is not currently supported, the supplier may propose customization. The buyer should ask for a development scope covering the function, hardware or software changes, sample process and validation responsibilities. A statement that customization is possible is not a completed design.

Identify who owns the required protocol or signal information and who can approve the result. The supplier may need details from the customer's main controller manufacturer. Without those inputs, it cannot reliably promise compatibility or estimate the work.

The quotation should distinguish existing capability from new development. State the deliverables and acceptance criteria for the custom work. This protects both sides from treating a preliminary discussion as an unconditional production commitment.

After approval, preserve the custom configuration in the product record. Service replacements must match the relevant version or follow an approved update route. A custom interface loses value if the replacement process later supplies a standard controller that does not provide the required function.

A concise supplier handoff

The most useful handoff begins with the customer's required outcome: what information must be received or what action must be commanded. It then identifies the receiving controller, proposed signal form if known and the vehicle context.

Ask the controller manufacturer to confirm whether the current design supports that function. If it does, request the electrical and functional definition, connector information and version applicability. If it does not, request the scope and evidence needed for a possible modification.

Include the required timing, normal states and behavior when information is unavailable. State whether the function is for display, coordination or another purpose. This gives the supplier the context needed to judge whether a simple output is sufficient or a more detailed interface is necessary.

The response should be reviewed with the receiving-system engineer before installation. The two sides need to agree the same function and implementation. This final reconciliation is what turns a list of interface features into an actual vehicle integration.

A functional state table before an electrical drawing

The following table is a hypothetical clarification tool. It does not describe an existing VETHY output and does not specify a voltage, connector or circuit. Its purpose is to help a customer decide what information it actually needs before asking the controller manufacturer to implement it.

The receiving-system engineer should explain what decision follows each answer. If the signal only drives a display, a simple definition may be adequate. If it coordinates another function, the required information and fallback may be different. The implementation should follow that purpose.

After the functional table is agreed, the controller supplier can propose the electrical or communication form. The vehicle-side supplier then checks compatibility. The final interface document should connect the functional meaning to the exact implementation so that neither side has to infer the relationship.

This order is efficient because it prevents the team from debating CAN, serial links or contacts before knowing whether the customer needs one state or several. It can also reveal that an existing supported function is sufficient, avoiding unnecessary customization.

During testing, use the table as the expected-result record. Observe each relevant state through an approved method and record what the receiving system displays or does. A test that only shows the active state leaves the ambiguous waiting and unavailable states unresolved.

Keep the approved table with the controller version record. If software changes, review whether the reported meaning or timing changes. A physically identical replacement should not be assumed functionally identical without the relevant configuration information.

For a customer-facing answer, the supplier can then state the confirmed function in plain language and attach the technical definition. That response is more useful than saying only that an interface is supported, because it tells the customer what the vehicle will actually know.

Frequently asked questions

If a customer only needs an on/off signal, must the system use CAN?

Not necessarily. The appropriate form depends on the function and the receiving controller. Define the meaning and electrical requirements first, then obtain confirmation from both suppliers. A simpler interface may be sufficient, but it must still be specified correctly.

Is an enable input the same as operating feedback?

No. An enable input requests or permits operation. Feedback reports a defined state. The equipment may not be operating exactly as requested, so the two functions should remain separate in the specification.

Can a shared RS-485 or CAN label prove compatibility?

No. The application protocol, configuration and behavior must match. Request the relevant technical information and test the functions required by the vehicle rather than relying on the interface name alone.

What can VETHY confirm before making an interface promise?

VETHY should confirm the requirement with the customer and obtain the exact capability from the controller supplier. The response should identify the model, version, signal definition and any development work. Unverified CAN, serial or status-feedback functions should not be advertised as standard features.

Make the requirement understandable before making it technical

The strongest interface specification begins with a clear operational sentence and ends with a tested electrical or communication agreement. That sequence prevents unnecessary complexity and exposes missing information early.

DENSO's update is a useful reminder that thermal systems increasingly depend on controls as well as hardware. Buyers can respond by separating requests, states, measurements and diagnostics, then asking suppliers to confirm the exact functions their vehicle needs.