KopherUDS: ECU-Side UDS Diagnostic Middleware

Summary

KopherUDS provides configurable automotive UDS diagnostic middleware. It combines DCM, DEM, NM, DoCAN / ISO-TP, and DoIP / TCP-IP into a reusable diagnostic runtime, then connects DID, DTC, Routine, I/O, memory, flash, and boot behavior through project callbacks.

Interactive PC diagnostics, automated testing, trace, and reports belong to KITE UDS Tester. Kopher Config, KopherUDS, and KITE UDS Tester can share DID, DTC, Routine, session, and security definitions, reducing duplicated diagnostic data across ECU and PC tooling.

Product Roles

Component	Engineering role
Kopher Config	Manages diagnostic definitions, validates project rules, and generates ECU configuration.
KopherUDS	Runs diagnostic services, event handling, network state, and transport inside the ECU runtime.
KITE UDS Tester	Performs interactive PC diagnostics, automated validation, trace, and report export.
KopherBoot	Owns PBL / SBL, flash programming, secure boot, recovery, and the safe-update lifecycle.

These products share diagnostic data and parts of the BSW foundation so configuration, ECU runtime, PC validation, and programming workflows use one consistent diagnostic model.

Runtime Architecture

Layer	KopherUDS responsibility
Application / Boot Integration	DID, DTC, Routine, I/O, memory, and flash / boot callbacks.
DCM	Diagnostic Session, SecurityAccess, service routing, P2 / P2* timing, positive / negative responses, and pending flows.
DEM	Events, debounce, snapshots, extended data, DTC state, clear / report, and ControlDTCSetting.
NM / ComM / PduR	Network wake / sleep, diagnostic communication hold, and message routing.
Transport	DoCAN / ISO-TP and DoIP / TCP-IP.
Platform Services	CAN / Ethernet drivers, NvM / Fee / Ea, flash drivers, and the target MCU.

Application hooks remain project-specific. The shared diagnostic core owns protocol and state management, while each ECU project owns actual data sources, hardware I/O, Routines, memory protection, and flash policy.

Configurable UDS Services

KopherUDS provides selectable UDS service modules for each ECU profile, covering common session, ECU control, DTC, DID, memory, SecurityAccess, communication, Routine, and programming workflows.

Group	Dedicated core handlers
Session / ECU Control	0x10 DiagnosticSessionControl, 0x11 ECUReset, 0x3E TesterPresent
DTC	0x14 ClearDiagnosticInformation, 0x19 ReadDTCInformation, 0x85 ControlDTCSetting
Data / I/O	0x22 ReadDataByIdentifier, 0x24 ReadScalingDataByIdentifier, 0x2E WriteDataByIdentifier, 0x2F InputOutputControlByIdentifier
Memory / Security / Communication	0x23 ReadMemoryByAddress, 0x27 SecurityAccess, 0x28 CommunicationControl
Routine / Programming	0x31 RoutineControl, 0x34 RequestDownload, 0x35 RequestUpload, 0x36 TransferData, 0x37 RequestTransferExit

Authentication, periodic DID, dynamic DID, file transfer, secured data transmission, response on event, link control, and related needs can be extended for the relevant OEM, transport, security, storage, and ECU profile.

Each ECU can configure services, subfunctions, sessions, security levels, and callback behavior so the shared diagnostic core fits different controllers and in-vehicle network architectures.

DID, DTC, and Routine Integration

• DID paths cover lists and ranges, multiple DIDs, sync / async client-server, sender / receiver, and optional NvM integration.
• DEM connects events, debounce, snapshots, extended data, and DTC state to DCM clear, report, and ControlDTCSetting paths.
• RoutineControl covers StartRoutine, StopRoutine, and RequestRoutineResults while each project implements the actual Routine callbacks.
• Memory and programming services provide negotiation, transfer state, and callbacks; the project or KopherBoot owns allowed regions, erase / write, verification, and recovery policy.

SecurityAccess Integration

UDS 0x27 uses configurable GetSeed / CompareKey callbacks to separate the diagnostic service core from the actual algorithm. DCM policy can handle pending operations, attempt counters, delay timers, and NRC 0x35 / 0x36 / 0x37 before a project connects a software algorithm, HMAC, or HSM / SHE-backed key service.

This boundary keeps the UDS service flow stable without hard-wiring OEM key policy or protected key material into the shared diagnostic core.

Engineering Workflow

1. Define DID, DTC, Routine, session, SecurityAccess, timing, and transport profiles.
2. Use Kopher Config to validate rules and generate the ECU configuration required by KopherUDS.
3. Integrate DCM, DEM, NM, transport, and application / boot callbacks with the target MCU.
4. Use KITE UDS Tester for interactive diagnostics, automated tests, trace, and report export.
5. Reconcile generated configuration, PC evidence, and on-target behavior for project acceptance.

Project Delivery

KopherBit can support diagnostic specification preparation, Kopher Config configuration, KopherUDS stack integration, application callbacks, transport and platform-service integration, plus KITE UDS Tester test cases, trace, and reports. Delivery scope can be tailored to the ECU, OEM diagnostic specification, and development phase.

FAQ

What is the difference between KopherUDS and KITE UDS Tester?

KopherUDS is ECU-side diagnostic middleware; KITE UDS Tester is a PC diagnostic instrument. KopherUDS handles DCM, DEM, NM, and transport inside the ECU, while KITE UDS Tester sends service requests and provides response / NRC analysis, automated testing, trace, and reports.

How is the KopherUDS service scope configured?

Engineering teams select session, DID, DTC, Routine, SecurityAccess, memory, communication, and programming services for each ECU profile, then configure subfunctions, sessions, security levels, timing, and project callbacks. OEM-specific services can be extended on the same architecture.

Does it support DoCAN and DoIP?

The architecture provides DoCAN / ISO-TP and DoIP / TCP-IP integration paths. Actual drivers, PduR, ComM, NM, network profiles, and on-target timing must be configured and validated within the ECU project.

How do KopherUDS and KopherBoot divide responsibility?

KopherUDS provides the application-side ECU diagnostic core and programming service hooks. KopherBoot owns the boot stage, flash flow, startup trust, recovery, and safe-update lifecycle. They can reuse parts of the diagnostic BSW foundation but remain separate products.