EO-1 reference model · worked example

A formal verification cycle on the EO-1 model

One requirement change on the EO-1 CubeSat, followed through a formal program from the change request to the baseline: a failed re-test, an issue, a nonconformance and its waiver, the hazards and failure modes the requirement controls, the corrective action, the re-test, sign-off, the customer compliance matrix, a design review and the exports. Each step below is done on the pages a program team uses, and the limits met on the way are listed at the end.

On this page

Starting point
1. Change request
2. The re-test fails
3. Nonconformance and waiver
4. Hazards: reopened and re-evaluated
5. FMECA
6. Corrective action and re-test
7. Sign-off: RVTM and VCRM
8. Customer compliance matrix
9. Design review: RIDs and gate record
10. Baseline and exports
Edge cases on the way
Limits met
Try it

Starting point

The cycle starts from the EO-1 reference model as Holarch builds it with New Demo Project → CubeSat. In that project the Formal program and Safety & Reliability switches (Project Preferences → Program features) are on, so the Deviations & Waivers, Compliance Matrix, Hazard Log and FMECA pages and the RVTM's closure columns are shown.

The subject is requirement 3.3 Depth of Discharge: The EPS shall limit battery depth of discharge to 30% per orbit. It is Approved, verified by test TC-07 Battery Capacity Test (Passed), and it is a control of two hazards: HAZ-001 Battery thermal runaway and HAZ-004 Battery breakup after end of mission.

1. Change request

Cell lot data shows faster capacity fade than the vendor curve above 25% depth of discharge (failure mode FM-002 Cell capacity fade). The systems lead opens Change Requests → New Change Request, gives the reason, and adds the edit with Add Change ▾ → Change an Item…: the statement becomes 25% per orbit. Nothing in the model changes yet.

After Submit for Review the board approves the request with a note, and Apply Changes writes the new text as one undo step. The requirement's history records the edit as made via CR-1.

Change request CR-1, Implemented: lower the depth of discharge limit to 25%, with its reason, the affected item 3.3 Depth of Discharge, the items traced to it, and the proposed change shown as a word difference from 30% to 25% — CR-1 after it was applied. Below the affected item, Holarch lists what traces to it: the functions and equipment that satisfy it, TC-07, both hazards and FM-002.

CR-1 after it was applied. Below the affected item, Holarch lists what traces to it: the functions and equipment that satisfy it, TC-07, both hazards and FM-002.

Two things follow from the edit itself. Requirement 3.3 goes back from Approved to In Review, because its text changed after approval. And its links to what depends on it become suspect links, including the link to TC-07: the test passed against 30%, not 25%.

2. The re-test fails

In the Test Center, TC-07 is run again with ↻ Re-run on its row: tester, configuration (EPS firmware 1.4.0, battery pack QM-1), verification stage Qualification and the event name are recorded with the result. The depth of discharge logic trips at 29%, not 25%: the firmware threshold table was not updated. The result is recorded as Failed, and the RVTM shows 3.3 Failed at once.

From the failed run, + Create Issue raises ISS-4, linked to the test case and the requirements it verifies.

3. Nonconformance and waiver

The failed row in the Test Center offers Disposition… next to the issue. TC-07 verifies two requirements, 3.2 Battery Capacity (met: 78.1 Wh) and 3.3; only 3.3 is affected, so 3.2 is unticked. The disposition is Use As Is: battery pack QM-1 stays in the thermal-vacuum campaign with the old threshold, and the flight units get corrected firmware. Use As Is leaves a departure from the requirement, so the same dialog submits a waiver with its expiry date, its effectivity (battery pack QM-1, thermal-vacuum campaign only) and its justification.

Test Center rows TC-04 to TC-13 with expected and actual results, evidence buttons, status buttons and verified requirements; TC-04 and TC-09 are Failed with their issue and a Disposition button; TC-07 Battery Capacity Test is Passed with stage Qualification and event Battery qualification run 3 — The Test Center at the end of the cycle: TC-07 Passed on its third run. The demo's other failures, TC-04 and TC-09, still wait for a disposition.

The Test Center at the end of the cycle: TC-07 Passed on its third run. The demo's other failures, TC-04 and TC-09, still wait for a disposition.

On Verification → Deviations & Waivers, W-1 is approved; the row records who approved it and when. Edit… on the row refines the effectivity with the unit's serial number. While W-1 is approved and unexpired, the RVTM counts 3.3 as Waived, not as verified: its status stays Failed.

Deviations and Waivers page: DEV-1 against 4.3 Fault Detection and W-1 against 3.3 Depth of Discharge, both Approved, with effectivity, expiry and approver; below, nonconformance NC-1, Closed, Major, disposition Use As Is, found by TC-07, waiver W-1 — Deviations & Waivers: the demo's deviation DEV-1, the new waiver W-1 and the nonconformance NC-1 it accepts.

