Part of Firmware Reversing.

• File offset: 0x78834c (VA 0xf7016040)
• Status: 🟡* Partially traced — clean prologue-to-blr (1,636 bytes, 0x78834c-0x7889b0; the next real prologue starts immediately at 0x7889b4, no gap), but a large, heavily-branching body with the usual interstitial <data> word-pairs — a full line-by-line reconstruction wasn't pursued.
• Real name source: not found in the symbol table under any name searched so far — found immediately after DumpNavGraph while mining the new AdasTools/CArr_AdasMain class family, see Firmware Reversing.

Target	What it suggests
PSD_getAdasSpeedLimit__FUl20ADAS_SPEED_DIRECTION	A real, global "PSD" function — plausibly Posted-Speed-Display — reading an ADAS speed limit for a given direction. UPDATE, walked back: originally described as "presumably from a camera-based ADAS module" — that specific claim wasn't well-supported and is retracted. The direction parameter is a strong signal for a map-attribute lookup instead (direction-dependent posted limits are a real, period-correct digital-map attribute; a camera reporting a detected sign wouldn't need "which direction" as an input the way a map-segment query would). No camera/video-decoder class appears anywhere in the whole-file reloc-confirmed name catalog (1,573 names), which is more consistent with map-sourced than camera-sourced data
__vd__18TIMEx_FlowExplorerPvUi (called twice)	Same real TIMEx_FlowExplorer destructor seen on DumpNavGraph — another confirmed real link to the TMC pipeline
handlePosCoord__19CArr_NavigationMainPcRlT2Ri	Same real position-coordinate handler seen on DumpNavGraph
readDouble__20CfcIoBinaryUcs2CodecR13CfcUtilBuffer	Same real double-decoder seen on DumpNavGraph
__vd__19CfcNetMemoryChannelPv / _vt$25CfcNetServerMemoryChannel	Lower confidence than originally stated — the "already confirmed on mv_convert_slot_nr" claim this entry leaned on is now retracted (that page's own CfcNetMemoryChannel reference was confirmed wrong), and spot-checking this specific address (0x6a8e1c) independently shows content inconsistent with a simple destructor (a multi-branch dispatcher, not a short teardown routine). Not re-verified further; read as unconfirmed
__as__23CfcTypeObjectDescriptorRC23CfcTypeObjectDescriptor	Real assignment operator on a CfcTypeObjectDescriptor — object-descriptor bookkeeping as part of message handling
setJunctionId__16CfcTypeNavDBInfoi	Same shared primitive seen repeatedly on mv_convert_slot_nr/mv_lefthand_traffic — consistently paired at its call sites with a (small int, larger int) literal pair (0x76,0x33b here), the same shape seen at every other call site of this function across this wiki. UPDATE: resolved — this is almost certainly a call to unk_F6F24CE8, this project's now-identified real throw/EH-dispatch runtime entry point (see Firmware Reversing), whose own first two arguments are exactly a (category-id, descriptor-table-pointer) pair — the "larger int" is very likely itself a VA/pointer value, not a line number. Not re-verified at this specific call site, but the shape now has a confirmed, concrete explanation rather than being an open pattern.

UPDATE: revised, after re-examining the evidence against what's actually known about this specific head unit generation. A real function handling ADAS/map-attribute speed-limit data, rate-limited the same way as DumpNavGraph (same +0x4c54 global counter family, same 0xa-ish small-threshold shape), that reads a posted speed limit and touches the TMC (TIMEx_FlowExplorer) and navigation-position (CArr_NavigationMain) pipelines. The earlier "receives a detected speed-limit sign from an external ADAS camera module" framing is retracted — it was speculation that went beyond what the evidence supports (see the retraction on the PSD_getAdasSpeedLimit row above), and it doesn't sit well against this hardware generation's known real capabilities: the RNS-510 (circa 2007-2008, VW's "Silver" navigation platform generation, pre-dating MQB-era eHorizon/ADAS sensor integration) is well-documented as using static NAVTEQ-era map data with no onboard camera/radar sensor fusion, and no path to display camera/radar-derived driver-assist data. The "communicates over a server-side memory channel" claim is also retracted — it rested on a CfcNetMemoryChannel reference no longer trusted (see the Callees table above).

What IS solidly confirmed: this firmware's ADAS-adjacent code really does use a genuine MOST bus (Media Oriented Systems Transport) for communication — the whole-file reloc-confirmed name catalog (see Firmware Reloc-Confirmed Names) found a real class, Adas_Most_Dispatcher (Send, SetFBlockAvailable, DispMqStruct). But MOST was a general-purpose automotive multimedia bus, not something exclusive to camera/radar ADAS — it's equally consistent with this code sending map-derived speed-limit/horizon data to OTHER systems (e.g. instrument-cluster display, adaptive transmission/headlight controllers on higher-trim platform variants sharing this same supplier codebase) rather than receiving camera input. Likely best explanation overall: this compiled binary is shared navigation-platform code (from the same supplier, Siemens VDO/Continental, across a family of related head units and trim levels/model years) that includes real, genuinely-compiled map-attribute-driven "electronic horizon"-style data distribution — the existence of this code does not by itself mean this specific RNS-510 configuration exercises it with real camera/radar hardware, which it most likely doesn't have.