Skip to content
Arc
Menu

Aviation

Requirements management for aviation teams.

Connect aircraft and system requirements to design decisions and verification evidence. Keep assurance work tied to the configuration it assesses.

Book a demo

02Engineering challenges

Keep assurance connected across disciplines.

Aircraft, system, software and hardware teams contribute different parts of the review.

  1. Intent gets lost between levels

    Aircraft intent needs to remain connected to system requirements, implementation decisions and the verification that addresses it.

  2. Changes affect another discipline

    A message or interface update can alter software, hardware and supplier assumptions that need joint assessment.

  3. Results assess a different configuration

    Assurance reviewers need the requirement revision, hardware and software state and conditions represented by each result.

03How Arc helps

Connect aircraft intent to multidisciplinary review.

Bring requirements, implementation assumptions and verification evidence into a connected engineering record.

Aircraft and system context

Retain the reason behind the requirement.

Connect aircraft intent to system requirements, interfaces and implementation assumptions. Keep the source, rationale and responsible discipline with each record.

Inspect the fictional aircraft requirement

Illustrative engineering example: a fictional candidate message-rate revision connects interface, system, software, hardware, verification and configuration records for multidisciplinary review.

The records form a review trail, not a derivation hierarchy or an executed product demonstration. No timing result, certification or approved assurance conclusion is supplied.

Illustrative engineering example · Aircraft message-rate review

System requirement

SYS-REQ-07

System owner

  • SYS-REQ-07reviewed alongside

    Software requirement

    SW-REQ-03

    Software owner

  • SYS-REQ-07reviewed alongside

    Hardware assumption

    HW-ASM-04

    Electronic-hardware owner

  • SYS-REQ-07affected by

    Candidate interface

    IF-TIM-07

    Message-rate revision

    Pending

These links express connected review context. They are not a software-to-hardware derivation hierarchy.

Awaiting multidisciplinary review

Requirement record
System requirementSYS-REQ-07
Candidate interface
IF-TIM-07 message-rate revision
System responsibility
Timing requirement and allocation
Software context
SW-REQ-03 · software owner
Hardware assumption
HW-ASM-04 · hardware owner
Verification context
VER-TIM-02 / CFG-AV-B · verification owner
Owner
System owner

Awaiting multidisciplinary review

Illustrative engineering example. Connected review records retain separate responsibilities. Arrows do not imply software-to-hardware derivation.
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.

Design changes and agents

Review the impact across software and hardware.

Trace an interface update into the affected system and software requirements, electronic-hardware assumptions and verification work before acceptance.

Inspect the fictional timing comparison
Illustrative engineering example · Aircraft message-rate review

IF-TIM-07 candidate message-rate revision

Message-rate definition

Current

Source definition · rate not supplied

Proposed

Candidate definition · rate not supplied

Affected records

  • IF-TIM-07 candidate message-rate revision

    SYS-REQ-07

    System owner reviews timing and allocation

  • IF-TIM-07 candidate message-rate revision

    SW-REQ-03

    Software owner reviews behaviour

  • IF-TIM-07 candidate message-rate revision

    HW-ASM-04

    Hardware owner reviews the interface assumption

  • IF-TIM-07 candidate message-rate revision

    VER-TIM-02 / CFG-AV-B

    Verification owner reviews applicability and further work

  • No numerical message rate or completed timing result is supplied.
  • System, software, hardware and verification responsibilities remain separate.

Awaiting multidisciplinary review

Full change comparison
IF-TIM-07 candidate message-rate revision
Record / valueCurrentProposed
Message-rate definitionSource definition · rate not suppliedCandidate definition · rate not supplied
System requirement referenceUnchangedSYS-REQ-07SYS-REQ-07
Software requirement referenceUnchangedSW-REQ-03SW-REQ-03
Hardware assumption referenceUnchangedHW-ASM-04HW-ASM-04
Verification recordVER-TIM-02VER-TIM-02 applicability to review
Assessed configurationPrevious state not specifiedCandidate CFG-AV-B

Unchanged constraints

  • No numerical message rate or completed timing result is supplied.
  • System, software, hardware and verification responsibilities remain separate.

Affected records

