7.5: Tool Qualification Across Standards - Unified Framework

Introduction

Tool qualification is not a monolithic concept. Different safety-critical standards define distinct frameworks for evaluating the trustworthiness of development, verification, and production tools. In this chapter, you'll discover a unified view across five major standards:

• DO-330 (aviation software tools)
• ISO 26262-8 (automotive functional safety tools)
• IEC 61508-7 (industrial functional safety tools)
• IEC 62304 (medical device software tools)
• ASPICE 4.0 (automotive process assessment, no explicit tool qualification but requires tool validation)

Understanding these frameworks is essential for organizations operating across multiple domains or developing products subject to multiple regulatory regimes. The emergence of AI-based development tools (code generators, verification assistants, requirements analyzers) adds complexity: these tools may not fit cleanly into traditional qualification categories.

This chapter focuses on framework comparison and decision logic. Case studies and detailed templates are provided in companion sections.

Section 1: Executive Comparison

1.1 Standards at a Glance

1.2 Unified Safety Level Mapping

Note: This mapping is approximate. DO-330 TQL levels map to DAL independently; ISO 26262-8 TCL considers both ASIL and tool error impact.

1.3 Core Philosophy Differences

Key Insight: All frameworks evaluate two factors:

1. Impact of tool failure: What happens if the tool makes an undetected error?
2. Mitigation confidence: How likely are we to catch that error?

The standards differ in how they formalize these evaluations.

1.4 Decision Flow: Which Standard Applies?

Use this decision tree to determine which tool qualification standard applies based on your project's industry domain, safety integrity level, and regulatory requirements.

Multi-Standard Scenarios:

• Aviation software in automotive-certified MCU: Apply both DO-330 TQL and ISO 26262-8 TCL. Use highest qualification level.
• Medical device with automotive components: IEC 62304 + ISO 26262. Tool must satisfy both frameworks.
• Industrial controller certified to multiple SILs: IEC 61508-7 governs. Tool qualification follows highest SIL.

Section 2: DO-330 Framework (TQL 1-5)

2.1 DO-330 Context

DO-330:2016, "Software Tool Qualification Considerations," is a supplement to DO-178C. It addresses tools whose output is used as part of the airborne software certification evidence. DO-330 applies when:

1. A tool's output is used to satisfy DO-178C objectives, AND
2. The tool's output is not independently verified, AND
3. An error in the tool could introduce undetected errors into the final software.

Key Principle: If you independently verify the tool's output (e.g., review every line of auto-generated code), the tool does not require qualification. Qualification is required when you trust the tool.

2.2 Tool Qualification Levels (TQL)

DO-330 defines five TQLs, determined by the DAL of the software being developed and the criteria the tool output is used to satisfy.

TQL Determination Logic:

1. Identify the DAL of the software being developed.
2. Identify which DO-178C objectives the tool output satisfies.
3. Map to TQL using DO-330 Table 5-1.

Example:

• Compiler for DAL-A software: Generates object code (replaces verification of source-to-object code correctness). TQL-1 required.
• Static analyzer for DAL-B software: Detects dead code (satisfies DO-178C Table A-4 objective). TQL-2 required.
• Requirements management tool for DAL-C: Manages traceability (satisfies DO-178C Table A-3 objective). TQL-3 required.

2.3 Qualification Artifacts

DO-330 requires three primary artifacts:

Tool Qualification Plan (TQP)

• Purpose: Defines the qualification strategy.
• Contents:
  • Tool identification and version
  • TQL determination rationale
  • Qualification approach (tool development vs. service history)
  • Organizational responsibilities
  • Schedule and resources

Tool Operational Requirements (TOR)

• Purpose: Specifies what the tool must do correctly.
• Contents:
  • Functional requirements for the tool
  • Operational constraints (environment, inputs, outputs)
  • Expected outputs for given inputs
  • Error handling requirements
  • Traceability: Each TOR must trace to the DO-178C objective it supports.

Tool Verification Plan (TVP) and Results

• Purpose: Demonstrates the tool meets TOR.
• Contents:
  • Test cases covering all TOR
  • Test procedures
  • Test results and analysis
  • Verification coverage analysis
  • Known limitations and workarounds

Evidence Package: TQP + TOR + TVP + test results + configuration management records.

2.4 Rigor Reduction: Error Detection and Service History

DO-330 allows TQL reduction if:

1. Error Detection: Tool outputs are subject to verification activities that would detect errors. Example: Code generator output is manually reviewed line-by-line → tool may not require qualification.

2. Service History: Tool has extensive successful operational history. DO-330 Section 12.2.3 allows credit for service history but provides limited quantitative guidance. Typically interpreted as years of use in similar DAL context.

Critical: Error detection credit requires documented verification activities. Simply claiming "we review the output" is insufficient without evidence.

Section 3: ISO 26262-8 Framework (TCL 0-3)

3.1 ISO 26262-8 Context

ISO 26262-8:2018, Section 11, "Supporting processes: Tool confidence level determination," defines how to assess tools used in automotive functional safety activities. Unlike DO-330, ISO 26262-8 applies to all tools used in the safety lifecycle, not just those replacing verification.

Applicability: Any tool that could introduce errors affecting safety analysis, design, implementation, or verification.

3.2 Tool Confidence Levels (TCL)

ISO 26262-8 defines four TCLs:

3.3 TCL Determination Methodology

ISO 26262-8:2018 Clause 11.4.6 defines TCL determination based on two factors:

Tool Impact (TI)

TI assesses the potential for a tool error to introduce or fail to detect errors in safety-related work products.

• TI1: Tool cannot introduce error or error has no safety impact.
• TI2: Tool can introduce error that violates safety requirement.

Tool Error Detection (TD)

TD assesses the likelihood that a tool error will be detected by subsequent activities (manual review, testing, independent tools).

• TD1: High confidence that tool errors will be detected.
• TD2: Medium confidence.
• TD3: Low confidence (tool output is trusted without verification).

TCL Determination Matrix

ASIL Influence: TCL determination is independent of ASIL, but qualification rigor scales with ASIL:

• TCL-1 for ASIL-D requires more evidence than TCL-1 for ASIL-A.
• TCL-3 for ASIL-D requires maximum rigor (equivalent to developing the tool as ASIL-D software).

3.4 Qualification Methods

ISO 26262-8:2018 Clause 11.4.7-11.4.10 defines qualification approaches:

Increased Confidence from Use (11.4.7)

"Proven in use" reduction: TCL may be reduced by one level if:

1. Tool has been used successfully in at least 10 different projects of comparable ASIL.
2. Projects used the tool in the same operational context (same inputs, environment, configuration).
3. No tool errors were detected that could violate safety requirements.
4. Tool version is identical or differs only in non-safety-relevant features.

Example: A requirements management tool used successfully in 15 ASIL-D projects over 5 years may reduce from TCL-2 to TCL-1.

Evaluation of Tool Development (11.4.8)

Assess the tool's own development process:

• Tool developed per ISO 26262 (software tool developed as ASIL software)?
• Configuration management applied?
• Verification and validation performed?
• Known limitations documented?

For TCL-3 tools at ASIL-C or ASIL-D, this often means the tool itself must be developed to ASIL-C/D rigor.

Validation of Tool (11.4.9)

Validate the tool for its intended use:

• Define Tool Validation Requirements (TVR): What must the tool do correctly?
• Execute validation tests demonstrating TVR satisfaction.
• Document test results and coverage.

Note: This is similar to DO-330 TOR/TVP but scoped to the tool's use in the safety lifecycle.

Tool Qualification Plan

For TCL-2 and TCL-3, a Tool Qualification Plan is recommended, containing:

• Tool identification and version
• TCL determination rationale
• Qualification method(s) selected
• Acceptance criteria
• Organizational responsibilities

3.5 Evidence Requirements by TCL and ASIL

Key Insight: TCL-3 at ASIL-D is prohibitively expensive. Organizations avoid TCL-3 by:

1. Using independent verification of tool output (reduces TD → lowers TCL).
2. Selecting tools with "proven in use" history.
3. Using multiple diverse tools (error detection improves).

Section 4: IEC 61508-7 Framework

4.1 IEC 61508-7 Context

IEC 61508-7:2010, "Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures," addresses tools in Annex A and Annex B. IEC 61508 applies to industrial safety systems (process control, machinery, railways, etc.).

Scope: Tools used in the development, verification, and operation of safety-related E/E/PE systems.

4.2 Tool Categories

IEC 61508-7 Annex A categorizes tools:

Offline Support Tools (Table A.4)

Tools that support development but do not execute on the safety system:

• Requirements management tools
• Design tools (CAD, modeling)
• Simulators
• Static analyzers
• Compilers
• Test tools

Assessment Requirement: Tools must be assessed for their impact on safety. The assessment rigor depends on:

1. The SIL of the system being developed.
2. The tool's potential to introduce undetected errors.

Online Support Tools (Table A.5)

Tools that execute on the safety system or directly interact with it:

• Diagnostic software
• Configuration tools
• Calibration tools

Assessment Requirement: Higher rigor. These tools may directly affect the operational safety system.

4.3 Tool Assessment Methodology

IEC 61508-7 does not define "Tool Qualification Levels" like DO-330 or ISO 26262-8. Instead, it requires:

1. Tool Selection (Clause 7.4.2.12): Select tools appropriate for the SIL.
2. Tool Validation (Clause 7.4.2.13): Validate tools for their intended use.
3. Tool Assessment (Annex A): Assess the tool's potential to introduce errors.

Assessment Criteria:

• Development Quality: Was the tool developed using systematic methods?
• Validation Evidence: Has the tool been validated for this use case?
• Service History: Has the tool been used successfully in similar SIL contexts?
• Configuration Management: Is the tool version controlled?
• Known Limitations: Are tool limitations documented and understood?

4.4 Evidence Requirements

Practical Interpretation: SIL-3 and SIL-4 offline tools (e.g., compilers, static analyzers) require evidence similar to ISO 26262 TCL-2 or TCL-3.

4.5 Simplified Assessment for Lower SILs

IEC 61508-7 allows simplified assessment for SIL-1 and SIL-2 offline tools:

• SIL-1: Tool description and rationale for suitability.
• SIL-2: Tool description + basic validation (e.g., vendor test results).

Contrast with ISO 26262: IEC 61508 is less prescriptive. ISO 26262-8 provides explicit TCL determination logic; IEC 61508-7 requires engineering judgment.

Section 5: IEC 62304 Framework

5.1 IEC 62304 Context

IEC 62304:2006/A1:2015, "Medical device software - Software life cycle processes," addresses tools in Section 5.1. IEC 62304 applies to software used in medical devices or as medical devices.

Regulatory Context: IEC 62304 is harmonized with EU Medical Device Regulation (MDR) and recognized by FDA. Tool assessment is part of design control (21 CFR 820.70).

5.2 Tool Assessment Requirements

IEC 62304:2006 Clause 5.1.1 states:

"The software development plan shall identify the software tools to be used and the configuration management and problem resolution processes to be employed."

IEC 62304:2006 Clause 5.1.4 states:

"The manufacturer shall document the rationale for the selection of software tools and shall validate tools for their intended use if the tool output is not verified."

Key Requirement: If the tool output is not independently verified, the tool must be validated for its intended use.

5.3 Tool Validation Approach

IEC 62304 does not define tool qualification levels. Instead, it requires a risk-based approach:

1. Identify the tool's role: What does the tool do? What outputs does it produce?
2. Assess the risk: What is the potential impact on patient safety if the tool introduces an error?
3. Determine verification strategy: Will the tool output be independently verified?
   • Yes: Tool does not require validation (output verification is sufficient).
   • No: Tool must be validated.
4. Validate the tool: Demonstrate the tool produces correct outputs for its intended use.

Validation Evidence:

• Tool description and version
• Intended use and operational context
• Validation test cases covering intended use
• Validation test results
• Known limitations and contraindications
• Configuration management (tool version control)

5.4 Safety Class Influence

IEC 62304 defines three software safety classes:

Example:

• Compiler for Class C device: Output (object code) is not manually verified. Tool must be validated. Evidence: Test cases demonstrating correct code generation, configuration management, known limitations.
• Requirements tool for Class B device: Output (requirements traceability matrix) is manually reviewed. Tool validation may be reduced or waived if review is documented.

5.5 Integration with Design Control (FDA)

FDA 21 CFR 820.70(i) requires validation of automated processes:

"When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol."

FDA Expectation: Tool validation is part of design control. Evidence must demonstrate:

1. Tool is suitable for its intended use.
2. Tool limitations are understood and mitigated.
3. Tool version is controlled.
4. Tool validation is documented and reviewed.

Practical Advice: FDA inspectors look for:

• Tool validation protocol (plan)
• Tool validation report (results)
• Traceability to software development plan
• Configuration management of tool versions

Section 6: Multi-Standard Scenarios

6.1 Common Multi-Standard Contexts

