System Overview

Executive Takeaway

The RFQX baseline describes an Electric Clutch Actuator ECU for the TRATON GW AMT platform. The functional actuator scope is requirement-backed; the final cybersecurity allocation still depends on customer decisions for diagnostics, update, PKI, secure communication, and evidence ownership.

Use this page as the system/security entry point, not as approval evidence.
Counts below support the interpretation; they are not a substitute for customer responsibility confirmation.

Snapshot

Requirements1076Markdown-derived

Features18Capability model

Interfaces10Trust boundaries

Security Capabilities13Security model

Traceability GateWARN - Customer Clarification NeededCurrent

Customer ReadinessReady for customer clarification workshopWorkshop

Product Definition

The system is a 24V electric clutch actuator (ECA) control ECU for the TRATON GW automated manual transmission (AMT) gearbox platform, delivering CAN- and PWM-commanded clutch engagement and disengagement with closed-loop position control and onboard error handling, and required to provide authenticated UDS diagnostics, secure software update and flash pr...

High-Level Diagram

High-Level System Overview Diagram

Vehicle/drivetrain context, the Electric Clutch Actuator ECU, and its main external interfaces and security paths.

flowchart TB Net["Vehicle Network (CAN)"] Tester["Diagnostic Tester"] Update["Software Update Package / Flash Backend"] PKI["Key and Certificate Provisioning"] OEM["OEM Security Backend (TRATON)"] SecOps["Security Event and Vulnerability Handling"] Dev["Supplier Development Environment"] subgraph ECA["Electric Clutch Actuator ECU"] App["Clutch Actuation Application Software"] Boot["Bootloader and Software Update Handling"] Sec["Security Services: keys, crypto, logging"] end Net <-->|CAN signals, PWM, actuator status| App Tester -->|authenticated UDS / Auth 0x29| Sec Update -->|signed software, IVD| Boot PKI -->|keys, certificates, trust anchors| Sec Boot --> App Sec --> App App -->|security events| SecOps SecOps -->|vulnerability feedback| OEM Dev -->|software, security evidence| OEM OEM -->|requirements, approval, residual risk| Sec

Mermaid source

flowchart TB
  Net["Vehicle Network (CAN)"]
  Tester["Diagnostic Tester"]
  Update["Software Update Package / Flash Backend"]
  PKI["Key and Certificate Provisioning"]
  OEM["OEM Security Backend (TRATON)"]
  SecOps["Security Event and Vulnerability Handling"]
  Dev["Supplier Development Environment"]
  subgraph ECA["Electric Clutch Actuator ECU"]
    App["Clutch Actuation Application Software"]
    Boot["Bootloader and Software Update Handling"]
    Sec["Security Services: keys, crypto, logging"]
  end
  Net <-->|CAN signals, PWM, actuator status| App
  Tester -->|authenticated UDS / Auth 0x29| Sec
  Update -->|signed software, IVD| Boot
  PKI -->|keys, certificates, trust anchors| Sec
  Boot --> App
  Sec --> App
  App -->|security events| SecOps
  SecOps -->|vulnerability feedback| OEM
  Dev -->|software, security evidence| OEM
  OEM -->|requirements, approval, residual risk| Sec

