Five-Level Decomposition
The system element hierarchy uses a five-level product decomposition aligned with IEC 60601-1 requirements for medical electrical equipment:
| Level | Type | Definition | Example (Smart Infusion Pump) |
|---|
| 1 | System | The complete product as delivered | V Series Infusion Pump System |
| 2 | Subsystem | A major functional grouping | Fluid Pumping & Housing Subsystem |
| 3 | Assembly | An integrated unit within a subsystem | Peristaltic Pump Mechanism |
| 4 | Subassembly | A sub-unit within an assembly | Drive Motor Assembly |
| 5 | Component | An individual part | Motor Driver/Controller |
elementType custom field on each system element work item, using the systemElementType enumeration. The hierarchical parent-child relationship uses the standard Polarion parent link role.
Reference Architecture: Smart Infusion Pump
The solution’s reference device uses a 1 system + 6 subsystem decomposition with 35 total system elements:
| Subsystem | Components | Primary Domain |
|---|
| Fluid Pumping & Housing | Peristaltic Pump, Drive Motor, Motor Controller, Pump Door, Door Sensor, Tubing Clamp, Enclosure | Mechanical, Electromechanical |
| Control & Processing | Main Control Unit, System Firmware, Memory, Real-Time Clock | Software, Electrical |
| User Interface | LCD Display, LED Display, Keypad, Internal Light | Electrical, Usability |
| Sensing & Monitoring | Occlusion Sensor, Bubble Sensor, Drip Sensor, Alarm Indicators | Electrical, Mechanical |
| Power Management | AC Power Input, DC Supply, Battery Pack, Charging Circuitry, DC Ports | Electrical, Thermal |
| External Communications | Wireless Module, RS232 Port, Nurse Call Interface | Electrical, RF |
How System Elements Connect to Other Entities
System elements serve as an anchor point for several traceability paths:
| Relationship | Link Role | Direction | Purpose |
|---|
| Functions allocated to elements | allocatedTo | Function —> System Element | Defines what each element is supposed to do |
| Failure modes assessed on elements | assesses | Failure Mode —> System Element | DFMEA: what can go wrong with this element |
| Risk records assessed on elements | assesses | Risk Record —> System Element | HARA: risk analysis scoped to an element |
| Process steps associated | associates | Process Step —> System Element | PFMEA: which manufacturing steps produce this element |
| Design requirements scoped | subsystem constraint | Document-level | Design requirements filtered to the element’s subsystem |
The project uses a consistent naming convention: SRS-SUB-001 through SRS-SUB-006 for system requirement specs, DRS-SUB-001 through DRS-SUB-006 for design requirement specs, and DFMEA-SUB-001 through DFMEA-SUB-006 for DFMEA documents. Each subsystem gets its own document set.
Subsystem Scoping and the Document Constraint
The subsystem custom field on documents enables a critical constraint: when linking design requirements to system requirements in the PowerSheet RTM view, the picker only shows design requirements from documents whose subsystem field matches the current document’s subsystem.
This prevents cross-subsystem contamination. A design requirement for the Power Management Subsystem cannot accidentally be linked to a system requirement belonging to the User Interface Subsystem.
The RTM model enforces this through the $context.source.document.subsystem constraint on the DesignRequirement-to-SystemRequirement relationship.
System Element Lifecycle
System elements follow an extended 7-state lifecycle (compared to the standard 6-state workflow):
| State | Description |
|---|
| Draft | Initial creation |
| In Progress | Active engineering work (unique to system elements) |
| In Review | Under peer review |
| Pending Approval | Awaiting formal approval |
| Approved | Approved for use |
| Rejected | Returned for rework |
| Obsolete | No longer active |
Functions and the Design Chain
Each system element can have functions allocated to it. Functions describe what the element is intended to do — the operational capability or behavior. In the reference project, 46 functions are allocated across the 35 system elements.
Functions serve as the bridge between the system element hierarchy and DFMEA:
- System elements define what the device is made of
- Functions define what each element does
- Failure modes analyze how each function can fail
- Risk controls address those failure modes
This chain ensures that every component has been analyzed for potential failures and that risk controls are traceable to specific design functions.
Related Pages
