Audi Central Gateway

Audi Central Gateway#

The Audi cGW3.1 is a central vehicle-network gateway with a real-time control domain, an application-processor domain and automotive Ethernet hardware. Its software combines vehicle-bus integration, diagnostics, software updates, connected-vehicle applications, feature authorization and authenticated time.

This reference describes the CGW’s hardware, software organization, interfaces, message formats and implementation behavior. Address-specific details are scoped to their firmware variant. Configuration defaults and compiled client interfaces do not imply that every vehicle variant enables the same functions.

Architecture#

                       Backend and cBox roles
                               |
                 Application-network integration
                               |
       +-----------------------+-----------------------+
       |       Automotive Ethernet gateway domain     |
       |       BCM device; exact routing unresolved   |
       +-----------------------+-----------------------+
                               |
       +-----------------------+-----------------------+
       |                                               |
 i.MX6Solo application platform                 MPC5748G MCU
 U-Boot / Linux / Android                       PowerPC BE VLE
 Mindroid / Java services                      Native UDS / XCP
 Cloud / dealer / recovery                     FoD / time / NV
       |                                               |
       +---- Logical vehicle-message integration ------+
                               |
                    CAN / FlexRay / Ethernet

The diagram expresses software and functional roles, not a complete electrical schematic. The exact BCM part, port policy and mapping of internal software connections to physical links remain unresolved.

The application platform is identified as i.MX6Solo revision 1.4, ARMv7 at 792 MHz with 256 MiB RAM, Android 6.0.1/API 23 and Linux 4.1.49 PREEMPT. The Java core is Y317/v15.3.3-r1, built2018-03-16. These identifiers belong to the application platform, not automatically to the native MCU firmware.

For native addresses, MCU image A names the PowerPC implementation described in the functional chapters. Earlier MCU images have separately scoped addresses and behavior. Their correspondence and the commercial version of image A are not fully established. The architecture chapter defines the software variants and memory regions.

Reference Chapters#

Topic	Contents
Architecture and software	Processor domains, software variants, memory organization, runtime and internal service roles.
Physical interfaces	Main connector, CAN/FlexRay pin groups, Ethernet activation, board debug contacts, UART, JTAG, reset and recovery selection.
Communication stacks	CAN/ISO-TP, FlexRay, DoIP, XCP, native transports, vehicle-message framing and RPC boundaries.
Diagnostics and programming	UDS services, sessions, SecurityAccess, DIDs, routine contracts, CheckMemory and programming paths.
Vehicle functions and bridge	Vehicle/application families, channels, message IDs, codecs, FoD manager and bridge state machines.
FoD, cryptography and NV	FSC layouts, signature verification, key rotation, cache consumers, persistence and restore behavior.
Authentic time	Challenge/response policy, reassembly, signature verification, calendars, software clocks, cache and storage.
SOME/IP RPC and Testability	Service and method IDs, payload types, dispatch, callbacks, configuration and the CGW’s Testability service.
Platform, cloud and updates	Boot/storage, Mindroid services, connected applications, cloud roles, dealer ODIS, recovery and OTA.
Implementation constraints	Security-control boundaries, state/ownership semantics, parser limits and unresolved implementation details.

Interface Overview#

Hexadecimal identifiers use an explicit 0x prefix below; port numbers and rates are decimal. Protocol namespaces are independent, even when numbers overlap.