6.2 Evidence Consolidation Strategy

When multiple standards apply, avoid duplicate effort:

1. Identify common requirements: All standards require tool description, intended use, validation evidence.
2. Map frameworks: Create a matrix showing how each standard's requirements are satisfied.
3. Consolidate artifacts: Use a single Tool Qualification Plan that addresses all applicable standards.
4. Reference evidence: Each standard's evidence package references the consolidated artifacts.

Example: Compiler for Automotive Avionics

Consolidation Benefit: Single test suite, single plan, single CM approach. Standard-specific sections in the plan address unique requirements (e.g., DO-330 TQL determination, ISO 26262-8 TCL determination).

6.3 Decision Tree for Multi-Standard Tool Qualification

This decision tree guides teams through the multi-standard qualification process, showing how to identify overlapping requirements and consolidate qualification evidence across standards.

Key Principle: Qualify once, map evidence to all applicable standards.

6.4 Case Study: Static Analyzer for ASIL-D + DAL-B

Context: A static analyzer is used to detect coding standard violations in software that must meet both ISO 26262 ASIL-D and DO-178C DAL-B requirements.

DO-330 Analysis:

• Tool output (coding violation report) is used to satisfy DO-178C Table A-4 objective (code review).
• DAL-B → TQL-2 required.
• TOR: Tool must detect all violations of coding standard X.
• TVP: Test suite demonstrates detection of known violations.

ISO 26262-8 Analysis:

• TI: TI2 (tool failure could miss coding violation that violates safety requirement).
• TD: TD2 (manual code review also performed, but not exhaustive).
• TCL: TCL-2.
• ASIL-D → full qualification required.

Consolidation:

• Single Tool Qualification Plan addresses both DO-330 TQL-2 and ISO 26262-8 TCL-2.
• TOR/TVR consolidated: Define what violations must be detected.
• TVP/Validation consolidated: Single test suite, mapped to both standards.
• Evidence package: CM records, test results, known limitations.

Result: One qualification effort satisfies both DO-330 and ISO 26262-8.

Section 7: AI-Specific Tool Qualification

7.1 The AI Tool Qualification Challenge

Traditional tool qualification frameworks assume:

1. Determinism: Given the same input, the tool produces the same output.
2. Transparency: The tool's behavior can be understood and verified.
3. Stability: The tool's version is fixed and controlled.

AI-based tools (code generators, verification assistants, requirements analyzers) violate these assumptions:

• Non-determinism: LLMs may produce different outputs for the same prompt.
• Opacity: Neural network behavior is not easily explainable.
• Evolution: AI models are frequently updated, often without user control (cloud-based APIs).

Question: Can AI tools be qualified under DO-330, ISO 26262-8, IEC 61508-7, or IEC 62304?

Answer: Traditional qualification is difficult, but augmented frameworks and risk mitigation make AI tools usable in safety-critical contexts.

7.2 AI Tool Qualification Strategies

Strategy 1: Reduce Qualification Need via Verification

Approach: Independently verify all AI tool outputs.

Example: AI code generator produces code. Human developer reviews every line before integration. Tool does not require qualification (DO-330 error detection credit, ISO 26262-8 TD1, IEC 62304 output verification).

Limitation: Defeats the purpose of AI assistance (no productivity gain). Only practical for small outputs or high-risk contexts.

Strategy 2: Statistical Validation

Approach: Validate the AI tool on a large, representative test set.

Example: AI requirements analyzer is tested on 10,000 requirements with known correct classifications. Tool achieves 99.5% accuracy. Validation evidence documents test set, results, and limitations.

Applicability:

• DO-330: TOR defines required accuracy. TVP includes statistical validation. TQL determination per DAL.
• ISO 26262-8: TCL determination considers error detection (statistical validation improves TD). TCL-2 or TCL-3 depending on ASIL and validation rigor.
• IEC 62304: Validation includes statistical evidence. Class C requires extensive test set and known limitations.

Limitation: Statistical validation does not guarantee correctness for every input. Edge cases may fail.

Strategy 3: Human-in-the-Loop (HITL) Oversight

Approach: AI tool provides recommendations; human makes final decisions.

Example: AI suggests code refactorings. Developer reviews and approves each suggestion. AI tool is a "use tool" (IEC 61508-7 terminology), not a "development tool."

Qualification Impact:

• DO-330: Tool output is not trusted → no qualification required.
• ISO 26262-8: TI reduced (tool does not introduce error without human approval) → TCL-0 or TCL-1.
• IEC 62304: Output is verified by human → validation may be reduced.
• ASPICE: HITL is consistent with ASPICE principle of human accountability.

Applicability: HITL is the primary strategy for AI tools in safety-critical contexts. See Part VI (AI Agent Guide) for HITL protocols.

Strategy 4: Novel TCL "3-AI" Framework (Proposed)

Motivation: ISO 26262-8 TCL-3 assumes tool development to ASIL rigor. AI models cannot be developed this way (training is non-deterministic, behavior is emergent).

Proposed Framework: Extend ISO 26262-8 with "TCL-3-AI" for AI tools:

Example: AI code generator for ASIL-D.

• Traditional TCL-3: Impossible (cannot develop LLM to ASIL-D rigor).
• TCL-3-AI: Model validated on 100,000 code generation tasks. Confidence scoring applied. Human reviews all generated code. Tool approved for use with HITL protocol.

Status: This framework is not standardized. It reflects emerging industry practice (ASPICE 4.0 emphasizes HITL, ISO 26262 Edition 3 draft mentions AI tools).

7.3 HITL Requirements from ASPICE

ASPICE 4.0 does not define tool qualification levels, but SUP.8 (Configuration Management) requires tool validation. More importantly, ASPICE process accountability requires human sign-off:

• SWE.1: Requirements analysis → human engineer signs off.
• SWE.3: Detailed design → human engineer signs off.
• SWE.4: Unit construction and verification → human engineer signs off.

Implication: AI tools can assist, but humans own the work product. This is HITL by design.

Practical Guidance:

1. AI tool generates draft requirements. Engineer reviews, modifies, approves.
2. AI tool suggests code. Engineer reviews, tests, approves.
3. AI tool performs static analysis. Engineer reviews findings, makes decisions.

Documentation: Work products must identify:

• Tool used (name, version)
• Tool role (draft generation, analysis, verification)
• Human review performed (reviewer name, date, approval)

7.4 Confidence Limitations and Uncertainty Quantification

AI tools introduce uncertainty. Traditional tools are binary (pass/fail, compliant/non-compliant). AI tools provide probabilistic outputs (confidence scores, likelihood estimates).

Implication for Tool Qualification:

• TOR/TVR must define acceptable confidence thresholds.
• Validation must measure confidence calibration (are 90% confidence predictions correct 90% of the time?).
• Known limitations must document failure modes (e.g., "tool performs poorly on embedded assembly code").

Example: AI Requirements Analyzer:

• TOR: Tool shall classify requirements as "functional" or "non-functional" with ≥95% accuracy and provide confidence score.
• Validation: Test on 10,000 requirements. Measure accuracy and confidence calibration.
• Results: 96.2% accuracy. Confidence scores calibrated (95% confidence predictions are 94.8% accurate).
• Known Limitations: Tool performs poorly on requirements with domain-specific jargon (automotive ECU terminology). Confidence scores drop to 70% for such requirements.
• Usage Protocol: Human reviews all classifications with confidence <90%. All automotive ECU requirements reviewed regardless of confidence.

Status: This approach is not standardized but aligns with statistical validation practices in IEC 62304 and risk-based approaches in ISO 14971 (medical device risk management).

Conclusion

Tool qualification is not a one-size-fits-all process. DO-330, ISO 26262-8, IEC 61508-7, and IEC 62304 provide distinct frameworks tailored to their domains. Understanding these frameworks enables effective tool selection, qualification, and multi-standard compliance.

Key Takeaways:

1. DO-330: TQL 1-5 based on DAL and error detection. Focuses on tools replacing verification.
2. ISO 26262-8: TCL 0-3 based on tool impact (TI) and error detection (TD). Scales with ASIL.
3. IEC 61508-7: Tool categories (use, development, verification) with SIL-dependent assessment.
4. IEC 62304: Risk-based tool validation if output not independently verified.
5. Multi-Standard: Consolidate evidence, map to each framework, qualify to most stringent level.
6. AI Tools: HITL oversight, statistical validation, and uncertainty quantification enable use in safety-critical contexts.

Next Steps: The following sections provide detailed case studies and practical templates for implementing tool qualification across multiple standards.

The emergence of AI tools challenges traditional qualification paradigms, but augmented frameworks and human-in-the-loop protocols enable responsible adoption. The next evolution of safety standards will formalize these approaches—organizations adopting AI tools today are pioneering the practices that will become tomorrow's standards.

Section 8: Four Complete Case Studies

This section presents detailed tool qualification case studies demonstrating practical application of the frameworks presented in Sections 2-5. Each case study includes TCL/TQL determination, evidence packages, integration with ASPICE processes, and regulatory compliance summaries.

8.1 Case Study 1: Static Code Analyzer (Polyspace Bug Finder R2024a)

Tool Context

Tool: MathWorks Polyspace Bug Finder R2024a Purpose: Static analysis for MISRA C:2012 compliance, coding rule violations, and defect detection Standards: ISO 26262 (automotive, ASIL-D) + DO-178C (aviation, DAL-B) Usage Context: Verification of safety-critical embedded software for automotive ECU and avionics flight control system

Multi-Standard TCL/TQL Determination

ISO 26262-8 Analysis:

1. Tool Impact (TI):

   • TI2: Tool failure could miss coding violations that violate safety requirements (e.g., uninitialized variables, NULL pointer dereferences, buffer overflows).
   • If the tool fails to detect a violation, the defect may propagate to production software.

2. Tool Error Detection (TD):

   • TD2: Medium confidence. Manual code review is performed, but not exhaustive (focused on logic, not all MISRA violations).
   • Unit testing detects runtime failures but may miss latent defects.

3. TCL Determination: TI2 + TD2 → TCL-2

4. ASIL-D Implication: TCL-2 at ASIL-D requires full tool evaluation and validation per ISO 26262-8:2018 Clause 11.4.9.

DO-330 Analysis:

1. DAL: Software is DAL-B (flight control system).
2. Objective Satisfaction: Tool output (static analysis report) is used to satisfy DO-178C Table A-4 objectives:
   • Objective 6: "Verify that the Source Code is accurate and consistent."
   • Objective 7: "Verify that the Source Code conforms to standards."
3. Error Detection: Tool output is not independently verified line-by-line. Manual review is selective.
4. TQL Determination: DAL-B + tool output used for verification → TQL-2 (per DO-330 Table 5-1).

Unified Qualification Level: TCL-2 (ISO 26262-8) ≡ TQL-2 (DO-330)

Both frameworks require comparable rigor:

• Tool Qualification Plan
• Tool Operational Requirements / Tool Validation Requirements
• Tool Verification Plan with test evidence
• Configuration management

Tool Operational Requirements (TOR) Excerpt

TOR-001: The tool shall detect all MISRA C:2012 mandatory rules violations in C source code. TOR-002: The tool shall detect all MISRA C:2012 required rules violations in C source code with ≥98% sensitivity (true positive rate). TOR-003: The tool shall generate ≤5% false positive rate for MISRA C:2012 required rules. TOR-004: The tool shall detect uninitialized variables in all execution paths. TOR-005: The tool shall detect NULL pointer dereferences with ≥99% sensitivity. TOR-006: The tool shall detect buffer overflows (array index out of bounds) with ≥99% sensitivity. TOR-007: The tool shall support C99 language standard (automotive context). TOR-008: The tool shall support C90 language standard (avionics context per DO-178C guidance). TOR-009: The tool shall produce machine-parsable output (XML/JSON) for traceability to requirements. TOR-010: The tool shall execute deterministically: identical source code and configuration shall produce identical results.

Traceability:

• TOR-001, TOR-002, TOR-003 → DO-178C Table A-4 Objective 7 (coding standards conformance)
• TOR-004, TOR-005, TOR-006 → DO-178C Table A-4 Objective 6 (code accuracy)
• TOR-001 through TOR-006 → ISO 26262-6:2018 Table 9 (static code analysis for ASIL-D)

Evidence Package (8 Items)

Test Coverage Summary:

• MISRA C:2012 rules coverage: 143/143 mandatory rules, 158/159 required rules (1 rule excluded: Rule 17.3, hardware-specific)
• Defect detection coverage: Uninitialized variables (50 test cases), NULL dereferences (40 test cases), buffer overflows (35 test cases), type mismatches (25 test cases)
• False positive analysis: 2.3% false positive rate (within TOR-003 requirement of ≤5%)

Integration with ASPICE SWE.4 (Software Unit Verification)

ASPICE SWE.4 BP1: "Develop a unit verification strategy"

• Integration: Polyspace static analysis is part of the unit verification strategy. Work product: "Unit Verification Strategy" references Polyspace as verification tool.

