Webasto's New Diagnostics: What Vehicle HVAC Buyers Should Ask About Service

The news and the decision it raises

On October 26, 2026, Webasto announced new air heaters alongside Webasto System Diagnostics. Its release describes a cloud-connected workshop tool for installation, commissioning, maintenance and troubleshooting, with saved test records, technician-authorized software updates and operation for up to 30 days without internet access. It identifies LIN and CAN communication through a Webasto diagnostic connector. These are Webasto's stated capabilities for its own system, not evidence that the tool supports another manufacturer's HVAC equipment. [Source]

For a fleet or vehicle converter, the useful question is what happens after the installation team leaves. A heating or cooling system can meet its temperature target on handover day yet become difficult to support when a vehicle changes depot, loses connectivity or receives a replacement controller. Service access therefore belongs in the original purchase decision. It should not first appear as an unresolved issue during a breakdown.

The following analysis translates that news into a practical service specification. It does not compare measured product performance or recommend replacing an existing system solely because a newer diagnostic tool exists. The objective is to help buyers define ownership of the information, equipment and decisions needed to keep a vehicle operating.

Start with the person who must restore the vehicle

Different fleets have different recovery routes. A city operator may return a bus to the same workshop every evening. A long-haul carrier may depend on unfamiliar roadside service providers. A camper converter may hand the vehicle to an owner who travels between countries. Each situation creates a different requirement for tools, access and documentation.

Write a short recovery story before evaluating a connected system. Identify who receives the complaint, who can inspect the vehicle, who can access diagnostics and who has authority to approve replacement parts. Include the likely time of day. A service route that works only during the supplier's office hours may leave a weekend operator with a long interruption even when the repair itself is straightforward.

For an export distributor, the first responder may speak a different language from the manufacturer. A useful diagnostic record should therefore contain unambiguous identifiers, units and timestamps. A screenshot of an untranslated warning message is a weak substitute for a structured record showing controller version, supply conditions, operating request and the actual fault code.

The procurement team should ask the proposed service partner to walk through this recovery story. The response exposes gaps that a general promise of technical support can conceal. The important result is an agreed sequence with named responsibilities, not a larger collection of brochures.

Define the diagnostic boundary

A vehicle HVAC complaint can originate outside the HVAC unit. An air conditioner may stop because the supply voltage falls under load, the vehicle withdraws an enable signal or a protective control detects an unsuitable operating condition. A heater may receive a valid command but lack an installation condition required by its own instructions. Reading a fault list alone does not explain the whole system.

The diagnostic boundary should cover the HVAC equipment and the vehicle interfaces that determine whether it can operate. Ask which measurements are visible to a technician and which require separate instruments. A controller might display its own supply voltage but have no knowledge of voltage at the battery terminals. That distinction matters when resistance in a connection causes a local voltage drop.

Similarly, a displayed temperature may represent an inlet sensor rather than the occupied zone. A normal reading at that sensor does not establish that passengers receive adequate airflow. The service record should identify each measurement location instead of presenting a single unlabeled temperature as proof of comfort.

Create an interface drawing that shows power, controls, sensors and service connections. It need not disclose proprietary circuit design. It should make clear which supplier is responsible for each connection and which observations are available when something goes wrong. This drawing becomes the shared reference for the vehicle builder, installer and workshop.

Treat offline operation as a workflow question

Offline capability is not a simple yes-or-no feature. A tool might read current faults without internet access but require a connection to retrieve repair instructions. Another might retain existing vehicle information yet be unable to enroll a new controller. A workshop needs to know which functions remain available and for how long.

For any proposed diagnostic platform, request a function-by-function matrix. Separate fault reading, live measurements, actuator checks, configuration changes, firmware installation, service-document retrieval and report export. Also distinguish an already authorized laptop from a freshly replaced device. A cached account can behave differently from a new login at a remote depot.

Connectivity should be tested in a controlled demonstration. Ask the service provider to disconnect its network, open a previously enrolled vehicle record and produce a report. Then ask what happens when the vehicle has never been seen before. The supplier can explain restrictions without the buyer assuming that every connected feature is available offline.

A fleet does not necessarily need every function everywhere. It may accept advanced programming at a central workshop while requiring fault identification at remote locations. The point is to make that division intentional. The emergency procedure should state when a local technician can continue, when a specialist must intervene and how the vehicle is handled while waiting.

Separate physical connectors from protocol compatibility

An interface label such as CAN or LIN describes only part of a communication system. It does not establish that two devices understand the same messages, use the same configuration or permit the same service operations. A familiar connector shape is even less conclusive.

When a buyer requests vehicle integration, the first step is to describe the required function in ordinary language. Does the vehicle need an HVAC on/off status signal? Must it request a temperature? Does the operator need fault information? Is remote configuration actually required? These are different scopes, and each creates different responsibilities.

