Entity Types

Entity types are the building blocks of TestAuto2. They define what work items can exist, which fields they contain, and how they relate to other work items through link roles. Understanding entity types is essential for configuring the RTM model.

Entity Type Overview

The TestAuto2 RTM model defines 13 entity types organized across five categories:

Category	Entity Types
Requirements Hierarchy	CustomerRequirement, SystemRequirement, SubsystemRequirement, DesignRequirement, Characteristic, UseStep
Analysis and Control	Hazard, Harm, SafetyGoal, Function, FailureMode, ProcessFailureMode, RiskControl, RiskRecord
Verification	TestCase, VerificationTestCase, ValidationTestCase
System Structure	SystemElement, ProcessStep

Requirements Hierarchy

Requirements decompose through four levels in the V-model: customer → system → subsystem → design. Each level refines the previous level, creating traceability from stakeholder needs through implementation specifications.

CustomerRequirement

Property	Type	Default	Description
`polarionType`	String	`userStory`	Polarion work item type ID
`moduleFolder`	String	`Requirements`	Auto-creates in this folder
`moduleName`	String	`CUSTOMER-REQS`	Document identifier
`moduleDocType`	String	`ReqSpec`	Polarion document type
`outlineNumber`	Boolean	`true`	Enables hierarchical numbering (CUS-001, CUS-001.1)
`classification`	Field	`classification`	Safety classification (SC/CC)
`refines`	Link Role	—	Refined by SystemRequirement entities
`validates`	Link Role	—	Validated by ValidationTestCase entities

Purpose: Captures user-visible system needs and business requirements. Customer requirements are authored early in project planning and traced through system requirements to validation tests. Example:

CUS-001: AEB System shall activate when collision threat detected
- Classification: SC (Safety Critical)
- Validates: V-01 (Validation test for obstacle detection)

SystemRequirement

Property	Type	Default	Description
`polarionType`	String	`systemReq`	Polarion work item type ID
`moduleDocType`	String	`systemRequirementsSpecification`	Document type constraint
`refines`	Link Role	—	Refines CustomerRequirement
`refinedBy`	Link Role	—	Refined by SubsystemRequirement and DesignRequirement
`verifies`	Link Role	—	Verified by VerificationTestCase
`classification`	Field	`classification`	Safety classification
`asil`	Field	`asil`	Automotive Safety Integrity Level

Purpose: Defines system-level functional and non-functional requirements that satisfy customer needs. System requirements are verified at the system integration level and refined into subsystem requirements. Example:

SYS-001: AEB system shall initiate braking within 500ms of obstacle detection
- ASIL: B (determined by HARA)
- Refines: CUS-001
- Verified by: SV-01 (System verification test)

SubsystemRequirement

Property	Type	Default	Description
`polarionType`	String	`sysReq`	Same as SystemRequirement (distinguished by document type)
`moduleDocType`	String	`subsystemRequirementsSpecification`	Subsystem-level doc type
`refines`	Link Role	—	Refines SystemRequirement
`refinedBy`	Link Role	—	Refined by DesignRequirement
`verifies`	Link Role	—	Verified by VerificationTestCase
`subsystemScope`	Constraint	—	Cross-reference limited to same subsystem

Purpose: Decomposes system requirements to subsystem level. Enables allocation of requirements to ECU, sensor, and interface subsystems while maintaining traceability. Example:

SUB-001: ECU Processing Subsystem shall compute obstacle distance from sensor fusion
- Refines: SYS-001
- Verified by: SV-02 (Subsystem verification for ECU)

DesignRequirement

Property	Type	Default	Description
`polarionType`	String	`sysReq`	Polarion work item type ID
`moduleDocType`	String	`designRequirementsSpecification`	Design-level document type
`subType`	Field	`designReqSubType`	Classifies design requirement kind (e.g., interface, algorithm, data structure)
`refines`	Link Role	—	Refines SubsystemRequirement
`refinedBy`	Link Role	—	Refined by Characteristic
`verifies`	Link Role	—	Verified by VerificationTestCase
`classification`	Field	`classification`	SC/CC classification
`subsystemScope`	Constraint	—	Cross-references limited to same subsystem

