RFQ Review Dashboard

Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.

Last updated: 2026-06-29 11:49
RTRFQX Review TeamWorkspace

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 Requirements1789Markdown-derived
Reviewed Requirements1789internal review done
Not Reviewed0remaining
Accepted145clear scope
Accepted with Assumption310confirm method/owner
Partially Accepted241shared responsibility
Rejected0with rationale
Clarification Needed208blocked
Customer Decision Pending1789awaiting feedback
Mapped to Cybersecurity Concept696accepted/partial
Mapped to Estimation1789all requirements
Mapped to Supplier System Req.698derived

Supplier System Requirement Derivation

Customer Requirements1789total
Active Requirements1790in baseline
Derived Supplier System Requirements73many-to-many
Customer Requirements Mapped to SSRs698to SSRs
Unmapped Active Requirements0derivable, unmapped
Blocked by Clarification238open
Derivation Coverage %100.0%of derivable

Coverage detail → · Supplier system requirements →

Review Status Summary

StatusCountMeaningNext Action
Proposal Ready1515Supplier proposal draftedSend to customer
Needs Customer Clarification208Progress
Reference - no action63Progress
Reviewed Internally3Reviewed; proposal not finalResolve clarification/review

Top Open Points

Open Point IDTopicImpactOwnerRequired Customer AnswerStatus
OP-001ECU designation, variant and item definition for TARAHighOEM / CustomerConfirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).Open
OP-002Diagnostic security role model and service authorizationHighShared (OEM policy / Supplier ECU)Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.Open
OP-003Key and certificate ownership, provisioning and lifecycleHighOEM / Customer (PKI) + Supplier (ECU)Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.Open
OP-004Secure software update / backend campaign responsibilityHighShared (OEM backend / Supplier ECU)Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.Open
OP-005Secure on-board communication (SecOC/SDT) signal allocationHighOEM / CustomerConfirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication.Open
OP-009Cybersecurity work products, DIA and responsibility splitHighOEM / Customer + Supplier (DIA)Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.Open
OP-006Incident response and vulnerability management ownershipMediumOEM / Customer (fleet) + Supplier (ECU)Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.Open
OP-008Production, development and debug-interface hardeningMediumShared (OEM process / Supplier ECU)Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy).Open

All open points →

Top Open Point Cards

OP-001: Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).

Topic: ECU designation, variant and item definition for TARA | Owner: OEM / Customer | Status: Open | Related requirements: 8

Decision detail

Why it matters: The item definition fixes the scope of the whole cybersecurity case; without it, assets, goals and effort cannot be frozen.

Required decision: Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).

Impact if unresolved: TARA scope and effort stay open; downstream assets, goals and design may rework.

High

OP-002: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.

Topic: Diagnostic security role model and service authorization | Owner: Shared (OEM policy / Supplier ECU) | Status: Open | Related requirements: 37

Decision detail

Why it matters: Diagnostic access is a primary attack surface; authorization scope drives security access design and verification effort.

Required decision: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.

Impact if unresolved: Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service.

High

OP-003: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.

Topic: Key and certificate ownership, provisioning and lifecycle | Owner: OEM / Customer (PKI) + Supplier (ECU) | Status: Open | Related requirements: 19

Decision detail

Why it matters: Key lifecycle responsibility determines ECU storage requirements, provisioning interfaces and production-line dependencies.

Required decision: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.

Impact if unresolved: ECU secure-storage and provisioning design is blocked; production-line and PKI dependencies stay open.

High

OP-004: Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.

Topic: Secure software update / backend campaign responsibility | Owner: Shared (OEM backend / Supplier ECU) | Status: Open | Related requirements: 25

Decision detail

Why it matters: Update is a high-impact attack surface; the backend/ECU split decides which controls and evidence the supplier must deliver.

Required decision: Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.

Impact if unresolved: Update-control scope and evidence ownership stay open; risk of an unprotected update path.

High

OP-005: Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication.

Topic: Secure on-board communication (SecOC/SDT) signal allocation | Owner: OEM / Customer | Status: Open | Related requirements: 24

Decision detail

Why it matters: Communication protection allocation drives CAN matrix changes, key needs and runtime budget; it cannot be inferred safely.

Required decision: Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication.

Impact if unresolved: Protected-signal design, key needs and runtime budget stay open; risk of unprotected critical signals.

High

OP-009: Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.

Topic: Cybersecurity work products, DIA and responsibility split | Owner: OEM / Customer + Supplier (DIA) | Status: Open | Related requirements: 9

Decision detail

Why it matters: ISO 21434 work-product ownership must be agreed; otherwise the supplier may carry OEM-owned obligations or leave gaps.

Required decision: Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.

Impact if unresolved: Without an agreed DIA the supplier risks owning customer work products or leaving cybersecurity gaps in the case.

High

OP-006: Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.

Topic: Incident response and vulnerability management ownership | Owner: OEM / Customer (fleet) + Supplier (ECU) | Status: Open | Related requirements: 2

Decision detail

Why it matters: Post-SOP cybersecurity obligations (UNECE R155 / ISO 21434 clause 7) need a clear owner to bound lifecycle effort.

Required decision: Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.

Impact if unresolved: Lifecycle effort and field-response capability stay unbounded; risk of an R155 compliance gap.

Medium

OP-008: Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy).

Topic: Production, development and debug-interface hardening | Owner: Shared (OEM process / Supplier ECU) | Status: Open | Related requirements: 5

Decision detail

Why it matters: Production and debug interfaces are a common attack surface; expectations drive hardware fusing and EOL process design.

Required decision: Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy).

Impact if unresolved: Hardware fusing and EOL process design stay open; risk of an exposed debug/production interface.

Medium

High-Impact Requirements

