Valeo's Five-Way Refrigerant Valve: What Compact Heat-Pump Routing Means for Controls and Service

News facts: a compact valve in Valeo's 2026 showcase

In its September 30, 2026 Paris Motor Show announcement, Valeo included a compact five-way refrigerant valve among its electrification technologies. The official CES 2026 award listing describes a rotating-plate design that replaces three solenoid-operated valves and one check valve, supporting switching between air-conditioning and heat-pump modes. Those descriptions establish the announced architecture and recognition; they do not provide an independent durability result, a service interval or compatibility with an unspecified vehicle. Valeo's dated show announcement and the official CES product listing are the primary sources.

The important engineering question is how to control and diagnose a more integrated thermal circuit. The following analysis develops that question independently; it is not a disclosure of Valeo's internal control strategy or a claim that VETHY uses this component.

Integration moves complexity rather than making it disappear

Combining functions can reduce the number of separate items that must be packaged and connected. However, the vehicle still needs to achieve each intended operating mode and move between modes correctly. A simpler physical layout can therefore require a more explicit functional description. The buyer should ask where the remaining complexity is managed: in the valve, in the thermal controller, in the vehicle software or in their interfaces.

This is not an argument against integration. It is a way to compare integrated and distributed solutions fairly. Counting parts is easy; comparing the complete engineering and service responsibility is harder. A useful comparison includes assembly work, control interfaces, verification effort, fault isolation and replacement scope. None of those can be settled by the external appearance of the module alone.

The first document to request is a functional circuit description for the proposed vehicle. It should identify the supported modes and the intended paths in each mode at a level appropriate to the customer's integration responsibility. A marketing illustration can introduce the concept, but it should not become the only reference used by software, mechanical and service teams.

Define a mode by its purpose, not by a valve position

A position is a component state. Cooling a cabin, conditioning a battery and supporting a heating cycle are vehicle purposes. The project needs a clear connection between the two. Otherwise, one team may discuss a numbered position while another assumes that the same number guarantees a particular thermal outcome.

For each vehicle mode, state the requested result, the necessary permissions and the measurements used to assess whether the result is being achieved. Keep those items separate from the actuator command. An accepted command does not necessarily prove that the complete thermal system is performing its intended function. The circuit may still be constrained by another component or by a vehicle-level operating limit.

Use names that remain understandable across the project. A mode called “battery preparation before charging” communicates more than an unexplained software code. The software code still belongs in the engineering record, but the relationship between the code and the operating purpose should be traceable. That helps the service team interpret logs after the original development engineers are no longer involved in every enquiry.

Map the transitions that a driver can actually trigger

A mode map should include transitions, not just a list of stable states. Drivers change temperature settings, select demisting functions, start the vehicle and stop it. Dispatch schedules and charging events may introduce additional requests. Each of those events can cause the thermal controller to reconsider what the system should do.

Start by listing the ordinary events in a representative operating day. Then identify which events can occur close together. A vehicle may leave a charging station while the cabin is still warming, or a driver may request a different comfort mode during another conditioning operation. The project should define how competing requests are handled rather than relying on whichever message happens to arrive first.

The transition record should include the starting state, requested destination, prerequisites and expected completion information. It should also identify what happens if the transition cannot finish. This is a functional specification, not a set of refrigerant-handling instructions. Detailed pressure, timing and hardware limits must come from the approved component and system engineering documentation.

Keep command, acknowledgement and outcome distinct

A controller can issue a command without receiving an acknowledgement. It can receive an acknowledgement without the requested physical outcome being achieved. It can also observe a satisfactory outcome while a diagnostic signal remains uncertain. These possibilities should be represented separately in the interface description.

This distinction matters when several suppliers are involved. If one supplier defines success as a transmitted command and another defines it as a temperature response, both may believe they have completed their obligation while the vehicle behavior remains unresolved. An interface contract should state exactly what each signal means and what it does not mean.

For a service tool, plain language can sit above those technical states. A technician should be able to distinguish a rejected request, an unavailable operating mode and a detected component fault. Combining them into a single generic warning may simplify the display but make repair decisions harder. The customer-facing message should be understandable without erasing the detail needed by the service process.

Ask what happens when power or communication is interrupted

An integrated valve does not operate in isolation from the vehicle's electrical and communication environment. The development team should assess interruptions and recovery within the approved validation scope. The important procurement issue is whether those cases have an assigned owner and an agreed result.

Consider a hypothetical vehicle that loses a control message during a mode change. The system may need to retain a known state, enter a limited state or wait for a renewed authorization. The correct behavior depends on the complete design. A buyer should not prescribe it from a generic article, but should require the supplier and integrator to state and validate it.