Purpose: Specifies detailed design requirements at component level. Design requirements are verified through testing and refined into measurable characteristics. Example:

DES-001: Camera image processing algorithm shall detect objects ≥ 1.0m distant
- Subtype: Algorithm Requirement
- Refines: SUB-001
- Refined by: CHR-012 (Detection accuracy characteristic)

UseStep

Property	Type	Default	Description
`polarionType`	String	`userStory`	Polarion work item type ID
`description`	Field	—	Describes the operational scenario
`step`	Field	—	Sequential step number in use case flow
`actor`	Field	—	Actor performing the step (driver, system, environment)
`precondition`	Field	—	Condition that must be true before step

Purpose: Documents operational scenarios and use cases describing how the system is used. Use steps provide context for operational situations in HARA and system testing. Example:

USE-01: Driver approaching stopped vehicle at highway speed
- Actor: Vehicle operating autonomously
- Precondition: AEB system powered, sensor fusion active
- Step: 1 (first step in AEB activation flow)

Characteristic Entity

Property	Type	Default	Description
`polarionType`	String	`workItem`	Polarion work item type ID
`refines`	Link Role	—	Refines DesignRequirement
`targetValue`	Field	—	Nominal or expected value for the characteristic
`tolerance`	Field	—	Allowable deviation or range specification
`classification`	Field	`classification`	SC (Safety Critical) or CC (Critical Component) badge
`unit`	Field	—	Measurement unit (mm, Hz, dB, etc.)
`assessedBy`	Link Role	—	Assessed by FailureMode entities in FMEA

Purpose: Captures measurable design parameters (dimensions, frequencies, thresholds) that are verified in testing and analyzed in FMEA. Each characteristic links to design requirements and to failure modes for risk analysis. Example:

CHR-012: Camera Detection Range Accuracy
- Target Value: 100 ± 5 meters
- Classification: SC (Safety Critical)
- Unit: meters
- Assessed by: FM-045 (Camera detection failure at extreme range)

Analysis & Control Entities

Hazard

Property	Type	Default	Description
`polarionType`	String	`hazard`	Polarion work item type ID
`description`	Field	—	Description of potential hazardous situation
`cause`	Field	—	Root cause or triggering event
`consequence`	Field	—	Potential harm if hazard occurs
`severity`	Field	`haraSeverity`	S0–S3 per ISO 26262 (no injury to fatal)
`exposure`	Field	`haraExposure`	E0–E4 per ISO 26262 (rare to highly probable)
`controllability`	Field	`haraControllability`	C0–C3 per ISO 26262 (easily to difficult to control)
`asil`	Field	`haraAsil`	Computed ASIL (QM, A, B, C, D)
`derivedTo`	Link Role	—	Derived to SafetyGoal entities

Purpose: Documents potential hazardous situations identified in HARA. Each hazard is assessed using ASIL classification matrix (Severity × Exposure × Controllability) to determine required functional safety integrity level. Example:

HAZ-001: Loss of Obstacle Detection
- Cause: Camera/radar sensor failure
- Consequence: Collision with undetected obstacle
- Severity: S3 (fatal or serious injury)
- Exposure: E4 (highly probable)
- Controllability: C3 (difficult for driver to control)
- ASIL: D (highest safety level)
- Derived to: SG-01 (Safety goal for sensor redundancy)

Harm

Property	Type	Default	Description
`polarionType`	String	`harm`	Polarion work item type ID
`description`	Field	—	Description of potential injury or damage
`severity`	Field	`harmSeverity`	Injury severity classification (e.g., minor, serious, fatal)
`affectedParty`	Field	—	Who could be harmed (occupants, pedestrians, property)
`linkedTo`	Link Role	—	Linked to Hazard for harm-hazard mapping

Purpose: Describes potential injuries or damage resulting from hazardous situations. Used in medical device and ISO 14971 risk management contexts.