ASPICE SWE.4 BP2: "Develop unit verification test cases"

• Integration: Static analysis complements dynamic test cases. Test cases cover runtime behavior; Polyspace covers static defects.

ASPICE SWE.4 BP3: "Verify software units"

• Integration: Polyspace analysis results are reviewed and tracked. Findings are linked to requirements and design elements via bidirectional traceability.

ASPICE Work Product:

• SWE.4 WP1: "Unit verification strategy" → References Polyspace qualification package (evidence items 1-8).
• SWE.4 WP2: "Unit verification results" → Includes Polyspace analysis reports with defect disposition (fixed, accepted with deviation, false positive).

Assessor Evidence: During ASPICE assessment, the assessor reviews:

• Tool qualification plan (demonstrates SUP.8 compliance: tool validation)
• Polyspace analysis reports with traceability to requirements
• Defect tracking showing all findings addressed

Restrictions and Limitations

Restriction 1: Polyspace Bug Finder R2024a shall not be used for multi-threaded code analysis without supplemental concurrency analysis tools (e.g., ThreadSanitizer, manual review).

Restriction 2: Polyspace output for pointer aliasing (MISRA Rule 8.13, const qualification) shall be manually reviewed by a qualified engineer. False positives are known for function pointers with complex call graphs.

Restriction 3: Tool configuration (analysis settings, rule deviations) shall be version-controlled and approved by the Safety Manager (ISO 26262) and DER (DO-178C Designated Engineering Representative).

Restriction 4: Tool version R2024a is qualified. Updates to R2024b or later require re-validation per Tool Qualification Plan Section 7 (change impact analysis).

Regulatory Compliance Summary

Outcome: Polyspace Bug Finder R2024a approved for use in ASIL-D automotive and DAL-B avionics software projects under documented restrictions.

8.2 Case Study 2: Requirements Management Tool (IBM Doors Next Gen v7.0.3)

Tool Context

Tool: IBM Doors Next Gen v7.0.3 (formerly IBM Rational DOORS Next Generation) Purpose: Requirements management, traceability, change control, baseline management Standards: ISO 26262 (automotive, ASIL-C) + IEC 62304 (medical device software, Class C) Usage Context: Automotive infotainment system (ASIL-C safety functions: eCall emergency notification) + medical device diagnostic software (Class C: patient risk if malfunction)

Multi-Standard TCL Assessment

ISO 26262-8 Analysis:

1. Tool Impact (TI):

   • TI2: Tool failure could introduce requirements errors (e.g., missing requirements, incorrect traceability, lost change history) that propagate to design and code.
   • If requirements are incomplete or traceability is broken, safety verification is compromised.

2. Tool Error Detection (TD):

   • TD1: High confidence. Requirements are manually reviewed by systems engineers, safety engineers, and project leads.
   • Traceability matrices are audited during design reviews and verification activities.
   • Independent verification is performed using separate tools (e.g., export to Excel, manual inspection).

3. TCL Determination: TI2 + TD1 → TCL-1

4. ASIL-C Implication: TCL-1 at ASIL-C requires documented tool evaluation and basic validation (ISO 26262-8:2018 Table 4, row TCL-1).

IEC 62304 Analysis:

1. Safety Class: Class C (death or serious injury possible if diagnostic software malfunctions).
2. Tool Output Verification: Requirements documents are reviewed and approved by multiple stakeholders (medical device project manager, clinical engineer, regulatory affairs).
3. Validation Requirement: IEC 62304:2006 Clause 5.1.4 requires tool validation if output is not verified. Since requirements are verified via review, validation may be reduced.
4. Risk-Based Decision: Despite output verification, traceability errors could evade review (human error in manual inspection). Validate tool for traceability correctness.

Unified Qualification Level: TCL-1 (ISO 26262-8) + IEC 62304 Validation (reduced rigor)

Evidence requirements:

• Tool description and version
• Tool Qualification Plan (addresses both standards)
• Tool Validation Requirements (what must the tool do correctly?)
• Validation test cases (focus on traceability correctness, baseline integrity)
• Known limitations

Tool Qualification Plan (TQP) Structure

IBM Doors Next Gen v7.0.3 - Tool Qualification Plan
Document ID: TQP-DOORS-703-01
Revision: 1.2
Date: 2024-10-15

1. Executive Summary
   - Tool: IBM Doors Next Gen v7.0.3
   - Purpose: Requirements management and traceability
   - Standards: ISO 26262 (ASIL-C, TCL-1) + IEC 62304 (Class C, reduced validation)
   - Qualification Approach: Tool validation per ISO 26262-8 Clause 11.4.9 + IEC 62304 Clause 5.1.4

2. Tool Scope and Context
   - Projects: Automotive infotainment (eCall safety function), medical diagnostic software
   - Work Products: System requirements, software requirements, traceability matrices, change history
   - ASPICE Processes Supported: SYS.2 (System Requirements Analysis), SWE.1 (Software Requirements Analysis), SUP.10 (Change Request Management)

3. Standards Applicability
   - ISO 26262-8:2018 Section 11: TCL-1 determination rationale (TI2 + TD1)
   - IEC 62304:2006 Section 5.1: Tool validation with output verification credit
   - 21 CFR 820.70(i): Software validation (FDA design control)

4. TCL/TQL Determination
   - ISO 26262-8: TCL-1 (per Section 8.2 of this case study)
   - IEC 62304: No explicit TCL; validation required with reduced rigor due to output verification

5. Evidence Requirements (Mapped to Standards)
   - Tool description → ISO 26262-8 Clause 11.4.1, IEC 62304 Clause 5.1.4
   - Tool Validation Requirements (TVR) → ISO 26262-8 Clause 11.4.9, IEC 62304 Clause 5.1.4
   - Validation test cases and results → ISO 26262-8 Clause 11.4.9, IEC 62304 Clause 5.1.4
   - Known limitations → ISO 26262-8 Clause 11.4.1, IEC 62304 Clause 5.1.4
   - Configuration management → ISO 26262-8 Clause 11.4.1, 21 CFR 820.70(i)

6. Test Approach
   - Functional validation: 50 test cases covering requirements creation, modification, deletion, linking, baselining
   - Traceability validation: 20 test cases covering bidirectional traceability correctness (suspect links, impact analysis)
   - Baseline validation: 10 test cases covering baseline creation, restoration, comparison
   - Negative testing: 10 test cases covering error handling (invalid links, concurrent edits)

7. Success Criteria
   - All test cases pass (90/90 expected)
   - Known limitations documented and accepted by Safety Manager (ISO 26262) and Quality Manager (IEC 62304)
   - Tool configuration baselined and version-controlled

8. Organizational Responsibilities
   - Tool Owner: Systems Engineering Manager
   - Validation Engineer: QA Lead
   - Reviewers: Safety Manager (ISO 26262), Quality Manager (IEC 62304), Regulatory Affairs (FDA)
   - Approval Authority: Project Manager (automotive), Medical Device Project Manager (medical)

9. Sign-Off Section
   - Tool Owner: _______________ Date: ___________
   - Safety Manager: _______________ Date: ___________
   - Quality Manager: _______________ Date: ___________

Evidence Checklist (12 Items)

Note: Item 8 (service history) provides evidence for potential TCL reduction per ISO 26262-8 Clause 11.4.7. However, TCL-1 is already low-rigor, so reduction to TCL-0 was not pursued.

ASPICE SWE.1 Support Documentation

ASPICE SWE.1 BP1: "Specify software requirements"

• Tool Support: IBM Doors Next Gen stores software requirements with attributes (ID, description, rationale, acceptance criteria, safety relevance, ASIL classification).
• Work Product: SWE.1 WP1 "Software Requirements Specification" is authored in Doors.

ASPICE SWE.1 BP2: "Define software architectural elements and their interfaces"

• Tool Support: Doors maintains traceability from software requirements (SWE.1) to software architectural elements (SWE.2).
• Work Product: Traceability matrix (SWE.1 WP2) is generated from Doors.

ASPICE SWE.1 BP3: "Ensure consistency and bidirectional traceability"

• Tool Support: Doors "suspect links" feature detects when a requirement changes and linked elements are not updated.
• Validation Evidence: Test case TC-TRC-015 validates suspect link detection. Result: Doors correctly flags suspect links when source requirement is modified.

ASPICE SWE.1 BP4: "Communicate agreed software requirements"

• Tool Support: Doors baseline feature creates immutable snapshots for communication to stakeholders.
• Validation Evidence: Test case TC-BASE-003 validates baseline integrity. Result: Baseline restoration reproduces exact requirement state at baseline creation time.

ASPICE Assessor Evidence:

• Tool Qualification Plan demonstrates SUP.8 (Configuration Management) compliance: tool is validated.
• Traceability matrices generated from Doors demonstrate SWE.1 BP3 compliance.
• Baseline reports demonstrate SWE.1 BP4 compliance.

Version Control and Audit Trail Proof

Configuration Management:

• Doors Next Gen server version: 7.0.3 (build 7.0.3-RTP-I20231115_0600)
• Database configuration: PostgreSQL 14.5, backed up daily
• Access control: LDAP integration, role-based permissions (Reader, Contributor, Admin)
• Version control: Doors native versioning enabled (all requirement changes tracked)

Audit Trail Validation:

• Test Case TC-AUDIT-001: Create requirement, modify 3 times, delete. Verify audit trail records all 5 events (create, modify ×3, delete).
  • Result: PASS. Audit trail shows timestamps, user IDs, change descriptions.
• Test Case TC-AUDIT-002: Restore requirement from baseline. Verify restored version matches baseline content.
  • Result: PASS. Content, attributes, links match baseline snapshot.

Evidence for FDA Inspection:

• Audit trail reports (Doors export) demonstrate 21 CFR 820.70(i) compliance (software validation).
• Audit trail demonstrates 21 CFR 11 (electronic records) compliance if e-signatures are used.

Traceability Matrix with Design Artifacts

Example Traceability Chain (Automotive eCall Function):

Doors Traceability Links:

• SYS-REQ-1234 → SWE-REQ-5678 (Satisfies)
• SWE-REQ-5678 → SWE-ARCH-9012 (Implemented By)
• SWE-ARCH-9012 → SWE-UNIT-3456 (Realized By)
• SWE-REQ-5678 → TC-ECALL-001 (Verified By)

Validation Test Case TC-TRC-020: Create traceability chain as above. Modify SWE-REQ-5678 (change "3 seconds" to "2 seconds"). Verify Doors flags SWE-ARCH-9012, SWE-UNIT-3456, TC-ECALL-001 as "suspect" (downstream items may need update).

Result: PASS. Doors correctly identifies all downstream links as suspect. Impact analysis report lists affected artifacts.

ASPICE Compliance: Bidirectional traceability per SWE.1 BP3 demonstrated. Tool qualification evidence supports SUP.8 compliance.

8.3 Case Study 3: CI/CD Pipeline (GitLab Runner 16.5 + ArgoCD 2.9)

Tool Context

Tool: GitLab Runner 16.5 (CI executor) + ArgoCD 2.9 (CD deployment) Purpose: Continuous integration (automated build, test, static analysis) and continuous deployment (automated deployment to test/staging environments) Standards: Multi-standard: ISO 26262 (ASIL-B), IEC 61508 (SIL-2), IEC 62304 (Class B) Usage Context: Automotive infotainment (ASIL-B), industrial HMI (SIL-2), medical monitoring device (Class B)

Multi-Standard TCL Assessment

ISO 26262-8 Analysis:

1. Tool Impact (TI):

   • TI2: CI/CD pipeline failure could deploy incorrect software (e.g., failed tests not detected, wrong binary deployed).
   • If a test failure is not detected or reported, defective software may be released.

2. Tool Error Detection (TD):

   • TD2: Medium confidence. Pipeline logs are reviewed, but not exhaustively.
   • Deployment to production requires manual approval (HITL gate).
   • Test results are independently verified (test reports reviewed by QA engineer).

3. TCL Determination: TI2 + TD2 → TCL-2

4. ASIL-B Implication: TCL-2 at ASIL-B requires tool evaluation and validation (ISO 26262-8:2018 Table 4, row TCL-2).

IEC 61508-7 Analysis:

1. SIL: SIL-2 (industrial HMI: operator injury possible if malfunction).
2. Tool Category: Offline support tool (build and test automation).
3. Assessment Requirement: IEC 61508-7 Annex A, Table A.4 requires tool validation for SIL-2.
4. Evidence: Tool description, validation for intended use (build/test correctness), service history.

IEC 62304 Analysis:

1. Safety Class: Class B (non-serious injury possible if monitoring device malfunctions).
2. Tool Output Verification: Build artifacts (binaries) are tested (functional testing, integration testing).
3. Validation Requirement: IEC 62304:2006 Clause 5.1.4: Validate tool if output not verified. Since binaries are tested, validation may be reduced.
4. Risk-Based Decision: CI/CD configuration errors could bypass tests. Validate tool for test execution correctness.