Capability Matrix

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Capability	Product Role	Architecture Component	Interfaces	Security Relevance	Evidence Status	Open Decision
Clutch Actuation Control	Core actuator control	Application Software / System Core	Vehicle Network Interface (CAN)	Safety-relevant command/status handling	Confirmed	Confirm final variant scope
Vehicle Integration and CAN Communication	Vehicle command/status exchange	External Interfaces / Application Software	Vehicle Network Interface (CAN), PWM wake-up	Message authenticity/freshness allocation	Confirmed	Confirm signal catalog and SecOC/SDT scope
Secure Diagnostics and Role-Based Access	Controlled service and engineering access	Diagnostic Server / Security Services	Diagnostic Tester Interface	Privileged access control	Inferred	Confirm roles, service list and lockout policy
Secure Software Update and Flash	Maintain trusted ECU software	Bootloader / Update Logic	Update / Flash Interface, Diagnostic Tester Interface	Software authenticity and integrity	Inferred	Confirm signing chain, rollback and ownership
Key and Certificate Handling	Trust-material lifecycle	Security Services / Hardware Platform	PKI / Provisioning Interface	Root of trust for diagnostics, update and secure communication	Inferred	Confirm HSM capability, key hierarchy and PKI ownership
Secure Data Transfer / Communication Boundary	Protected security-relevant data exchange	Security Services / External Interfaces	Vehicle Network Interface, Secure Data Transfer Interface	Authenticity, integrity and freshness	Inferred	Confirm protected signals and freshness model
Security Logging and Event Handling	Security evidence and response input	Security Services / Backend and IT Systems	Logging / Event Reporting Interface	Auditability and incident support	Inferred	Confirm event set, storage and reporting path
Cybersecurity Lifecycle and Evidence	Approval-ready security case	Compliance Process / Engineering Toolchain	Supplier Evidence, OEM Approval Interface	Traceable residual-risk argument	Confirmed	Confirm DIA split and approval authority

Interface Matrix

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Interface	Source	Target	Data / Control Flow	Trust Boundary	Security Controls	Open Decision
Vehicle Network Interface (CAN)	Transmission control / vehicle ECUs	ECA application software	CAN demand, PWM wake-up, actuator status and DTCs	Vehicle network to ECU	Signal validation, freshness, authenticity where allocated	Confirm topology, signal catalog and protection profile
Diagnostic Tester Interface	Service / engineering tester	ECA diagnostic server	UDS requests, Auth 0x29, sessions and programming	External service tool to ECU	Authentication, authorization, lockout, rate limiting and audit	Confirm role model and service whitelist
Software Update / Flash Interface	Programming tool or update backend	Bootloader / update logic	Signed packages, IVD data and programming results	Offboard update source to ECU	Signature validation, integrity checks, rollback control and logging	Confirm signing chain, rollback and backend owner
Key and Certificate Provisioning Interface	PKI / provisioning authority	ECA security services	Keys, certificates and trust anchors	Trust authority to ECU	Protected storage, certificate validation and lifecycle control	Confirm PKI owner, HSM capability and renewal/revocation
Secure Data Transfer Interface	Vehicle network peers	ECA security/application services	SecOC/SDT protected messages, counters and MACs	ECU-to-ECU data boundary	Freshness, replay protection, MAC verification and discard rules	Confirm message allocation and profile
Security Logging / Event Reporting Interface	ECA ECU	Backend / security operations	Security events, diagnostic attempts and update results	ECU to offboard operations	Event integrity, retention, access control and privacy treatment	Confirm upload path, retention and owner
Supplier Development / Evidence Interface	Supplier ALM / CI / test environment	Evidence repository and release process	Requirements, tests, builds, traceability and release artifacts	Engineering environment to evidence baseline	Access control, artifact integrity and audit trail	Confirm tool ownership and evidence retention
OEM Approval / Evidence Interface	Supplier security engineering	TRATON / OEM review board	Cybersecurity concept, V&V evidence, risks and decisions	Supplier to OEM governance boundary	Controlled evidence handoff and decision logging	Confirm approval workflow and residual-risk authority

Security Matrix

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Security Capability	Protects	Applied To	Mechanism	Evidence	Open Decision
Secure Diagnostics and RBAC	Diagnostic access state and privileged services	Diagnostic Tester Interface / Diagnostic Server	UDS Auth 0x29, authorization, lockout and audit	Strong	Confirm final role model and service list
Secure Software Update	ECU software and firmware authenticity	Bootloader / Update Logic	Signed packages, integrity validation, rollback control and update logging	Strong	Confirm signing chain, rollback and campaign ownership
Data Authenticity and Integrity Verification	Security-relevant vehicle data	Vehicle Network / Secure Data Transfer Interface	SecOC/SDT-style MAC, freshness and replay rejection	Moderate	Confirm protected signal allocation
Key and Certificate Handling	Keys, certificates and trust anchors	Security Services / Hardware Platform / PKI	Provisioning, validation, protected storage and renewal/revocation	Strong	Confirm HSM capability and PKI ownership
Communication Boundary Control	Vehicle and offboard interface boundaries	External Interfaces / Security Services	Input validation, boundary filtering and fail-safe discard behaviour	Moderate	Confirm exact boundaries and failure policy
Security Logging	Security event evidence	Logging / Event Reporting Interface	Event capture, retention, integrity and reporting	Moderate	Confirm event set and reporting channel
Vulnerability and Incident Handling	Field security posture	Security Operations / Compliance Process	Vulnerability intake, triage, mitigation and incident workflow	Strong	Confirm reporting channels and responsibilities
Cybersecurity Evidence and DIA	Approval and residual-risk case	Engineering Toolchain / OEM Approval Interface	Traceability, V&V evidence, decision logging and residual-risk approval	Strong	Confirm DIA split and authority