SafetyGoal

Property	Type	Default	Description
`polarionType`	String	`safetyGoal`	Polarion work item type ID
`description`	Field	—	Statement of the safety goal
`asil`	Field	`asil`	ASIL level (inherited from hazard)
`allocatedTo`	Link Role	—	Allocated to SystemRequirement entities
`derivedFrom`	Link Role	—	Derived from Hazard
`mitigatedBy`	Link Role	—	Mitigated by RiskControl entities

Purpose: High-level safety objectives derived from hazard analysis. Safety goals specify what the system must do to prevent or mitigate identified hazards at a required ASIL level. Example:

SG-01: Ensure Continuous Sensor Availability (ASIL D)
- Derived from: HAZ-001 (Loss of Obstacle Detection)
- Allocated to: SYS-002 (Redundant sensor fusion requirement)
- Mitigated by: RC-015 (Sensor health monitoring control)

Function

Property	Type	Default	Description
`polarionType`	String	`function`	Polarion work item type ID
`description`	Field	—	Functional behavior description
`classification`	Field	`classification`	SC or CC classification
`assessedBy`	Link Role	—	Assessed by FailureMode entities in FMEA
`allocatedTo`	Link Role	—	Allocated to SystemElement via function allocation

Purpose: Defines system and subsystem functions that are analyzed in FMEA. Functions describe what the system does; failure modes describe how functions can fail. Example:

FUNC-005: Obstacle Detection Function
- Classification: SC (Safety Critical)
- Assessed by: FM-001 through FM-015 (failure modes for detection function)
- Allocated to: SYS-001 (AEB System)

FailureMode

Property	Type	Default	Description
`polarionType`	String	`failureMode`	Polarion work item type ID
`description`	Field	—	How the function can fail
`effect`	Field	—	Consequence of the failure
`cause`	Field	—	Root cause of failure
`fmSeverity`	Field	`fmeaSeverity`	1–10 severity rating
`preOccurrence`	Field	`fmeaOccurrence`	1–10 pre-mitigation occurrence rate
`preDetection`	Field	`fmeaDetection`	1–10 pre-mitigation detection rate
`postOccurrence`	Field	`fmeaOccurrence`	Post-mitigation occurrence (after control implementation)
`postDetection`	Field	`fmeaDetection`	Post-mitigation detection (after control implementation)
`ap`	Field	`actionPriority`	H/M/L action priority (computed from pre-mitigation RPN)
`apPost`	Field	`actionPriority`	Post-mitigation action priority
`mitigatedBy`	Link Role	—	Mitigated by RiskControl entities
`assesses`	Link Role	—	Assesses Function or Characteristic

Purpose: Documents potential failures in FMEA analysis. Failure modes are assessed using severity-occurrence-detection scoring, and action priority determines control implementation priorities. Example:

ProcessFailureMode

Property	Type	Default	Description
`polarionType`	String	`processFailureMode`	Polarion work item type ID
`description`	Field	—	Manufacturing/process failure scenario
`effect`	Field	—	Consequence on product quality
`cause`	Field	—	Process root cause
`severity`	Field	`fmeaSeverity`	1–10 rating
`occurrence`	Field	`pfmeaOccurrence`	1–10 pre-mitigation rate
`detection`	Field	`pfmeaDetection`	1–10 detection rate
`mitigatedBy`	Link Role	—	Mitigated by ControlPlanItem

Purpose: Analyzes failures in manufacturing and assembly processes. Process FMEA uses similar scoring methodology but focuses on process control rather than design. Example:

RiskControl

Property	Type	Default	Description
`polarionType`	String	`riskControl`	Polarion work item type ID
`description`	Field	—	Technical control measure or mitigation action
`controlType`	Field	`controlType`	Enumeration: Detection, Preventive, Corrective, etc.
`effectiveness`	Field	—	Estimated or measured reduction in risk (%)
`responsible`	Field	—	Team or person responsible for implementation
`targetCompletionDate`	Field	—	Scheduled completion date
`mitigates`	Link Role	—	Mitigates FailureMode or ProcessFailureMode
`implements`	Link Role	—	Implements SafetyGoal