Deviations & Waivers: the demo's deviation DEV-1, the new waiver W-1 and the nonconformance NC-1 it accepts.

4. Hazards: reopened and re-evaluated

The Hazard Log flags both hazards that 3.3 controls: 1 control failed. HAZ-001 Battery thermal runaway was at Controls Verified; the safety engineer sets it back to Open and raises its residual likelihood from Improbable to Remote while the control is not met, which moves its residual risk from Medium to Serious on the hazard matrix.

HAZ-004 Battery breakup after end of mission was accepted by the program manager before the change. Its acceptance was given against the old 30% limit, so the Hazard Log flags it: Accepted before 3.3 Depth of Discharge changed: accept again, also shown on the hazard itself and as model check Risk.2. It is reviewed after the re-test and renewed by the acceptance authority, which clears the flag.

Hazard Log with the likelihood by severity grid and four hazards: HAZ-001 Battery thermal runaway, Controls Verified, High before and Medium after controls, controls 3.3 and 3.5 with 1 of 2 verified; HAZ-004 Accepted, 1 of 1 verified, accepted by L. Brandt — The Hazard Log after the re-test: HAZ-001 back at Controls Verified with residual risk Medium, HAZ-004's acceptance renewed. HAZ-001 keeps one flag: its other control, 3.5 Battery Thermal Control, is still a TBD in the model.

The Hazard Log after the re-test: HAZ-001 back at Controls Verified with residual risk Medium, HAZ-004's acceptance renewed. HAZ-001 keeps one flag: its other control, 3.5 Battery Thermal Control, is still a TBD in the model.

5. FMECA

On the FMECA worksheet, FM-002 Cell capacity fade gets 3.3 as a control, occurrence 4 instead of 6 with the lower depth of discharge, status Action Planned and the recommended action. Its RPN drops from 90 to 60.

FMECA worksheet grouped by item: FM-001 Cell internal short with RPN 135 above the limit, FM-002 Cell capacity fade with severity 5, occurrence 4, detection 3, RPN 60, control 3.3 Depth of Discharge, 1 of 1 verified, Action Planned — FM-002 with its new rating and its control, verified through the RVTM.

FM-002 with its new rating and its control, verified through the RVTM.

6. Corrective action and re-test

On Risks, Issues & Decisions → Issues & Actions, a new action, AI-2, resolves ISS-4: update the EPS threshold table to 25% and re-run TC-07, assigned to the power engineer with a due date.

The firmware 1.4.0 log first attached to TC-07 as evidence turns out not to show the run under review, so it is removed from the test case's Evidence list. TC-07 then runs again on firmware 1.4.1 and passes (trip at 25.2%), with the new log and the capacity data as evidence files. The test's run log keeps both runs, the failed one and the passed one. The suspect link between 3.3 and TC-07 is reviewed and cleared: the new run covers the new text.

ISS-4 cannot be closed while AI-2 is open. Once AI-2 is closed, ISS-4 and NC-1 are closed with their resolutions.

Issues and Actions register, all items: actions AI-1 to AI-3, issues ISS-1 to ISS-4 and nonconformance NC-1 with kind, status, assignee, due date and source; AI-2, AI-3, ISS-4 and NC-1 are Closed — The register at the end of the cycle. Each item shows where it came from: a test case, an issue or a review comment.

The register at the end of the cycle. Each item shows where it came from: a test case, an issue or a review comment.

7. Sign-off: RVTM and VCRM

On the RVTM, 3.3 is now Passed and its Closure column offers Sign Off…. It is signed off with notes naming the run and the evidence files; the row records who signed off and when. Requirement 4.3 Fault Detection, failed but covered by the approved deviation DEV-1, is signed off too; it stays Failed and is counted as Waived, separately from the verified requirements.

RVTM summary cards: 11 of 32 verified (Passed), 1 waived, 2 of 32 closed (signed off), 3 failed, 12 not run, 3 planned-only, 3 unverified — The RVTM totals: waived requirements are counted on their own card, not as verified.

The RVTM totals: waived requirements are counted on their own card, not as verified.

RVTM rows 1.7 to 4.4 with method, level, verifying test, stage, evidence count, own and rolled-up status, deviation or waiver and closure: 3.3 Passed with waiver W-1 and Closed by A. Morgan; 4.3 Failed with DEV-1 Approved and Closed; 2.1 and 2.2 Failed with Disposition buttons — 3.3 closed; 4.3 closed under DEV-1. The other rows show Sign Off… once they are Passed or covered.

3.3 closed; 4.3 closed under DEV-1. The other rows show Sign Off… once they are Passed or covered.

