Skip to content
Arc
Menu

Automotive

Requirements management for automotive teams.

Connect vehicle requirements, system interfaces and verification evidence. Review hardware and software changes across the teams responsible.

Book a demo

02Engineering challenges

Follow each change across the vehicle.

Software, electronics, calibration and supplier interfaces contribute to the same vehicle behaviour.

  1. Changes reach across suppliers

    An ECU update can affect hardware interfaces and calibration owned by another team or supplier.

  2. Tests cover particular variants

    Simulation and bench evidence belongs to an identified hardware, software and calibration state.

  3. Assurance questions need distinct reviews

    Malfunction safety, intended-functionality performance and cybersecurity require separate scope and acceptance decisions.

03How Arc helps

Connect vehicle behaviour across hardware and software.

Keep the requirements, interfaces and evidence behind each variant available for review.

Vehicle and supplier context

Connect vehicle intent to the system interface.

Link requirements to ECUs, supplier interfaces and their owners. Keep the source revision and vehicle configuration with each review record.

Inspect the fictional vehicle requirement

Illustrative engineering example: fictional candidate IF-SENS-03 is associated with CFG-VEH-B. The same interface change is reviewed through three distinct assurance scopes.

No supplier, fault scenario, test result or accepted vehicle change is supplied. Scope and owner are to confirm, and evidence applicability is Pending in each review.

Illustrative engineering example · Vehicle sensor-interface review

Candidate vehicle interface

IF-SENS-03

CFG-VEH-B

Pending

  • IF-SENS-03reviewed for

    Malfunction-related safety

    Scope and owner to confirm

    Pending

  • IF-SENS-03reviewed separately for

    Intended-functionality performance

    Scope and owner to confirm

    Pending

  • IF-SENS-03reviewed separately for

    Cybersecurity exposure

    Scope and owner to confirm

    Pending

Shared system links do not merge the methods or acceptance authorities of these scopes.

Awaiting engineer review

Requirement record
Vehicle interfaceIF-SENS-03Candidate revision
Candidate configuration
CFG-VEH-B
Malfunction-related safety
Scope and owner to confirm
Intended-functionality performance
Scope and owner to confirm
Cybersecurity exposure
Scope and owner to confirm
Evidence applicability
Pending
Owner
Scope and owner to confirm

Awaiting engineer review

Illustrative engineering example. The three assurance scopes are distinct and unresolved. No safety or cybersecurity conclusion is supplied.
Arc FOREST-3 demo requirements table with REQ-013 marked Needs re-verification
Arc FOREST-3 demo. REQ-013 has a candidate change from 150 to 200 W and is marked Needs re-verification.

Variant changes and agents

Review the effect across the vehicle.

Follow an interface or calibration change into affected requirements and evidence. Keep malfunction safety, intended-functionality performance and cybersecurity questions distinct.

Inspect the fictional interface comparison
Illustrative engineering example · Vehicle sensor-interface review

IF-SENS-03 candidate review scopes

Interface revision

Current

Prior content not supplied

Proposed

Candidate IF-SENS-03

Malfunction-related safety
Scope and owner to confirmPending
Intended-functionality performance
Scope and owner to confirmPending
Cybersecurity exposure
Scope and owner to confirmPending

Affected records

  • IF-SENS-03 candidate review scopes

    IF-SENS-03

    Candidate interface change under review

  • IF-SENS-03 candidate review scopes

    CFG-VEH-B

    Candidate vehicle configuration · evidence applicability Pending

  • Keep malfunction safety, intended-functionality performance and cybersecurity exposure as separate scopes.
  • No actual interface payload, prior assessment or test result is supplied.

Awaiting engineer review

Full change comparison
IF-SENS-03 candidate review scopes
Record / valueCurrentProposed
Interface revisionPrior content not suppliedCandidate IF-SENS-03
Vehicle configurationPrior state not suppliedCandidate CFG-VEH-B
Malfunction-related safetyPrevious assessment not suppliedScope and owner to confirm
Intended-functionality performancePrevious assessment not suppliedScope and owner to confirm
Cybersecurity exposurePrevious assessment not suppliedScope and owner to confirm
Evidence applicabilityPrevious scope not suppliedPending

Unchanged constraints

  • Keep malfunction safety, intended-functionality performance and cybersecurity exposure as separate scopes.
  • No actual interface payload, prior assessment or test result is supplied.

Affected records

IF-SENS-03
Candidate interface change under review
CFG-VEH-B
Candidate vehicle configuration · evidence applicability Pending

