Skip to main content

Overview

diagram
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.

Project Metadata

Core project identity and administrative settings that appear throughout the Polarion user interface and reporting.
PropertyTypeDefaultDescription
Project NameStringTestAuto2 — Automotive Safety SolutionDisplay name for the project in Polarion UI, dashboards, and reports
Project IDStringTestAuto2Unique identifier used in URLs, SVN paths, and API calls. Example: https://polarion.demo.nextedy.com/polarion/#/project/TestAuto2
Project PrefixStringAEBShort prefix prepended to work item IDs (e.g., AEB-001, AEB-002). Controls numbering scheme across all work item types
Project DescriptionTextAutomatic Emergency Braking Functional Safety and Systems EngineeringLong description displayed on project home page and in project selection dialogs
Project LeadUser Reference(configured via UI)User assigned as project administrator and primary contact. Controls access to project administration features
Project ColorHex Color#1976D2 (blue)Primary color used for project branding in dashboards, banners, and UI elements
Secondary ColorHex Color#90CAF9 (light blue)Secondary accent color used in charts, progress indicators, and visual separators
Project Start DateDate2025-01-01Project creation or formal start date. Used in timeline views and Gantt charts
Project ManagerUser Reference(configured via UI)User assigned as project program manager with reporting and coordination responsibilities
Project LocationStringSandbox/TestAuto2SVN 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.
PropertyTypeValuesDescription
Applicable StandardsEnumeration (multi-value)ISO 26262, AIAG-VDA FMEA, IATF 16949, ISO 21448 SOTIFStandards governing requirements, design, verification, and safety analysis. Affects dashboard metrics, compliance checklists, and report generation
ISO 26262 ScopeEnumerationConcept (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 TargetEnumerationQM, A, B, C, DMaximum Automotive Safety Integrity Level in scope. Used for HARA risk matrix configuration and functional safety completeness thresholds
FMEA MethodologyEnumerationAIAG-VDA, ISO 26262, ISO 31010Risk analysis methodology governing FMEA severity/occurrence/detection scales and Action Priority calculation. Affects Risksheet column formulas
Risk Matrix StyleEnumerationASIL 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 MethodEnumerationTest (ISO 26262 Part 6), Inspection, Analysis, DemonstrationPrimary 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.
PropertyTypeExample ValuesDescription
Enabled Work Item TypesListcustomerRequirement, 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 TypeField MappingSee Custom Fields ReferenceProject-specific fields added to work item types for automotive safety domain (e.g., classification, asil, postmitigationAP, testMethod)
Enumeration ValuesEnumeration Setsseverity: [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 FieldsField RulesAll types: title, description. Design Reqs: verification method. Failure Modes: severity, occurrence, detectionFields that must have values before a work item can transition to certain lifecycle states (e.g., “Ready for Review”)
Form LayoutUI ConfigurationSee Form Layouts ReferenceField grouping, ordering, visibility rules (show/hide based on other field values), and UI hints for each work item type
ID Prefix by TypeString PatterncustomerRequirement → 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 TypePurposeModule TypeRisksheet ConfigPowerSheet Support
customerSpecificationCustomer-origin requirements (V-model top level)LiveDocNoneIncluded in RTM expansion
systemRequirementsSpecificationSystem-level functional requirementsLiveDocNoneDefault RTM source
subsystemRequirementsSpecificationSubsystem decomposition of system requirementsLiveDocNoneIncluded in RTM expansion
designRequirementsSpecificationDetailed design specifications (V-model bottom level)LiveDocNoneIncluded in RTM expansion
testsSpecificationVerification/validation test cases and proceduresLiveDocNoneLinked from verification PowerSheets
characteristicsSpecificationProduct characteristics and acceptance criteriaLiveDocNoneCharacteristics PowerSheet source
functionsSpecificationSystem behavioral functions and operational modesLiveDocNoneFunctions PowerSheet source
riskSpecificationRisk analysis modules (HARA, FMEA, HAZID, Control Plan)LiveDoc + Risksheet✓ Configured per analysis typeNone (Risksheet-specific)
powersheetNextedy PowerSheet traceability matricesPowerSheet ModuleNone✓ Standalone module
genericGeneral-purpose wiki/documentation pagesLiveDocNoneNone
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 TypeParent TypeCardinalityExample RelationshipsCustom Fields
Customer RequirementNone (top-level)1:N → System Reqsrefinesclassification, priority
System RequirementCustomer Req (refined by)1:N → Design/Subsystem Reqsrefines, links to functionsasil, classification, verificationMethod
Design RequirementSystem/Subsystem Req1:N → Test Casesverifies, verified by test casesclassification, subType, verificationMethod
FunctionSystem Element1:N → Failure Modeshas failure modefunctionalArea, safetyRelevant
System ElementNone (top-level)Tree hierarchycontains, implementsasil, safetyRelevant, status
CharacteristicSystem Element1:N → Control Plan Itemshas control intargetValue, tolerance, unit
Failure ModeFunction1:N → Risk Controlsmitigated byseverity, occurrence, detection, actionPriority
Risk ControlNone (top-level)M:N → Failure Modesmitigates, verifies → Test CasescontrolType, verificationEvidence
Test CaseTest Spec (LiveDoc)1:N → Requirements, Failure Modesverifies, validatestestMethod, acceptanceCriteria
Process StepNone (top-level)1:N → Process Failure Modeshas process FMprocessArea, operator
Process Failure ModeProcess Step1:N → Control Plan Itemsdetected byseverity, occurrence, detection, riskPriority
Control Plan ItemNone (top-level)M:N → Characteristics, Process FMscontrols, measuressampleSize, 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.
PropertyTypeExampleDescription
risksheet.json AttachmentFile Referencedocument.risksheetJSON configuration file attached to a riskSpecification document. Defines columns, groups, formulas, cell styling, views, and levels
Query FilterLucene/SQL Querytype: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 GroupsStructured ListSituation Analysis, Assessment, Risk Analysis, Risk ControlsLogical groupings of columns for readability. Each group has a title and list of column definitions
Column Level HeadersHierarchicalLevel 0: HARA, Level 1: Hazard ID, Level 2: SeverityMulti-level column headers that organize columns into conceptual sections (e.g., pre-mitigation vs. post-mitigation Assessment)
FormulasVelocity/JavaScript(severity * occurrence * detection) / 10 for RPN calculationComputed columns that derive values from other fields using mathematical expressions. Recalculate on-save
Cell DecoratorsVisual RulesRed background if AP=‘H’, Green if AP=‘L’Conditional styling applied to cells based on field values. Examples: traffic light colors, icons, badges
ViewsNamed FiltersUnreviewed Items, High Risk Items, Incomplete AssessmentPredefined row filters shown as tabs in the Risksheet UI. Users can switch views without modifying underlying data
LevelsMerge HierarchySystem FMEA ← Subsystem FMEA ← Component FMEAHierarchy 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.
PropertyTypeExampleDescription
PowerSheet YAML FileFile Referencewhole-rtm.yaml, component-rtm.yaml in .polarion/nextedy/sheet-configurations/Configuration defining row/column sources, link expansion, group aggregation, and renderer rules
Row Source QueryLucene/SQLtype:systemRequirement AND space:RequirementsInitial row population. Can be a specific type, hierarchical element list, or custom saved collection
Row GroupingField PathsystemElement.name, statusGroups rows by values of specified field (e.g., “group by system element” or “group by requirement status”)
Column DefinitionsStructured ListEntity types with expansion pathsSpecifies which work item types appear as columns and how they are linked/expanded from row source
Expansion PathLink Traversalrefines→designRequirement→verifies→testCaseDefines how PowerSheet traverses links from row source to find column entities. Used for requirements traceability and hierarchy visualization
RenderersField MappersRender link count, status icon, verification method badge, SC/CC flagCustom rendering logic for cells showing not just data but visual summaries (e.g., “3/5 verified” with progress bar)
Views / FiltersNamed 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 SupportCross-Project LinksLink to requirements from related projectsEnables 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.
PropertyTypePossible ValuesDescription
Document WorkflowState MachineDraft → Ready for Review → Under Review → Approved → PublishedDefines lifecycle states that documents progress through. Controls which roles can perform which actions at each state
Initial StateEnumerationDraftState assigned when a new document is created
Review RequiredBooleantrueWhether “Ready for Review” state requires formal approval gate before publishing
Approver RolesRole ListSafety Manager, Design Lead, Program ManagerRoles authorized to approve documents at review gate. Varies by document type and standards context
Change ManagementBooleantrueWhether modifications to published documents require change tracking and re-approval. Typical for ISO 26262 compliance
Automatic State TransitionsRule 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:
PathPurpose
.polarion/polarion-project.xmlProject metadata (name, prefix, lead)
.polarion/nextedy/models/*.yamlRTM domain model definitions
.polarion/nextedy/sheet-configurations/*.yamlRisksheet/PowerSheet configs
.polarion/documents/fields/custom-fields.xmlCustom field definitions
.polarion/documents/workflow/*.xmlDocument workflow definitions
.polarion/hats/*/tracker/*-form-layout.xmlWork item form layouts per role
.polarion/tracker/fields/custom-fields.xmlTracker custom field definitions
.polarion/pages/Wiki pages and velocity scripts