Interface	Addressing / Format	CGW Role
Diagnostic CAN	Classic CAN500kbit/s; ISO-TP requests0x710, responses0x77A	UDS diagnostic endpoint.
CAN XCP	Extended identifiers0x18FC8600 request /0x18FC8601 response	Separate measurement/calibration protocol implementation.
DoIP	TCP/UDP13400; logical addressing independent of CAN IDs	Native diagnostic integration and companion diagnostic client.
Vehicle-message bridge	BE16 category, BE16 selector, BE16 payload length; payload<=250 bytes	Logical vehicle models, diagnostics and application integration.
Companion vehicle connector	TCP57032 to role `gateway`	Six-byte framed vehicle stream, not RPC.
Data collector	Independent TCP57042 connector	Collection/configuration path distinct from the vehicle stream.
Companion RPC	TCP29173 to role `cbox`;16-byte SOME/IP framing	NetworkAccess, Voice, PubSub and configuration integration.
CGW Testability service	Service0xFF00; optional listener30601	Typed echoes, event triggers and callback lifecycle, not arbitrary memory access.
Dealer ODIS	TCP60000; control and recovery phases	Recovery selection and update transfer.
UART	Described921600-baud connection and115200-baud Linux console	Physical-net identity, routing and variant applicability remain unresolved.
Board debug	TMS/TCK/TDI/TDO, RESET, TX/RX, VCC/GND labels	Board-level debug and console signal access; electrical limits remain qualified.

The native bridge’s generic connection installer is known, but its concrete bearer and peer binding are not. The Java57032 connector alone does not identify that native implementation. Image A independently binds UDP10510 for the 182-byte Ethernet/FlexRay bridge, separately from its CAN XCP implementation.

Vehicle And Application Functions#

The vehicle-message registry contains420 records and417 distinct group/ID keys, with135 referenced models and225 complete model/binder/serializer triples in the core archive. Its five populated groups are Vehicle, Logging, Diagnostics, GatewaySystem and BasebandSystem. Three OTA selectors have duplicate definitions; this core’s inbound lookup is first-wins, with three later records shadowed and both reverse topic mappings retained.

Application families include remote locks and alarm, vehicle status and tracking, climate/heating, charging/departure planning, mobile key and roles/rights, diagnostics, data collection, FoD, authentic time and software updates. Presence of a model or application archive is not a list of enabled commercial rights.

The complete registry, model-class associations and26 application archive entries are available as the vehicle catalog.

Full Vehicle Stream Reference#

Framing and dispatch: gateway-role TCP57032, lookup, lifecycle, errors and ordered interceptors.
Complete functions: 420 records, 417 keys, directions, wakeup metadata and gates.
Payload schemas: 135 XML models plus 12 nested models, 567 fields per direction.
Subscriptions: local topic associations, application bindings and unresolved semantics.
Functions JSON and Functions CSV.
Schemas JSON, Subscriptions JSON and Protocol JSON.

Diagnostic And Authorization Model#

UDS is implemented through separate registered providers, catalog entries and fallback handlers. Session bytes0x01/0x02/0x03/0x40/0x4F have distinct contracts; OEM0x40 is not an alias for standard programming0x02. Gates also include source, readiness, operation state, length and sequencing requirements.

FoD FSC data can be staged through DID0x3C01 and processed through RID0xC001. Staging, structural acceptance, signature verification, entitlement application and nonvolatile completion are distinct stages. Type-05 key replacement uses the selected incumbent verifier and separate context/freshness checks; public-key exports do not expose a private signer.

Authentic time uses a retained challenge, a restricted five-field response and RSA-PSS/SHA-256 verification. Its setter updates software calendars/counter anchors; a physical RTC/OS-clock write is not established. DIDs0x5487/0x5488 return cached calendar forms whose invalid fallback is indistinguishable on the wire from a valid2000-01-01T00:00:00 value.

Asynchronous admission, completion and durable storage are separate throughout the native implementation. Fixed routine results, positive acknowledgements and cache population must be interpreted through their specific producers.

Full RPC Reference#

The companion application defines five services,81 methods and28 events. NetworkAccess, VoiceManager, PubSub and CBoxConfiguration are compiled remote clients; Testability also has a local server. Its23 sparse implemented methods must not be mistaken for every ID from1 through88.

The detailed chapters retain unresolved bindings rather than assigning unsupported sensor names, commercial feature names, physical peers or cryptographic primitives.