Unified Qualification Level: TCL-2 (ISO 26262-8) ≡ SIL-2 Assessment (IEC 61508-7) ≡ Class B Validation (IEC 62304)

All three frameworks require comparable evidence:

• Tool description
• Configuration management (pipeline-as-code version control)
• Validation test cases (demonstrate test execution correctness)
• Known limitations

Pipeline Configuration Management

Configuration-as-Code:

• GitLab CI configuration: .gitlab-ci.yml (version-controlled in Git repository)
• ArgoCD deployment manifests: Kubernetes YAML files (version-controlled in Git repository)
• Version control system: Git (GitLab-hosted, SHA-256 commit hashes)

Example .gitlab-ci.yml (Simplified):

# .gitlab-ci.yml - CI Pipeline for ASIL-B Automotive Software
# Version: 1.3.2
# Safety-Critical Configuration: ASIL-B per ISO 26262

stages:
  - build
  - static_analysis
  - test
  - deploy_staging

variables:
  ASIL_LEVEL: "ASIL-B"
  MISRA_COMPLIANCE: "MISRA-C:2012"

build:
  stage: build
  image: gcc:11.4
  script:
    - make clean
    - make CFLAGS="-std=c99 -Wall -Wextra -Werror -O2"
    - sha256sum build/app.elf > build/app.elf.sha256
  artifacts:
    paths:
      - build/app.elf
      - build/app.elf.sha256
    expire_in: 30 days
  tags:
    - safety-critical

static_analysis:
  stage: static_analysis
  image: mathworks/polyspace:R2024a
  script:
    - polyspace-bug-finder -sources src/ -misra3 mandatory-required -results-dir polyspace_results/
    - python scripts/parse_polyspace.py --input polyspace_results/ --output polyspace_report.xml
  artifacts:
    reports:
      junit: polyspace_report.xml
  tags:
    - safety-critical
  # Critical: Job fails if Polyspace detects mandatory MISRA violations
  allow_failure: false

test:
  stage: test
  image: gcc:11.4
  script:
    - make test
    - gcov src/*.c
    - lcov --capture --directory . --output-file coverage.info
    - lcov --summary coverage.info
  coverage: '/lines.*: \d+\.\d+%/'
  artifacts:
    reports:
      junit: test_results.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml
  tags:
    - safety-critical
  # Critical: Job fails if test coverage < 100% (ASIL-B requirement)
  coverage: '/lines.*: (\d+\.\d+)%/'
  after_script:
    - if [ $(lcov --summary coverage.info | grep lines | awk '{print $2}' | cut -d'%' -f1 | cut -d'.' -f1) -lt 100 ]; then exit 1; fi

deploy_staging:
  stage: deploy_staging
  image: bitnami/argocd:2.9
  script:
    - argocd app sync infotainment-staging --grpc-web
    - argocd app wait infotainment-staging --health
  environment:
    name: staging
  only:
    - main
  tags:
    - safety-critical
  # Production deployment requires manual approval (HITL gate)
  when: manual

Configuration Management Evidence:

• Git commit: a3f7e8c (.gitlab-ci.yml version 1.3.2)
• Git tag: v2.1.0-ASIL-B (approved configuration for ASIL-B software)
• Approval: Safety Manager (signed Git tag with GPG key)

Change Control:

• All changes to .gitlab-ci.yml require pull request review by Safety Manager (ISO 26262), QA Lead (IEC 62304).
• ArgoCD configuration changes require review by DevOps Lead and Safety Manager.

Evidence of Repeatability and Consistency

Validation Test Case TC-CI-001: Execute CI pipeline 10 times with identical source code. Verify build output (binary SHA-256 hash) is identical.

Result: PASS. All 10 builds produced identical binary (deterministic build):

Build 1: SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Build 2: SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
...
Build 10: SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Validation Test Case TC-CI-002: Inject a MISRA violation (mandatory rule 9.1: uninitialized variable). Verify pipeline fails at static_analysis stage.

Result: PASS. Pipeline failed as expected:

Job static_analysis failed:
  Polyspace Bug Finder detected 1 mandatory MISRA violation:
  - File: src/controller.c, Line 42, Rule 9.1 (uninitialized variable 'status')
  Exit code: 1

Validation Test Case TC-CI-003: Inject a test failure (unit test assertion). Verify pipeline fails at test stage.

Result: PASS. Pipeline failed as expected:

Job test failed:
  Test case test_eCall_initiation FAILED:
    Expected: eCall initiated within 3000ms
    Actual: eCall initiated in 3200ms
  Exit code: 1

Validation Test Case TC-CD-001: Deploy version v2.1.0 to staging. Verify deployed version matches Git tag v2.1.0.

Result: PASS. ArgoCD deployed exact commit from tag v2.1.0:

Application: infotainment-staging
Target Revision: v2.1.0 (commit a3f7e8c)
Deployed Revision: a3f7e8c (verified via kubectl)
Health Status: Healthy

Test Result Linkage to Requirements

Traceability Chain (ISO 26262 compliance):

Automated Traceability:

• GitLab CI parses test results (JUnit XML format) and links to requirements via test case IDs.
• Custom Python script (scripts/traceability.py) generates traceability matrix from Git artifacts.

Evidence for ISO 26262 Audit:

• Traceability matrix shows all requirements have corresponding test cases executed in CI pipeline.
• Pipeline logs prove test execution occurred and passed.

Disaster Recovery Procedures

Scenario 1: GitLab Runner Failure

Risk: CI pipeline cannot execute (runner offline, resource exhaustion).

Detection: GitLab monitoring alerts on runner health (Prometheus + Grafana).

Recovery:

1. GitLab Runner is deployed as Kubernetes pod with 3 replicas (high availability).
2. If 1 replica fails, GitLab scheduler routes jobs to healthy replicas.
3. If all replicas fail, Kubernetes restarts pods automatically.
4. If Kubernetes cluster fails, manual failover to backup GitLab instance (RTO: 4 hours).

Validation: Test case TC-DR-001: Terminate 1 GitLab Runner pod. Verify pipeline continues on remaining pods.

• Result: PASS. Pipeline executed on healthy pod without interruption.

Scenario 2: ArgoCD Deployment Failure

Risk: Incorrect software deployed to staging/production.

Detection: ArgoCD health checks fail; deployment rollback triggered.

Recovery:

1. ArgoCD automatically rolls back to previous healthy version if health check fails.
2. Manual rollback available via ArgoCD CLI: argocd app rollback infotainment-staging.
3. Deployment to production requires manual approval (HITL gate prevents automated incorrect deployment).

Validation: Test case TC-DR-002: Deploy version with failing health check. Verify ArgoCD rolls back.

• Result: PASS. ArgoCD detected health check failure (HTTP 500 from application) and rolled back to previous version within 30 seconds.

Scenario 3: Configuration Corruption

Risk: .gitlab-ci.yml or ArgoCD manifest corrupted (syntax error, malicious change).

Detection: Git hooks validate YAML syntax on commit. GitLab CI validates .gitlab-ci.yml on pipeline start.

Recovery:

1. Invalid .gitlab-ci.yml prevents pipeline execution (fail-safe).
2. Revert to last known good configuration via Git: git revert <bad_commit>.
3. ArgoCD "dry run" mode validates manifests before applying.

Validation: Test case TC-DR-003: Commit invalid .gitlab-ci.yml (syntax error). Verify pipeline fails to start.

• Result: PASS. GitLab rejected pipeline with error: "YAML syntax error at line 15".

ASPICE SYS.4-5 (System Integration and Testing) Support

ASPICE SYS.4 BP1: "Develop system integration strategy"

• Tool Support: GitLab CI executes system integration tests in test stage.
• Work Product: "System Integration Strategy" references GitLab CI pipeline configuration.

ASPICE SYS.5 BP1: "Develop system qualification test strategy"

• Tool Support: ArgoCD deploys system to staging environment for qualification testing.
• Work Product: "System Qualification Test Strategy" references ArgoCD deployment process.

ASPICE SYS.5 BP3: "Achieve system qualification test coverage"

• Tool Support: GitLab CI generates coverage reports (line coverage, branch coverage).
• Work Product: Coverage reports (coverage.xml) demonstrate test coverage.

ASPICE Assessor Evidence:

• GitLab CI configuration (.gitlab-ci.yml) demonstrates automated integration and testing.
• ArgoCD deployment logs demonstrate controlled deployment to test environments.
• Coverage reports demonstrate test coverage requirements (100% for ASIL-B).

Known Limitations

Limitation 1: GitLab Runner executes in Docker containers with limited resource isolation. Concurrent pipeline executions may interfere if resource limits are not configured.

• Mitigation: Resource limits configured per job (CPU: 2 cores, RAM: 4GB). GitLab enforces limits.
• Validation: Test case TC-LIMIT-001 verifies resource limits are enforced.

Limitation 2: ArgoCD synchronization is eventually consistent. Deployment may take up to 3 minutes to complete.

• Mitigation: ArgoCD app wait command used in pipeline to block until deployment is healthy.
• Validation: Test case TC-CD-002 verifies app wait blocks until health check passes.

Limitation 3: GitLab CI does not natively support hardware-in-the-loop (HIL) testing. HIL tests require separate infrastructure.

• Mitigation: HIL tests executed outside CI pipeline (manual or separate automation). CI pipeline generates artifacts (binaries) for HIL testing.
• Documentation: HIL test results linked to GitLab pipeline via external test management tool.

8.4 Case Study 4: AI Code Assistant (GitHub Copilot Enterprise with Compliance Checker)

Tool Context

Tool: GitHub Copilot Enterprise (GPT-4 based, version 1.156.0) + Custom Compliance Checker (MISRA rule validator) Purpose: AI-assisted code generation, code completion, refactoring suggestions Standards: ISO 26262 (ASIL-C) with AI-specific handling Usage Context: Automotive body control module (window control, mirror adjustment, ASIL-C safety functions: anti-pinch detection)

AI-Specific TCL Assessment: Novel "TCL-3-AI" Framework

Challenge: Traditional ISO 26262-8 TCL framework assumes deterministic tools. GitHub Copilot is non-deterministic (may produce different code for identical prompts).

Proposed Framework: Extend ISO 26262-8 with "TCL-3-AI" for AI code generation tools used in safety-critical contexts.

ISO 26262-8 Traditional Analysis (for comparison):

1. Tool Impact (TI):

   • TI2: AI-generated code directly enters source code. If incorrect, errors propagate to production software.

2. Tool Error Detection (TD):

   • TD3 if code is not reviewed: AI output trusted without verification → TCL-3 (maximum rigor).
   • TD1 if code is fully reviewed: Human reviews every line → TCL-1.

3. Problem: TCL-3 for AI tools is impractical (would require developing GitHub Copilot to ASIL-C rigor, impossible for closed-source LLM).

Proposed TCL-3-AI Framework:

TCL-3-AI Determination for GitHub Copilot:

• Tool generates safety-critical code (anti-pinch detection logic).
• TI: TI2 (code errors could violate safety requirements).
• TD: TD1 (HITL verification mandatory: all code reviewed by safety-qualified engineer).
• Traditional TCL: TI2 + TD1 → TCL-1.
• Override to TCL-3-AI: Despite TD1, AI tool's novel risk profile (non-determinism, opacity) requires augmented framework. Apply TCL-3-AI.

HITL Verification Requirements

ASPICE Principle: Humans own work products. AI assists, but does not replace human accountability.

HITL Protocol for GitHub Copilot:

1. Code Generation:

   • Engineer writes prompt (code comment describing desired functionality).
   • GitHub Copilot suggests code completion.
   • No automatic acceptance: Engineer reviews suggestion before accepting.

2. Mandatory Review Checklist (per ASIL-C requirements):

   • Code correctness: Does the code implement the intended functionality?
   • Safety implications: Could the code introduce safety-critical errors (e.g., timing issues, race conditions, buffer overflows)?
   • MISRA C:2012 compliance: Does the code violate any MISRA rules? (Custom compliance checker runs automatically)
   • Integration: Does the code integrate correctly with existing architecture?
   • Testing: Are new unit tests required to verify the generated code?

3. Compliance Checker Integration:

   • Custom plugin (copilot-misra-checker) analyzes GitHub Copilot suggestions in real-time.
   • If suggestion violates MISRA mandatory rule → automatic rejection (suggestion not displayed to engineer).
   • If suggestion violates MISRA required/advisory rule → warning displayed (engineer decides whether to accept with deviation).

4. Documentation:

   • All accepted AI-generated code annotated with comment:

     /* AI-Generated Code: GitHub Copilot 1.156.0
      * Prompt: "Implement anti-pinch detection using window motor current"
      * Reviewed by: J. Smith (Safety Engineer)
      * Review date: 2024-11-15
      * MISRA deviations: None
      */
     bool detect_anti_pinch(uint16_t motor_current) {
         return (motor_current > ANTI_PINCH_THRESHOLD_MA);
     }
     

