Mermaid requirement diagram in Markdown to PDF
Requirements carry their risk and verification method, and the diagram links the elements that satisfy and verify them.
Requirements with id, text, risk and verification method, and the elements that satisfy and verify them, inside a safety case for lift control software.
Markdown source
Markdown · 102 lines---
title: Passenger lift controller, safety requirements and verification
author: Safety engineering
---
# Passenger lift controller: safety requirements and verification
**Version 3.2. Controller software release 7.4. Owner: the safety engineering lead. Assessment by the notified body on 8 June 2026.**
This sheet is the control document for the four safety requirements the controller software has to meet before a release is installed in a building. Every requirement names the method that verifies it and the evidence kept in the safety file.
## Requirements
```mermaid
requirementDiagram
requirement door_interlock {
id: 1
text: The car does not move while any landing door is open.
risk: high
verifymethod: test
}
functionalRequirement level_tolerance {
id: 1.1
text: The car stops within 10 mm of the landing before the doors open.
risk: high
verifymethod: test
}
functionalRequirement overload_hold {
id: 1.2
text: With the car above rated load the doors stay open and a message is shown.
risk: medium
verifymethod: test
}
performanceRequirement rescue_time {
id: 2
text: After a power loss the car reaches a landing on battery within 90 seconds.
risk: high
verifymethod: demonstration
}
element rig {
type: test rig
docref: SE-RIG-2026-03
}
element site_test {
type: commissioning test
docref: SE-COMM-7.4
}
element controller {
type: software
docref: controller-7.4
}
element battery_unit {
type: hardware
docref: BU-120
}
door_interlock - contains -> level_tolerance
door_interlock - contains -> overload_hold
rig - verifies -> door_interlock
rig - verifies -> level_tolerance
site_test - verifies -> overload_hold
site_test - verifies -> rescue_time
controller - satisfies -> door_interlock
battery_unit - satisfies -> rescue_time
```
## Verification and result for release 7.4
| Id | Requirement | Method | Limit | Result |
|:---|:------------|:-------|:------|:-------|
| 1 | No movement with a door open | 10,000 cycles on the rig with forced door faults | 0 movements | 0 movements in 10,000 cycles |
| 1.1 | Stop within 10 mm of the landing | 2,000 stops on the rig at rated and empty load | 10 mm | Worst case 6.2 mm |
| 1.2 | Overload holds the doors | Commissioning test at 110 per cent of rated load | Doors stay open | Passed in 12 of 12 installations |
| 2 | Rescue within 90 seconds | Commissioning test with the mains isolated | 90 s | Worst case 41 s |
## Installations covered
| Site | Lifts | Commissioned |
|:-----|------:|:-------------|
| Residential tower, 32 floors | 4 | 14 April 2026 |
| Hospital, main block | 6 | 28 April 2026 |
| Railway station, platform access | 2 | 12 May 2026 |
> [!CAUTION]
> Requirement 1 has no software-only fallback. If the door interlock input is lost the controller stops the car at the next landing and takes the lift out of service until a technician resets it on site.
## Path to the assessment
- [x] Rig tests complete, 15 May 2026
- [x] Commissioning tests on the 12 installations, 12 May 2026
- [ ] Internal review of the safety file, 1 June 2026
- [ ] Assessment by the notified body, 8 June 2026
*All organizations in the sample documents are invented. Names and figures are illustrative.*
Rendered pages
PDF · 2 pages · 21 KBThe sample documents describe invented organizations in several countries. All names and figures are illustrative.
Mermaid diagrams in Markdown to PDF: every sampleIn the Markdown reference