The VCRM view of the same page lists each requirement's verification method, level, stage and event, the form many contracts ask for.

VCRM view: requirements with inspection, analysis, demonstration and test columns, level, stage, event, verifying test and status; 3.2 and 3.3 show stage Qualification and event Battery qualification run 3

8. Customer compliance matrix

The customer's statement of work has two requirements the change touches: SOW-4.2 Battery cycle life and SOW-4.7 Safe mode. On Needs & Requirements → Compliance Matrix, with the statement of work chosen as the customer specification, SOW-4.2 is Compliant through 3.3 (Passed), and SOW-4.7 is Partially Compliant with a response that names DEV-1 and its expiry.

Compliance Matrix for Customer SOW: Agricultural Imaging Service, 2 of 2 requirements assessed: SOW-4.2 Battery cycle life Compliant, answered by 3.3 Depth of Discharge, Passed; SOW-4.7 Safe mode Partially Compliant with a response naming DEV-1, answered by 4.3 Fault Detection, Failed

9. Design review: RIDs and gate record

The CDR review package holds the System Requirements Specification. On Reviews → Comments (RIDs), the board's comments are dispositioned: RID-1 (no cold-case analysis for the battery heater, from the demo) is Accepted and opens action AI-3; the new RID-2 on 3.3 asks for the depth of discharge margin at end of life and is Accepted with Changes. A RID closes only once it has a disposition and its actions are closed.

Comments (RIDs) tab: RID-1 on 3.5 Battery Thermal Control, Major, Accepted, action AI-3 Closed, status Closed; RID-2 on 3.3 Depth of Discharge, Minor, Accepted with Changes, Closed

On Gate Records, the review is recorded with its chair, attendees, package, outcome Passed and notes, then closed with Close Review. Minutes (Word) writes the record as a document.

Gate record Critical Design Review: EPS delta, Closed, outcome Passed, chair L. Brandt, package RP-1 CDR review package, attendees and notes naming CR-1, NC-1, W-1, the TC-07 re-test, HAZ-001 and FM-002

10. Baseline and exports

A project baseline on Baselines & Versions freezes the state the review accepted. Compare shows what changed after it.

Baselines and Versions: the project baseline CDR EPS Delta Baseline and the document baseline SRR Baseline with approvals, and the Compare panel

The cycle ends with the exports a program hands on:

Export	What it carries from the cycle
UML/SysML (XMI)	The model as SysML 1.6 for other tools, with the revised 3.3 and, with Holarch attributes on, its verification closure.
ReqIF	The requirements with their attributes, including closure and compliance, and their trace relationships.
Word (generated document)	The System Requirements Specification with the revised 3.3; also the change request log and the gate minutes.
Project file (JSON)	Everything: the change request, the records, the hazards and failure modes, the baselines and the evidence files.
Registers (Excel or CSV)	Hazard Log, FMECA, Deviations & Waivers with the nonconformances, Issues & Actions, the RVTM with stage, event and closure, and the Compliance Matrix.

Edge cases on the way

Requirement revised after approval. Applying CR-1 sends 3.3 from Approved back to In Review and marks its links suspect, so the test that passed against the old text is reviewed before it counts again.
Requirement revised after sign-off. A later edit to 3.3's text turns its closure into Closed, requirement changed until the suspect link to TC-07 is reviewed, or the requirement is reopened and signed off again.
Expired waiver. With DEV-1's expiry date in the past, Deviations & Waivers marks it Expired, 4.3 is no longer counted as waived, and its closure shows Closed, now Failed.
Invalid verification evidence. Evidence that does not show the run under review is removed from the test case; the run log still records each run with its result, tester and configuration.
Reopened hazard. A failed control flags the hazard; it is set back to Open and its residual risk re-rated until the control passes again.
Changed risk acceptance. An acceptance given before a change to the hazard's controls is flagged until it is renewed. Who accepted and when are attributes of the hazard, so its history keeps the earlier acceptance.

Limits met

These are the places where the cycle needed a manual step or where Holarch does not yet do what a formal program might expect:

Approval of the new text. An approved and applied change request does not approve the requirement's new text: 3.3 goes back to In Review and is approved again on its own.
Evidence validity. An evidence file has no valid or invalid state. Invalid evidence is removed, and the reason belongs in the sign-off notes.
Gate criteria. A gate record captures entry criteria only for a gate of an SE Process guide; EO-1 has none switched on, so its record has no criteria snapshot.
Exchange formats. XMI and ReqIF carry the requirements and their attributes, not the formal records: hazards, failure modes, waivers, nonconformances and issues travel in the project file and the register exports.

Try it

Create the demo with New Demo Project → CubeSat, or import the EO-1 project file, and follow the steps above. The Formal Program and Verification docs describe each page.