Recovery is equally important. After communication returns, does the controller know the actual component state or merely the last state it requested? How is disagreement resolved? What information is retained for diagnosis? These questions can reveal an interface gap before it becomes an intermittent field complaint that is difficult to reproduce in a workshop.

Compare service scope at the same functional level

A distributed arrangement may allow individual items to be replaced separately, while an integrated arrangement may define a larger replacement unit. That observation alone does not decide which approach is better. The comparison needs the actual service policy, expected diagnostic process, part availability and access on the vehicle.

Ask what the approved service unit is and what work the workshop is allowed to perform. A compact assembly may be easy to install during vehicle production yet difficult to access after surrounding equipment has been fitted. Conversely, fewer external connections may simplify some service operations. The project should assess the installed configuration rather than drawing conclusions from a bench photograph.

The financial comparison should include the likely repair pathway, not just the component price. Who performs the diagnosis? Is a replacement held locally? What information must accompany a returned unit? How does the supplier distinguish a product defect from a system condition? These questions help an importer understand the support obligation that accompanies an integrated product.

A diagnostic plan should begin before the first prototype

Diagnostics are often discussed late, after the physical circuit and controller have been selected. That can leave the service team with insufficient information to distinguish several causes of the same symptom. A better approach is to define the important fault questions while the interfaces are still being designed.

For each significant complaint, identify what information would help separate possible causes. A loss of heating after a mode change, for example, should lead the team to ask which requests were active, which permissions were present, what state was reported and how the temperatures responded. Those are categories of evidence, not a diagnosis of a particular product.

Keep the necessary record manageable. Logging everything at all times can create a large volume of data that nobody reviews. Logging too little can make an intermittent event impossible to understand. The engineering team should choose an appropriate set of signals, timing and event records for the intended diagnostic questions, then verify that the workshop can retrieve and interpret them.

Test sequences with a clear acceptance boundary

A successful test should state what it demonstrates. A component cycling through commanded positions may demonstrate actuator behavior under specified conditions. A complete circuit test may demonstrate a thermal mode. A vehicle test may demonstrate acceptable occupant comfort during a realistic transition. These are related but different acceptance boundaries.

Create a layered plan. Use component evidence where it is applicable, then address the integration questions that remain. Do not repeat a supplier's test merely to create another report, and do not assume that supplier evidence covers a vehicle installation it never assessed. Each test should close a specific gap in the evidence chain.

Include representative transition sequences in addition to steady operation. Record the configuration, starting conditions and permitted limits. If a sequence fails, preserve the event record before changing several settings at once. Controlled changes make it easier to understand whether the cause belongs to hardware, calibration, communication or an incorrect initial assumption.

A hypothetical software revision shows the traceability problem

Imagine a vehicle program that updates its cabin comfort logic after the initial prototype tests. The hardware remains unchanged, but the software now requests a different sequence during a cold start. If the earlier acceptance report is filed only under the valve part number, the project may incorrectly treat it as proof that the revised vehicle behavior is already validated.

The solution is to record the complete relevant configuration. That includes the hardware revision, controller software, calibration and vehicle arrangement associated with each result. The level of detail should be sufficient to determine whether a later change affects the tested behavior. This is ordinary configuration control applied to a thermal system that increasingly depends on software.

The same principle applies to service replacements. A physically compatible unit may still require an approved software or calibration combination. A distributor should not promise interchangeability based only on the shape of the housing or the connector. The current application and replacement instructions must establish the supported combination.

Avoid using efficiency claims without a vehicle baseline

An integrated component may support a more efficient system, but a component announcement does not establish the energy saving of a particular vehicle. The vehicle's thermal demand, operating modes, control strategy and environmental conditions all affect the result. A buyer should ask for a comparison that matches the intended use.

State the baseline explicitly. Is the comparison against a different circuit architecture, a previous software calibration or another vehicle? Are cabin conditions equivalent? Is battery conditioning included? Does the reported electrical energy cover the whole thermal system or only one device? Without those answers, an attractive percentage may not help the buyer make an engineering decision.

The same caution applies to a claim about reduced complexity. Fewer separate parts can be a measurable packaging fact, but lower total development or service effort requires a broader assessment. Keep physical counts, assembly time, diagnostic effort and energy performance as separate measures. That makes it possible to recognize a real advantage without stretching it into an unsupported general conclusion.

Decide who owns the circuit when responsibilities cross suppliers

The integrated component supplier may understand its own assembly in depth, while the vehicle manufacturer controls the overall operating strategy. A bodybuilder may change the interior or install additional thermal loads. A workshop may later replace a component under a distributor's support process. The project needs a clear owner for the circuit behavior that crosses those boundaries.

