Automated Vehicle Recovery HMI: Show State Before Permission to Move

If an automated vehicle is stopped in a minimal-risk condition, the recovery HMI should not combine diagnosis, permission and motion into one ambiguous action. Show the verified vehicle state first. Make the operator confirm that the data is fresh and the recovery path is allowed. Only then expose or enable a deliberate motion command. For the front-interface RFQ, freeze status zones, warning legends, display-window geometry, authorization cues, tactile controls, backlighting and the controller boundary before approving the sample. A clear overlay or keypad supports the workflow, but it does not replace the automated-driving logic or vehicle-level safety validation.

Why this recovery-interface question is timely

An original paper submitted on August 7, 2026 examines what happens after an automated vehicle reaches a minimal-risk condition and a human intervention operator may need to decide whether the vehicle should stay where it is, return to traffic or move to another position. The researchers organize almost 30 possible causes and use scenario trees to show how many conditional decisions can follow a stop.

The paper is not a Baoshengda study and it does not specify a front-panel supplier. Its useful interface consequence is more direct: the operator needs reliable real-time status, an understandable representation of the vehicle and its surroundings, and protection against accidental operating actions. That turns a systems problem into a concrete HMI procurement question. Which information belongs in the visible state layer, which action confirms permission, and which control can actually request motion?

Use three layers instead of one recovery screen

A practical recovery HMI can be reviewed as three separate layers.

1. **State:** What condition is the vehicle in, why did it stop, which data is valid, and how old is that data?

2. **Permission:** Has the required health check passed, is the route or action authorized, and is the operator acting in the correct role?

3. **Motion:** Which limited action is being requested, what feedback confirms the request, and how can it be stopped or cancelled?

The layers can share one enclosure, but they should not look like interchangeable menu choices. A green status indicator is not permission to move. A selected route is not a motion command. A command acknowledgement is not proof that the vehicle executed the action.

This table is an interface review aid, not a safety architecture. The vehicle or system owner must define what actions are allowed and under which conditions.

Keep state presentation legible before adding controls

The front panel should make abnormal state easier to understand, not merely fit more icons around a display. Start with the information the operator must see before touching a control.

• Reserve a stable area for stopped, degraded, recovery-ready and unavailable states.
• Show data freshness or communication loss where it cannot be mistaken for a vehicle fault.
• Separate warnings that block movement from advisories that only add context.
• Keep the vehicle-state area readable when one or more channels are unavailable.
• Define day, night, dimmed and high-glare appearance for every critical legend.
• Avoid using one color as the only distinction between blocked, permitted and completed states.

For an automotive overlay or HMI panel, this affects window transmission, dead-front printing, icon spacing, diffuser zones and backlight isolation. It also affects the bezel and display geometry. A status symbol that looks clear in artwork can disappear after a smoked window, protective lens and night dimming are added.

Separate permission from the motion request

A common layout risk is placing a confirmation key beside directional keys and allowing the same key to mean both acknowledge and execute. That may shorten the menu, but it increases the chance that a status-review action becomes an operating action.

Before sample approval, define whether permission uses a separate key, a guarded sequence, a hold action, two-step confirmation or another system-owned method. Then make sure the front interface supports that decision. Useful checks include key spacing, different embossing, distinct tactile force, contrasting backlight behavior and adequate clearance around a stop or cancel control.

Do not let artwork decide the operating philosophy by accident. The function list must come from the controller and safety teams first. The overlay, keypad and display window should then express that allocation consistently.

Build an evidence matrix for every visible state

A rendered front view is not enough for this type of HMI. Ask for a state matrix that pairs controller output with the physical sample appearance.

For each important state, record:

• display content or window condition;
• illuminated and non-illuminated legends;
• enabled, disabled and hidden controls;
• expected tactile response;
• accepted and rejected key actions;
• acknowledgement and completion feedback;
• appearance after communication loss or power recovery.

Review the matrix on the mounted sample, not only on a loose overlay. Bezel shadow, lens tint, viewing angle and backlight leakage can change the meaning of adjacent zones. If a physical key is required, test it with the actual dome, spacer, adhesive stack and housing support. If the interface is touch-based, define the alternative response when touch input is unavailable or uncertain.

Define the supplier boundary before quotation

Baoshengda can review and manufacture component-level front interfaces such as automotive graphic overlays, display windows, backlit or dead-front legends, tactile membrane-key zones and related flex-tail circuits. The automotive HMI component page shows the closest product scope.

The interface supplier does not determine whether a stopped vehicle may re-enter traffic. The vehicle maker, system integrator or responsible controller team owns the diagnostic truth, communication path, operator authentication, authorization state machine, motion control, fail-safe behavior, cybersecurity and vehicle-level validation. A well-separated panel can reduce visual and tactile ambiguity, but it cannot prove that the recovery system is safe.

This boundary should appear in the drawing package and responsibility matrix. Otherwise a sample can pass appearance review while the system team assumes that critical logic or testing belongs to the panel supplier.

Prototype tests that expose confusing recovery controls

Run interface tests with the complete housing and representative controller states.

• Present the operator with a stopped state and confirm that motion controls remain unavailable until the defined permission condition is shown.
• Simulate stale or missing data and check that the loss indication is more prominent than any recovery-ready cue.
• Try the wrong key during each state and record the visible and tactile response.
• Review bright, dim and oblique viewing conditions for warnings, window contrast and dead-front legends.
• Check whether gloves, repeated use or low attention make adjacent keys difficult to distinguish.
• Power-cycle the unit and confirm that default artwork and backlight states do not suggest permission before the controller is ready.
• Inspect the tail, connector and rear clearance after the panel is mounted so a routing change does not alter key feel or display alignment.

A useful sample report includes photos of each state, controller-state references and a short exception list. It should not rely on a single photo of the normal screen.

RFQ checklist for a recovery HMI front interface

Send the following items with the quotation request:

• front artwork and mechanical outline;
• display active area, window, lens and bezel geometry;
• complete state, warning and telltale list;
• permission, motion, stop and cancel function allocation;
• enabled, disabled, hidden and flashing-state matrix;
• key type, force, travel, embossing and spacing requirements;
• backlight color, brightness, dimming and dead-front requirements;
• tail direction, connector, pin map and installed bend route;
• enclosure material, mounting method, cleaning and temperature conditions;
• controller-side truth table and sample acceptance evidence;
• supplier, integrator and vehicle-level validation responsibility matrix;
• prototype quantity and program stage.

When the state matrix and drawings are ready, send them through the Request Quote page. The first review should confirm that the visible status hierarchy, permission zone and physical control allocation can be manufactured without implying that the front-panel supplier owns the automated-driving decision logic.