5. Rejection Tracking:

   • If engineer rejects GitHub Copilot suggestion → reason logged (incorrect, unsafe, non-compliant).
   • Rejection data collected for AI tool performance analysis (feedback loop for model improvement).

HITL Evidence for ISO 26262 Audit:

• Code review records (annotated source code with reviewer signatures).
• Compliance checker logs (MISRA violations detected and resolved).
• Rejection logs (AI suggestions rejected due to safety concerns).

Training Data Provenance Documentation

Challenge: GitHub Copilot is trained on public GitHub repositories. Training data may include unsafe or non-compliant code.

Risk: AI may suggest unsafe patterns learned from low-quality training data.

Mitigation:

1. Model Version Control:

   • GitHub Copilot Enterprise version: 1.156.0 (model checkpoint: GPT-4-turbo, 2024-04-01).
   • Model version fixed for project duration (no automatic updates).
   • Version change requires re-validation per TCL-3-AI framework.

2. Training Data Analysis (Limited by Vendor Transparency):

   • GitHub provides limited training data provenance (proprietary).
   • Assumption: Training data includes diverse C codebases, but quality is unknown.
   • Consequence: Cannot rely on training data quality for safety assurance.

3. Validation on Domain-Specific Data:

   • Since training data provenance is unknown, validate tool on automotive-specific test set.
   • Test set: 1,000 automotive embedded C code generation tasks (e.g., "implement CAN message parser," "implement debounce logic for button input").
   • Validation criteria: Generated code must be (a) syntactically correct, (b) MISRA-compliant (no mandatory violations), (c) functionally correct per task description.

Validation Results:

• Syntactic correctness: 982/1000 tasks (98.2%) produced compilable code.
• MISRA compliance: 756/1000 tasks (75.6%) produced code with no MISRA violations. Remaining 244 tasks had required/advisory violations (acceptable if reviewed).
• Functional correctness: 890/1000 tasks (89.0%) produced code that passed functional unit tests.

Conclusion: GitHub Copilot performance is not sufficient for unsupervised use (11% functional failure rate). HITL review is mandatory.

Documentation:

• Validation report (Copilot_Validation_Report_v1.0.pdf) submitted to Safety Manager.
• Approval granted for HITL-supervised use only.

Output Validation Procedures per ASPICE SWE.4

ASPICE SWE.4: Software Unit Verification

AI Tool Integration:

1. Unit Construction (ASPICE SWE.3):

   • Engineer uses GitHub Copilot to generate unit implementation.
   • Generated code reviewed per HITL protocol.
   • Code integrated into codebase after approval.

2. Unit Verification (ASPICE SWE.4):

   • Unit testing: All AI-generated code covered by unit tests (100% coverage required for ASIL-C).
   • Static analysis: Polyspace Bug Finder analyzes AI-generated code (same as human-written code).
   • Manual review: Code review by peer engineer (not the original reviewer) per ASPICE SWE.4 BP4.

Validation Test Cases for AI-Generated Code:

Test Case TC-AI-001: Generate code for anti-pinch detection. Verify HITL review checklist completed.

• Result: PASS. Engineer reviewed code, documented review, accepted code.

Test Case TC-AI-002: Generate code that violates MISRA mandatory rule (uninitialized variable). Verify compliance checker rejects suggestion.

• Result: PASS. Compliance checker blocked suggestion with message: "MISRA Rule 9.1 violation detected (uninitialized variable). Suggestion rejected."

Test Case TC-AI-003: Generate code for CAN message parser. Verify unit tests cover all branches.

• Result: PASS. Unit tests cover 100% of branches in AI-generated code (verified by gcov).

Test Case TC-AI-004: Generate code for debounce logic. Verify Polyspace detects no defects.

• Result: PASS. Polyspace analysis: 0 defects detected.

ASPICE Work Product:

• SWE.3 WP1: "Software Unit Implementation" → Includes AI-generated code with HITL annotations.
• SWE.4 WP1: "Unit Verification Results" → Includes unit test results, static analysis results, code review records for AI-generated code.

Restrictions on Autonomous Generation

Restriction 1: GitHub Copilot shall not be used in "autonomous mode" (suggestions auto-accepted without review). All suggestions require explicit engineer acceptance.

Restriction 2: GitHub Copilot shall not be used for safety-critical algorithms without domain expert review. Examples:

• Anti-pinch detection logic → requires safety engineer review.
• CAN bus error handling → requires communication engineer review.
• Timing-critical code (ISRs) → requires real-time systems engineer review.

Restriction 3: GitHub Copilot shall not be used for cryptographic code (out of scope for automotive body control; if required, use certified cryptographic libraries).

Restriction 4: GitHub Copilot model version (1.156.0) is fixed for project duration. Updates require re-validation per TCL-3-AI framework (Section 8.4).

Restriction 5: GitHub Copilot suggestions that violate MISRA mandatory rules shall be automatically rejected by compliance checker. Engineer cannot override (fail-safe).

Enforcement:

• Restrictions enforced by development environment configuration (VSCode extension settings).
• Compliance checker integrated into CI pipeline (rejects code commits with MISRA violations).

Confidence Level Documentation

Challenge: AI tools provide probabilistic outputs. How to quantify confidence in generated code?

Approach: Confidence scoring based on validation results and suggestion characteristics.

Confidence Score Calculation:

Overall Confidence Score: Weighted sum of factors.

Example:

• AI-generated code for anti-pinch detection:
  • MISRA compliance: 2 required violations (deviation justified) → 0.5
  • Syntactic correctness: Compiles with 1 warning (unused variable) → 0.7
  • Functional tests: 10/10 tests pass → 1.0
  • Code complexity: Cyclomatic complexity = 8 → 1.0
• Confidence Score: 0.4×0.5 + 0.2×0.7 + 0.3×1.0 + 0.1×1.0 = 0.74

Usage Protocol:

• Confidence score ≥ 0.8: Standard HITL review (engineer review required, no additional oversight).
• Confidence score 0.6 - 0.8: Enhanced review (peer engineer reviews in addition to original engineer).
• Confidence score < 0.6: Reject suggestion (engineer writes code manually).

Documentation:

• Confidence scores logged for all accepted AI suggestions.
• Monthly report to Safety Manager: distribution of confidence scores, trends over time.

Status: Confidence scoring is experimental (not required by ISO 26262). Demonstrates proactive safety culture and provides data for future AI tool qualification frameworks.

Integration with Human Verification Workflow

Workflow Overview: The following diagram shows the end-to-end tool qualification workflow for AI coding assistants (e.g., GitHub Copilot), from initial risk assessment through validation testing to ongoing monitoring and re-qualification triggers.

Key HITL Gates:

1. Gate 1: MISRA compliance checker (automated, fail-safe).
2. Gate 2: Engineer HITL review checklist (mandatory human decision).
3. Gate 3: Confidence score threshold (automated, risk-based).
4. Gate 4: Unit testing (automated, but human analyzes failures).
5. Gate 5: Peer code review (human decision, ASPICE requirement).

ASPICE Compliance:

• HITL gates align with ASPICE process accountability (humans own work products).
• All gates documented in work products (code annotations, review records, test results).

ISO 26262 Compliance:

• HITL gates provide TD1 error detection (high confidence tool errors will be detected).
• Multiple verification layers (compliance checker, unit tests, static analysis, peer review) provide defense-in-depth.

Outcome: GitHub Copilot approved for use in ASIL-C project under TCL-3-AI framework with mandatory HITL protocol.

Section 9: Practical Templates

This section provides four production-ready templates for tool qualification documentation. These templates consolidate requirements from DO-330, ISO 26262-8, IEC 61508-7, and IEC 62304, enabling multi-standard compliance with minimal duplication.

9.1 Template 1: Tool Qualification Plan (TQP)

This template addresses DO-330 TQP, ISO 26262-8 Tool Qualification Plan, IEC 61508-7 tool assessment documentation, and IEC 62304 tool validation plan requirements.

# Tool Qualification Plan (TQP)
**Document ID**: TQP-[TOOL_NAME]-[VERSION]-[REV]
**Tool Name**: [Full tool name and version]
**Revision**: [Revision number]
**Date**: [YYYY-MM-DD]
**Author**: [Name, Role]
**Approvers**: [Safety Manager, Quality Manager, Project Manager]

---

## 1. Executive Summary