Top Conclusions

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Conclusion	Status	Evidence	Impact	Decision Needed
ECA ECU product identity and AMT platform context	Confirmed	3299216_1.md function statements; system_identity.md	Stabilizes review-board naming	Confirm final product designation/variant
Cybersecurity concept and evidence package are in scope	Confirmed	Cybersecurity and process requirements	Makes this an architecture/security baseline, not a brochure	Confirm approval workflow
Secure diagnostics, update and key/certificate handling apply to the ECU	Inferred	UDS, flash/IVD and certificate/key requirements	Drives security services and trust-boundary design	Confirm exact allocation
SecOC/SDT-style protection is needed for selected data flows	Requires Confirmation	Secure communication requirements	Blocks final interface-security allocation	Customer must identify protected signals

Evidence

Executive system overview evidence

1. Executive Conclusion

The system is the Electric Clutch Actuator (ECA) Control ECU for the TRATON GW Automated Manual Transmission (AMT) Gearbox Platform. Its confirmed job is CAN- and PWM-commanded clutch actuation with position feedback and error handling. The requirement set is dominated by cybersecurity obligations: authenticated diagnostics, secure software update, and key/certificate handling. The actuation function and the obligation to deliver a cybersecurity concept with evidence are confirmed; the concrete security mechanisms, diagnostic roles, key hierarchy and final item definition still require customer confirmation. This package is a concept and TARA-input baseline, not a final risk assessment.

Classification legend: Confirmed = explicit in requirements; Inferred = strongly implied; Requires Confirmation = customer decision needed.

2. What This System Is

A safety-related 24V electric clutch actuator (ECA) ECU with its own embedded controller, common across the TRATON GW AMT driveline range (city bus to heavy haulage). Evidence basis: REQ-AUTO-00063; REQ-AUTO-00064; REQ-AUTO-00065; REQ-AUTO-00066; REQ-AUTO-00069; REQ-AUTO-00072; REQ-AUTO-00078; REQ-AUTO-00079 (showing 8 of 57).

3. What This System Does

Engages and disengages the clutch on CAN/PWM position and speed demand with closed-loop position control.
Reports actuator position, status and faults onto the vehicle network.
Exposes authenticated UDS diagnostics and service/programming access.
Accepts authenticity- and integrity-verified software updates and flash programming.
Provides key/certificate handling and security logging to support the vehicle security concept.

4. Main System Features

The eight top-level product capabilities below are graded against the extracted requirements.

Capability	Confidence	Executive description
Clutch Actuation Control	Confirmed	CAN- and PWM-commanded clutch engage/disengage with closed-loop position control and onboard error handling.
Vehicle Integration and CAN Communication	Confirmed	Position/speed demand and actuator status exchanged over the CAN bus plus a 1kHz PWM wake-up signal.
Secure Diagnostics and Role-Based Access	Inferred	Authenticated UDS services including Authentication 0x29, role-based access, lockout and logging.
Secure Software Update and Flash	Inferred	Authenticity- and integrity-verified flash/IVD programming with bootloader and application state control.
Key and Certificate Handling	Inferred	Provisioning, validation and lifecycle handling of keys, certificates and trust anchors.
Secure Data Transfer / Communication Boundary	Inferred	SecOC/SDT-style authenticity, integrity and freshness on security-relevant vehicle data.
Security Logging and Event Handling	Inferred	Recording of security-relevant events to support audit, detection and incident handling.
Cybersecurity Lifecycle and Evidence	Confirmed	Cybersecurity concept, TARA input, verification/validation evidence, traceability and OEM residual-risk approval.

