Skip to main content
This page explains the architectural decisions behind TestAuto2, how data flows between components, why certain design choices were made, and how the architecture enables the solution to meet the demanding requirements of functional safety standards while remaining maintainable and extensible.

​
The Three-Layer Architecture

TestAuto2 follows a three-layer architectural pattern where each layer has distinct responsibilities: diagram

​
Why This Layering Matters

The separation of concerns enables each layer to evolve independently. You can reconfigure a Risksheet column without touching Polarion custom fields, or modify the RTM model without breaking existing risk analysis workflows. This architecture supports configuration over customization — a principle that reduces long-term maintenance costs and upgrade friction.
All three layers use declarative configuration files (XML for Polarion, YAML for PowerSheet/RTM, JSON for Risksheet) rather than procedural code. This means configuration changes don’t require software development skills, compilation, or deployment pipelines.

​
Data Layer: Polarion ALM Foundation

Polarion ALM provides the persistent data store and baseline ALM capabilities. TestAuto2 extends Polarion’s data model with custom work item types, custom fields, enumerations, link roles, and workflows specifically designed for automotive safety.

​
Custom Work Item Type Taxonomy

The solution defines 20+ specialized work item types organized into V-Model layers: diagram Each type carries custom fields specific to its role. For example, FailureMode includes fields for FMEA severity, occurrence, detection, and Action Priority, while Hazard includes HARA-specific fields for controllability, exposure, and ASIL classification. Polarion’s link role system enables typed relationships between work items. TestAuto2 defines 14 specialized link roles:
Link RoleFrom → ToPurpose
refinesCustomerReq → SystemReqRequirements decomposition
allocatedToFunction → SystemElementFunction allocation to hardware/software
assessesFailureMode → Function/CharacteristicFMEA analysis scope
mitigatesRiskControl → FailureModeRisk treatment traceability
verifiesTestCase → RequirementV-model verification
validatesValidationTestCase → CustomerReqV-model validation
hasHazardSystemElement → HazardHARA scoping
hasCauseHazard → CauseCausal chain
hasHarmHazard → HarmConsequence modeling
These link roles are not arbitrary metadata — they drive query logic in PowerSheet expansions, Risksheet pickers, and compliance calculations in dashboards. For instance, the Safety Readiness Scorecard computes FMEA coverage by counting FailureMode work items with mitigates links to RiskControl items.
Think of link roles as typed foreign keys in a relational database. They enforce referential integrity (via RTM constraints) and enable join-like operations in Velocity templates and Lucene queries.

​
Integration Layer: The RTM Domain Model

The RTM (Requirements Traceability Matrix) domain model sits between Polarion’s raw data model and the presentation tools. Defined in .polarion/nextedy/models/rtm.yaml, the RTM model specifies:
  1. Entity types — Which Polarion work item types participate in traceability
  2. Relationships — Which link roles connect entities, with cardinality and directionality
  3. Constraints — Validation rules (e.g., “DesignRequirement can only link to SystemRequirement within the same subsystem”)
  4. Expansion paths — How PowerSheet should traverse the graph to populate rows

​
Why the RTM Model Exists

Without the RTM abstraction, every Risksheet and PowerSheet would need to hardcode Polarion type names, link roles, and query logic. Changes to the data model would cascade through dozens of configurations. The RTM model centralizes these definitions, enabling single-source-of-truth data modeling. For example, the CustomerRequirement entity in rtm.yaml declares: 
CustomerRequirement:
  polarionType: customerReq
  constraints:
    moduleFolder: Requirements
    moduleName: CUSTOMER-REQS
  relationships:
    - name: refinedBy
      linkRole: refines
      target: SystemRequirement
      cardinality: one-to-many
PowerSheet configurations reference this entity by name (CustomerRequirement) rather than by Polarion type (customerReq). If you rename the Polarion type, you update it once in rtm.yaml, and all dependent configurations remain valid.

​
Entity Type Examples

The RTM model defines 13 entity types. Key examples:
  • SystemElement: Represents hierarchical system architecture (System → Subsystem → Component). Used for ASIL decomposition and FMEA scoping.
  • FailureMode: Central to DFMEA analysis. Assesses Function or Characteristic entities via the assesses link role.
  • RiskControl: Mitigates FailureMode entities. Enables pre/post-mitigation risk calculation in Risksheet formulas.
  • Characteristic: Refines DesignRequirement and is assessed by FailureMode. Links design intent to failure analysis.
Each entity type maps to exactly one Polarion work item type but can be constrained to specific modules or document types using constraints clauses.

​
Presentation Layer: Risksheet and PowerSheet

​
Risksheet: Risk Analysis Tables

Risksheet renders interactive tables for HARA, FMEA, PFMEA, and Control Plans. Each Risksheet is defined by a JSON configuration file (e.g., risksheet.json attached to a Polarion module) that specifies:
  • Columns: Fields to display (custom fields, computed formulas, linked work item pickers)
  • Views: Progressive disclosure workflows (e.g., “Analysis View” → “Mitigation View” → “Validation View”)
  • Formulas: JavaScript expressions for computed columns (e.g., ASIL calculation, Action Priority logic)
  • Levels: Hierarchical grouping (System → Subsystem → Component)