Awaiting engineer review

Illustrative qualitative comparison. The candidate interface content and prior configuration are not supplied. No standards satisfaction is inferred.

Review findings with their source context.

Agents help trace dependencies and flag requirement or verification gaps. Engineers assess the proposed action within the relevant assurance scope.

Inspect the fictional agent proposal
Illustrative engineering example · Vehicle sensor-interface review

Sources

  • IF-SENS-03
  • CFG-VEH-B
  • Three assurance scopes
  • Evidence applicability

Finding

The candidate identifies three different assurance questions, but their scope, owners and evidence expectations are unresolved.

Proposed action

Confirm each scope and responsible owner, connect the relevant requirements and risk records, and assess evidence applicability before accepting the interface change.

Engineer review

Awaiting engineer review

This authored proposal does not perform a safety or cybersecurity assessment or establish automatic standards satisfaction.

Source and proposal detail

Sources

  • IF-SENS-03

    Candidate sensor-interface revision.

  • CFG-VEH-B

    Candidate vehicle configuration.

  • Three assurance scopes

    Malfunction safety, intended-functionality performance and cybersecurity exposure: Scope and owner to confirm.

  • Evidence applicability

    Pending for the candidate.

Finding

The candidate identifies three different assurance questions, but their scope, owners and evidence expectations are unresolved.

Proposed action

Confirm each scope and responsible owner, connect the relevant requirements and risk records, and assess evidence applicability before accepting the interface change.

Awaiting engineer review

This authored proposal does not perform a safety or cybersecurity assessment or establish automatic standards satisfaction.

Illustrative sourced proposal. It does not perform the safety, intended-functionality or cybersecurity assessments.
Arc FOREST-3 demo impact analysis showing a proposed branch and conflict notice
Arc FOREST-3 demo. The impact view shows an unapproved branch and a conflict notice for review.

Evidence and variant review

Identify the vehicle state behind the result.

Connect requirements to simulation or bench evidence and its hardware, software and calibration references. Retain pending applicability decisions for the candidate variant.

Inspect the fictional evidence trail
Illustrative engineering example · Vehicle sensor-interface review
  1. 01

    Candidate interface

    IF-SENS-03

    Pending

    assessed within
  2. 02

    Assessed vehicle configuration

    CFG-VEH-B

    Hardware / software
    To identify
    Calibration
    To identify
    Test setup / conditions
    To identify

    Pending

    reviewed for
  3. 03

    Separate scope reviews

    Malfunction-related safety
    Scope and owner to confirm
    Intended-functionality performance
    Scope and owner to confirm
    Cybersecurity exposure
    Scope and owner to confirm

    Pending

    needs scoped
  4. 04

    Result and supporting evidence

    No candidate result supplied

    Pending

    reviewed for applicability
  5. 05

    Applicability decision

    Separate responsible owners to decide

    Pending

Evidence applicability is Pending. A shared configuration does not combine assurance methods or acceptance decisions.

Illustrative configuration-evidence review. No simulation, bench result or acceptance decision is supplied.

Bring each assurance owner into the decision.

Review proposed work with system, supplier, safety, cybersecurity and verification owners. Retain the baseline and the separate scope decisions needed for acceptance.

Inspect the fictional vehicle review
Illustrative engineering example · Vehicle sensor-interface review
Main developmentProposed branch
  1. 01Review basis

    Source vehicle programme records

    Main development
  2. 02Candidate branch

    IF-SENS-03 / CFG-VEH-B

    Proposed branch
  3. 03Scope and owner to confirm

    Malfunction-related safety

    Proposed branch
  4. 04Scope and owner to confirm

    Intended-functionality performance

    Proposed branch
  5. 05Scope and owner to confirm

    Cybersecurity exposure

    Proposed branch
  6. 06Applicability Pending

    Configuration-specific evidence

    Proposed branch
  7. 07Pending decision

    Merge only after acceptance

    Proposed branch

Responsible review

  • Scope and owner to confirm
  • Scope and owner to confirm
  • Scope and owner to confirm
  • Scope and owner to confirm
Baseline and configuration detail
Main developmentProposed branch
  1. 01Review basis

    Source vehicle programme records

  2. 02Candidate branch

    IF-SENS-03 / CFG-VEH-B

  3. 03Scope and owner to confirm

    Malfunction-related safety

  4. 04Scope and owner to confirm

    Intended-functionality performance

  5. 05Scope and owner to confirm

    Cybersecurity exposure

  6. 06Applicability Pending

    Configuration-specific evidence

  7. 07Pending decision

    Merge only after acceptance