SYS-REQ-07
System owner reviews timing and allocation
SW-REQ-03
Software owner reviews behaviour
HW-ASM-04
Hardware owner reviews the interface assumption
VER-TIM-02 / CFG-AV-B
Verification owner reviews applicability and further work

Awaiting multidisciplinary review

Illustrative qualitative comparison. No timing value, accepted allocation or completed verification result is invented.

Inspect the sources behind an agent finding.

Agents help check requirement quality, trace dependencies and flag verification gaps. Engineers assess the finding and proposed action in the programme’s assurance context.

Inspect the fictional agent proposal
Illustrative engineering example · Aircraft message-rate review

Sources

  • IF-TIM-07
  • SYS-REQ-07 / SW-REQ-03
  • HW-ASM-04
  • VER-TIM-02 / CFG-AV-B

Finding

The connected records identify affected disciplines, but no supplied evidence resolves VER-TIM-02 applicability to CFG-AV-B.

Proposed action

Ask the system, software, hardware and verification owners to assess the revision, preserve their separate dispositions and identify further analysis or testing before acceptance.

Engineer review

Awaiting multidisciplinary review

Connected review records are not a derivation hierarchy. Engineers retain acceptance authority and determine the assurance significance of the proposal.

Source and proposal detail

Sources

  • IF-TIM-07

    Candidate message-rate revision.

  • SYS-REQ-07 / SW-REQ-03

    System timing and software behaviour have separate owners.

  • HW-ASM-04

    Electronic-hardware interface assumption.

  • VER-TIM-02 / CFG-AV-B

    Verification applicability to the candidate remains pending.

Finding

The connected records identify affected disciplines, but no supplied evidence resolves VER-TIM-02 applicability to CFG-AV-B.

Proposed action

Ask the system, software, hardware and verification owners to assess the revision, preserve their separate dispositions and identify further analysis or testing before acceptance.

Awaiting multidisciplinary review

Connected review records are not a derivation hierarchy. Engineers retain acceptance authority and determine the assurance significance of the proposal.

Illustrative sourced proposal. It is not executed development-assurance work or an authority decision.
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.

Assessed configurations and review

Keep evidence attached to the configuration assessed.

Connect each requirement to its procedure, evidence and hardware or software state. Retain pending applicability decisions when the candidate aircraft system changes.

Inspect the fictional assurance trail
Illustrative engineering example · Aircraft message-rate review
  1. 01

    Candidate interface revision

    IF-TIM-07

    Message-rate proposal

    Pending

    reviewed against
  2. 02

    System requirement

    SYS-REQ-07

    System owner

    reviewed alongside
  3. 03

    Software requirement

    SW-REQ-03

    Software owner

    reviewed alongside
  4. 04

    Hardware assumption

    HW-ASM-04

    Hardware owner

    reviewed with
  5. 05

    Verification record

    VER-TIM-02

    Verification owner · applicability pending

    Pending

    assessed for
  6. 06

    Candidate configuration

    CFG-AV-B

    Pending

    awaits
  7. 07

    Review decision

    Awaiting multidisciplinary review

    Pending

The sequence connects review records. It does not represent software-to-hardware derivation. No verification result or accepted configuration is supplied.

Illustrative connected review trail, not a derivation hierarchy. Verification applicability is pending.

Review with the accountable disciplines.

Bring system, software, hardware and verification owners into the same branch review. Keep the programme baseline distinct from the configuration represented by each result.

Inspect the fictional multidisciplinary review
Illustrative engineering example · Aircraft message-rate review
Main developmentProposed branch
  1. 01Review basis

    Source aircraft programme records

    Main development
  2. 02Branch proposal

    IF-TIM-07 candidate revision

    Proposed branch
  3. 03System and software review

    SYS-REQ-07 / SW-REQ-03

    Proposed branch
  4. 04Hardware review

    HW-ASM-04

    Proposed branch
  5. 05Pending verification review

    VER-TIM-02 / CFG-AV-B

    Proposed branch
  6. 06Awaiting review

    Multidisciplinary dispositions

    Proposed branch
  7. 07Pending decision

    Merge only after acceptance

    Proposed branch

Responsible review

  • System owner
  • SW-REQ-03 · software owner
  • HW-ASM-04 · hardware owner
  • VER-TIM-02 / CFG-AV-B · verification owner