Purpose: Specifies control actions that reduce or eliminate identified risks. Controls can be design changes, process improvements, or monitoring strategies. Example:

RC-001: Lens Heating and Cleaning System
- Type: Preventive
- Effectiveness: 65% (reduces occurrence from 6 to 3)
- Implements: SG-01 (Continuous sensor availability)
- Mitigates: FM-001 (Camera lens degradation)

RiskRecord

Property	Type	Default	Description
`polarionType`	String	`riskRecord`	Polarion work item type ID
`description`	Field	—	Risk or issue description
`status`	Field	—	Open, In Progress, Closed, Reopened
`probability`	Field	`riskProbability`	Likelihood classification
`impact`	Field	`riskLevel`	Consequence severity classification
`riskLevel`	Field	—	Computed risk matrix intersection (Low/Medium/High/Critical)
`owner`	Field	—	Individual responsible for risk
`linkedTo`	Link Role	—	Linked to Hazard, FailureMode, or RiskControl

Purpose: Tracks residual risks and issues discovered during design or test phases. Risk records maintain visibility into unresolved safety concerns.

Verification Entities

TestCase

Property	Type	Default	Description
`polarionType`	String	`testCase`	Polarion work item type ID
`description`	Field	—	Test objective and acceptance criteria
`procedure`	Field	—	Step-by-step test procedure
`verifies`	Link Role	—	Verifies SystemRequirement, SubsystemRequirement, or DesignRequirement
`validates`	Link Role	—	Validates CustomerRequirement
`evidence`	Link Role	—	Links to external evidence (test reports, logs)

Purpose: Generic test case that can verify requirements at any level or validate customer requirements.

VerificationTestCase

Property	Type	Default	Description
`polarionType`	String	`testCase`	Polarion work item type ID
`moduleDocType`	String	`verificationSpecification`	Verification document type
`verifies`	Link Role	—	Verifies SystemRequirement, SubsystemRequirement, or DesignRequirement
`evidence`	Link Role	—	Links to verification evidence (test logs, reports)

Purpose: Verification-specific test case that proves requirements are correctly implemented. Verification tests are organized in system/subsystem/design verification documents and tracked separately from validation tests. Example:

SV-01: System Verification Test - Braking Response Time
- Verifies: SYS-001 (AEB activation within 500ms)
- Procedure: Simulate obstacle at range X, measure braking activation time
- Evidence: V-SVT-001-20260215.log (test execution log)

ValidationTestCase

Property	Type	Default	Description
`polarionType`	String	`testCase`	Polarion work item type ID
`moduleDocType`	String	`validationSpecification`	Validation document type
`validates`	Link Role	—	Validates CustomerRequirement
`evidence`	Link Role	—	Links to validation evidence (field trial data, customer feedback)

Purpose: Validation test that confirms the system meets customer needs and operates correctly in real-world conditions. Validation is distinct from verification and occurs after system implementation. Example:

VAL-01: Customer Validation - AEB Activation in Real Traffic Scenario
- Validates: CUS-001 (AEB system shall activate when collision threat detected)
- Procedure: Test vehicle in real traffic, measure system performance over 1000 km
- Evidence: Field trial report with pedestrian detection accuracy metrics

System Structure Entities

SystemElement

Property	Type	Default	Description
`polarionType`	String	`systemElement`	Polarion work item type ID
`description`	Field	—	Element description and responsibility
`status`	Field	`systemElementStatus`	Concept, Design, Implemented, Verified, etc.
`outlineNumber`	Boolean	`true`	Hierarchical numbering (AEB.1, AEB.1.1, AEB.1.1.1)
`safetyRelevant`	Field	—	Boolean: is this element safety-relevant?
`allocatedFrom`	Link Role	—	Allocated from SafetyGoal or Function
`allocatedTo`	Link Role	—	Allocated to ProcessStep entities
`parentElement`	Link Role	—	Parent in hierarchy (system → subsystem → component)
`childElement`	Link Role	—	Children in hierarchy