A simple status output may satisfy an application that otherwise risks being over-specified as full digital integration. Conversely, a basic enable wire will not deliver detailed operating data just because a display shows the system as active. The interface specification must match the desired information and control authority.

Ask the controller supplier for the electrical characteristics, connector definition, message or signal description, timing requirements and behavior when communication disappears. Obtain written confirmation for the exact hardware and software versions. This is particularly important when a fleet plans to source replacement controllers years later. Compatibility should be demonstrated at the agreed interface, not inferred from a marketing term.

Make commissioning a permanent vehicle record

Commissioning should establish a baseline that later technicians can use. Without that baseline, a workshop may not know whether an observed setting is original, whether a sensor was moved or whether a software version changed after delivery. The resulting uncertainty increases diagnosis time and encourages unnecessary parts replacement.

A practical record begins with the vehicle identifier and exact HVAC model. Add the controller and software versions, installation photographs, electrical supply arrangement, approved configuration and date of the check. Measurements need operating conditions: ambient temperature, selected mode, fan setting and whether the vehicle's other loads were running.

For cooling equipment, document the installed configuration and the checks required by its approved instructions. Do not improvise refrigerant procedures from a generic internet article. For combustion heaters, the manufacturer's installation and commissioning requirements remain decisive. A software report does not replace inspections that require a qualified person at the vehicle.

The record should remain accessible when the vehicle moves between workshops. A PDF attached to the asset register can be more useful than an impressive dashboard that only one contractor can open. Where a cloud platform is used, agree an export format and a retention period. The fleet should know how to obtain its own service history before a support contract ends.

Control software changes like physical changes

Software can change the behavior of an otherwise unchanged HVAC unit. A new calibration may alter how it responds to a command, reports a fault or enters a protective state. The workshop should therefore know what version is installed and why a change is proposed.

A change record can be concise. It should identify the old and new versions, the reason for the update, the vehicles affected and the checks required afterward. If the update addresses a specific fault, the acceptance test should reproduce the original operating condition where practical. A successful upload alone does not prove that the original problem is resolved.

Before a fleet-wide update, use an agreed representative vehicle and a supported recovery procedure. Do not assume that older software can always be restored. Ask the supplier which recovery actions are available if a programming process is interrupted and which equipment is required. This is a planning question, not an invitation to bypass the supplier's controls.

The same discipline applies to replacement controllers. Record whether the part arrives configured, requires commissioning or must be matched to vehicle options. Stocking a controller without the means to configure it may create the appearance of spare-parts readiness without providing a usable repair route.

A worked service-readiness example

Consider an illustrative fleet with 40 converted service vans operating from four depots. The numbers are hypothetical and do not describe a Webasto or VETHY customer. The buyer is choosing between two support arrangements for the same type of duty: local fault identification with central specialist escalation, or full diagnostics at every depot.

Under the first arrangement, each depot needs a clear inspection checklist, access to the vehicle's commissioning record and a way to capture the observations requested by the central specialist. The central team needs suitable diagnostic access and an agreed method for exchanging reports. This arrangement may be practical if vehicles return regularly and advanced faults are infrequent, but those assumptions should be checked against the fleet's own records.

Under the second arrangement, every depot needs trained personnel, current tools and a process for maintaining access. The fleet must account for staff turnover and replacement laptops. A tool purchased once does not remain useful automatically if the only trained technician leaves or the account renewal is forgotten.

The comparison should include time to identify a problem, time to obtain a decision, travel to a capable workshop and time waiting for a configured replacement. These are operational measures rather than promises about the equipment's inherent reliability. A supplier with a clear escalation route may outperform a nominally broader service network that cannot access the correct information.

During the pilot, give each depot the same simulated complaint without damaging or altering the vehicle. Ask the staff to identify the vehicle record, find the correct instructions and explain their escalation route. Record where they become stuck. This exercise checks organizational readiness without creating an artificial technical fault or submitting a misleading warranty claim.

The final decision should follow the fleet's support geography. It should not be driven solely by the number of functions shown on a diagnostic screen. What matters is whether the available people can use the required functions when an actual vehicle needs attention.

Specify useful service data, not maximum data

Collecting more data is not automatically better. A service team needs observations that help distinguish plausible causes and confirm a repair. An unstructured stream of values can make a simple complaint harder to understand, particularly when measurements use different clocks or undocumented units.

Begin with a small diagnostic dataset: requested mode, actual operating state, relevant temperatures, supply conditions, fault identifiers and software version. Add other signals only when they answer a defined question. For example, a compressor command may be useful alongside the actual reported state; either value alone can leave the technician uncertain about where the request stopped.

Timestamps deserve special attention. State the time zone and whether data came from the vehicle, a service laptop or a cloud system. A mismatch of several minutes can make an apparent cause occur after the reported fault. Fleet managers should also distinguish live readings from cached values on a disconnected screen.