A responsibility matrix should assign the functional specification, interface definition, calibration, vehicle validation and service documentation. It should also explain how changes are approved. If each supplier can change its own part of the system independently, a previously validated combination can become uncertain even when every component remains individually compliant with its own specification.

For a new commercial-vehicle project, the VETHY engineering page is a useful route for beginning a requirements discussion. Describe the intended vehicle and duty rather than requesting a component simply because it appeared in a recent technology announcement. An engineering review can then identify what must be defined before any proposed architecture can be responsibly evaluated.

What this means for HVAC modules and parking cooling

The relevance to a custom HVAC module is the need to define the module's boundary. Does the module include only the air-handling assembly, or also the refrigerant circuit and control logic? Which vehicle signals does it require? Which outcomes can the module supplier validate independently, and which require the complete vehicle? Those questions prevent a module drawing from being mistaken for a complete system specification.

The HVAC modules page can frame that discussion around integration requirements. A customer supplying an evaporator assembly drawing should also explain the intended system and control responsibilities. Without that context, two quotations can describe similar hardware while assuming different functions and different validation work.

For a conventional parking air conditioner, the news does not imply that an EV heat-pump routing component is relevant to the product. The useful transferable practice is to make control states and service responsibilities clear. Keep the specific product selection grounded in its actual cooling duty, supply architecture and supported application rather than in a technology trend.

Build a decision record that survives the design meeting

After comparing architectures, record why the selected approach fits the project. Include the requirements that drove the decision, the evidence already available and the questions still open. A decision record should make the tradeoffs understandable to someone who was not present at the meeting.

For example, a project might select integration because packaging constraints dominate, while accepting a particular replacement-unit strategy. Another might retain a distributed layout because of an established service arrangement. Those are hypothetical decisions, not recommendations for every vehicle. What matters is that the chosen tradeoff is explicit and supported by the project's circumstances.

Revisit the decision when those circumstances change. A different production volume, vehicle layout or support market may change the balance. Avoid treating the original choice as permanently correct merely because it has already been implemented. At the same time, do not reopen it for every minor change; use the recorded assumptions to identify which changes are materially relevant.

Review one difficult transition in detail

Before expanding the test matrix, choose one transition that combines several realistic requests. A hypothetical example is a vehicle leaving an external power connection while the cabin requests heat and the battery controller changes its permitted auxiliary budget. The aim is not to create an unnecessarily dramatic failure. It is to make the ordinary handover between operating states visible.

Write a short timeline showing the requests and permissions expected at each step. Identify the observation that confirms completion and the condition that would require the sequence to stop. Then compare the timeline with the system's recorded behavior. If different teams interpret the same event differently, resolve the definition before accumulating more test runs. A small, well-understood sequence can reveal an interface misunderstanding that a large collection of steady-state results misses.

Preserve useful information in the service handover

The final service package should explain the supported replacement unit, identification method, software dependencies and route for technical escalation. It should also identify what the workshop can verify locally and what requires supplier assessment. Those boundaries prevent an installer from improvising an unsupported intervention when the fault information is incomplete.

Provide examples of the information needed for an intermittent complaint: vehicle configuration, operating context, relevant event time and available diagnostic record. Avoid asking the workshop to collect an undefined mass of data. A precise request improves the chance that the first support exchange contains enough information to move the investigation forward.

Finally, keep the service package aligned with revisions. A new control release may change a status description or a required recovery sequence even when the hardware remains visually identical. The document reference supplied to the workshop should identify the supported configuration so that older instructions do not quietly become the default for a newer system.

Frequently asked questions

Does a five-way valve mean five independent thermal systems?

No. A port or way count describes the component, not the number of independently controlled vehicle functions. The actual supported modes depend on the circuit and controller. Ask for the functional architecture and operating-mode description rather than inferring system capabilities from the product name.

Does an award prove that the part is suitable for my vehicle?

No. Recognition identifies an innovation within the award program's scope. Suitability still requires application information, interface review and appropriate validation. The dated news in this article is a reason to examine an architecture, not a substitute for vehicle-specific engineering evidence.

Is integration necessarily harder to repair?

Not necessarily. The answer depends on the service unit, access, diagnosis, parts availability and support model. Compare the complete repair pathway for the actual vehicle. An isolated component price or count of external connections cannot establish the total service outcome.

What should a buyer request before approving a compact thermal module?

Request the supported modes, interface responsibilities, fault and recovery behavior, validation scope and service concept. Identify which items are confirmed and which remain development work. That package provides a sound basis for a decision while keeping the product announcement separate from claims about the finished vehicle.