Overview
Project Properties are stored in .polarion/polarion-project.xml and related configuration directories. Modifications require appropriate permissions and typically follow a configuration management workflow with review and approval steps.
Core project identity and administrative settings that appear throughout the Polarion user interface and reporting.
| Property | Type | Default | Description |
|---|
| Project Name | String | TestAuto2 — Automotive Safety Solution | Display name for the project in Polarion UI, dashboards, and reports |
| Project ID | String | TestAuto2 | Unique identifier used in URLs, SVN paths, and API calls. Example: https://polarion.demo.nextedy.com/polarion/#/project/TestAuto2 |
| Project Prefix | String | AEB | Short prefix prepended to work item IDs (e.g., AEB-001, AEB-002). Controls numbering scheme across all work item types |
| Project Description | Text | Automatic Emergency Braking Functional Safety and Systems Engineering | Long description displayed on project home page and in project selection dialogs |
| Project Lead | User Reference | (configured via UI) | User assigned as project administrator and primary contact. Controls access to project administration features |
| Project Color | Hex Color | #1976D2 (blue) | Primary color used for project branding in dashboards, banners, and UI elements |
| Secondary Color | Hex Color | #90CAF9 (light blue) | Secondary accent color used in charts, progress indicators, and visual separators |
| Project Start Date | Date | 2025-01-01 | Project creation or formal start date. Used in timeline views and Gantt charts |
| Project Manager | User Reference | (configured via UI) | User assigned as project program manager with reporting and coordination responsibilities |
| Project Location | String | Sandbox/TestAuto2 | SVN repository path used for checkout/export operations: https://pol2.prod.nextedy.com/svn/Sandbox/TestAuto2 |
Standards and Compliance Configuration
Properties that define which automotive safety standards apply to this project and how compliance is tracked and reported.
| Property | Type | Values | Description |
|---|
| Applicable Standards | Enumeration (multi-value) | ISO 26262, AIAG-VDA FMEA, IATF 16949, ISO 21448 SOTIF | Standards governing requirements, design, verification, and safety analysis. Affects dashboard metrics, compliance checklists, and report generation |
| ISO 26262 Scope | Enumeration | Concept (Part 3), System Design (Part 4), Hardware Design (Part 5), Software Dev (Part 6) | Which ISO 26262 development phases are in scope. Controls which custom fields appear in forms (e.g., ASIL allocation, safety goals) |
| ASIL Target | Enumeration | QM, A, B, C, D | Maximum Automotive Safety Integrity Level in scope. Used for HARA risk matrix configuration and functional safety completeness thresholds |
| FMEA Methodology | Enumeration | AIAG-VDA, ISO 26262, ISO 31010 | Risk analysis methodology governing FMEA severity/occurrence/detection scales and Action Priority calculation. Affects Risksheet column formulas |
| Risk Matrix Style | Enumeration | ASIL Matrix (S-E-C), AP Matrix (Sev-Occ-Det), RPN Matrix (numeric) | Visual risk assessment matrix displayed in HAZID and FMEA dashboards. Controls color coding and acceptance thresholds |
| Verification Method | Enumeration | Test (ISO 26262 Part 6), Inspection, Analysis, Demonstration | Primary verification approach for design requirements. Affects traceability expectations (test case links vs. inspection records) |
Changing the FMEA Methodology or Risk Matrix Style mid-project can break existing Risksheet formulas and dashboard calculations. Coordinate with safety engineering and configuration management before making changes.
Work Item Type Configuration
Properties controlling which work item types are available and how they are configured with custom fields, validation rules, and form layouts.
| Property | Type | Example Values | Description |
|---|
| Enabled Work Item Types | List | customerRequirement, systemRequirement, designRequirement, hazard, failureMode, riskControl, testCase, etc. | Set of work item types available in this project. Each type has dedicated custom fields, form layout, and workflow |
| Custom Fields Per Type | Field Mapping | See Custom Fields Reference | Project-specific fields added to work item types for automotive safety domain (e.g., classification, asil, postmitigationAP, testMethod) |
| Enumeration Values | Enumeration Sets | severity: [1-10], actionPriority: [H, M, L], status: [New, In Progress, Done], etc. | Predefined dropdown and multi-select values for custom fields. Organized by work item type |
| Mandatory Fields | Field Rules | All types: title, description. Design Reqs: verification method. Failure Modes: severity, occurrence, detection | Fields that must have values before a work item can transition to certain lifecycle states (e.g., “Ready for Review”) |
| Form Layout | UI Configuration | See Form Layouts Reference | Field grouping, ordering, visibility rules (show/hide based on other field values), and UI hints for each work item type |
| ID Prefix by Type | String Pattern | customerRequirement → CUST-, systemRequirement → SYS-, designRequirement → DES- | Optional prefixes to distinguish work item IDs by type. If not configured, all items use project prefix (AEB-001, AEB-002, etc.) |
Example custom field configuration for Design Requirement:
<customField>
<name>classification</name>
<type>enum</type>
<required>false</required>
<multiValue>false</multiValue>
<enumValues>
<value>Functional</value>
<value>Performance</value>
<value>Interface</value>
<value>Safety-Related</value>
<value>Non-Functional</value>
</enumValues>
</customField>
<customField>
<name>subType</name>
<type>enum</type>
<required>true</required>
<multiValue>false</multiValue>
<enumId>designRequirement-subType</enumId>
</customField>
Document Type Configuration
Document types define categories of Polarion LiveDoc modules and govern their structure, available fields, and integration with Risksheet and PowerSheet.
| Document Type | Purpose | Module Type | Risksheet Config | PowerSheet Support |
|---|
| customerSpecification | Customer-origin requirements (V-model top level) | LiveDoc | None | Included in RTM expansion |
| systemRequirementsSpecification | System-level functional requirements | LiveDoc | None | Default RTM source |
| subsystemRequirementsSpecification | Subsystem decomposition of system requirements | LiveDoc | None | Included in RTM expansion |
| designRequirementsSpecification | Detailed design specifications (V-model bottom level) | LiveDoc | None | Included in RTM expansion |
| testsSpecification | Verification/validation test cases and procedures | LiveDoc | None | Linked from verification PowerSheets |
| characteristicsSpecification | Product characteristics and acceptance criteria | LiveDoc | None | Characteristics PowerSheet source |
| functionsSpecification | System behavioral functions and operational modes | LiveDoc | None | Functions PowerSheet source |
| riskSpecification | Risk analysis modules (HARA, FMEA, HAZID, Control Plan) | LiveDoc + Risksheet | ✓ Configured per analysis type | None (Risksheet-specific) |
| powersheet | Nextedy PowerSheet traceability matrices | PowerSheet Module | None | ✓ Standalone module |
| generic | General-purpose wiki/documentation pages | LiveDoc | None | None |
The riskSpecification document type is special—it can host either structured LiveDoc content or a Risksheet embedded widget. The .polarion/documents/<DocumentId>/document.risksheet attachment configures the Risksheet view for that specific document.
RTM Domain Model Configuration
The Relational Traceability Model (RTM) defines which work item types exist, their relationships, and expansion paths used by PowerSheet.
| Entity Type | Parent Type | Cardinality | Example Relationships | Custom Fields |
|---|
| Customer Requirement | None (top-level) | 1:N → System Reqs | refines | classification, priority |
| System Requirement | Customer Req (refined by) | 1:N → Design/Subsystem Reqs | refines, links to functions | asil, classification, verificationMethod |
| Design Requirement | System/Subsystem Req | 1:N → Test Cases | verifies, verified by test cases | classification, subType, verificationMethod |
| Function | System Element | 1:N → Failure Modes | has failure mode | functionalArea, safetyRelevant |
| System Element | None (top-level) | Tree hierarchy | contains, implements | asil, safetyRelevant, status |
| Characteristic | System Element | 1:N → Control Plan Items | has control in | targetValue, tolerance, unit |
| Failure Mode | Function | 1:N → Risk Controls | mitigated by | severity, occurrence, detection, actionPriority |
| Risk Control | None (top-level) | M:N → Failure Modes | mitigates, verifies → Test Cases | controlType, verificationEvidence |
| Test Case | Test Spec (LiveDoc) | 1:N → Requirements, Failure Modes | verifies, validates | testMethod, acceptanceCriteria |
| Process Step | None (top-level) | 1:N → Process Failure Modes | has process FM | processArea, operator |
| Process Failure Mode | Process Step | 1:N → Control Plan Items | detected by | severity, occurrence, detection, riskPriority |
| Control Plan Item | None (top-level) | M:N → Characteristics, Process FMs | controls, measures | sampleSize, frequency, reactionPlan |
The RTM domain model is defined in .polarion/nextedy/models/ as YAML files. Each entity type, relationship, and expansion path used by PowerSheet is explicitly configured. See RTM Model Configuration for detailed reference.
Risksheet Configuration Properties
Properties that control how Risksheet documents are configured and displayed within riskSpecification type documents.
| Property | Type | Example | Description |
|---|
| risksheet.json Attachment | File Reference | document.risksheet | JSON configuration file attached to a riskSpecification document. Defines columns, groups, formulas, cell styling, views, and levels |
| Query Filter | Lucene/SQL Query | type:failureMode AND systemElement:"Sensor Housing" | Initial data set loaded into Risksheet. Uses Polarion query syntax to select work items by type, custom field values, links, etc. |
| Column Groups | Structured List | Situation Analysis, Assessment, Risk Analysis, Risk Controls | Logical groupings of columns for readability. Each group has a title and list of column definitions |
| Column Level Headers | Hierarchical | Level 0: HARA, Level 1: Hazard ID, Level 2: Severity | Multi-level column headers that organize columns into conceptual sections (e.g., pre-mitigation vs. post-mitigation Assessment) |
| Formulas | Velocity/JavaScript | (severity * occurrence * detection) / 10 for RPN calculation | Computed columns that derive values from other fields using mathematical expressions. Recalculate on-save |
| Cell Decorators | Visual Rules | Red background if AP=‘H’, Green if AP=‘L’ | Conditional styling applied to cells based on field values. Examples: traffic light colors, icons, badges |
| Views | Named Filters | Unreviewed Items, High Risk Items, Incomplete Assessment | Predefined row filters shown as tabs in the Risksheet UI. Users can switch views without modifying underlying data |
| Levels | Merge Hierarchy | System FMEA ← Subsystem FMEA ← Component FMEA | Hierarchy configuration showing how Risksheet documents at different system levels relate and merge data. Used for hierarchical FMEA rollup |
Example risksheet.json snippet for DFMEA:
{
"name": "Design FMEA",
"query": "type:failureMode",
"columnGroups": [
{
"title": "Situation Analysis",
"columns": ["systemElement", "function", "failureMode"]
},
{
"title": "Pre-Mitigation Assessment",
"columns": ["severity", "occurrence", "detection", "actionPriority", "rpn"]
},
{
"title": "Risk Controls",
"columns": ["controlDescription", "controlType"]
},
{
"title": "Post-Mitigation Assessment",
"columns": ["severityPost", "occurrencePost", "detectionPost", "actionPriorityPost"]
}
],
"formulas": {
"actionPriority": "if(severity >= 7, 'H', if(severity >= 4, 'M', 'L'))",
"rpn": "severity * occurrence * detection"
},
"cellDecorators": {
"actionPriority": {
"H": { "backgroundColor": "#FF5252", "color": "white" },
"M": { "backgroundColor": "#FFC107", "color": "black" },
"L": { "backgroundColor": "#4CAF50", "color": "white" }
}
}
}
PowerSheet Configuration Properties
Properties controlling how PowerSheet YAML configurations define traceability columns, expansion paths, and cross-project queries.
| Property | Type | Example | Description |
|---|
| PowerSheet YAML File | File Reference | whole-rtm.yaml, component-rtm.yaml in .polarion/nextedy/sheet-configurations/ | Configuration defining row/column sources, link expansion, group aggregation, and renderer rules |
| Row Source Query | Lucene/SQL | type:systemRequirement AND space:Requirements | Initial row population. Can be a specific type, hierarchical element list, or custom saved collection |
| Row Grouping | Field Path | systemElement.name, status | Groups rows by values of specified field (e.g., “group by system element” or “group by requirement status”) |
| Column Definitions | Structured List | Entity types with expansion paths | Specifies which work item types appear as columns and how they are linked/expanded from row source |
| Expansion Path | Link Traversal | refines→designRequirement→verifies→testCase | Defines how PowerSheet traverses links from row source to find column entities. Used for requirements traceability and hierarchy visualization |
| Renderers | Field Mappers | Render link count, status icon, verification method badge, SC/CC flag | Custom rendering logic for cells showing not just data but visual summaries (e.g., “3/5 verified” with progress bar) |
| Views / Filters | Named Presets | ”Ready for Design”, “Awaiting Verification”, “Covered by Test” | Quick filters showing only rows/columns meeting certain criteria without modifying the underlying sheet |
| Multi-Project Support | Cross-Project Links | Link to requirements from related projects | Enables PowerSheet to show traceability across project boundaries if configured for multi-project scenarios |
Example PowerSheet YAML for Whole RTM:
name: Whole RTM
description: Complete requirements traceability from customer to test
rows:
source: type:customerRequirement
groupBy: none
columns:
- name: systemRequirement
linkRole: refines
hierarchical: true
- name: designRequirement
expansionPath: systemRequirement→refines→designRequirement
hierarchical: true
- name: testCase
expansionPath: designRequirement→verifies→testCase
count: true
renderer: testCoverageBar
renderers:
testCoverageBar:
type: bar
valueSource: link.count
color: "#4CAF50"
showLabel: true
Workflow and Lifecycle Configuration
Properties defining state transitions, approval gates, and document lifecycle for risk specifications and requirements documents.
| Property | Type | Possible Values | Description |
|---|
| Document Workflow | State Machine | Draft → Ready for Review → Under Review → Approved → Published | Defines lifecycle states that documents progress through. Controls which roles can perform which actions at each state |
| Initial State | Enumeration | Draft | State assigned when a new document is created |
| Review Required | Boolean | true | Whether “Ready for Review” state requires formal approval gate before publishing |
| Approver Roles | Role List | Safety Manager, Design Lead, Program Manager | Roles authorized to approve documents at review gate. Varies by document type and standards context |
| Change Management | Boolean | true | Whether modifications to published documents require change tracking and re-approval. Typical for ISO 26262 compliance |
| Automatic State Transitions | Rule List | ”If all requirements verified → transition to Ready for Publication” | Optional rules that automatically move documents to next state when conditions are met (e.g., coverage thresholds reached) |
Document workflow states have legal significance under ISO 26262. “Published” status indicates formal approval for use as baseline. Never bypass approval workflows in production projects.
File Structure Reference
Project Properties are distributed across the SVN project structure:
| Path | Purpose |
|---|
.polarion/polarion-project.xml | Project metadata (name, prefix, lead) |
.polarion/nextedy/models/*.yaml | RTM domain model definitions |
.polarion/nextedy/sheet-configurations/*.yaml | Risksheet/PowerSheet configs |
.polarion/documents/fields/custom-fields.xml | Custom field definitions |
.polarion/documents/workflow/*.xml | Document workflow definitions |
.polarion/hats/*/tracker/*-form-layout.xml | Work item form layouts per role |
.polarion/tracker/fields/custom-fields.xml | Tracker custom field definitions |
.polarion/pages/ | Wiki pages and velocity scripts |
Related Reference Pages