Secondary displays and HUDs must agree with cluster and stack, not contradict them

What it is

A head-up display, passenger screen, rear screen, or wheel mini-display is another surface besides cluster and center stack. It may repeat or excerpt what those two already show. It may not tell a second story: a HUD speed limit that disagrees with the cluster, passenger navigation that takes the driver down another road, a rear-seat destination fighting the route the stack is computing. Conflict is worse than absence—absence sends people to the authority screen; conflict makes them choose between two facts, and those seconds are not on the road. This entry is whether multiple screens share one world. It is not how far a virtual image should sit; that is the HUD’s own optics.

Why it happens

People assume one vehicle has one traffic picture and one destination at a time. Multiple screens fed by different app instances, different refresh beats, or a passenger setting written only to their own panel break that assumption. A HUD sits in the forward view, so a conflict is taken as a fact about the road. Another route on the passenger display is read in peripheral vision as “the system changed its mind.” Conflict is not only a different number: opposite arrows, a mismatch in arrival time, automation lamps on in the HUD and off in the cluster. Refresh lag makes a brief conflict of its own: the stack has a new destination, the HUD still draws the old next act.

Studying it

Stage dual routes, dual speed limits, or dual automation states, conflicting only in the HUD, only on the passenger display, or nowhere, and watch which surface people follow and how long they take to notice.

Independent variables: conflict type (value / direction / state), surface that hosts the conflict, whether the two screens refresh together. Dependent variables: follows of the wrong source, time to notice, extra glances to reconcile, spoken “which one do I trust.”

Making the conflict lurid in the lab overstates detection; a 5 km/h limit gap or a one-exit offset in a real product is more often taken as “I misread.” Treat a passenger changing the destination as its own condition, not only system-side desync.

Where it stops holding

A passenger movie or a rear-seat game is not required to match the cluster; it is required not to write a second navigation or control-authority state for driving. A black screen or “no signal” is absence, not conflict. Small geometric differences between map vendors are usually not a driving conflict if arrows and gross direction still agree; opposite exit numbers or opposite lane-level guidance are. Desktop multi-display window placement is a workflow issue with no forward roadway, and is not the magnitude of cabin conflict.

Applying it

• Push driving-related speed limit, next act, and control-authority from one data source to HUD, cluster, and stack; do not let each app compute its own.
• A passenger change of destination must become the vehicle’s one route before it appears on any driver-visible screen; drafts on the passenger panel must not enter the HUD.
• Align refresh so one glance can see the same frame of fact; if that is impossible, let the secondary screen lag rather than announce ahead of the authority screen.
• Verify by opposing HUD and cluster on the next exit and counting how many drivers follow the HUD before they change lanes. That share is conflict taken as road fact.

Related

• Within the group: K6.11.1 The cluster shows driving-critical real-time information, not optional functions · K6.11.2 The center stack carries navigation, media, and other secondary work · K6.11.4 Repeated information across screens needs a designated source of truth
• Adjacent: K6.05 Head-up Display · K6.07 Passenger and Rear-seat Interaction
• Search terms: HUD conflict · multi-display consistency · in-vehicle HMI · source of truth