5. High-Level Architecture

Inside the ECU boundary: clutch actuation control, application software, the embedded hardware/power-electronics platform, security services, the diagnostic server, and bootloader/update handling. Outside: the vehicle CAN network, the diagnostic tester, the update/flash and PKI backends, supplier development tooling, security operations, and the OEM/TRATON approval path. See the high-level system overview diagram at the top of this page.

6. Main External Interfaces

Interface	Connected parties	Purpose	Main data	Security relevance	Status
Vehicle Network Interface (CAN)	ECA ECU <-> transmission control / other ECUs	Receive position/speed demand, report actuator status and faults	CAN signals, PWM wake-up, status, DTCs	High	Confirmed
Diagnostic Tester Interface	Service/engineering tester -> ECA ECU diagnostic server	Service, programming and authenticated diagnostics	UDS requests/responses, Auth 0x29, session state	High	Inferred
Software Update / Flash Interface	Programming tool / update backend -> ECA bootloader	Deliver and verify software/flash content	Update packages, signatures, IVD data, results	High	Inferred
Key and Certificate Provisioning Interface	PKI / provisioning authority -> ECA security services	Provision and validate keys, certificates, trust anchors	Keys, X.509 certificates, trust anchors	High	Inferred
Secure Data Transfer Interface	Vehicle network peers <-> ECA application	Authenticated, fresh exchange of security-relevant data	SecOC/SDT-protected messages, counters, MACs	High	Inferred
Security Logging / Event Reporting Interface	ECA ECU -> security operations / backend	Move security events into monitoring and incident handling	Security events, logs, fault records	Medium	Inferred
Supplier Development / Evidence Interface	Engineering / ALM / CI tooling -> evidence artifacts	Create, trace and archive engineering and security evidence	Requirements, tests, traceability, releases	Medium	Confirmed
OEM Approval / Evidence Interface	Supplier security engineering -> TRATON / OEM	Exchange cybersecurity concept, evidence and residual-risk approval	Concept, V&V evidence, risk records	High	Confirmed

7. High-Level Cybersecurity Concept

The ECU must protect its clutch-control behaviour, software/firmware, cryptographic material and diagnostic access. The security-critical interfaces are the diagnostic tester, the update/flash path, the key/certificate provisioning path and the vehicle data boundary. 109 of 1076 requirements are cybersecurity-classified. The required lifecycle controls are secure diagnostics, secure update, data authenticity, key handling, logging, and a documented evidence/approval flow with the OEM.

Security capability	Protects	Applied to	Evidence strength	Open decision
Secure Diagnostics and RBAC	Diagnostic access state, privileged services	Diagnostic Tester Interface	Strong (UDS/0x29 evidence)	Confirm final diagnostic role model and lockout policy
Secure Software Update	ECU software and firmware authenticity	Update / Flash Interface	Strong (flash/IVD evidence)	Confirm signing chain, rollback and update-sequence ownership
Data Authenticity and Integrity Verification	Security-relevant vehicle data	Secure Data Transfer Interface	Moderate (SecOC/SDT evidence)	Confirm which signals require SecOC/SDT and the protection profile
Key and Certificate Handling	Cryptographic keys, certificates, trust anchors	Provisioning Interface	Strong (certificate/key evidence)	Confirm key hierarchy, HSM capability and PKI ownership
Communication Boundary Control	CAN / vehicle network boundary	Vehicle Network Interface	Moderate (CAN/message evidence)	Confirm boundary filtering and fail-safe behaviour
Security Logging	Security event evidence	Logging / Event Reporting Interface	Moderate (log/audit evidence)	Confirm event set, storage and reporting channel
Vulnerability and Incident Handling	Field security posture	OEM / SecOps Interfaces	Strong (process evidence)	Confirm reporting channels and response responsibilities
Cybersecurity Evidence and DIA	Approval and residual-risk case	OEM Approval Interface	Strong (concept/evidence requirements)	Confirm DIA split and residual-risk acceptance workflow

