A SIL verification workbook is the calculation record that shows a safety instrumented function achieves the safety integrity level it was assigned. Search for a SIL calculation spreadsheet and this is the document you are looking for. Most teams build and store it as a workbook, one row per SIF, one tab per subsystem. A row carries a SIF from the target set in its LOPA through the sensor, logic solver, and final element that make up its subsystem, to a pass or fail result against that target. It is a controlled engineering document, not a scratchpad, and it stays alongside the safety requirement specification and the I/O list, true only as long as the drawing and device data behind it stay current.
Key takeaways
- A SIL verification workbook is a controlled calculation record, one row per SIF, showing a subsystem achieves its target safety integrity level.
- It is commonly built as a spreadsheet, which is why the same document also gets searched for as a SIL calculation spreadsheet.
- Its fields name the SIF, the subsystem tags, the architecture, the reliability data source, the proof test interval, and the achieved result.
- Every field traces back to another document, the LOPA, the safety requirement specification, the P&ID, or the I/O list.
- The workbook only stays true when it is reconciled against those documents on every revision. A swapped device or a re-scoped SIF can leave it verifying a plant that no longer exists.
What a SIL verification workbook is
Every project that assigns a SIL target through a LOPA needs a document proving the safety instrumented function built for that target actually reaches it. That document is the SIL verification workbook, structured one row, or one calculation block, per SIF. Each row is a self-contained audit trail, the assigned target, the subsystem specified to meet it, the data behind that subsystem, and the result. A plant with a dozen SIFs has a workbook with a dozen rows, or a dozen tabs if the format splits each SIF onto its own sheet.
The workbook does not decide the target SIL. That comes from the LOPA. It does not build the subsystem either. That comes from detailed design and the I/O list. What it does is close the loop, confirming the specified sensors, logic solver, and final elements, as actually configured, deliver the integrity the hazard analysis called for.
The fields it carries
| Field | What it holds | Where it comes from |
|---|---|---|
| SIF identifier | The unique reference for the safety instrumented function, such as SIF-101 | The SIF register |
| Safety function description | A plain statement of what the SIF does, such as reactor high pressure trip | The safety requirement specification |
| Target SIL | The safety integrity level the SIF must achieve | The LOPA that assigned it |
| Sensor subsystem tags | The transmitter or switch tags that initiate the trip | The P&ID and the I/O list |
| Logic solver | The safety PLC or relay platform the SIF runs on | The P&ID and the SIS architecture |
| Final element subsystem tags | The valve or motor trip tags that take the safe state action | The P&ID and the I/O list |
| Architecture per subsystem | The voting arrangement named for each subsystem, such as 1oo1, 1oo2, or 2oo3 | The safety requirement specification |
| Device reliability data source | The manufacturer's safety manual or certificate behind the device data | The vendor's SIL certificate |
| Proof test interval | The field naming how often the subsystem is tested | The safety requirement specification and the maintenance plan |
| Achieved result | The pass or fail outcome against the target | The verification calculation itself |
| Revision and approval block | The document revision, the author, the checker, and the approver | The engineering document control system |
Two fields are easy to under-specify. Architecture names the voting arrangement itself, not a reliability number, since how many devices sit in a subsystem changes what is being verified before any device-level data even enters it. Proof test interval is exactly that, a field, holding whatever value the safety requirement specification and the maintenance plan set elsewhere.
Where a signed workbook stops being true
A SIL verification workbook is only true for the plant it was built against. Every field in the table above traces back to a specific record, the SIF register, the LOPA, the safety requirement specification, the P&ID, the I/O list, or a vendor certificate, and the result only holds while all of those still describe the same plant.
Two changes break that silently, and neither shows up as a failed calculation. A device gets substituted during procurement or construction, and the installed transmitter or valve is a different model than the one named in the reliability data source. A SIF gets re-scoped, an initiating cause added or removed, while the workbook still verifies the old scope. Either way the workbook still says pass, for a plant that no longer exists.
This is why the workbook is a management of change trigger, not a one-time deliverable. A device swap, a P&ID revision touching a SIF's subsystem, or a re-scoped hazard scenario each has to route back through the workbook before that SIF is considered verified again.
What it has to reconcile against
The workbook is one of several documents describing the same SIF, and any one of them changing without the others is the drift a functional safety audit exists to catch.
| Document | What must agree | The drift that bites |
|---|---|---|
| SIF register and safety requirement specification | Every SIF identifier and its target SIL | A SIF added to the register but never reaches the workbook, or a revised target the workbook still verifies against the old value |
| I/O list | The subsystem tags, the signal class, and the rack assignment for each device | A device re-tagged or moved to a different rack after the workbook was built, so the workbook and the wiring no longer match |
| P&ID revision | The revision the subsystem tags and the SIF scope were taken from | A later P&ID revision that adds a device, changes a tag, or re-scopes the SIF after the workbook was issued |
| Installed device vs certificate | The device model in the field matching the model the reliability data source describes | A field substitution during procurement that installs a different model than the one the certificate covers |
The workbook is a snapshot of a plant that keeps moving
A SIL verification workbook is a snapshot, and a plant keeps changing after it is signed. Treating a P&ID revision, an I/O list change, or a device substitution as an event that touches every downstream document is what keeps the snapshot honest. The SIF register and the I/O list already have to agree on every tag before a workbook exists. The BPCS and SIS separation that keeps safety hardware on its own rack is what makes the subsystem tags traceable to the field. And the requirement behind all of it is written into IEC 61511 itself, not into any spreadsheet template.