Purpose: Defines the system architecture hierarchy. System elements represent physical or logical components (AEB System, ECU Subsystem, Camera Module, etc.) and support allocation of functions, requirements, and process steps. Example - Hierarchy:

ProcessStep

Property	Type	Default	Description
`polarionType`	String	`processStep`	Polarion work item type ID
`description`	Field	—	Process step description
`outlineNumber`	Boolean	`true`	Sequential numbering
`phase`	Field	—	V-model phase (Planning, Requirements, Design, Implementation, Verification, Validation)
`allocatedTo`	Link Role	—	Allocated to SystemElement entities (many-to-many)
`inputFrom`	Link Role	—	Receives input from previous process step
`outputTo`	Link Role	—	Produces output consumed by next process step

Purpose: Documents the development and verification process flow. Process steps enable tracking of which system elements participate in each phase and establish process-to-design traceability for ISO 26262 compliance. Example:

PS-01: System Requirements Specification Phase
- Phase: Requirements
- Allocatedto: AEB (System)
- OutputTo: PS-02 (System architecture definition)

PS-02: System Architecture Definition Phase
- Phase: Design
- Allocated to: AEB.1, AEB.2, AEB.3 (all subsystems)
- InputFrom: PS-01
- OutputTo: PS-03 (Detailed design phase)

Entity Type Configuration

Entity types are defined in the RTM model YAML file (.polarion/nextedy/models/rtm.yaml). Each entity type includes:

entityTypes:
  SystemRequirement:
    polarionType: sysReq
    moduleDocType: systemRequirementsSpecification
    outlineNumber: true
    fields:
      - name: description
        type: Text
      - name: asil
        type: Enumeration
        options: [QM, A, B, C, D]
    linkRoles:
      - role: refines
        targetType: CustomerRequirement
      - role: refinedBy
        targetType: SubsystemRequirement
    moduleConstraint:
      autoCreate:
        folder: Requirements
        name: SYSTEM-REQS

Each work item created in TestAuto2 instantiates one of these entity types, inheriting its fields, relationships, and constraints.

Modifying entity types requires SVN commit and project reload. Changes affect all documents using those entity types. Always validate risksheet and powersheet configurations after entity type changes to ensure they still reference correct fields and link roles.

Getting Started

Concepts

Reference

Guides

Troubleshooting

FAQ

Entity Type Overview

Requirements Hierarchy

CustomerRequirement

SystemRequirement

SubsystemRequirement

DesignRequirement

UseStep

Characteristic Entity

Analysis & Control Entities

Hazard

Harm

SafetyGoal

Function

FailureMode

ProcessFailureMode

RiskControl

RiskRecord

Verification Entities

TestCase

VerificationTestCase

ValidationTestCase

System Structure Entities

SystemElement

ProcessStep

Entity Type Configuration

Getting Started

Concepts

Reference

Guides

Troubleshooting

FAQ

​Entity Type Overview

​Requirements Hierarchy

​CustomerRequirement

​SystemRequirement

​SubsystemRequirement

​DesignRequirement

​UseStep

​Characteristic Entity

​Analysis & Control Entities

​Hazard

​Harm

​SafetyGoal

​Function

​FailureMode

​ProcessFailureMode

​RiskControl

​RiskRecord

​Verification Entities

​TestCase

​VerificationTestCase

​ValidationTestCase

​System Structure Entities

​SystemElement

​ProcessStep

​Entity Type Configuration

Entity Type Overview

Requirements Hierarchy

CustomerRequirement

SystemRequirement

SubsystemRequirement

DesignRequirement

UseStep

Characteristic Entity

Analysis & Control Entities

Hazard

Harm

SafetyGoal

Function

FailureMode

ProcessFailureMode

RiskControl

RiskRecord

Verification Entities

TestCase

VerificationTestCase

ValidationTestCase

System Structure Entities

SystemElement

ProcessStep

Entity Type Configuration