Baseline and configuration detail
Main developmentProposed branch
  1. 01Review basis

    Source aircraft programme records

  2. 02Branch proposal

    IF-TIM-07 candidate revision

  3. 03System and software review

    SYS-REQ-07 / SW-REQ-03

  4. 04Hardware review

    HW-ASM-04

  5. 05Pending verification review

    VER-TIM-02 / CFG-AV-B

  6. 06Awaiting review

    Multidisciplinary dispositions

  7. 07Pending decision

    Merge only after acceptance

Programme baseline
Meaning
The named aircraft programme state and requirement revisions assessed at a review, including open assurance decisions.
Assessed configuration
Meaning
The hardware, software and conditions represented by verification evidence. CFG-AV-B is a candidate. VER-TIM-02 applicability remains pending.
Illustrative review path. No certification, accepted revision, merge or new baseline is shown as completed.
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

Keep development and assurance scopes distinct.

Aircraft and system development, safety assessment, software, electronic hardware and aviation cybersecurity have distinct scopes. Use the editions agreed with the programme and relevant authority.

Connect the invoked assurance obligations to their requirements and evidence. Record the agreed edition, tailoring and discipline owner so each baseline review retains its governing context.

The certification basis or contract determines invoked editions and required evidence. Linking records or citing guidance does not establish compliance, certification or tool qualification.

SAE ARP4754
Aircraft and system development assurance, including requirements validation and implementation verification.
SAE ARP4761
Safety assessment of civil aircraft, systems and equipment.
DO-178C
Development assurance for airborne software.
DO-254
Design assurance for airborne electronic hardware.
DO-326A
Airworthiness security addressing threats to aircraft safety from intentional unauthorised electronic interaction.

Connect discipline and supplier references through API and MCP.

Keep model, code, hardware and supplier source revisions with the requirements and evidence they inform. Agree supported operations, mappings and review responsibilities.

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 can Arc connect for aircraft and system development?

Arc connects aircraft and system requirements, design decisions, interfaces, software and electronic-hardware references and verification evidence. Sources, revisions and owners provide context for multidisciplinary review.

How can Arc support a change affecting software and hardware?

Trace the proposed interface or requirement change into connected system requirements, software requirements, hardware assumptions and verification records. Reviewers assess the dependencies together while retaining each discipline’s responsibility.

How are ARP4754, ARP4761, DO-178C, DO-254 and DO-326A handled?

Keep their scopes distinct. SAE ARP4754 addresses aircraft and system development assurance, ARP4761 safety assessment, DO-178C airborne software, DO-254 airborne electronic hardware and DO-326A airworthiness security. Arc connects invoked obligations, requirements and evidence under the editions agreed with the programme and relevant authority.

Can verification evidence carry forward after an aircraft-system change?

Retain the requirement revision, procedure, hardware and software configuration and conditions assessed. The responsible reviewers determine what the evidence still supports and what needs further verification for the candidate design.

How can aircraft, software, hardware and supplier teams collaborate?

Use a connected record with source revisions, allocations and discipline owners. Review proposed work on a branch and retain the agreed baseline. The example on this page is a review trail rather than a software-to-hardware derivation hierarchy.

Can agents make development-assurance approval decisions?

Agents help inspect requirement quality, trace dependencies and flag evidence gaps. Engineers review the sources and proposed actions. Approval and assurance decisions remain with the programme’s responsible reviewers and authorities.

Can aviation teams connect tools and choose their deployment?

Supported API operations and permitted MCP tools can connect engineering references through agreed mappings and review. Customer-owned AWS or Azure deployment and supported AI-provider keys are available under an agreed setup. Confirm the programme’s access and processing requirements.

What can an aviation team review in an Arc demo?

A demo can follow an aircraft-system requirement through an interface change, affected discipline records and verification-evidence review. Book a demo to discuss the assurance workflow relevant to your team.

06Engineering resources

Engineering resources

Browse the blog
  1. Requirements traceability guideFollow a requirement from its source through allocation, results and evidence.Guide
  2. Baselines and configurationsDistinguish the programme state from the configuration represented by evidence.Product
  3. Security and deploymentReview hosting, access, AI processing and rollout responsibilities.Product

07Next step

Review your next aircraft-system change in Arc.

See how requirements, discipline decisions and verification evidence stay connected through assurance review.

Book a demo