Show high-impact requirements (611)
Requirement IDTopicSupplier PositionEstimation ImpactCybersecurity ImpactRequired Decision
RFQX-1001379436-P10-000-01-0009Method and scope shall be proposed to and approved by the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0010Documentation on the method and results shall be provided to the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0011Note: 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 ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0014For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk.Needs Customer ClarificationLowCybersecurity requirement handlingConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0016It shall be possible to verify which cybersecurity controls were derived from which requirements.Needs Customer ClarificationLowCybersecurity requirement handlingConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0026Methods shall be proposed to and approved by the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0028Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier.Accept with AssumptionHighNoneValidate assumption with customer; complete mapping; implement.
RFQX-1001379436-P10-000-01-0033Methods shall be proposed and approved by the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0035The details shall be agreed upon between the vehicle manufacturer and the supplier.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0036Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production.Partially AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-1001379436-P10-000-01-0041It 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 AcceptHighKey managementAgree responsibility split (DIA) for the non-ECU portion.
RFQX-1001379436-P10-000-01-0042Secrets, 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 AssumptionHighKey managementValidate assumption with customer; complete mapping; implement.
RFQX-1001379436-P10-000-01-0045It shall be possible to update the software of the ECU.Accept with AssumptionHighCybersecurity requirement handlingValidate assumption with customer; complete mapping; implement.
RFQX-1001379436-P10-000-01-0052The report shall include information needed to identify the affected vehicles/products.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0053Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0054Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability.Partially AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-1001379436-P10-000-01-0056The 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.Needs Customer ClarificationLowVulnerability managementConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0057Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0063All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU.Partially AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-1001379436-P10-000-01-0064End-of-life and decommissioning shall be specifically considered.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0065Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-1001379436-P10-000-01-0066b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0001The gearbox itself shall be used in all drivetrains and the ECA shall be common and must be complaint to be put on any driveline setup.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0008The variant type shall be based on delivery agreement and Brand involved.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0009Common marking requirements that must be fulfilled for each marking variant are: Marking method: MA1 Marking height: 3 mm Date format: YYMMDD A unique serial number A DMC according to Scania STD 4562 (Ref 14.18) that contains the part number and serial number information.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0010The marking shall not be visible when the ECA is mounted on a gearbox.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0011The ECA units shall be delivered to the required Traton brand’s production in a position in the pallet where the marking is visible.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-00154.16) shall be marked according to the requirements in Scania STD19 (Ref 14.17) Tentik, wordmark variant W Part number (9 digits, two spaces in format 12 345 6789) Marking method: CAS Marking height: 2-6 mm.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0016Details to be agreed with Traton 2.9 Traton shall be invited to participate in electrical and mechanical design reviews.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-00172.10 Traton requires extensive testing to be performed by the supplier to verify all demands stated in the requirement specification.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-00182.12 Traton requires: - Documentation of the product, i.e.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0024When the ECA is assembled, it shall not be possible to insert an object larger than Ø0,2 mm (A wire could be used as test object) between the ECA and gearbox flange, so that the object enters the space behind the ECA. The rubber grommet at the lower part of the flange can have the same interface as the surrounding aluminum flange.Partially AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-3299216-1-0028The surface roughness of the ECA opposite to surface B shall be equal or finer than Ra 3,2 µm.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0033It shall be possible to pull the pushrod 50 times with a force of 300 N without risk for it to come loose from the ECA. 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 AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-3299216-1-0036The ECA shall provide a support for a clutch snap in tool on the marked surface in Figure 4 ISO view of 3D envelope. The maximum force is 1kN. Surface indents are allowed as long as it does not affect other requirements or the structural integrity of the ECA.Partially AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-3299216-1-0037The holes shall also block the guide pin from protruding more than 14 mm from the gearbox housing.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0038Alternatively it can have a loose fit in the ECA, but it shall be possible to reconnect it by pushing it back by hand.Needs Customer ClarificationLowNoneConfirm with customer whether this is a binding requirement and assign a customer ID.
RFQX-3299216-1-0039The hole shall be equipped with a cover possible to assemble and disassemble at least 50 times without tools. If an interference fit is chosen, the maximum force to assemble/disassemble shall be 50 N in room temperature. It shall still remain intac t and keep tightness after vibration testing (See req.10.5)Partially AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-3299216-1-0040When the cover is assembled it shall not be possible to insert an object larger than Ø0,2 mm into the gearbox housing between the cover and ECA. A wire could be used as test object. Figure 6 - Snap in tool spacePartially AcceptMediumNoneAgree responsibility split (DIA) for the non-ECU portion.
RFQX-3299216-1-0041The ECA shall have a loop or similar feature where the cable can be fixated with a cable tie Optionally an M8 screw thread and rotation stop for a sheet metal bracket indicated in Figure 4 - ISO view of 3D envelope, can be provided. The loop or Scania assembled bracket shall be located close to the centre ( ± 20 mm) of the cable section between the connector and last cable fixation point on the gearboxPartially AcceptLowNoneAgree responsibility split (DIA) for the non-ECU portion.

Workflow Progress

StepStatusOutputBlocking Issue
Input Analysiscomplete1789 requirements parsed (Markdown-derived).-
Supplier Proposal Preparationcomplete1529 proposals ready.-
Customer Feedback Pendingin_progress1 feedback rows processed.-
Agreement Baselinein_progressAgreement baseline status: Not established.No customer feedback has been ingested.
Estimation Readyin_progressQualitative estimation impact generated.Pending or modified customer decisions affect estimation.
Concept Draft Readyin_progressInitial cybersecurity concept drafted.Customer feedback/open points still affect the concept.
System Requirement Derivation Readyin_progress73 candidate supplier system requirements derived.Customer feedback/open points still block SSR finalization.

Concept draft → · Supplier system requirements →