Skip to main content

The Problem TestAuto2 Solves

Modern automotive systems face stringent functional safety regulations. A single Advanced Driver Assistance System (ADAS) like Automatic Emergency Braking requires coordinating hundreds of requirements, identifying and mitigating dozens of hazards, analyzing failure modes across multiple system decomposition levels, and demonstrating traceability from customer needs through design and testing to regulatory auditors. Traditional approaches scatter this information across Excel spreadsheets, Word documents, and disconnected tools. This fragmentation creates three critical problems:
  1. Traceability Breakdown — When a safety goal changes, engineers must manually hunt through dozens of files to find affected requirements, failure modes, and test cases
  2. Compliance Blind Spots — Without live visibility into coverage metrics, teams discover gaps too late in the development cycle
  3. Review Paralysis — Stakeholders can’t efficiently review risk analyses when data is locked in static documents rather than interactive, filterable views
TestAuto2 solves these problems by unifying the entire safety lifecycle in a single, traceable data model.

How TestAuto2 Works

TestAuto2 is not a standalone application—it’s a pre-configured Polarion project that combines three components into an integrated safety engineering workspace: diagram

The Three-Layer Architecture

Layer 1: Polarion ALM Foundation
Polarion provides the underlying data repository (work items stored as XML), version control (SVN-based), workflow engine (draft → review → approved), and user management. Every requirement, hazard, failure mode, and test case is a Polarion work item with custom fields, links to other items, and attachments.
Layer 2: Nextedy Tool Integration
Risksheet and PowerSheet are JavaScript-based UI plugins embedded in Polarion LiveDoc documents. Risksheet presents risk data in spreadsheet-like tables optimized for FMEA workflows (with features like hierarchical row grouping, computed formulas, and traffic-light cell styling). PowerSheet renders requirements traceability matrices showing which requirements refine others, which test cases verify them, and which failure modes threaten them.
Layer 3: TestAuto2 Configuration
The solution layer defines what data to capture and how to organize it. This includes:
  • Work item types like Hazard, Failure Mode, Safety Goal, Risk Control
  • Custom fields like ASIL classification, Action Priority, SC/CC designation
  • Link relationships defining allowed connections (e.g., “Failure Mode assesses Function”, “Risk Control mitigates Failure Mode”)
  • Document templates for HARA documents, FMEA documents, Control Plans
  • Dashboard configurations showing live compliance metrics and coverage gaps
Think of TestAuto2 as a configured database schema plus specialized UIs. Polarion is the database engine, Risksheet/PowerSheet are the spreadsheet-like query interfaces, and TestAuto2 is the pre-built schema designed for automotive safety workflows.

The V-Model Data Flow

TestAuto2 organizes work items according to the automotive V-Model development process: diagram Left side (decomposition): Requirements flow down from customer needs through system requirements to detailed design requirements. Functions are allocated to system elements and analyzed for failure modes. Bottom (risk analysis): HARA identifies hazards and derives safety goals. FMEA analyzes failure modes at system, subsystem, and component levels. Risk controls are designed to mitigate failures. Right side (integration & verification): Verification test cases confirm design requirements meet system requirements. Validation test cases confirm system requirements satisfy customer needs. Risk control effectiveness is verified through testing. Every arrow in this diagram is a traced link in the Polarion database, queryable through PowerSheet matrices or dashboard reports.

What Makes TestAuto2 Different

1. Living Traceability

Most tools export static traceability matrices as PDFs. TestAuto2’s PowerSheet configurations are live queries that automatically update when work items change. If a safety engineer adds a new risk control linked to a failure mode, the Requirements Traceability Report immediately reflects the new mitigation without manual regeneration.

2. Multi-Standard Compliance Built-In

Rather than forcing teams to choose between ISO 26262 and AIAG-VDA FMEA, TestAuto2’s data model accommodates both. A single Failure Mode work item can have:
  • ISO 26262 fields: ASIL inheritance from parent safety goal
  • AIAG-VDA fields: Severity (1-10), Occurrence (1-10), Detection (1-10), Action Priority (H/M/L)
  • IATF 16949 fields: SC/CC classification for special characteristics
The Safety Readiness Scorecard dashboard computes compliance percentages per standard in real-time.

3. Hierarchical Risk Analysis

TestAuto2 supports multi-level FMEA decomposition:
LevelAnalyzesRisksheet Document
SystemTop-level functions that can failSystem FMEA (SFMEA)
SubsystemSubsystem-specific failure modesSubsystem FMEA
ComponentPart-level design failuresDesign FMEA (DFMEA)
ProcessManufacturing/assembly failuresProcess FMEA (PFMEA)
Each level filters failure modes by allocatedTo link to the relevant System Element. A component-level DFMEA only shows failure modes allocated to that component, while a system-level SFMEA rolls up risks across all subsystems.

4. Workflow-Driven Maturity Gates

Work items and documents progress through defined workflow states:
  • Draft → editable, no signatures required
  • In Review → peer review in progress
  • Pending Approval → awaiting formal signatures from project_approver role
  • Approved → signed off, ready for publication
  • Published → baselined, used as stable reference
This enforces review discipline: a HARA document cannot reach Published status until at least one approver signs it. The Risk Specification Workflow prevents premature release of safety-critical analyses.

Common Misconceptions

TestAuto2 requires Polarion ALM + Nextedy Risksheet + Nextedy PowerSheet licenses. It cannot run independently. Think of it as a solution package (configuration + templates + dashboards) that activates when installed into a licensed Polarion environment.
Users sometimes confuse Risksheet (the tabular UI tool) with Polarion LiveDoc (the document container). A HARA document is a Polarion LiveDoc containing a Risksheet widget. The Risksheet widget queries work items matching a Lucene query (e.g., type:hazard) and displays them in a table. Editing a cell in Risksheet updates the underlying work item in the Polarion database.
A common misconception is that engineers must manually set ASIL on every requirement and failure mode. In reality, ASIL is calculated via formulas in Risksheet configurations:
  • Hazards have ASIL determined by S×E×C matrix (ISO 26262-3 Table 2)
  • Safety Goals inherit ASIL from their linked hazards
  • Failure Modes inherit ASIL from parent functions via allocatedTo chains
Manual override is possible, but the default behavior is computed inheritance to maintain consistency.

Where to Go from Here

Understanding what TestAuto2 is and how it works conceptually prepares you to: For practical tasks like creating FMEA documents or generating reports, see the How-To Guides section.