Risksheet configurations are data-driven: they read Polarion work items via REST API and render them according to the JSON schema. No server-side code changes are required to add a column or modify a formula. Example: ASIL Calculation in HARA Risksheet The HARA Risksheet includes a formula column that computes ASIL classification: 
// Formula for ASIL column
if (S === 'S0') return 'QM';
if (S === 'S1' && E <= 'E1') return 'QM';
if (S === 'S1' && E === 'E2' && C <= 'C1') return 'A';
// ... ISO 26262-3 Table 4 logic
This formula references custom field values (S, E, C) and outputs the ASIL enum value, which Polarion persists back to the Hazard work item.

​
PowerSheet: Traceability Matrices

PowerSheet renders hierarchical RTM sheets that expand entity relationships dynamically. A PowerSheet YAML configuration specifies:
  • Root entity: Starting point for row expansion (e.g., CustomerRequirement)
  • Expansion paths: Which relationships to traverse (e.g., refinedBy → SystemRequirement → verifiedBy → TestCase)
  • Column groups: Attributes to display for each entity type
  • Renderers: How to format cells (icons, traffic lights, links)
PowerSheet uses the RTM model to validate configurations at load time. If a YAML file references a relationship that doesn’t exist in rtm.yaml, PowerSheet rejects the configuration with a descriptive error. Example: Whole RTM Sheet Expansion The “Whole RTM Sheet” PowerSheet expands the entire V-model from customer requirements through validation:
  • CustomerRequirement (root)
    • refines -> SystemRequirement
      • refines -> DesignRequirement
        • verifies -> VerificationTestCase
    • validates -> ValidationTestCase
Each level in the expansion displays relevant columns: description, status, traceability link counts, and compliance indicators.

​
Data Flow: From User Input to Persistence

Understanding the round-trip data flow clarifies how the architecture maintains consistency: diagram The architecture enforces single-source-of-truth: Polarion work items are authoritative, and all presentation tools (Risksheet, PowerSheet, dashboards) query the same data via Polarion APIs. No data is duplicated or cached outside Polarion’s database.

​
Why This Architecture Supports ISO 26262

ISO 26262 requires demonstrable traceability, configuration management, and change control. The TestAuto2 architecture addresses these requirements:
  1. Bidirectional Traceability: Link roles enable automated traceability reports. The RTM model enforces relationship integrity.
  2. Configuration Management: Polarion’s built-in versioning tracks all work item changes. Baselines freeze project state for audits.
  3. Workflow Control: Polarion workflows enforce review/approval gates. Documents cannot transition to “Approved” state without passing validation rules.
  4. Tool Qualification: Risksheet and PowerSheet configurations are declarative (YAML/JSON), not executable code, reducing tool qualification burden under ISO 26262-8.
Traceability in TestAuto2 goes beyond link creation. The RTM model enforces semantic constraints (e.g., “DesignRequirement must refine a SystemRequirement within the same subsystem”). Constraints prevent accidental cross-subsystem links that would violate architectural boundaries.

​
Extensibility Points

The architecture provides well-defined extension mechanisms:
  • Add a new work item type: Define in Polarion XML, add to rtm.yaml entity types, reference in Risksheet/PowerSheet configs
  • Add a custom field: Define in Polarion custom-fields.xml, add to Risksheet column definitions or PowerSheet column groups
  • Add a new link role: Define in Polarion link-roles.xml, add to rtm.yaml relationships, use in Risksheet pickers or PowerSheet expansions
  • Add a new report: Create Velocity template in .polarion/pages/, query work items via $trackerService, render using Nextedy macros
Each extension point is isolated to a single configuration layer, minimizing ripple effects.

​
Scalability Considerations

The architecture handles projects with thousands of work items through several mechanisms:
  • Lazy Loading: Risksheet and PowerSheet load only visible rows on initial render, fetching additional data as users scroll.
  • Query Optimization: Lucene queries in Velocity templates are indexed by Polarion’s search engine.
  • Hierarchical Levels: Risksheet levels (System → Subsystem → Component) partition large datasets into manageable chunks.
  • View Filtering: Progressive workflow views reduce cognitive load by hiding irrelevant columns.
Projects with 10,000+ work items typically see <3 second load times for Risksheet tables and <5 seconds for full RTM expansion in PowerSheet.

​
Comparison to Alternative Architectures

Why not a standalone FMEA tool? Standalone tools require manual data export/import to maintain traceability with requirements in Polarion. The integrated architecture eliminates this friction and ensures real-time consistency. Why not custom Polarion scripting? Custom server-side scripts (Workflow Functions, Java extensions) require deployment, testing, and version-specific compatibility. Declarative configurations (YAML/JSON) survive Polarion upgrades with minimal changes. Why not a data warehouse? A central warehouse would introduce eventual consistency issues and complicate change tracking. Polarion as the single source of truth ensures strong consistency and leverages built-in audit logging.

​
Next Steps

Now that you understand the architectural layers and data flows, explore how specific components work: For practical application of this architecture: