RFQ Review Dashboard
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Executive Takeaway
The RFQX package is ready for customer proposal review, not agreement baseline. Supplier positions are drafted, but customer decisions remain open for responsibility allocation, diagnostics/update assumptions, and cybersecurity evidence ownership.
- Use the requirement register to review individual supplier positions.
- Use open points before accepting shared or customer-owned cybersecurity scope.
- Counts below support prioritization; they are not a customer approval claim.
Open Requirement Review RegisterDocument IntelligenceOpen PointsSupplier Proposal Summary
Total Customer Requirements1076Markdown-derived
Reviewed Requirements1076internal review done
Not Reviewed0remaining
Accepted283clear scope
Accepted with Assumption389confirm method/owner
Partially Accepted275shared responsibility
Rejected0with rationale
Clarification Needed7blocked
Customer Decision Pending1076awaiting feedback
Mapped to Cybersecurity Concept947accepted/partial
Mapped to Estimation1076all requirements
Mapped to Supplier System Req.948derived
Supplier System Requirement Derivation
Customer Requirements1076total
Active Requirements966in baseline
Derived Supplier System Requirements74many-to-many
Customer Requirements Mapped to SSRs947to SSRs
Unmapped Active Requirements0derivable, unmapped
Blocked by Clarification6open
Derivation Coverage %100.0%of derivable
Review Status Summary
| Status | Count | Meaning | Next Action |
|---|---|---|---|
| Proposal Ready | 1060 | Supplier proposal drafted | Send to customer |
| Reviewed Internally | 16 | Reviewed; proposal not final | Resolve clarification/review |
Top Open Points
| Open Point ID | Topic | Impact | Owner | Required Customer Answer | Status |
|---|---|---|---|---|---|
| OP-001 | ECU designation, variant and item definition for TARA | High | OEM / Customer | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | Open |
| OP-002 | Diagnostic security role model and service authorization | High | Shared (OEM policy / Supplier ECU) | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Open |
| OP-003 | Key and certificate ownership, provisioning and lifecycle | High | OEM / Customer (PKI) + Supplier (ECU) | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | Open |
| OP-004 | Secure software update / backend campaign responsibility | High | Shared (OEM backend / Supplier ECU) | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | Open |
| OP-005 | Secure on-board communication (SecOC/SDT) signal allocation | High | OEM / Customer | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | Open |
| OP-009 | Cybersecurity work products, DIA and responsibility split | High | OEM / Customer + Supplier (DIA) | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | Open |
| OP-006 | Incident response and vulnerability management ownership | Medium | OEM / Customer (fleet) + Supplier (ECU) | Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier. | Open |
| OP-008 | Production, development and debug-interface hardening | Medium | Shared (OEM process / Supplier ECU) | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | Open |
High-Impact Requirements
Show high-impact requirements (413)
| Requirement ID | Topic | Supplier Position | Estimation Impact | Cybersecurity Impact | Required Decision |
|---|---|---|---|---|---|
| REQ-AUTO-00001 | The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0001 | Cybersecurity methods and strategies - The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0002 | Risk assessment - The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations. | Accept with Assumption | High | Vulnerability management | Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00006 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. | Needs Customer Clarification | Unknown | None | Send linked open point to the customer for decision. |
| REQ_SEC_0003 | Cybersecurity concept - The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0022 | Marcus Lindner EPXC Published 6(16) - All risks identified in cybersecurity risk analyses shall be evaluated. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00009 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0023 | Cybersecurity controls shall sufficiently reduce the risk. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00011 | It shall be possible to verify which cybersecurity controls were derived from which requirements. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0024 | The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0004 | Verification and validation - The supplier shall provide documentation of the verification and validation methods of cybersecurity features. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0005 | The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0025 | Marcus Lindner EPXC Published 7(16) - A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier. | Accept with Assumption | High | None | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0042 | The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0008 | Software security - The ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU. | Accept with Assumption | High | Authentication | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0009 | Security architecture - The supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0020 | Cryptographic libraries - Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier. | Accept with Assumption | High | None | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0012 | Interfaces - Communication interfaces shall use boundary controls such as ingress/egress filtering. | Accept with Assumption | High | None | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0014 | Any interfaces used for development purposes shall be removed or disabled in series production. | Accept with Assumption | High | None | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0026 | Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production. | Partially Accept | Low | None | Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_SEC_0027 | Information security - It shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0016 | Key management - It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer. | Partially Accept | High | Key management | Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_SEC_0019 | Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases. | Accept with Assumption | High | Key management | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0015 | ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0043 | Security updates - It shall be possible to update the software of the ECU. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0030 | Marcus Lindner EPXC Published 10(16) - The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0045 | In case of cybersecurity incidents, the incident response process shall be used. | Accept with Assumption | High | Incident response | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0034 | Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability. | Partially Accept | Medium | None | Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00051 | The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability. | Accept with Assumption | High | Vulnerability management | Validate assumption with customer; complete mapping; implement. |
| REQ_SEC_0050 | Marcus Lindner EPXC Published 12(16) - All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU. | Partially Accept | Medium | None | Agree responsibility split (DIA) for the non-ECU portion. |
| REQ_SEC_0051 | Logging - Security related events shall be identified and logged. | Accept with Assumption | High | Logging and audit trail | Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00078 | P 1 Page 4 Mechanical interface 4.1 The maximum release stroke is 22,4 mm from FCCP 4.2 The total stroke of the actuator shall be 85 mm. | Partially Accept | High | None | Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00091 | Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand. | Partially Accept | Medium | None | Agree responsibility split (DIA) for the non-ECU portion. |
| req-5.10 | P 1 Page 5 Clutch engage and disengage 5.1 It shall be possible to disengage the clutch in 180ms (= Ts) with accuracy according to req 5.10,and max speed set to 125mm/s (see req 6.4) Time is measured according to Figure 7 – Max disengage time, where the dashed line is the position request as it becomes available on the CAN bus, and the full line is the actual PP. | Partially Accept | Medium | None | Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00116 | The FCCP after a clutch engage shall be updated to 90% of the step within 0,2 s per mm that the FCCP have changed during the stroke. | Accept with Assumption | High | None | Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00140 | If the actuator can move faster than this value it shall be controlled in a such way that it does not exceed this limit. | Partially Accept | Medium | None | Agree responsibility split (DIA) for the non-ECU portion. |
| REQ-AUTO-00146 | Message contents to be agreed with Traton 6.9 ECA identification number: The ECA shall report a unique ECA individual identification number 6.10 Supplier code: The ECA shall report supplier code 5 via CAN. | Needs Customer Clarification | Unknown | None | Send linked open point to the customer for decision. |
| req-6.20 | 6.13 Error State Diagnostic - ESD and Error State Action - ESA The ECA shall send a bit field via CAN containing errors present Additionally, see req 6.20, req 6.22 ,req. | Accept with Assumption | High | Diagnostic security | Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00164 | The filter time shall equal the update frequency . | Accept with Assumption | High | None | Validate assumption with customer; complete mapping; implement. |
| REQ-AUTO-00169 | 6.21 Cyber Security: Cybersecurity shall be considered through a separate process with the latest Traton workflow in mind. | Accept with Assumption | High | Cybersecurity requirement hand | Validate assumption with customer; complete mapping; implement. |
Workflow Progress
| Step | Status | Output | Blocking Issue |
|---|---|---|---|
| Input Analysis | complete | 1076 requirements parsed (Markdown-derived). | - |
| Supplier Proposal Preparation | complete | 1060 proposals ready. | - |
| Customer Feedback Pending | pending | Awaiting customer feedback ingestion. | Customer feedback not yet ingested. |
| Agreement Baseline | pending | Agreement baseline status: Not established. | Depends on customer feedback. |
| Estimation Ready | in_progress | Qualitative estimation impact generated. | Pending or modified customer decisions affect estimation. |
| Concept Draft Ready | in_progress | Initial cybersecurity concept drafted. | Customer feedback/open points still affect the concept. |
| System Requirement Derivation Ready | in_progress | 74 candidate supplier system requirements derived. | Customer feedback/open points still block SSR finalization. |