ISO 26262 traceability audit failing in compliance-validation module

Our ISO 26262 compliance-validation module reports missing bidirectional trace chains between safety requirements and test results. The audit report shows ‘Incomplete Trace Coverage’ for functional safety requirements, but I can manually verify the traces exist in DOORS Next.

The validation query returns incomplete results:


Validation Rule: ISO_26262_Trace_Chain
Status: FAILED - 47 of 203 requirements missing complete trace
Missing: Requirement → Design → Implementation → Test

I suspect artifact type inheritance isn’t working correctly in traceability queries. The safety requirements inherit from a base ‘FunctionalRequirement’ type, and the validation might not be following inheritance chains. How do I configure baseline completeness verification to include inherited artifact types?

That makes sense. Our safety requirements use three concrete types that inherit from FunctionalRequirement: ‘SystemRequirement’, ‘SoftwareRequirement’, and ‘HardwareRequirement’. The validation rule only specifies ‘FunctionalRequirement’. Should I list all three concrete types explicitly in the validation configuration, or is there a way to enable inheritance-aware queries?

ISO 26262 traceability has strict requirements for complete trace chains through all lifecycle phases. The compliance-validation module uses explicit artifact type matching by default - it won’t follow inheritance unless configured. Check if your validation rule includes all concrete artifact types, not just the base types.

Here’s the complete configuration to resolve your ISO 26262 traceability audit failures:

1. ISO 26262 Functional Safety Traceability Requirements: ISO 26262 mandates complete bidirectional trace chains through all lifecycle phases. Your validation rule must verify:

  • Requirements → Architecture/Design (satisfies)
  • Architecture/Design → Implementation (implements)
  • Implementation → Test Cases (testedBy)
  • Test Cases → Test Results (verifies)
  • Backward traces in all directions

2. Bidirectional Trace Chain Validation: Edit your validation rule configuration:


Rule: ISO_26262_Trace_Chain
Trace Chain Definition:
  - Forward: satisfies, implements, testedBy, verifies
  - Backward: satisfiedBy, implementedBy, tests, verifiedBy
Validation Mode: Complete Chain Required

Each requirement must have a complete forward and backward trace path through all phases.

3. Artifact Type Inheritance in Traceability Queries: Navigate to Compliance Validation > Rule Configuration > ISO_26262_Trace_Chain:

  • Set ‘Artifact Type Matching’ = ‘Include Subtypes’
  • Add base type: ‘FunctionalRequirement’
  • Enable ‘Follow Type Inheritance’ checkbox
  • Set ‘Inheritance Depth’ = ‘Unlimited’ (or specific depth if needed)

This configuration makes the query engine resolve all concrete types (SystemRequirement, SoftwareRequirement, HardwareRequirement) that inherit from FunctionalRequirement.

4. Baseline Completeness Verification: For existing baselines created before inheritance configuration:

  • Navigate to Baselines > Select affected baselines
  • Run ‘Baseline Metadata Refresh’ utility
  • Select ‘Update Type Inheritance Information’
  • Verify refresh completes without errors

This updates baseline metadata to reflect current type inheritance without modifying artifact versions.

5. Audit Report Generation with Full Artifact Coverage: Configure comprehensive audit reporting:

  • Compliance Validation > Audit Reports > ISO 26262 Template
  • Enable ‘Include All Artifact Types’ (includes inherited types)
  • Set ‘Trace Coverage Display’ = ‘Show Missing Links by Phase’
  • Enable ‘Baseline Comparison’ to track coverage changes over time
  • Set ‘Report Format’ = ‘ISO 26262 Compliance Matrix’

Run the audit report generator after applying these configurations. The report should now show complete trace coverage including all inherited artifact types. Any remaining failures will indicate genuine missing traces that need to be created, not configuration issues.

For the 47 requirements showing failures, re-run the validation after baseline refresh. If failures persist, use the detailed audit report to identify which specific trace links are genuinely missing in each lifecycle phase.

I enabled ‘Include Subtypes’ but the audit still fails for some requirements. Looking closer at the failed items, they’re all in baselines created before we configured the inheritance setting. Does baseline completeness verification require re-baselining after configuration changes?

Also verify your bidirectional trace chain validation is configured for all required link types. ISO 26262 requires specific trace relationships: ‘satisfies’ (req→design), ‘implements’ (design→code), ‘verifies’ (test→req). Each direction needs explicit configuration in the validation rule. Missing any link type in either direction will cause audit failures even if some traces exist.