Access should follow job responsibilities. A driver may need to see an operating warning while a technician needs detailed diagnostics. Configuration changes may require a separate role. This separation makes the workflow clearer and reduces accidental changes. It also gives the fleet a useful audit trail when several organizations support the same vehicle.

Ask how the service offer survives staff and supplier changes

The useful life of a commercial vehicle can exceed the term of an individual support agreement. Procurement should therefore consider what happens when a distributor changes, a workshop closes or the fleet brings maintenance in-house. These are ordinary business events, not exceptional failures.

Request a description of account transfer, vehicle reassignment and access recovery. The fleet should know which records belong to it and which remain within the supplier's system. Ask how an authorized replacement workshop obtains the information needed for a repair without relying on a former employee's personal account.

Documentation should be versioned and attached to the exact model. A generic manual for a product family may omit an option fitted to a particular vehicle. Keep the installed bill of materials, configuration record and approved service instructions together. When a component is superseded, record the replacement relationship and any associated setup requirements.

This is also where a distributor can demonstrate value beyond selling equipment. A consistent vehicle record, a maintained service contact and an organized spare-parts process make technical support easier to use. Buyers should ask for examples of the process and agree deliverables for their own project rather than accepting unsupported claims about universal support coverage.

Build a service acceptance checklist

Before accepting the first vehicle, confirm that an authorized technician can identify the installed system, locate its instructions and retrieve a meaningful diagnostic record. Check that the report uses understandable units and identifies the software version. Verify that the fleet receives the commissioning record in the agreed format.

Next, check the support route. The installer, distributor and manufacturer should agree who receives a complaint and which information must accompany it. The fleet should not have to discover the relationship between those organizations during its first outage. Include the route for an urgent operating interruption and the route for a non-urgent documentation question.

Finally, review replacement readiness. Identify the service items expected to be stocked, the items supplied on order and any component requiring programming. Record who performs that programming and where. A promise of fast shipping is incomplete if the vehicle still cannot operate after the replacement arrives.

Keep the checklist proportionate. A straightforward parking air conditioner does not need the same service architecture as an integrated high-voltage vehicle thermal system. The buyer should require the functions necessary for its application and verify them, rather than adding digital complexity without a clear operational benefit.

Put recovery time into the supplier scorecard

For a useful pilot scorecard, record four timestamps: when the complaint is received, when the required information is complete, when a technical decision is available and when the vehicle is ready to return. These milestones separate diagnosis from administrative and logistics delays. They also show where a better record or clearer contact route could help.

Do not interpret a shorter recovery time in one exercise as a measured reliability improvement. The equipment may fail at exactly the same rate while the organization becomes better at responding. That distinction matters when the result is presented to fleet management. Reliability, diagnostic speed and repair availability should have their own evidence.

After the pilot, choose one concrete improvement for each avoidable delay. It might be a missing installation photograph, a clearer controller identifier or a documented route for obtaining an authorized replacement. This turns the service review into an operational improvement that can be checked on the next case.

Questions buyers often raise

Does a connected diagnostic tool make an HVAC system more reliable?

It can improve visibility and help a technician identify faults, but it does not by itself establish component reliability. Buyers should separate evidence about failure rates from evidence about diagnosis and recovery. A service demonstration shows what a tool can do; it does not replace durability testing of the installed equipment.

Is CAN compatibility enough for a vehicle integration project?

No. The exact signals, electrical arrangement, message definitions and controller versions must be agreed. Start with the function the vehicle needs and obtain confirmation from both sides of the interface. A shared communication technology does not automatically create shared control behavior.

Should every depot own the same advanced equipment?

That depends on the repair route and operating geography. Some fleets benefit from local diagnosis and a central specialist. Others need full capability at several sites. Compare the actual steps and delays in each arrangement, including training and account maintenance, before standardizing tools.

What should a buyer request from VETHY?

Bring the vehicle application, supply voltage, installation concept and required control functions. VETHY can discuss the proposed HVAC scope and the documentation needed for evaluation. Use the vehicle HVAC project page or RFQ guide to define the brief. Any diagnostic interface, software function or third-party integration must be confirmed for the proposed configuration.

Turn the announcement into a better project brief

The practical lesson from connected service announcements is to make support observable. A buyer should be able to see how a technician identifies the unit, reads relevant information, follows approved instructions and records the result. This creates a clearer basis for comparison than a general claim that a product is smart or connected.

For a new project, attach a one-page service schedule to the technical brief. List the required records, permitted access roles, offline expectations, escalation route and replacement setup process. Ask the supplier to respond against each item. Resolve unknowns during the sample stage, while the installation and support arrangements can still be adjusted.

That approach also protects the commercial relationship. When responsibilities are written clearly, the customer knows what to provide and the supplier knows what evidence is expected. The result is a vehicle HVAC purchase evaluated as an operating system with a support life, rather than a hardware item that becomes somebody else's problem after delivery.