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:- Traceability Breakdown — When a safety goal changes, engineers must manually hunt through dozens of files to find affected requirements, failure modes, and test cases
- Compliance Blind Spots — Without live visibility into coverage metrics, teams discover gaps too late in the development cycle
- Review Paralysis — Stakeholders can’t efficiently review risk analyses when data is locked in static documents rather than interactive, filterable views
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:The Three-Layer Architecture
Layer 1: Polarion ALM FoundationPolarion 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
The V-Model Data Flow
TestAuto2 organizes work items according to the automotive V-Model development process: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
3. Hierarchical Risk Analysis
TestAuto2 supports multi-level FMEA decomposition:| Level | Analyzes | Risksheet Document |
|---|---|---|
| System | Top-level functions that can fail | System FMEA (SFMEA) |
| Subsystem | Subsystem-specific failure modes | Subsystem FMEA |
| Component | Part-level design failures | Design FMEA (DFMEA) |
| Process | Manufacturing/assembly failures | Process FMEA (PFMEA) |
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
Common Misconceptions
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
allocatedTochains
Where to Go from Here
Understanding what TestAuto2 is and how it works conceptually prepares you to:- Get hands-on experience: Follow Your First HARA Session to create your first hazard analysis
- Understand the technical architecture: Read Solution Architecture for component interaction diagrams
- Learn the data model: See Data Model Overview for work item type relationships
- Explore standards: Review ISO 26262 Functional Safety to understand compliance requirements