Programme baseline
Meaning
The agreed vehicle-programme revisions, allocations, review decisions and open issues at a named point in development.
Assessed configuration
Meaning
The actual hardware, software, calibration, model or test setup and conditions represented by a result. CFG-VEH-B is a candidate and its evidence is pending.
Illustrative review path. Scope ownership and evidence applicability remain open. No accepted vehicle baseline is implied.
Arc FOREST-3 demo test record with a retained Pass marked Needs re-verification
Arc FOREST-3 demo. A retained Pass is marked Needs re-verification. The screenshot shows no rerun.

04Standards and assurance scope

Connect the evidence while keeping assurance scopes distinct.

Functional safety, safety of the intended functionality and automotive cybersecurity cover complementary concerns. Keep their scope and acceptance decisions explicit.

Link the applicable obligations to requirements, evidence and accountable owners. Record the agreed scope and tailoring for functional safety, intended functionality, cybersecurity and process assessment.

Apply editions and scope agreed for the programme. Connected records provide review context. Compliance, process assessment outcomes and product acceptance remain with responsible programme and customer authorities.

ISO 26262
Functional safety concerning malfunctioning safety-related electrical or electronic systems.
ISO 21448
Safety of the intended functionality, including relevant specification or performance insufficiencies.
ISO/SAE 21434
Automotive electrical and electronic cybersecurity risk management.
Automotive SPICE
Development processes and their assessment. Agree the applicable process scope and evidence expectations.

Connect ECU and test references through API and MCP.

Retain supplier, software, calibration and simulation or bench setup references with the assessed vehicle configuration. Agree supported operations, mappings and permissions.

APIMCPSecurity and deployment
API and MCP
Connect supported records through the API, or give a compatible agent permitted programme context and tools through MCP. Agree mappings, permissions and review for the workflow.
Deployment and AI keys
Discuss deployment in your own AWS or Azure infrastructure under an agreed setup. Bring your own key is available for supported AI providers. Agree access, processing locations and retention for the programme.

05FAQ

Frequently asked questions

What vehicle engineering records can Arc connect?

Arc connects vehicle and system requirements, ECU and supplier interfaces, hardware and software references, calibration context and verification evidence. Each record can retain its source revision, configuration and responsible owner.

How can Arc support an ECU or sensor-interface change review?

Trace the proposed change through affected requirements, vehicle variants and evidence. Review the hardware, software and calibration assumptions alongside the candidate interface. Keep open assurance questions assigned to their owners.

How does Arc organise ISO 26262, ISO 21448, ISO/SAE 21434 and Automotive SPICE?

Keep functional safety under ISO 26262, intended-functionality safety under ISO 21448, cybersecurity under ISO/SAE 21434 and Automotive SPICE process assessment distinct. Arc can connect the agreed obligations, scope, owners and evidence without combining their assessment methods or acceptance decisions.

Can one vehicle test result verify every variant?

A result supports the hardware, software, calibration and simulation or bench conditions assessed. Review its applicability to each changed variant and requirement revision before reusing it as evidence.

How can customer and supplier teams coordinate requirements?

Retain source revisions, interface boundaries, allocations and owners in the connected record. Branch review can expose the changed assumptions and evidence decisions across ECU, supplier and vehicle teams.

Who approves agent suggestions for vehicle requirements?

The responsible engineers review the sources, finding and proposed action. Agents help inspect requirements and dependencies, while safety, intended-functionality, cybersecurity and acceptance decisions remain with their designated owners.

Can Arc connect automotive tools through API and MCP?

Use supported API operations and permitted MCP tools within agreed mappings, permissions and review. Confirm the exchange with ECU, simulation or test systems for the workflow. Customer-owned AWS or Azure deployment and supported AI-provider keys can be included in the agreed setup.

What can an automotive team explore in an Arc demo?

A demo can follow a vehicle requirement through a supplier interface change, affected variant references and evidence-applicability review. Book a demo to discuss your hardware and software workflow.

06Engineering resources

Engineering resources

Browse the blog
  1. Verification and evidenceConnect requirements, methods, results and assessed configurations.Product
  2. Requirements traceability guideFollow a requirement from its source through allocation, results and evidence.Guide
  3. Security and deploymentReview hosting, access, AI processing and rollout responsibilities.Product

07Next step

Review your next vehicle change in Arc.

See how requirements, supplier interfaces and variant evidence come together for review.

Book a demo