**Tool**: [Tool name, vendor, version]
**Purpose**: [Brief description of tool's role in development lifecycle]
**Standards**: [List all applicable standards: ISO 26262 (ASIL-X), DO-178C (DAL-X), IEC 61508 (SIL-X), IEC 62304 (Class X)]
**Qualification Level**: [TCL-X / TQL-X / SIL-X assessment / Class X validation]
**Qualification Approach**: [Tool development evaluation / Service history / Tool validation / Statistical validation (for AI tools)]

**Scope**: This Tool Qualification Plan defines the qualification strategy for [TOOL_NAME] used in [PROJECT_NAME] to [TOOL_PURPOSE]. The plan addresses requirements from [LIST_STANDARDS].

---

## 2. Tool Scope and Context

### 2.1 Tool Identification
- **Tool Name**: [Full name]
- **Vendor**: [Vendor name]
- **Version**: [Exact version number, build ID, release date]
- **Configuration**: [License type, modules enabled, integration with other tools]

### 2.2 Intended Use
- **Development Phase**: [Requirements / Design / Implementation / Verification / Validation / Configuration Management]
- **Work Products**: [List all work products the tool creates or modifies]
- **Safety-Critical Context**: [Yes/No - If yes, describe safety functions supported]

### 2.3 ASPICE Processes Supported
[List ASPICE process IDs and names]
- Example: SWE.1 Software Requirements Analysis
- Example: SWE.4 Software Unit Verification
- Example: SUP.8 Configuration Management

### 2.4 Operational Environment
- **Operating System**: [Windows 10, Linux Ubuntu 22.04, etc.]
- **Hardware**: [Minimum specs: CPU, RAM, disk]
- **Network**: [Standalone / Client-server / Cloud-based]
- **Integration**: [List integrated tools: version control, issue tracking, CI/CD]

---

## 3. Standards Applicability

### 3.1 DO-330 (Aviation)
**Applicable**: [Yes/No]
**DAL**: [DAL-A / DAL-B / DAL-C / DAL-D / DAL-E]
**DO-178C Objectives Satisfied**: [List objectives from DO-178C Tables A-3, A-4, A-5, A-6]
**TQL**: [TQL-1 / TQL-2 / TQL-3 / TQL-4 / TQL-5]
**Rationale**: [Why this TQL? Reference DO-330 Table 5-1]

### 3.2 ISO 26262-8 (Automotive)
**Applicable**: [Yes/No]
**ASIL**: [ASIL-A / ASIL-B / ASIL-C / ASIL-D / QM]
**TI (Tool Impact)**: [TI1 / TI2] - [Rationale]
**TD (Tool Error Detection)**: [TD1 / TD2 / TD3] - [Rationale]
**TCL**: [TCL-0 / TCL-1 / TCL-2 / TCL-3 / TCL-3-AI (if AI tool)]
**Rationale**: [Reference ISO 26262-8:2018 Clause 11.4.6 determination matrix]

### 3.3 IEC 61508-7 (Industrial)
**Applicable**: [Yes/No]
**SIL**: [SIL-1 / SIL-2 / SIL-3 / SIL-4]
**Tool Category**: [Offline support / Online support] - [Table A.4 / Table A.5]
**Assessment Requirement**: [Rigor level based on SIL and category]
**Rationale**: [IEC 61508-7:2010 Annex A requirements]

### 3.4 IEC 62304 (Medical)
**Applicable**: [Yes/No]
**Safety Class**: [Class A / Class B / Class C]
**Output Verification**: [Yes (tool validation reduced) / No (tool validation required)]
**Validation Requirement**: [IEC 62304:2006 Clause 5.1.4 - describe rigor level]
**Rationale**: [Risk-based determination]

### 3.5 ASPICE 4.0 (Process Assessment)
**Applicable**: [Yes - always applicable if ASPICE processes are used]
**SUP.8 Requirement**: Configuration Management - tool validation work product required
**Capability Level**: [CL1 / CL2 / CL3 / CL4 / CL5]
**Rationale**: [Tool validation supports SUP.8 base practices]

---

## 4. TCL/TQL Determination

### 4.1 Determination Logic
[Detailed explanation of how TCL/TQL was determined]

**For ISO 26262-8**:
- Tool Impact (TI): [TI1 / TI2]
  - Justification: [Can the tool introduce errors that violate safety requirements?]
- Tool Error Detection (TD): [TD1 / TD2 / TD3]
  - Justification: [Will tool errors be detected by subsequent activities?]
- TCL Matrix: TI[X] + TD[Y] → TCL-[Z]

**For DO-330**:
- DAL of software: [DAL-X]
- Tool output usage: [Replaces verification / Automates process / Generates code]
- DO-178C objectives satisfied: [List objectives]
- TQL determination: [TQL-X per DO-330 Table 5-1]

**For AI Tools (if applicable)**:
- Non-determinism: [Yes/No - quantify if yes]
- Training data provenance: [Known / Unknown / Proprietary]
- Statistical validation: [Yes/No - describe test set size if yes]
- HITL requirement: [Mandatory / Optional / Not required]
- Framework: [TCL-3-AI / Other novel framework]

### 4.2 Rigor Reduction (if applicable)
[Document any reductions in qualification rigor]

**Service History (ISO 26262-8 Clause 11.4.7)**:
- [Yes/No] - If yes:
  - Number of projects: [≥10 required]
  - ASIL levels: [Must match or exceed target ASIL]
  - Operational context: [Must match: same inputs, environment, configuration]
  - Tool version: [Must be identical or differ only in non-safety features]
  - TCL reduction: [TCL-X → TCL-Y]

**Error Detection (DO-330 Section 12.2.3)**:
- [Yes/No] - If yes:
  - Verification activities: [Describe what activities verify tool output]
  - Detection confidence: [High / Medium / Low]
  - TQL reduction: [TQL-X → TQL-Y]

---

## 5. Evidence Requirements (Mapped to Standards)

### 5.1 Evidence Matrix

| Evidence Item | DO-330 | ISO 26262-8 | IEC 61508-7 | IEC 62304 | Status |
|---------------|--------|-------------|-------------|-----------|--------|
| Tool Qualification Plan | Section 5.2 | Clause 11.4.10 | Annex A | Clause 5.1.4 | This document |
| Tool Description | Section 5.3 | Clause 11.4.1 | Annex A | Clause 5.1.4 | [Document ID] |
| Tool Operational Requirements (TOR) | Section 5.4 | Clause 11.4.9 (TVR) | Annex A | Clause 5.1.4 | [Document ID] |
| Tool Verification Plan (TVP) | Section 5.5 | Clause 11.4.9 | Annex A | Clause 5.1.4 | [Document ID] |
| Tool Verification Results | Section 5.6 | Clause 11.4.9 | Annex A | Clause 5.1.4 | [Document ID] |
| Known Limitations | Section 5.7 | Clause 11.4.1 | Annex A | Clause 5.1.4 | [Document ID] |
| Configuration Management | Section 6 | Clause 11.4.1 | Annex A | Clause 5.1.4 | [Document ID] |
| Service History (if applicable) | N/A | Clause 11.4.7 | Annex A | N/A | [Document ID] |
| Training Records | N/A | N/A | N/A | Clause 5.1.4 | [Document ID] |
| Tool Qualification Summary | Section 8 | Clause 11.4.10 | Annex A | Clause 5.1.4 | [Document ID] |

### 5.2 Evidence Delivery
- **Format**: [PDF / Word / Markdown / Tool-specific (e.g., Doors module)]
- **Storage**: [Document management system, version control, configuration item]
- **Access Control**: [Who can read/write? Safety Manager, QA, auditors]
- **Retention**: [Duration: project lifetime + X years per regulatory requirement]

---

## 6. Test Approach

### 6.1 Test Strategy
[Describe overall approach to tool verification/validation]

**Objectives**:
- Demonstrate tool meets all Tool Operational Requirements (TOR)
- Verify tool operates correctly in intended operational environment
- Validate tool error detection mechanisms (if applicable)
- Document known limitations and contraindications

**Test Types**:
- **Functional Testing**: Verify tool performs intended functions correctly
- **Negative Testing**: Verify tool handles errors gracefully (invalid inputs, resource exhaustion)
- **Performance Testing**: Verify tool meets performance requirements (speed, scalability)
- **Regression Testing**: Verify tool behavior unchanged after configuration changes
- **Statistical Validation** (AI tools): Verify tool performance on large representative test set

### 6.2 Test Coverage
[Define coverage criteria]

**For Traditional Tools**:
- All TOR requirements covered by ≥1 test case
- All tool features used in project covered by ≥1 test case
- Critical functions covered by ≥3 test cases (boundary conditions, error cases)

**For AI Tools**:
- Test set size: [≥1,000 for TCL-1-AI, ≥10,000 for TCL-3-AI]
- Test set representativeness: [Must match project domain: automotive, medical, industrial]
- Acceptance criteria: [≥95% accuracy, ≥90% confidence calibration, documented failure modes]

### 6.3 Test Execution
- **Test Environment**: [Match operational environment or document differences]
- **Test Data**: [Real project data / Synthetic data / Vendor-provided data]
- **Test Tools**: [Manual execution / Automated test framework]
- **Test Execution Schedule**: [Timeline: weeks, months]

### 6.4 Test Results Analysis
- **Pass Criteria**: [Define what constitutes a passed test]
- **Failure Analysis**: [How are failures investigated? Root cause, impact assessment]
- **Regression**: [If failures found, are all tests re-executed?]
- **Known Limitations**: [Acceptable failures documented as limitations]

---

## 7. Success Criteria

### 7.1 Qualification Success Criteria
The tool is qualified if all of the following criteria are met:

1. **Test Execution**: All test cases executed per Tool Verification Plan
2. **Test Pass Rate**: [≥98% for traditional tools, ≥95% for AI tools] of tests pass
3. **Critical Failures**: Zero critical failures (failures that violate safety requirements)
4. **Known Limitations**: All known limitations documented and accepted by [Safety Manager / Quality Manager]
5. **Configuration Management**: Tool version and configuration baselined and controlled
6. **Evidence Package**: All required evidence items (Section 5.1) delivered and reviewed
7. **Approval**: Tool Qualification Summary approved by [List approval authorities]

### 7.2 Acceptance Criteria by Standard

**DO-330**:
- TQP, TOR, TVP, test results approved by DER (Designated Engineering Representative)
- Tool qualification data submitted as part of Software Accomplishment Summary

**ISO 26262-8**:
- Tool evaluation report approved by Safety Manager
- Tool qualification evidence submitted with Safety Case

**IEC 61508-7**:
- Tool assessment documentation approved by functional safety manager
- Tool qualification evidence submitted with safety manual

**IEC 62304**:
- Tool validation report approved by Quality Manager
- Tool qualification evidence submitted with Design History File (FDA 21 CFR 820.30(j))

**ASPICE**:
- Tool validation work product (SUP.8) reviewed by ASPICE assessor
- Tool qualification supports capability level target (CL3 typical)

---

## 8. Organizational Responsibilities

| Role | Responsibility | Name | Signature | Date |
|------|----------------|------|-----------|------|
| **Tool Owner** | Overall responsibility for tool qualification; tool selection; configuration management | [Name] | | |
| **Validation Engineer** | Execute Tool Verification Plan; analyze test results; document known limitations | [Name] | | |
| **Safety Manager** (ISO 26262) | Review and approve TCL determination; review known limitations; approve tool for safety-critical use | [Name] | | |
| **DER** (DO-330) | Review and approve TQL determination; review TQP, TOR, TVP; approve tool for aviation use | [Name] | | |
| **Quality Manager** (IEC 62304) | Review and approve tool validation; ensure compliance with design control (21 CFR 820.70) | [Name] | | |
| **Project Manager** | Approve resources and schedule; approve tool qualification plan | [Name] | | |
| **ASPICE Assessor** (if applicable) | Review tool validation work product (SUP.8); assess process compliance | [Name] | | |

---

## 9. Schedule and Resources

### 9.1 Schedule
| Phase | Duration | Start Date | End Date | Deliverable |
|-------|----------|------------|----------|-------------|
| Tool Selection | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | Tool evaluation criteria, vendor selection |
| TQP Development | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | This document |
| TOR Development | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | Tool Operational Requirements |
| TVP Development | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | Tool Verification Plan |
| Test Execution | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | Test results |
| Results Analysis | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | Known limitations, test summary |
| Evidence Package | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | All evidence items (Section 5.1) |
| Approval | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | Approved Tool Qualification Summary |

### 9.2 Resources
- **Personnel**: [X FTEs: validation engineer, safety engineer, tool expert]
- **Equipment**: [Tool licenses, test environment, CI/CD infrastructure]
- **Budget**: [Cost estimate: tool licenses, personnel, external audits]

---

## 10. Change Management

### 10.1 Tool Version Updates
If the tool version changes (vendor releases new version):

1. **Impact Analysis**: Assess whether changes affect safety-related functionality
2. **Re-Validation Decision**:
   - **Minor updates** (bug fixes, UI changes): No re-validation required if changes do not affect TOR
   - **Major updates** (new features, algorithm changes): Partial re-validation (test affected TOR)
   - **Safety-critical changes**: Full re-qualification (execute entire TVP)
3. **Documentation**: Update Tool Qualification Plan, TOR, TVP as needed
4. **Approval**: Safety Manager approves re-validation plan

### 10.2 Configuration Changes
If the tool configuration changes (e.g., settings, plugins, integrations):

1. **Configuration Baseline**: Document new configuration
2. **Impact Analysis**: Assess whether changes affect safety-related functionality
3. **Re-Validation**: Execute subset of TVP covering affected functionality
4. **Approval**: Tool Owner approves configuration change

### 10.3 Process Changes
If project processes change (e.g., new ASPICE processes, new safety requirements):

1. **TOR Review**: Assess whether tool still meets updated requirements
2. **Re-Qualification Decision**: Safety Manager determines if re-qualification needed
3. **Documentation**: Update TQP, TOR, TVP as needed

---

## 11. Sign-Off Section

### 11.1 Plan Approval
This Tool Qualification Plan is approved for execution.

| Role | Name | Signature | Date |
|------|------|-----------|------|
| **Tool Owner** | | | |
| **Safety Manager** (ISO 26262) | | | |
| **DER** (DO-330, if applicable) | | | |
| **Quality Manager** (IEC 62304, if applicable) | | | |
| **Project Manager** | | | |

### 11.2 Qualification Approval (Completed After Evidence Package)
This tool is qualified for use per this plan.

| Role | Name | Signature | Date |
|------|------|-----------|------|
| **Safety Manager** | | | |
| **DER** (if applicable) | | | |
| **Quality Manager** (if applicable) | | | |

---

**Document Control**
Revision History:
| Revision | Date | Author | Changes |
|----------|------|--------|---------|
| 1.0 | YYYY-MM-DD | [Author] | Initial release |

9.2 Template 2: Tool Operational Requirements (TOR)

This template defines functional requirements for the tool (DO-330 TOR, ISO 26262-8 TVR).

# Tool Operational Requirements (TOR)
**Document ID**: TOR-[TOOL_NAME]-[VERSION]-[REV]
**Tool Name**: [Full tool name and version]
**Revision**: [Revision number]
**Date**: [YYYY-MM-DD]
**References**: Tool Qualification Plan [TQP-ID]

---

## 1. Introduction

### 1.1 Purpose
This document defines the operational requirements for [TOOL_NAME]. These requirements specify what the tool **must do correctly** to support [PROJECT_NAME] under [STANDARDS].

### 1.2 Scope
- **What the tool must do**: Functional requirements
- **What the tool must NOT do**: Constraints and prohibited behaviors
- **Performance requirements**: Speed, accuracy, resource usage
- **Interface requirements**: Integration with other tools, data formats
- **Error handling requirements**: How the tool must respond to invalid inputs or failure conditions

### 1.3 Traceability
Each TOR requirement is traceable to:
- **Standard requirements**: DO-178C objectives, ISO 26262-6 verification methods, etc.
- **Project requirements**: System requirements, software requirements
- **Test cases**: Tool Verification Plan test cases

---

## 2. Functional Requirements

### 2.1 Core Functionality
[Define what the tool must do in normal operation]

**TOR-FUNC-001**: The tool shall [primary function].
- **Rationale**: [Why is this required?]
- **Trace to**: [DO-178C Table A-X Objective Y / ISO 26262-6 Table Z / SWE-REQ-XXXX]

**TOR-FUNC-002**: The tool shall [secondary function].
- **Rationale**: [Why is this required?]
- **Trace to**: [Standard requirement / Project requirement]

[Continue for all functional requirements: typically 10-50 requirements depending on tool complexity]

### 2.2 Accuracy and Correctness Requirements

**TOR-ACC-001**: The tool shall produce [correct output] for [given input] with ≥[X]% accuracy.
- **Rationale**: [Accuracy needed for safety assurance]
- **Trace to**: [Standard requirement]
- **Acceptance Criteria**: [How is accuracy measured? Test set size, metrics]

**Example (Static Analyzer)**:
**TOR-ACC-001**: The tool shall detect all MISRA C:2012 mandatory rule violations in C source code with 100% sensitivity (no false negatives).
- **Rationale**: Mandatory rules address critical safety issues. False negatives (missed violations) could lead to safety-critical defects.
- **Trace to**: ISO 26262-6:2018 Table 9 (static code analysis), DO-178C Table A-4 Objective 7 (coding standards)
- **Acceptance Criteria**: Test on 500+ MISRA violation test cases; tool must detect all mandatory violations.

**TOR-ACC-002**: The tool shall produce ≤[X]% false positive rate for [analysis type].
- **Rationale**: [High false positive rate reduces trust and productivity]
- **Acceptance Criteria**: [Measure false positive rate on representative codebase]

---

## 3. Constraint Requirements (What Tool Must NOT Do)

**TOR-CONST-001**: The tool shall NOT [prohibited behavior].
- **Rationale**: [Safety or regulatory reason]
- **Enforcement**: [How is this constraint verified?]

**Example (AI Code Generator)**:
**TOR-CONST-001**: The tool shall NOT autonomously commit generated code to version control without human approval.
- **Rationale**: ASPICE requires human accountability for work products. Autonomous commits violate HITL principle.
- **Enforcement**: Development environment configured to require manual commit. Test case verifies auto-commit is disabled.

**TOR-CONST-002**: The tool shall NOT modify [safety-critical files] without [approval workflow].
- **Rationale**: [Change control for safety-critical artifacts]
- **Enforcement**: [Access control, configuration management]

---

## 4. Performance Requirements

**TOR-PERF-001**: The tool shall complete [operation] within [X] seconds/minutes for [workload size].
- **Rationale**: [Performance needed for integration into workflow]
- **Trace to**: [Project requirement / User requirement]
- **Acceptance Criteria**: [Benchmark: test on representative workload]

**Example (Requirements Tool)**:
**TOR-PERF-001**: The tool shall generate traceability matrix for 10,000 requirements within 60 seconds.
- **Rationale**: Traceability reports generated frequently during design reviews. Delays disrupt workflow.
- **Acceptance Criteria**: Benchmark on project database (12,000 requirements). Time to generate report: 45 seconds (PASS).

**TOR-PERF-002**: The tool shall support [concurrent users / data volume / transaction rate].
- **Rationale**: [Scalability for project team size / data size]

---

## 5. Interface Requirements

**TOR-INTF-001**: The tool shall import/export data in [format] compatible with [other tool].
- **Rationale**: [Integration with toolchain]
- **Trace to**: [Project toolchain architecture]
- **Acceptance Criteria**: [Test data exchange with other tool; verify no data loss]

**Example (CI/CD Pipeline)**:
**TOR-INTF-001**: The tool shall export test results in JUnit XML format compatible with GitLab CI/CD.
- **Rationale**: Test results must be visible in GitLab merge request UI for developer review.
- **Acceptance Criteria**: Execute test suite, export results, verify GitLab parses XML and displays pass/fail status.

**TOR-INTF-002**: The tool shall integrate with [version control system] via [API/plugin].
- **Rationale**: [Traceability to code changes]

---

## 6. Error Handling Requirements

**TOR-ERR-001**: The tool shall detect [error condition] and [response].
- **Rationale**: [Fail-safe behavior]
- **Trace to**: [Safety requirement / Regulatory requirement]
- **Acceptance Criteria**: [Inject error condition; verify tool response]

**Example (Compiler)**:
**TOR-ERR-001**: The tool shall detect invalid C syntax and terminate compilation with non-zero exit code and error message identifying file and line number.
- **Rationale**: Invalid syntax must not produce executable (fail-safe). Error message aids debugging.
- **Acceptance Criteria**: Compile file with syntax error; verify exit code ≠ 0 and error message present.

**TOR-ERR-002**: The tool shall [gracefully handle resource exhaustion] (out of memory, disk full).
- **Rationale**: [Prevent data corruption, provide diagnostic information]

---

## 7. Configuration Management Requirements

**TOR-CM-001**: The tool shall [version control] for [work products].
- **Rationale**: [Traceability, auditability per ASPICE SUP.8]
- **Trace to**: ASPICE SUP.8 BP1 (Configuration Identification)
- **Acceptance Criteria**: [Create work product, modify, verify version history retained]

**TOR-CM-002**: The tool shall [baseline/snapshot] functionality for [work products].
- **Rationale**: [Immutable snapshots for regulatory submission, design reviews]
- **Trace to**: ISO 26262-8:2018 Clause 8 (Configuration Management)

---

## 8. Documentation Requirements

**TOR-DOC-001**: The tool shall generate [report/documentation] containing [required information].
- **Rationale**: [Evidence for audits, regulatory submission]
- **Trace to**: [Standard requirement: DO-178C accomplishment summary, ISO 26262 safety case]
- **Acceptance Criteria**: [Generate report; verify all required information present]

**Example (Static Analyzer)**:
**TOR-DOC-001**: The tool shall generate analysis report containing: (a) list of violations by rule ID, (b) source file and line number, (c) violation severity, (d) timestamp of analysis.
- **Rationale**: Verification evidence for DO-178C Table A-4 objectives. Report must be traceable to source code version.
- **Acceptance Criteria**: Run analysis; verify report includes all required fields.

---

## 9. Traceability Matrix

| TOR ID | Description | Trace to Standard | Trace to Project Req | Test Case ID |
|--------|-------------|-------------------|----------------------|--------------|
| TOR-FUNC-001 | [Function] | DO-178C Table A-4 Obj 6 | SWE-REQ-1234 | TC-FUNC-001 |
| TOR-ACC-001 | [Accuracy] | ISO 26262-6 Table 9 | SWE-REQ-5678 | TC-ACC-001, TC-ACC-002 |
| TOR-CONST-001 | [Constraint] | ASPICE SUP.8 BP1 | N/A | TC-CONST-001 |
| [Continue for all TOR] | | | | |

---

## 10. Known Limitations and Exclusions

**Limitation 1**: The tool does not support [feature/scenario].
- **Rationale**: [Out of scope for project / Technical limitation]
- **Workaround**: [Manual process / Use alternative tool]

**Limitation 2**: The tool produces false positives for [specific pattern].
- **Rationale**: [Tool algorithm limitation]
- **Workaround**: [Manual review / Suppression with justification]

**Exclusion 1**: The following tool features are NOT qualified: [list features].
- **Rationale**: [Features not used in project]
- **Restriction**: Project team shall NOT use unqualified features.

---

**Document Control**
Revision History:
| Revision | Date | Author | Changes |
|----------|------|--------|---------|
| 1.0 | YYYY-MM-DD | [Author] | Initial release |

9.3 Template 3: Tool Verification Plan (TVP)

This template defines the test strategy for demonstrating the tool meets TOR (DO-330 TVP, ISO 26262-8 validation plan).

# Tool Verification Plan (TVP)
**Document ID**: TVP-[TOOL_NAME]-[VERSION]-[REV]
**Tool Name**: [Full tool name and version]
**Revision**: [Revision number]
**Date**: [YYYY-MM-DD]
**References**: Tool Qualification Plan [TQP-ID], Tool Operational Requirements [TOR-ID]

---

## 1. Introduction

### 1.1 Purpose
This Tool Verification Plan defines the test approach, test cases, and acceptance criteria for demonstrating that [TOOL_NAME] satisfies all Tool Operational Requirements (TOR).

### 1.2 Scope
- **Test Strategy**: Overall approach to verification
- **Test Cases**: Detailed test procedures covering all TOR requirements
- **Test Environment**: Hardware, software, configuration
- **Test Execution**: Schedule, responsibilities
- **Test Results Analysis**: Pass/fail criteria, known limitations

### 1.3 References
- Tool Qualification Plan: [TQP-ID]
- Tool Operational Requirements: [TOR-ID]
- [Standard references: DO-330, ISO 26262-8, IEC 61508-7, IEC 62304]

---

## 2. Verification Strategy

### 2.1 Objectives
1. Demonstrate tool correctness: Tool performs functions per TOR
2. Demonstrate tool reliability: Tool handles errors gracefully
3. Demonstrate tool performance: Tool meets speed/scalability requirements
4. Document known limitations: Tool failures documented and accepted

### 2.2 Verification Methods

| Method | Description | Applicability |
|--------|-------------|---------------|
| **Functional Testing** | Execute tool with valid inputs; verify correct outputs | All TOR-FUNC requirements |
| **Negative Testing** | Execute tool with invalid inputs; verify error handling | All TOR-ERR requirements |
| **Performance Testing** | Execute tool with representative workload; measure speed | All TOR-PERF requirements |
| **Integration Testing** | Execute tool with other tools; verify data exchange | All TOR-INTF requirements |
| **Statistical Validation** | Execute tool on large test set; measure accuracy | AI tools, TOR-ACC requirements |
| **Manual Inspection** | Review tool outputs manually; verify correctness | TOR-DOC requirements |

### 2.3 Test Coverage Criteria

**For Traditional Tools**:
- 100% of TOR requirements covered by ≥1 test case
- Critical TOR requirements (safety-related, accuracy) covered by ≥3 test cases
- All tool features used in project exercised by ≥1 test case

**For AI Tools** (TCL-3-AI):
- Test set size: [≥10,000 tasks for code generation, ≥1,000 tasks for analysis]
- Test set composition: [Representative of project domain: automotive embedded C, medical device software, etc.]
- Metrics: [Accuracy, precision, recall, false positive rate, confidence calibration]

---

## 3. Test Environment

### 3.1 Hardware
- **Processor**: [CPU model, cores, speed]
- **Memory**: [RAM size]
- **Storage**: [Disk type, capacity]
- **Network**: [Bandwidth, latency if cloud-based tool]

### 3.2 Software
- **Operating System**: [OS name, version]
- **Tool Under Test**: [Exact version, build ID, license configuration]
- **Supporting Tools**: [Version control, test framework, CI/CD]
- **Test Data**: [Source code repositories, requirements databases, test inputs]

### 3.3 Configuration
- **Tool Configuration**: [Settings, plugins, integrations - must match operational configuration]
- **Configuration Baseline**: [Document ID for configuration management]

---

## 4. Test Case Specification

### 4.1 Test Case Template

Each test case follows this structure:

Test Case ID: TC-[CATEGORY]-[NUMBER] TOR Requirement: [TOR-ID] Objective: [What does this test demonstrate?] Preconditions: [Tool state, input data, environment setup] Test Procedure:

1. [Step 1]
2. [Step 2] ... Expected Result: [What should happen?] Pass Criteria: [Objective criteria for pass] Actual Result: [Filled during test execution] Status: [PASS / FAIL / BLOCKED] Notes: [Any deviations, issues, observations]

### 4.2 Test Case Categories

| Category | TOR Coverage | Test Cases Count |
|----------|--------------|------------------|
| **FUNC** | Functional requirements (TOR-FUNC-*) | [X test cases] |
| **ACC** | Accuracy requirements (TOR-ACC-*) | [X test cases] |
| **CONST** | Constraint requirements (TOR-CONST-*) | [X test cases] |
| **PERF** | Performance requirements (TOR-PERF-*) | [X test cases] |
| **INTF** | Interface requirements (TOR-INTF-*) | [X test cases] |
| **ERR** | Error handling requirements (TOR-ERR-*) | [X test cases] |
| **CM** | Configuration management (TOR-CM-*) | [X test cases] |
| **DOC** | Documentation requirements (TOR-DOC-*) | [X test cases] |
| **TOTAL** | All TOR requirements | [X test cases] |

### 4.3 Example Test Cases

**Example 1: Static Analyzer Accuracy**

Test Case ID: TC-ACC-001 TOR Requirement: TOR-ACC-001 (Detect all MISRA C:2012 mandatory violations) Objective: Demonstrate tool detects uninitialized variable (MISRA Rule 9.1) Preconditions:

• Polyspace Bug Finder R2024a installed and licensed
• Test file: test_misra_9_1.c (contains uninitialized variable) Test Procedure:

1. Create C source file with uninitialized variable:

   void test_function(void) {
       int status; // Uninitialized
       if (status == 0) { // MISRA 9.1 violation
           do_something();
       }
   }
   

2. Run Polyspace analysis: polyspace-bug-finder -sources test_misra_9_1.c -misra3 mandatory
3. Review analysis report Expected Result: Polyspace detects MISRA Rule 9.1 violation at line 3 Pass Criteria: Report contains violation: "Rule 9.1: uninitialized variable 'status'" Actual Result: [PASS - Violation detected as expected] Status: PASS Notes: None

**Example 2: AI Code Generator HITL Gate**

Test Case ID: TC-CONST-001 TOR Requirement: TOR-CONST-001 (No autonomous commits) Objective: Demonstrate GitHub Copilot cannot commit code without human approval Preconditions:

• GitHub Copilot Enterprise 1.156.0 installed in VSCode
• Git repository initialized Test Procedure:

1. Write code comment: "// Implement CAN message parser"
2. GitHub Copilot generates code suggestion
3. Accept suggestion (code inserted into editor)
4. Verify code is NOT automatically committed to Git
5. Verify Git status shows uncommitted changes Expected Result: Code remains uncommitted until engineer manually runs git commit Pass Criteria: git status shows modified file in working directory (not committed) Actual Result: [PASS - Code not committed. Manual commit required.] Status: PASS Notes: Verified HITL gate enforced. Engineer must review and manually commit.

---

## 5. Test Execution

### 5.1 Test Execution Schedule
| Phase | Test Cases | Duration | Start Date | End Date | Responsible |
|-------|------------|----------|------------|----------|-------------|
| Functional Testing | TC-FUNC-001 to TC-FUNC-050 | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | [Validation Engineer] |
| Accuracy Testing | TC-ACC-001 to TC-ACC-020 | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | [QA Engineer] |
| Performance Testing | TC-PERF-001 to TC-PERF-010 | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | [Performance Engineer] |
| Integration Testing | TC-INTF-001 to TC-INTF-015 | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | [DevOps Engineer] |
| Negative Testing | TC-ERR-001 to TC-ERR-010 | [X weeks] | [YYYY-MM-DD] | [YYYY-MM-DD] | [Validation Engineer] |

### 5.2 Test Execution Responsibilities
- **Test Lead**: [Name] - Overall test execution management
- **Test Engineers**: [Names] - Execute test cases, document results
- **Tool Expert**: [Name] - Troubleshoot tool issues, provide configuration support
- **Reviewer**: [Name] - Review test results, approve known limitations

### 5.3 Test Execution Process
1. **Setup**: Configure test environment per Section 3
2. **Execution**: Execute test cases per Section 4
3. **Documentation**: Record actual results, status (PASS/FAIL/BLOCKED)
4. **Failure Analysis**: For each failed test:
   - Root cause analysis
   - Severity assessment (Critical / Major / Minor)
   - Disposition (Fix tool / Document limitation / Retest / Waive)
5. **Retest**: Re-execute failed tests after fixes
6. **Summary**: Generate Tool Verification Results document

---

## 6. Test Results Analysis

### 6.1 Pass Criteria (Overall)
The tool verification is successful if:
1. [≥98% for traditional tools, ≥95% for AI tools] of test cases pass
2. Zero critical failures (failures that violate safety requirements)
3. All known limitations documented and accepted by Safety Manager
4. Traceability: All TOR requirements covered by passed test cases

### 6.2 Failure Severity Classification

| Severity | Definition | Example | Disposition |
|----------|------------|---------|-------------|
| **Critical** | Violates safety requirement; blocks tool use | Static analyzer misses mandatory MISRA violation | Must fix or reject tool |
| **Major** | Impacts functionality; workaround exists | Traceability report missing timestamps | Fix or document limitation |
| **Minor** | Cosmetic issue; no impact on safety | UI formatting error | Document limitation or waive |

### 6.3 Known Limitations
[Documented in Section 10 of Tool Verification Results]

Each limitation includes:
- Description of failure/limitation
- Root cause (tool algorithm, configuration, environment)
- Impact assessment (safety impact, productivity impact)
- Workaround or mitigation (manual process, alternative tool)
- Acceptance decision (Safety Manager approval required)

---

## 7. Regression Testing

### 7.1 Regression Triggers
Regression testing (re-execute all or subset of test cases) is required if:
- Tool version changes (vendor update)
- Tool configuration changes (settings, plugins)
- Operational environment changes (OS upgrade, hardware change)
- TOR changes (new requirements added)

### 7.2 Regression Test Scope
- **Full regression**: All test cases re-executed (major tool version change)
- **Partial regression**: Subset of test cases (minor tool update, configuration change)
- **Risk-based selection**: Test cases related to changed functionality

---

## 8. Configuration Management

### 8.1 Test Artifacts Version Control
All test artifacts are version-controlled:
- Test cases (this document)
- Test data (input files, databases)
- Test scripts (automated test execution)
- Test results (logs, reports)

### 8.2 Baseline
Test artifacts are baselined at:
- Tool Verification Plan approval (this document)
- Start of test execution (test cases finalized)
- Completion of test execution (test results final)

---

## 9. Traceability Matrix: TOR to Test Cases

| TOR ID | TOR Description | Test Case IDs | Coverage |
|--------|-----------------|---------------|----------|
| TOR-FUNC-001 | [Function] | TC-FUNC-001, TC-FUNC-002, TC-FUNC-003 | 3 test cases |
| TOR-ACC-001 | [Accuracy] | TC-ACC-001, TC-ACC-002, ..., TC-ACC-050 | 50 test cases |
| TOR-CONST-001 | [Constraint] | TC-CONST-001 | 1 test case |
| [Continue for all TOR] | | | |
| **TOTAL** | [X TOR requirements] | [Y test cases] | [Z coverage %] |

**Coverage Analysis**:
- TOR requirements with 0 test cases: [None - 100% coverage required]
- TOR requirements with <3 test cases (critical requirements only): [List and justify]

---

**Document Control**
Revision History:
| Revision | Date | Author | Changes |
|----------|------|--------|---------|
| 1.0 | YYYY-MM-DD | [Author] | Initial release |

9.4 Template 4: Evidence Package Checklist (65 Items)

This checklist ensures all required evidence is collected for multi-standard compliance.

# Tool Qualification Evidence Package Checklist
**Tool Name**: [Tool name and version]
**Project**: [Project name]
**Standards**: [ISO 26262 ASIL-X / DO-330 TQL-X / IEC 61508 SIL-X / IEC 62304 Class X]
**Date**: [YYYY-MM-DD]
**Reviewed by**: [Safety Manager / Quality Manager / DER]

---

## Instructions
- Mark each item: [PASS] Complete | [FAIL] Not Applicable | [WARN] In Progress
- Provide document ID or reference for each completed item
- For "Not Applicable" items, provide justification

---

## A. Tool Description (5 Items)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| A.1 | Tool name, vendor, version | | | |
| A.2 | Tool purpose and intended use | | | |
| A.3 | Operational environment (HW, SW, network) | | | |
| A.4 | Integration with other tools | | | |
| A.5 | License and configuration details | | | |

---

## B. Functional Verification (15 Items)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| B.1 | Tool Operational Requirements (TOR/TVR) | | | |
| B.2 | Tool Verification Plan (TVP) | | | |
| B.3 | Test cases covering all TOR (≥50 test cases typical) | | | |
| B.4 | Test procedures (step-by-step) | | | |
| B.5 | Test environment configuration | | | |
| B.6 | Test data (inputs, expected outputs) | | | |
| B.7 | Test execution logs | | | |
| B.8 | Test results summary | | | |
| B.9 | Traceability matrix: TOR to test cases | | | |
| B.10 | Test coverage analysis (100% TOR coverage) | | | |
| B.11 | Functional test pass rate (≥98% for traditional tools) | | | |
| B.12 | Performance test results (speed, scalability) | | | |
| B.13 | Integration test results (data exchange with other tools) | | | |
| B.14 | Regression test results (if tool updated during project) | | | |
| B.15 | Independent review of test results | | | |

---

## C. Error Detection (10 Items)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| C.1 | Negative test cases (invalid inputs, error conditions) | | | |
| C.2 | Error handling verification (graceful failures) | | | |
| C.3 | Resource exhaustion testing (out of memory, disk full) | | | |
| C.4 | Boundary condition testing | | | |
| C.5 | Tool error detection mechanisms (self-checking features) | | | |
| C.6 | False positive analysis (if applicable) | | | |
| C.7 | False negative analysis (if applicable) | | | |
| C.8 | Edge case testing (AI tools: adversarial inputs) | | | |
| C.9 | Failure mode analysis (FMEA for tool) | | | |
| C.10 | Error detection confidence assessment (TD1/TD2/TD3) | | | |

---

## D. Configuration Management (8 Items)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| D.1 | Tool version and build ID | | | |
| D.2 | Configuration baseline (settings, plugins) | | | |
| D.3 | Version control of tool configuration files | | | |
| D.4 | Change control process for tool updates | | | |
| D.5 | Tool update history (if updated during project) | | | |
| D.6 | Impact analysis for tool updates | | | |
| D.7 | Access control (who can modify tool configuration) | | | |
| D.8 | Backup and recovery procedures | | | |

---

## E. Maintenance Procedures (7 Items)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| E.1 | Tool support and maintenance plan | | | |
| E.2 | Vendor support agreement (if commercial tool) | | | |
| E.3 | Tool update evaluation process | | | |
| E.4 | Disaster recovery procedures | | | |
| E.5 | Training records for tool users | | | |
| E.6 | Tool usage guidelines and restrictions | | | |
| E.7 | Tool decommissioning plan (end of project) | | | |

---

## F. Qualification Summary (5 Items)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| F.1 | Tool Qualification Plan (TQP) | | | |
| F.2 | TCL/TQL determination rationale | | | |
| F.3 | Tool Qualification Summary Report | | | |
| F.4 | Known limitations and contraindications | | | |
| F.5 | Approval signatures (Safety Manager, DER, QA) | | | |

---

## G. Regulatory Compliance (15 Items)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| **DO-330 (Aviation)** | | | | |
| G.1 | Tool Qualification Plan (TQP) per DO-330 Section 5.2 | | | |
| G.2 | Tool Operational Requirements (TOR) per Section 5.4 | | | |
| G.3 | Tool Verification Plan (TVP) per Section 5.5 | | | |
| G.4 | Tool Verification Results per Section 5.6 | | | |
| G.5 | DER approval of tool qualification | | | |
| **ISO 26262-8 (Automotive)** | | | | |
| G.6 | TCL determination per Clause 11.4.6 | | | |
| G.7 | Tool evaluation report per Clause 11.4.8 | | | |
| G.8 | Tool validation evidence per Clause 11.4.9 | | | |
| G.9 | Service history (if claiming "proven in use") per Clause 11.4.7 | | | |
| G.10 | Safety Manager approval | | | |
| **IEC 61508-7 (Industrial)** | | | | |
| G.11 | Tool assessment per Annex A | | | |
| G.12 | Tool category determination (offline/online) | | | |
| **IEC 62304 (Medical)** | | | | |
| G.13 | Tool validation per Clause 5.1.4 | | | |
| G.14 | Design History File (DHF) inclusion per 21 CFR 820.30(j) | | | |
| **ASPICE 4.0** | | | | |
| G.15 | Tool validation work product per SUP.8 | | | |

---

## H. AI-Specific Evidence (10 Items - if applicable)

| # | Evidence Item | Status | Document ID / Reference | Notes |
|---|---------------|--------|-------------------------|-------|
| H.1 | AI model version and checkpoint date | | | |
| H.2 | Training data provenance (if available) | | | |
| H.3 | Statistical validation test set (≥10,000 tasks) | | | |
| H.4 | Validation results (accuracy, precision, recall, F1) | | | |
| H.5 | Confidence calibration analysis | | | |
| H.6 | Adversarial testing results (edge cases, challenging inputs) | | | |
| H.7 | HITL protocol definition and enforcement | | | |
| H.8 | Human review records (code annotations, approval logs) | | | |
| H.9 | Rejection tracking (AI suggestions rejected by engineers) | | | |
| H.10 | Uncertainty quantification and confidence scoring | | | |

---

## Checklist Summary

| Category | Total Items | Complete | Not Applicable | In Progress |
|----------|-------------|----------|----------------|-------------|
| A. Tool Description | 5 | | | |
| B. Functional Verification | 15 | | | |
| C. Error Detection | 10 | | | |
| D. Configuration Management | 8 | | | |
| E. Maintenance Procedures | 7 | | | |
| F. Qualification Summary | 5 | | | |
| G. Regulatory Compliance | 15 | | | |
| H. AI-Specific Evidence | 10 | | | |
| **TOTAL** | **75** | | | |

**Completion Percentage**: [X%]
**Readiness for Approval**: [Yes / No - if No, list missing items]

---

## Reviewer Sign-Off

| Role | Name | Signature | Date | Comments |
|------|------|-----------|------|----------|
| **Tool Owner** | | | | |
| **Safety Manager** | | | | |
| **DER** (if DO-330) | | | | |
| **Quality Manager** (if IEC 62304) | | | | |
| **ASPICE Assessor** (if applicable) | | | | |

---

**Document Control**
Revision History:
| Revision | Date | Author | Changes |
|----------|------|--------|---------|
| 1.0 | YYYY-MM-DD | [Author] | Initial checklist |

End of Section 9: Practical Templates

Summary: Section 9 provides four publication-ready templates for tool qualification:

1. Tool Qualification Plan (TQP): 9-section consolidated plan addressing all standards
2. Tool Operational Requirements (TOR): Functional, constraint, performance, and interface requirements
3. Tool Verification Plan (TVP): Test strategy, test cases, execution, and results analysis
4. Evidence Package Checklist: 75-item checklist ensuring multi-standard compliance

These templates enable organizations to qualify tools efficiently across DO-330, ISO 26262-8, IEC 61508-7, IEC 62304, and ASPICE 4.0 with consolidated evidence and minimal duplication.