Document Purpose
Confirmed by requirements: this security access / rbac standard contributes 58 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior.
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Security Access / RBAC Standard · Security Access / RBAC · Core ECA system behavior
Confirmed by requirements: this security access / rbac standard contributes 58 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence.
Confirmed by requirements: supplier positioning is 5 accept; 10 accept with assumption; 42 partially accept; 1 informational only. The generated traceability links this document to 14 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Confirmed by requirements: this security access / rbac standard contributes 58 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior.
Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence.
Core ECA system behavior; Responsibility and customer approval model; Cybersecurity concept and evidence; Diagnostics and service access; System architecture design (showing 5 of 8)
Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Confirmed by requirements: supplier positioning is 5 accept; 10 accept with assumption; 42 partially accept; 1 informational only. The generated traceability links this document to 14 supplier system requirement records.
Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. Do not convert these items into agreed baseline scope until the customer confirms the decision.
Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
| Theme | Engineering Meaning | Requirement Count | Representative Requirements |
|---|---|---|---|
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 52 | REQ-AUTO-00785; REQ-AUTO-00786; REQ-AUTO-00787 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 44 | REQ-AUTO-00785; REQ-AUTO-00786; REQ-AUTO-00788 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 42 | REQ-AUTO-00786; REQ-AUTO-00788; REQ-AUTO-00791 |
| Diagnostics and service access | Defines UDS service behavior, authorization expectations, safe-state checks, and diagnostic evidence. | 26 | REQ-AUTO-00785; REQ-AUTO-00788; REQ-AUTO-00789 |
| System architecture design | Groups related document requirements into a single engineering theme. | 16 | REQ-AUTO-00785; REQ-AUTO-00787; REQ-AUTO-00789 |
| System | Groups related document requirements into a single engineering theme. | 10 | REQ-AUTO-00785; REQ-AUTO-00787; REQ-AUTO-00790 |
| System core | Groups related document requirements into a single engineering theme. | 9 | REQ-AUTO-00787; REQ-AUTO-00790; REQ-AUTO-00795 |
| Cybersecurity | Groups related document requirements into a single engineering theme. | 6 | REQ-AUTO-00788; REQ-AUTO-00808; REQ-AUTO-00818 |
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 2 Terms, definitions and abbrevations | 1 | 0 | 0 | 1 |
| -- 2.1 Document quirks | 1 | 0 | 0 | 1 |
| 3 Technical content | 50 | 42 | 2 | 11 |
| -- 3.2 Role Based Access Control Configuration | 9 | 7 | 1 | 3 |
| -- 3.3 ASN.1 definition | 1 | 1 | 0 | 1 |
| -- 3.6 role-configuration | 9 | 7 | 1 | 3 |
| -- 3.8 did-rules | 6 | 5 | 1 | 4 |
| -- 3.9 rid-rules | 3 | 3 | 1 | 2 |
| -- 3.10 Extending the Role Based Access Control Configuration using a certificate | 2 | 2 | 2 | 2 |
| -- 3.12 Logic | 8 | 7 | 1 | 5 |
| -- 3.14 Requests Specific Requirements | 12 | 10 | 1 | 4 |
| -- -- 3.14.1 Diagnostic over USD | 12 | 10 | 1 | 4 |
| 4 Referenced documents | 4 | 0 | 0 | 4 |
| -- 4.1 Normative references | 4 | 0 | 0 | 4 |
| Field | Value |
|---|---|
| Source PDF | customer-input/pdf/CVS151.pdf |
| Converted Markdown | converted/markdown/CVS151.md |
| Document Type | Security Access / RBAC Standard |
| Domain | Security Access / RBAC |
| Scope Summary | 58 extracted requirements; 14 linked SSRs; 2 linked open points. |
| Main Themes | Core ECA system behavior; Responsibility and customer approval model; Cybersecurity concept and evidence; Diagnostics and service access; System architecture design (showing 5 of 8) |
| Does Not Confirm | Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed. |
| Confidence | High |
| Evidence Basis | Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis. |
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Score | Category | Requirement / Reason | Supplier Position |
|---|---|---|---|---|
| REQ-AUTO-00789 | 77 | High risk due to unclear OEM/supplier responsibility | RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00804 | 77 | High risk due to unclear OEM/supplier responsibility | RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00806 | 77 | High risk due to unclear OEM/supplier responsibility | RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00808 | 77 | High risk due to unclear OEM/supplier responsibility | Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-rules one octet for the pattern rule settings followed by the diagnostic pattern of variable length.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00810 | 77 | High risk due to unclear OEM/supplier responsibility | Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00814 | 77 | High risk due to unclear OEM/supplier responsibility | Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00817 | 77 | High risk due to unclear OEM/supplier responsibility | Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00818 | 77 | High risk due to unclear OEM/supplier responsibility | RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC extension and any rules in the RBAC-configuration in the RBACC, the server shall enforce the rules in the client certificate D-RBACC extension.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00821 | 77 | High risk due to unclear OEM/supplier responsibility | 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00832 | 77 | High risk due to unclear OEM/supplier responsibility | 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBAC_REQ 28 The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ-AUTO-00820 | 63 | High risk due to unclear OEM/supplier responsibility | It can also be useful if you want to add or remove access rights from a client/tester, that needs access to one or several roles, but should not have access to everything (or should have more access) specified for the assigned roles.security relevant; architecture relevant; Partially Accept; linked open point | Partially Accept |
| REQ-AUTO-00833 | 63 | High risk due to unclear OEM/supplier responsibility | RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request.security relevant; architecture relevant; Partially Accept; linked open point | Partially Accept |
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Open Point | Priority | Question / Impact | Required Customer Decision | Recommended Supplier Position | Owner | Status |
|---|---|---|---|---|---|---|
| OP-002 | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Implement configurable session/security-access on the ECU and request the customer-confirmed service-to-role table. | Shared (OEM policy / Supplier ECU) | Open | |
| OP-003 | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.ECU secure-storage and provisioning design is blocked; production-line and PKI dependencies stay open. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | Provide ECU-side secure storage and provisioning hooks; require OEM confirmation of PKI ownership and the provisioning interface. | OEM / Customer (PKI) + Supplier (ECU) | Open |
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Requirement / Proposal | Supplier Position | Review | Security Capability | Feature / Interface | SSR | Open Point | Source |
|---|---|---|---|---|---|---|---|---|
| REQ-AUTO-00789 | RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | None | Hardware platform support None | SSR-RBAC-005 | OP-002 | 3.2 Role Based Access Control Configuration page 4 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 4 |
| REQ-AUTO-00804 | RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | OP-002 | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00806 | RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | OP-002 | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00808 | Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-rules one octet for the pattern rule settings followed by the diagnostic pattern of variable length.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | OP-002 | 3.8 did-rules page 9 Source detailsDocument section 3.8 did-rules Section path 3 Technical content > 3.8 did-rules Page reference page 9 |
| REQ-AUTO-00810 | Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-DIAG-003 | OP-002 | 3.8 did-rules page 9 Source detailsDocument section 3.8 did-rules Section path 3 Technical content > 3.8 did-rules Page reference page 9 |
| REQ-AUTO-00814 | Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-DIAG-003 | OP-002 | 3.9 rid-rules page 10 Source detailsDocument section 3.9 rid-rules Section path 3 Technical content > 3.9 rid-rules Page reference page 10 |
| REQ-AUTO-00817 | Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-DIAG-003 | OP-002 | 3.10 Extending the Role Based Access Control Configuration using a certificate page 11 Source detailsDocument section 3.10 Extending the Role Based Access Control Configuration using a certificate Section path 3 Technical content > 3.10 Extending the Role Based Access Control Configuration using a certificate Page reference page 11 |
| REQ-AUTO-00818 | RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC extension and any rules in the RBAC-configuration in the RBACC, the server shall enforce the rules in the client certificate D-RBACC extension.Proposal: Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Partially Accept | Proposal Ready | Certificate handling | Certificate handling None | SSR-KEY-002 | OP-003 | 3.10 Extending the Role Based Access Control Configuration using a certificate page 11 Source detailsDocument section 3.10 Extending the Role Based Access Control Configuration using a certificate Section path 3 Technical content > 3.10 Extending the Role Based Access Control Configuration using a certificate Page reference page 11 |
| REQ-AUTO-00821 | 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate.Proposal: Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Partially Accept | Proposal Ready | Certificate handling | Certificate handling None | SSR-KEY-002 | OP-002 | 3.12 Logic page 12 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 12 |
| REQ-AUTO-00832 | 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBAC_REQ 28 The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Partially Accept | Proposal Ready | Authentication | Authentication None | SSR-RBAC-002 | OP-002 | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00820 | It can also be useful if you want to add or remove access rights from a client/tester, that needs access to one or several roles, but should not have access to everything (or should have more access) specified for the assigned roles.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-COM-003 | OP-002 | 3.12 Logic page 12 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 12 |
| REQ-AUTO-00833 | RBAC_INFO 42 For 0x29 requests a corresponding matching rule in the RBACC is not required for the server to accept the request.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | OP-002 | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00834 | 3.14.1.2 SecuredData Transmission 0x84 RBAC_REQ 29 The server shall evaluate the reported internal service using the RBACC rules whenever it receives a UDS Service 0x84 requests.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-RBAC-004 | OP-002 | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00835 | RBAC_REQ 30 The server shall always allow reception of UDS SecuredDataTransmission 0x84 requests regardless of the RBACC settings.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | OP-002 | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00837 | Page 20 3.14.1.3 TesterPresent 0x3E RBAC_REQ 31 The server shall always allow reception of UDS TesterPresent 0x3E requests regardless of the RBACC settings.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | OP-002 | 3.14.1 Diagnostic over USD page 20 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 20 |
| REQ-AUTO-00828 | RBAC_REQ 24 The server shall allow requests that are contained in role 0 rules regardless of the client authentication state.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00791 | RBAC_REQ 2 If conflicting/overlapping rules are found within a role-configuration, the server shall enforce that deny rule takes precedence over the allow rule.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.2 Role Based Access Control Configuration page 5 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 5 |
| REQ-AUTO-00792 | RBAC_REQ 3 If a matching allow/deny rule is found and all the rule settings are fulfilled, the server shall accept/deny the request.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.2 Role Based Access Control Configuration page 5 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 5 |
| REQ-AUTO-00793 | RBAC_REQ 4 If a matching rule is found and not all the rule settings are fulfilled, the server shall consider the request rejected for that rule.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.2 Role Based Access Control Configuration page 5 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 5 |
| REQ-AUTO-00794 | RBAC_REQ 5 The server shall deny a request if no matching rule is found on RBACC.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.2 Role Based Access Control Configuration page 5 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 5 |
| REQ-AUTO-00796 | RBAC_REQ 6 The server shall evaluate each role-configuration independently from each other.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.2 Role Based Access Control Configuration page 6 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 6 |
| REQ-AUTO-00797 | RBAC_REQ 27 The server shall require that requests are authenticated for allow rules, using e.g., SecuredDataTransmission 0x84 (see CVS31, ISO-14229-1:2020).Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.2 Role Based Access Control Configuration page 6 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 6 |
| REQ-AUTO-00798 | Page 7 RBACC Role-configuration role Pattern-rule DENY Pattern-rule ALLOW DID-rule DENY DID-rule ALLOW RID-rule DENY RID-rule ALLOW Figure 2 – Visual representation of the RBACC 3.3 ASN.1 definition RBAC_REQ 7 The server and client shall define the RBACC as per the following ASN.1 definition: RBACC ::= SEQUENCE { version OCTET STRING (SIZE(2)), rbacc-id OCTET STRING (SIZE(16)), role-configurations SEQUENCE (SIZE(0..MAX)) OF Role-configuration } Role-configuration ::= SEQUENCE { role INTEGER(0..MAX), pattern-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), pattern-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(2..MAX)), did-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), did-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-deny SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)), rid-rules-allow SEQUENCE (SIZE(0...MAX)) OF OCTET STRING (SIZE(3)) }Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.3 ASN.1 definition page 7 Source detailsDocument section 3.3 ASN.1 definition Section path 3 Technical content > 3.3 ASN.1 definition Page reference page 7 |
| REQ-AUTO-00799 | RBAC_REQ 8 The server shall support in the version field two octets.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00800 | RBAC_REQ 9 The server shall support major version value 3 and minor version value 0.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00802 | RBAC_REQ 10 Before RBACC is stored, the server shall verify that the server supports the structure indicated in the version number.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00805 | RBAC_REQ 12 The server shall support 16 octets in the rbacc-id field.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00807 | RBAC_REQ 14 The server shall support role-configurations using 32-bit unsigned integer.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00809 | RBAC_REQ 16 The server shall support the pattern-rule setting according to Table 1.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.8 did-rules page 9 Source detailsDocument section 3.8 did-rules Section path 3 Technical content > 3.8 did-rules Page reference page 9 |
| REQ-AUTO-00811 | 4-7 N/A Reserved for future use 3.8 did-rules RBAC_REQ 17 The server shall support for every entry in the did-rules one octet which represents the did-rule settings followed by two octets that represent the DID.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.8 did-rules page 9 Source detailsDocument section 3.8 did-rules Section path 3 Technical content > 3.8 did-rules Page reference page 9 |
| REQ-AUTO-00813 | RBAC_REQ 19 The server shall support the did-rule setting according to Table 2.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.8 did-rules page 9 Source detailsDocument section 3.8 did-rules Section path 3 Technical content > 3.8 did-rules Page reference page 9 |
| REQ-AUTO-00815 | 4 Read 0 == This rule is not applicable when the DID is being read 1 == This rule is applicable when the DID is being read 5 Write 0 == This rule is not applicable when the DID is being written 1 == This rule is applicable when the DID is being written 6 IO-control 0 == This rule is not applicable when the DID is being used for IO-control 1 == This rule is applicable when the DID is being used for IO-control 7 N/A Reserved for future use 3.9 rid-rules RBAC_REQ 20 The server shall support for every entry in the rid-rules one octet which represents the rid-rule settings followed by two octets that represent the RID.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.9 rid-rules page 10 Source detailsDocument section 3.9 rid-rules Section path 3 Technical content > 3.9 rid-rules Page reference page 10 |
| REQ-AUTO-00816 | RBAC_REQ 21 The server shall support the rid-rule setting according to Table 3.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.9 rid-rules page 10 Source detailsDocument section 3.9 rid-rules Section path 3 Technical content > 3.9 rid-rules Page reference page 10 |
| REQ-AUTO-00819 | Page 12 RBAC_REQ 23 The server shall interpret the extnValue (see snipped above) as of one instance of a RBACC (see 3.3).Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.12 Logic page 12 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 12 |
| REQ-AUTO-00822 | Page 13 Figure 3 – Logic Overview RBAC_REQ 35 The server shall implement RBAC internal logic as per Figure 4.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-RBAC-004 | - | 3.12 Logic page 13 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 13 |
| REQ-AUTO-00823 | RBAC_REQ 32 The server shall implement RBAC pattern rule evaluation logic as per Figure 5.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Application software behavior None | SSR-RBAC-004 | - | 3.12 Logic page 15 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 15 |
| REQ-AUTO-00825 | RBAC_REQ 33 The server shall implement RBAC did rule evaluate as per Figure 6.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.12 Logic page 16 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 16 |
| REQ-AUTO-00826 | Page 17 RBAC_REQ 34 The server shall implement RBAC rid rule evaluate as per Figure 7.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.12 Logic page 17 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 17 |
| REQ-AUTO-00829 | RBAC_REQ 25 The server shall allow request that are contained in role 0 rule regardless if the request is data authenticated e.g over e.g., SecuredDataTransmission 0x84 (See CVS31, ISO 14229-1:2020).Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00830 | RBAC_REQ 26 The server shall allow request that are contained in role 0 rule regardless of the value of Confidentiality field setting.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00836 | RBAC_INFO 43 For 0x84 requests a corresponding matching rule in the RBACC is not required for the server to accept the 0x84 request but the server must find a corresponding matching rule for the internal request contained in the 0x84 prior to execute it.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00838 | RBAC_INFO 44 For 0x3E requests a corresponding matching rule in the RBACC is not required for the server to accept the request.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Backend and IT integration None | SSR-RBAC-003 | - | 3.14.1 Diagnostic over USD page 20 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 20 |
| REQ-AUTO-00788 | Page 3 1 Scope Concepts such as secure-update (CVS37) requires Role Based Access Control (RBAC) for diagnostics (UDS).Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | Diagnostic security | Diagnostic security None | SSR-RBAC-001 | - | 2.1 Document quirks page 3 Source detailsDocument section 2.1 Document quirks Section path 2 Terms, definitions and abbrevations > 2.1 Document quirks Page reference page 3 |
| REQ-AUTO-00827 | Meaning, role 0 is particularly useful for defining services, DIDs and RIDs that should be available to all clients/users, regardless of their diagnostics role and/or authorization/authentication status.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-RBAC-006 | - | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00839 | Page 26 Annex D DynamicallyDefineDataIdentifier When this service is being used, each DID included in the request must be evaluated against the rules that are applicable for the client (the rules in the client’s certificate and in the RBACC).Proposal: Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Accept with Assumption | Proposal Ready | Certificate handling | Certificate handling None | SSR-KEY-002 | - | 4.1 Normative references page 26 Source detailsDocument section 4.1 Normative references Section path 4 Referenced documents > 4.1 Normative references Page reference page 26 |
| REQ-AUTO-00785 | RBAC for diagnostics Foreword This Commercial Vehicle Standard (“CVS151”) contains requirement specifications for TRATON Group and may be referred to by any of its commercial vehicle Affiliates.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | page-1 Page 1 page 1 Source detailsDocument section page-1 Page 1 Section path Page 1 Page reference page 1 |
| REQ-AUTO-00790 | RBAC_REQ 1 Each RBACC shall only contain one role-configuration per each supported role.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-RBAC-006 | - | 3.2 Role Based Access Control Configuration page 4 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 4 |
| REQ-AUTO-00795 | RBAC_INFO 10 All RBACC ALLOW rules have a setting that dictates if a request, matching the rule, must be 14229-1:2020).Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-RBAC-006 | - | 3.2 Role Based Access Control Configuration page 5 Source detailsDocument section 3.2 Role Based Access Control Configuration Section path 3 Technical content > 3.2 Role Based Access Control Configuration Page reference page 5 |
| REQ-AUTO-00801 | RBAC_INFO 19 If other versions shall be supported is out of the scope of this document and shall be agreed upon between projects in Traton.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-RBAC-006 | - | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00812 | RBAC_REQ 18 The byte order for DID shall be big endian.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-RBAC-006 | - | 3.8 did-rules page 9 Source detailsDocument section 3.8 did-rules Section path 3 Technical content > 3.8 did-rules Page reference page 9 |
| REQ-AUTO-00831 | RBAC_INFO 40 This means that in role 0 encryption is never required.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-RBAC-006 | - | 3.14.1 Diagnostic over USD page 19 Source detailsDocument section 3.14.1 Diagnostic over USD Section path 3 Technical content > 3.14 Requests Specific Requirements > 3.14.1 Diagnostic over USD Page reference page 19 |
| REQ-AUTO-00840 | The client must have read access for all included DIDs and have access to the service themselves.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | Application software behavior None | SSR-SYS-008 | - | 4.1 Normative references page 26 Source detailsDocument section 4.1 Normative references Section path 4 Referenced documents > 4.1 Normative references Page reference page 26 |
| REQ-AUTO-00842 | Since reading of DIDs can be allowed by either a pattern-rule (starting with 22 [7]) and/or a DID-rule, both the pattern-rules and the DID-rules must be parsed when evaluating each DID.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | External interfaces External Interfaces | SSR-COM-002 | - | 4.1 Normative references page 26 Source detailsDocument section 4.1 Normative references Section path 4 Referenced documents > 4.1 Normative references Page reference page 26 |
| REQ-AUTO-00786 | Any review of this CVS151 shall only be done in agreement with the involved TRATON Group commercial vehicle Affiliates stated in the table below under section “Technical responsibility”.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-009 | - | page-1 Page 1 page 1 Source detailsDocument section page-1 Page 1 Section path Page 1 Page reference page 1 |
| REQ-AUTO-00787 | The User shall apply the latest version of this CVS151.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-005 | - | page-1 Page 1 page 1 Source detailsDocument section page-1 Page 1 Section path Page 1 Page reference page 1 |
| REQ-AUTO-00803 | If the version number does not comply with the server implementation, the server shall reject storing the data.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | Backend and IT integration None | SSR-TOOL-002 | - | 3.6 role-configuration page 8 Source detailsDocument section 3.6 role-configuration Section path 3 Technical content > 3.6 role-configuration Page reference page 8 |
| REQ-AUTO-00824 | E.g: For the evaluate pattern the rule setting Confidentiality is set to 0x01 (Confidentiality is required).Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-005 | - | 3.12 Logic page 16 Source detailsDocument section 3.12 Logic Section path 3 Technical content > 3.12 Logic Page reference page 16 |
| REQ-AUTO-00841 | When the client is performing the actual read operation (ReadDataByIdentifier [7]), the conditions and rules for all DIDs, aliased by the dynamically defined identifier, must be met, otherwise the request shall be rejected with an appropriate NRC.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-005 | - | 4.1 Normative references page 26 Source detailsDocument section 4.1 Normative references Section path 4 Referenced documents > 4.1 Normative references Page reference page 26 |
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| SSR | Statement / Trace | Feature | Security Capability | Interface | Responsibility | Status | Verification |
|---|---|---|---|---|---|---|---|
| SSR-COM-002 | External Interfaces — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for External Interfaces, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-00842. This SSR is also supported by requirements from other PDFs. | External Interfaces | None | External Interfaces | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-COM-003 | Backend and IT integration — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Backend and IT integration, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-00820. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-DIAG-003 | Backend and IT integration — Diagnostic ServicesThe ECU shall provide the diagnostic services for Backend and IT integration required by the allocated customer requirements, including the specified services, sessions and data identifiers.From this PDF: REQ-AUTO-00810; REQ-AUTO-00814; REQ-AUTO-00817. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Test |
| SSR-KEY-002 | Certificate handling — Key and Certificate HandlingThe ECU shall manage key and certificate material for Certificate handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ-AUTO-00818; REQ-AUTO-00821; REQ-AUTO-00839. This SSR is also supported by requirements from other PDFs. | Certificate handling | Certificate handling | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-001 | Diagnostic security — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Diagnostic security, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00788; REQ-AUTO-00808. This SSR is also supported by requirements from other PDFs. | Diagnostic security | Diagnostic security | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-002 | Authentication — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Authentication, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00832. This SSR is also supported by requirements from other PDFs. | Authentication | Authentication | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-003 | Backend and IT integration — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Backend and IT integration, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00791; REQ-AUTO-00792; REQ-AUTO-00793; REQ-AUTO-00794; REQ-AUTO-00796; REQ-AUTO-00797; REQ-AUTO-00798; REQ-AUTO-00799; REQ-AUTO-00800; REQ-AUTO-00802; REQ-AUTO-00804; REQ-AUTO-00805; REQ-AUTO-00806; REQ-AUTO-00807; REQ-AUTO-00809; REQ-AUTO-00811; REQ-AUTO-00813; REQ-AUTO-00815; REQ-AUTO-00816; REQ-AUTO-00819; REQ-AUTO-00825; REQ-AUTO-00826; REQ-AUTO-00828; REQ-AUTO-00829; REQ-AUTO-00830; REQ-AUTO-00833; REQ-AUTO-00835; REQ-AUTO-00836; REQ-AUTO-00837; REQ-AUTO-00838. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-004 | Application software behavior — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00822; REQ-AUTO-00823; REQ-AUTO-00834. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-005 | Hardware platform support — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Hardware platform support, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00789. | Hardware platform support | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-RBAC-006 | System behavior — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for System behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00790; REQ-AUTO-00795; REQ-AUTO-00801; REQ-AUTO-00812; REQ-AUTO-00827; REQ-AUTO-00831. | System behavior | None | None | Supplier-Owned | Candidate | Review + Test |
| SSR-SYS-005 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00787; REQ-AUTO-00824; REQ-AUTO-00841. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Test |
| SSR-SYS-008 | Application software behavior — System FunctionThe ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00840. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Test |
| SSR-SYS-009 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00786. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test |
| SSR-TOOL-002 | Backend and IT integration — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.From this PDF: REQ-AUTO-00803. This SSR is also supported by requirements from other PDFs. | Backend and IT integration | None | None | Shared | Blocked by Customer Clarification | Review + Test |
| Impact Area | Evidence From This PDF |
|---|---|
| Impacted system features | Application software behavior; Authentication; Backend and IT integration; Certificate handling; Diagnostic security; External interfaces; Hardware platform support; System behavior |
| Impacted interfaces | External Interfaces |
| Impacted security capabilities | Authentication; Certificate handling; Diagnostic security |
| Impacted architecture elements | Application Software; Backend and IT Systems; Compliance Process; External Interfaces; Hardware Platform; Security Services; System Core |
| Impacted work products | Cybersecurity concept; Cybersecurity verification report; DIA / cybersecurity case; Requirement traceability record; System/architecture design |
| Tools / IT / hardware / test | High/High/Medium; High/Low/Medium; Low/High/Low; Low/Low/Low; Medium/High/High; Medium/High/Low; Medium/High/Medium; Medium/Low/Low; Medium/Low/Medium |
| Design assumptions introduced | Security-relevant requirement the ECU can own once responsibility/method is confirmed. |
| Design decisions required | Agree responsibility split (DIA) for the non-ECU portion. |
| Impact | Status |
|---|---|
| Estimation impact | yes |
| Resource/tool/IT/HW/test impact | High/High/Medium; High/Low/Medium; Low/High/Low; Low/Low/Low; Medium/High/High; Medium/High/Low; Medium/High/Medium; Medium/Low/Low; Medium/Low/Medium |
Generated from document-specific requirement, traceability, SSR, and open-point evidence.
flowchart LR
doc["CVS151.pdf"]
d0["Authentication"]
doc --> d0
d1["Certificate handling"]
doc --> d1
d2["Diagnostic security"]
doc --> d2
f0["Feature: Application software behavior"]
doc --> f0
f1["Feature: Authentication"]
doc --> f1
f2["Feature: Backend and IT integration"]
doc --> f2
i0["Interface: External Interfaces"]
doc --> i0
s0["SSR: SSR-COM-002"]
doc --> s0
s1["SSR: SSR-COM-003"]
doc --> s1
s2["SSR: SSR-DIAG-003"]
doc --> s2
o0["Open point: OP-002"]
doc --> o0
o1["Open point: OP-003"]
doc --> o1
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Customer Requirement | SSR | Disposition | Confidence | Reason |
|---|---|---|---|---|
| REQ-AUTO-00785 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ-AUTO-00786 | SSR-SYS-009 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00787 | SSR-SYS-005 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00788 | SSR-RBAC-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00789 | SSR-RBAC-005 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00790 | SSR-RBAC-006 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00791 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00792 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00793 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00794 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00795 | SSR-RBAC-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00796 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00797 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00798 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00799 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00800 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00801 | SSR-RBAC-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00802 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00803 | SSR-TOOL-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00804 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00805 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00806 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00807 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00808 | SSR-RBAC-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00809 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00810 | SSR-DIAG-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00811 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00812 | SSR-RBAC-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00813 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00814 | SSR-DIAG-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00815 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00816 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00817 | SSR-DIAG-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00818 | SSR-KEY-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00819 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00820 | SSR-COM-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00821 | SSR-KEY-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00822 | SSR-RBAC-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00823 | SSR-RBAC-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00824 | SSR-SYS-005 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00825 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00826 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00827 | SSR-RBAC-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00828 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00829 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00830 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00831 | SSR-RBAC-006 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00832 | SSR-RBAC-002 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00833 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00834 | SSR-RBAC-004 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00835 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00836 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00837 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00838 | SSR-RBAC-003 | Shared Responsibility / CIA Needed | Low | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00839 | SSR-KEY-002 | Covered by Existing Supplier System Requirement | Low | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00840 | SSR-SYS-008 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00841 | SSR-SYS-005 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00842 | SSR-COM-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
customer-input/pdf/CVS151.pdfconverted/markdown/CVS151.mdConfirmed by requirements: this security access / rbac standard contributes 58 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence.
Confirmed by requirements: supplier positioning is 5 accept; 10 accept with assumption; 42 partially accept; 1 informational only. The generated traceability links this document to 14 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
| Field | Interpretation |
|---|---|
| Document Purpose | Confirmed by requirements: this security access / rbac standard contributes 58 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. |
| Engineering Interpretation | Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence. |
| Supplier Proposal Impact | Confirmed by requirements: supplier positioning is 5 accept; 10 accept with assumption; 42 partially accept; 1 informational only. The generated traceability links this document to 14 supplier system requirement records. |
| System / Security Impact | Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; cybersecurity concept and evidence. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them. |
| Customer Clarification Impact | Requires customer confirmation: 2 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. Do not convert these items into agreed baseline scope until the customer confirms the decision. |
| Confidence and Limits | Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed. |
| Theme | Summary | Requirement Count | Representative Requirements |
|---|---|---|---|
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 52 | REQ-AUTO-00785; REQ-AUTO-00786; REQ-AUTO-00787 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 44 | REQ-AUTO-00785; REQ-AUTO-00786; REQ-AUTO-00788 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 42 | REQ-AUTO-00786; REQ-AUTO-00788; REQ-AUTO-00791 |
| Diagnostics and service access | Defines UDS service behavior, authorization expectations, safe-state checks, and diagnostic evidence. | 26 | REQ-AUTO-00785; REQ-AUTO-00788; REQ-AUTO-00789 |
| System architecture design | Groups related document requirements into a single engineering theme. | 16 | REQ-AUTO-00785; REQ-AUTO-00787; REQ-AUTO-00789 |
| System | Groups related document requirements into a single engineering theme. | 10 | REQ-AUTO-00785; REQ-AUTO-00787; REQ-AUTO-00790 |
| System core | Groups related document requirements into a single engineering theme. | 9 | REQ-AUTO-00787; REQ-AUTO-00790; REQ-AUTO-00795 |
| Cybersecurity | Groups related document requirements into a single engineering theme. | 6 | REQ-AUTO-00788; REQ-AUTO-00808; REQ-AUTO-00818 |
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 2 Terms, definitions and abbrevations | 1 | 0 | 0 | 1 |
| -- 2.1 Document quirks | 1 | 0 | 0 | 1 |
| 3 Technical content | 50 | 42 | 2 | 11 |
| -- 3.2 Role Based Access Control Configuration | 9 | 7 | 1 | 3 |
| -- 3.3 ASN.1 definition | 1 | 1 | 0 | 1 |
| -- 3.6 role-configuration | 9 | 7 | 1 | 3 |
| -- 3.8 did-rules | 6 | 5 | 1 | 4 |
| -- 3.9 rid-rules | 3 | 3 | 1 | 2 |
| -- 3.10 Extending the Role Based Access Control Configuration using a certificate | 2 | 2 | 2 | 2 |
| -- 3.12 Logic | 8 | 7 | 1 | 5 |
| -- 3.14 Requests Specific Requirements | 12 | 10 | 1 | 4 |
| -- -- 3.14.1 Diagnostic over USD | 12 | 10 | 1 | 4 |
| 4 Referenced documents | 4 | 0 | 0 | 4 |
| -- 4.1 Normative references | 4 | 0 | 0 | 4 |
Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed.
| ID | Score | Category | Reason | Statement |
|---|---|---|---|---|
| REQ-AUTO-00789 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | RBAC_INFO 2 Before a client can execute diagnostics services that are under RBAC, the client must perform some type of authorization procedure towards the server/ECU. |
| REQ-AUTO-00804 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | RBAC_REQ 11 The server shall report the currently stored RBACC’s version via diagnostics. |
| REQ-AUTO-00806 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | RBAC_REQ 13 The server shall report the currently stored RBACC’s rbacc-id via diagnostics. |
| REQ-AUTO-00808 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Page 9 3.7 pattern-rules RBAC_REQ 15 The server shall support for every entry in the pattern-rules one octet for the pattern rule settings followed by the diagnostic pattern of variable length. |
| REQ-AUTO-00810 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Table 1 – Pattern Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. |
| REQ-AUTO-00814 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Page 10 Table 2 – DID Rule Settings Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. |
| REQ-AUTO-00817 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Page 11 Table 3 – RID Rule Setting Bit index Name Description 0 Reserved Reserved 1 UDS 0 == This rule is not valid for a UDS-server 1 == This rule is valid for a UDS-server This bit shall always assume value 1 2 Reserved Reserved 3 Confidentiality 0 == No confidentiality is required on the diagnostics request 1 == Confidentiality is required on the diagnostics request e.g., 0x84 (CVS32) Note: This bit is supported but not used for deny rules. |
| REQ-AUTO-00818 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | RBAC_REQ 22 If conflicting/overlapping rules are found between the client certificate D-RBACC extension and any rules in the RBAC-configuration in the RBACC, the server shall enforce the rules in the client certificate D-RBACC extension. |
| REQ-AUTO-00821 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 3.11 ECU-Diagnostics-Role Extension RBAC_REQ 36 The server shall exert the RBACC roles based on the ECU-diagnostics-Role extension on the client’s certificate. |
| REQ-AUTO-00832 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | 3.14 Requests Specific Requirements 3.14.1 Diagnostic over USD 3.14.1.1 Authenticate 0x29 RBAC_REQ 28 The server shall always allow reception of UDS authenticate 0x29 requests regardless of the RBACC settings. |
| Open Point | Priority | Question | Impact | Status |
|---|---|---|---|---|
| OP-002 | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service. | Open | |
| OP-003 | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | ECU secure-storage and provisioning design is blocked; production-line and PKI dependencies stay open. | Open |
| SSR | Title | Statement | Reqs From This PDF | Other PDFs | Status |
|---|---|---|---|---|---|
| SSR-COM-002 | External Interfaces — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for External Interfaces, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-00842 | yes | Blocked by Customer Clarification |
| SSR-COM-003 | Backend and IT integration — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for Backend and IT integration, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ-AUTO-00820 | yes | Blocked by Customer Clarification |
| SSR-DIAG-003 | Backend and IT integration — Diagnostic Services | The ECU shall provide the diagnostic services for Backend and IT integration required by the allocated customer requirements, including the specified services, sessions and data identifiers. | REQ-AUTO-00810; REQ-AUTO-00814; REQ-AUTO-00817 | yes | Blocked by Customer Clarification |
| SSR-KEY-002 | Certificate handling — Key and Certificate Handling | The ECU shall manage key and certificate material for Certificate handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle. | REQ-AUTO-00818; REQ-AUTO-00821; REQ-AUTO-00839 | yes | Blocked by Customer Clarification |
| SSR-RBAC-001 | Diagnostic security — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Diagnostic security, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00788; REQ-AUTO-00808 | yes | Blocked by Customer Clarification |
| SSR-RBAC-002 | Authentication — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Authentication, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00832 | yes | Blocked by Customer Clarification |
| SSR-RBAC-003 | Backend and IT integration — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Backend and IT integration, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00791; REQ-AUTO-00792; REQ-AUTO-00793; REQ-AUTO-00794; REQ-AUTO-00796; REQ-AUTO-00797; REQ-AUTO-00798; REQ-AUTO-00799; REQ-AUTO-00800; REQ-AUTO-00802; REQ-AUTO-00804; REQ-AUTO-00805; REQ-AUTO-00806; REQ-AUTO-00807; REQ-AUTO-00809; REQ-AUTO-00811; REQ-AUTO-00813; REQ-AUTO-00815; REQ-AUTO-00816; REQ-AUTO-00819; REQ-AUTO-00825; REQ-AUTO-00826; REQ-AUTO-00828; REQ-AUTO-00829; REQ-AUTO-00830; REQ-AUTO-00833; REQ-AUTO-00835; REQ-AUTO-00836; REQ-AUTO-00837; REQ-AUTO-00838 | yes | Blocked by Customer Clarification |
| SSR-RBAC-004 | Application software behavior — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00822; REQ-AUTO-00823; REQ-AUTO-00834 | yes | Blocked by Customer Clarification |
| SSR-RBAC-005 | Hardware platform support — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for Hardware platform support, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00789 | no | Blocked by Customer Clarification |
| SSR-RBAC-006 | System behavior — Secure Diagnostics / RBAC | The ECU shall enforce authenticated, role-authorised access for System behavior, restricting security-relevant diagnostic services per the OEM-agreed role model. | REQ-AUTO-00790; REQ-AUTO-00795; REQ-AUTO-00801; REQ-AUTO-00812; REQ-AUTO-00827; REQ-AUTO-00831 | no | Candidate |
| SSR-SYS-005 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00787; REQ-AUTO-00824; REQ-AUTO-00841 | yes | Blocked by Customer Clarification |
| SSR-SYS-008 | Application software behavior — System Function | The ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00840 | yes | Blocked by Customer Clarification |
| SSR-SYS-009 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00786 | yes | Candidate |
| SSR-TOOL-002 | Backend and IT integration — Tooling / IT / Evidence Storage | The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration. | REQ-AUTO-00803 | yes | Blocked by Customer Clarification |