8. Key Engineering Conclusions

Confirmed: the ECU is a clutch actuator controller; a cybersecurity concept plus evidence is a mandatory deliverable.
Inferred: secure diagnostics, secure update, key/certificate handling and secure data transfer are required controls for this ECU.
Requires confirmation: diagnostic role allocation, update-sequence ownership, key hierarchy/HSM, SecOC/SDT signal scope, and ECU boundary assumptions.
See the Key Conclusions page for the full conclusion register with status, evidence and impact.

9. Open Customer Decisions

Confirm the exact product designation, variant scope and item definition for TARA.
Confirm which security mechanisms are mandatory for this RFQ versus reference-only standards.
Confirm diagnostic roles, key/PKI ownership, update sequence ownership, and backend responsibilities.

10. Drill Down Into Details

Key Conclusions: full engineering conclusion register.
High-Level Architecture: rendered architecture and trust-boundary diagrams.
System Capabilities: per-capability detail and requirement basis.
Interfaces: full interface catalog with protection and open questions.
Cybersecurity Concept: assets, capability model and open security decisions.
Requirements and Traceability: the full Markdown-derived evidence base.

System identity evidence

System Identity

Working System Name

Electric Clutch Actuator (ECA) Control ECU - TRATON GW AMT Gearbox Platform

Classification: Working System Interpretation - Function Confirmed by Requirements, Exact Product Designation Requires Customer Confirmation

One-Sentence Product Definition

System Type

Safety-related drivetrain actuator ECU with integrated power-electronics actuation, carrying an automotive cybersecurity engineering scope (ISO/SAE 21434-style concept and TARA input).

Vehicle Context

TRATON GW AMT gearbox platform, specified as a common actuator across all drivelines from city buses to heavy haulage and mining (commercial vehicles; MAN / Scania / TRATON brands).

Main Engineering Interpretation

The deliverable is the clutch-actuator ECU itself plus the supplier-owned cybersecurity engineering package required around it. The actuation function (CAN/PWM clutch control with position feedback and error handling) is explicit in the requirements; the surrounding diagnostic, update, key/certificate and data-protection controls are required by the vehicle security specifications and must be allocated to this ECU during the concept phase.

Confidence Level

Confirmed (explicit in requirements): clutch actuation function, CAN/PWM control, AMT platform context. Evidence: REQ-AUTO-00064; REQ-AUTO-00065; REQ-AUTO-00066; REQ-AUTO-00078; REQ-AUTO-00079; REQ-AUTO-00088; REQ-AUTO-00089; REQ-AUTO-00090 (showing 8 of 58).
Inferred from requirements: secure diagnostics, secure update/flash, key/certificate handling, secure data transfer. Evidence: req-6.20; REQ-AUTO-00282; REQ-AUTO-00290; REQ_UDS-0051; REQ_UDS-0051; REQ-AUTO-00298; REQ-AUTO-00299; REQ-AUTO-00310 (showing 8 of 408).
Requires customer confirmation: exact product designation/variant, final diagnostic role model, key hierarchy, and final item/TARA definition.

Evidence Basis

Total Markdown-derived requirements: 1076
Cybersecurity requirements: 109
Synthesized features / interfaces / security capabilities: 18 / 10 / 13
Function source: converted/markdown-cleaned/3299216_1.md page 3-4 ("24V electrical clutch actuator for the Traton GW AMT gearbox platform"; "The ECA ... must have its own internal ECU").
Security scope source: TRATON/MAN/Scania vehicle security specifications and the RDDM requirement set (UDS, certificates, flash, authentication).
Source rule: synthesis uses extracted Markdown-derived requirements only; PDFs are not read by this phase and OCR is disabled.

Customer Confirmation Needed

Needs Customer Clarification: Confirm the exact ECU product designation, part number and variant scope.
Needs Customer Clarification: Confirm which security controls (UDS Auth 0x29, secure update, SecOC/SDT, certificate profiles) are mandatory for this RFQ versus reference standards.
Needs Customer Clarification: Confirm diagnostic role model, key hierarchy/HSM capability, PKI ownership, and the final item definition for TARA.