Feature availability

The screens and actions you see depend on the version of Hanterill you installed and the equipment in your car. The app checks which control units respond before showing vehicle-specific options. This page explains why an option may appear for one car and be absent for another.

How availability is reported#

Every vehicle capability in Hanterill falls into one of three clear categories:

Directly measured

Confirmed on the cable because the specific control unit or sensor answered a diagnostic read.

Derived from measured modules

Inferred by a transparent rule from a module that answered (for example, when a diesel aftertreatment module answers, diesel exhaust service panels apply).

Not observable in read-only mode

Requires factory server data or an undecoded internal configuration table that cannot be confirmed from a standard read.

Whenever a capability cannot be confirmed from a read-only check, Hanterill marks it as unknown and explains what information is missing, rather than falsely claiming that your car does not have that equipment.

How Hanterill detects what is installed on your car#

Rather than trusting a static lookup table, Hanterill checks which control units actually answer on your vehicle's network. From those responses, the capability check determines whether your car has:

• Electric drive controllers and high-voltage battery management
• A combustion engine or hybrid transmission controller
• A 48-volt mild-hybrid battery system
• Four-corner air suspension
• All-wheel-drive rear axle or differential electronics
• Forward driver-assistance cameras and blind-spot corner radars
• A Vehicle Gateway Module

Any valid response from a module proves that the hardware is physically installed on the car, even if a module reports a serial number in a slightly different format than expected. Only a complete lack of response (a timeout) or a platform where that module does not exist counts as absent.

Why a few features show as "unknown" until decoded#

A handful of vehicle options (such as whether a car has a panoramic glass roof or which type of tyre-pressure monitoring it uses) are stored inside a compact binary configuration block inside the central body computer rather than having their own separate control unit. When a specific setting is not yet decoded for your platform, Hanterill shows its capability status as unknown rather than guessing.

Checking module software levels#

Some diagnostic procedures and features depend on which software version a control unit is running. Hanterill reads software versions directly from the relevant modules in read-only mode, including:

Infotainment software level

Read directly from the Infotainment Head Unit (IHU).

Climate controller software level

Read directly from the Climate Control Module (CCM).

Brake controller software level

Read directly from the Brake Control Module (BCM2).

Aftertreatment software level

Read directly from the aftertreatment module when fitted on combustion models.

Hanterill displays the exact software version reported by the car. It does not make automated claims about whether a software version is "outdated" or "buggy," because official manufacturer service bulletins are stored on dealership servers rather than inside the vehicle.

How service and maintenance families are gated#

Before showing a maintenance routine or subsystem status panel, Hanterill checks both whether the procedure is supported by the app and whether the required hardware is present on your car:

Read-only status available

Hanterill can read the subsystem's live status and health indicators without changing anything on the vehicle.

Confirmed service routine available

The maintenance routine is built in and available behind confirmation dialogs and safety checks.

Read-only today (routine not yet mapped)

Hanterill can read sensors and fault codes for this subsystem, while the active workshop routine is not yet available.

Blocked by design

Arbitrary raw memory writes and unverified commands are permanently blocked so the app cannot corrupt module memory.

Equipment gating prevents you from running a routine that does not match your car. For example, camera and radar calibration checks require the forward camera or blind-spot radars to be present on the vehicle, and active grille shutter tests require the corresponding front controller.

Inspecting subsystem status in read-only mode#

Many workshop procedures have companion status readings that report whether a calibration is valid, whether a service counter is due, or whether a subsystem is ready. Hanterill can read all of those status indicators in a single read-only pass, opening a diagnostic session once per module and grouping the results by system family so you can inspect the car's maintenance state without triggering any actuators.

What capability checks do not do#

• No hidden server locks: Capability checks run 100% locally between your laptop and the car; they never check an online account or subscription.
• No silent hiding: When a feature is unavailable on your platform or trim level, Hanterill tells you which module or capability was absent rather than hiding the explanation.

Next#

• Service functions: the maintenance routines protected by capability and safety checks.
• Safety: how read-only mode and confirmation gates protect your vehicle.
• Supported vehicles: what is verified on CMA, SPA, and SEA1 vehicles.
• Data identifiers: how Hanterill reads individual values from each module.