Workflow Lifecycle

Unlike simple task tracking systems where items are just “done” or “not done,” automotive functional safety workflows enforce formal review cycles, signature-based approvals, and traceability of who approved what and when. This ensures audit compliance and change accountability.

​

Two Parallel Workflows

TestAuto2 implements two distinct but parallel workflow systems:

1. Work Item Workflow — Controls individual safety artifacts (hazards, failure modes, requirements, test cases)
2. Document Workflow — Controls Polarion LiveDoc modules that contain collections of work items (HARA documents, FMEA documents, requirements specifications)

These workflows interact but remain independent: a document can be in review while containing draft work items, or an approved document can contain items pending approval. This separation enables parallel work and iterative refinement.

​

Work Item Lifecycle States

Work items in TestAuto2 follow a seven-state lifecycle that mirrors typical automotive engineering maturity gates:

​

State Descriptions

​

Why Assignee Matters

The workflow enforces assignee requirements for all forward transitions from draft. You cannot start progress, send to review, or request approval without assigning the work item to a specific person. This isn’t bureaucracy — it’s accountability. ISO 26262 auditors will ask “who analyzed this hazard?” and “who verified this requirement?” The assignee field provides that answer.

​

Document Lifecycle States

Risk specification documents (HARA, FMEA) and requirements specifications follow a four-state lifecycle optimized for formal release management:

​

State Descriptions

​

The Role of Signatures

When a document transitions to inReview, TestAuto2 automatically adds all users with the project_approver role as required signers. The document cannot transition to approved until:

• At least one approver signs with “approved” verdict
• No approver signs with “disapproved” verdict

This implements the AtLeastOneApprovedAndNooneDisapproved approval policy. It’s a safety net: any single approver can block publication if they identify a critical issue, but you don’t need unanimous consent to proceed.

​

The Approval Cascade Problem

A common misconception: “If I approve a document, all the work items inside it are automatically approved.” This is false. Document approval and work item approval are independent. A published HARA document can contain draft hazards. An approved FMEA can contain unapproved failure modes awaiting post-mitigation analysis. This independence is intentional. It allows:

• Incremental approval: Approve high-confidence items early while lower-confidence items remain in review
• Parallel workflows: Design engineers refine requirements while safety engineers finalize hazard analysis in the same document
• Change control: Lock down document structure (approved document) while allowing iterative refinement of specific items

The tradeoff: you must check both document status and work item status to understand true completion. The Safety Readiness Scorecard and role dashboards provide this dual view automatically.

​

Reopening vs. Rework

TestAuto2 distinguishes between two types of backward transitions:

​

Reopen (Work Items)

• What it does: Returns work item to draft from any state (inReview, approved, rejected)
• Signature behavior: Marks all workflow signatures as obsolete, clears approvals and resolution
• Cascade behavior: Can automatically reopen linked items (parent, depends_on relationships)
• Use case: Material changes requiring fresh review cycle (e.g., ASIL downgrade after hazard re-analysis)

​

Rework (Documents)

• What it does: Returns document to draft from inReview, approved, or published
• Signature behavior: Marks all signatures obsolete, resets signature verdict
• Cascade behavior: Does not cascade to contained work items
• Use case: Approval rejected due to incomplete analysis; substantial content changes after publication

​

When to Use Each State Transition

Understanding when to transition is as important as understanding how. Here’s practical guidance:

​

Draft → In Progress

When: You begin active analysis or engineering work.
Before transition: Assign the work item to yourself or a team member.
Example: Safety engineer starts ASIL classification for a newly identified hazard.

​

In Progress → In Review

When: Work is complete enough for peer feedback.
Before transition: Fill in all mandatory fields; ensure analysis is coherent (even if preliminary).
Example: FMEA failure modes have severity/occurrence/detection ratings and you want cross-functional review of the risk controls.

​

In Review → Pending Approval

When: Peer review comments are addressed; item is ready for formal sign-off.
Before transition: Resolve all review feedback; confirm analysis meets standards requirements.
Example: All FMEA review comments incorporated; ready for engineering manager approval.

​

Pending Approval → Approved

When: Required approvers have signed.
Automated by: Signature policy enforcement — you cannot manually force this transition.
Example: Safety manager signs off on HARA; work item automatically transitions to approved once signature policy is satisfied.

​

Any State → Obsolete

When: Work item is no longer valid due to design changes, scope reduction, or superseding items.
Before transition: Fill in resolution field explaining why (for audit trail).
Example: Hazard obsoleted because system design change eliminates the exposure scenario.

​

Document Workflow Example: FMEA Approval

Here’s how a typical Design FMEA document progresses through the workflow:

1. Draft: Safety engineer creates DFMEA document, populates failure modes, assigns severity/occurrence ratings, links to characteristics. Document status: draft.
2. Send for Review: Engineer completes initial analysis, clicks “Send for Review”. Document transitions to inReview. System auto-adds engineering managers as required signers.
3. Review Cycle: Cross-functional team reviews in risksheet, adds comments via Polarion discussions. Some failure modes are in inReview (work item level), others still draft.
4. Rework Iteration: Reviewers identify missing failure modes. Engineer uses rework action to return document to draft, adds missing modes, re-sends for review.
5. Approval: All review comments addressed. Engineering manager signs with “approved” verdict. Document transitions to approved.
6. Publication: DFMEA baselined for use in verification planning. Engineer clicks “Publish”. Document transitions to published.
7. Post-Publication Change: Design change requires adding new failure mode. Engineer uses rework to return to draft, adds failure mode, repeats review cycle.

For step-by-step instructions on executing these workflow actions, see Submit Document for Review and Approve Document.

​

Workflow and Traceability

Workflow states affect traceability queries and coverage metrics:

• PowerSheet traceability matrices show all linked items regardless of workflow state, but often include status columns to highlight draft/unapproved items.
• Coverage reports (Safety Readiness Scorecard, FMEA Coverage Report) may exclude obsolete items from denominators but include all other states.
• nxLinkCoverage macro filters can exclude draft or obsolete items to show “approved coverage” vs. “total coverage”.

This means your traceability view changes as items mature through the workflow. A requirement with 100% test coverage in draft tests shows 0% coverage if filtered to approved tests only.

​

Relationship to Standards Compliance

ISO 26262 Part 2 requires documented approval for safety work products at defined lifecycle phases. The workflow lifecycle provides this documentation automatically:

• Signatures = Approval records for ISO 26262 Part 8 (audit trail)
• Workflow states = Work product maturity for ISO 26262 Part 2 (lifecycle phase gates)
• Resolution field = Change justification for ISO 26262 Part 8 Clause 9 (configuration management)

See Standards Compliance Model for how workflow states map to ISO 26262 work product maturity levels.

---

Related Concepts:
Document Types and Modules • Traceability Model • Standards Compliance Model Related Guides:
Submit Document for Review • Approve Document • Request Rework