The impact list for lab occupancy
Which test binds the bench, which binds the vehicle, which is documentation only. Impact comes from the delta against the previous baseline, not from link status. You decide whether to re-test, re-document, or record a deviation. The same list goes back to DOORS via ReqIF and CSV.
DOORS remains the system of record. That stays.
DOORS is the leading system for requirements, for good reason. Modules, links, baselines, history, access: the tool can do that, and it has sat there for years. A programme that runs it did not build that structure by accident. It grew because the vehicle, the variants and the change requests grew. Cevelar does not replace it. It starts where a changed requirement must become a test plan.
Related: requirements management beside an ALM and test plan from an OEM spec.
What suspect links do not decide
The test method on the requirement is an attribute in DOORS. Effort, duration and which resource is bound sit beside it, usually in a side list. The recorded evidence (against which revision, under which conditions) is not an object in the tool. Whether it still holds after a change request is a judgement, not a derivation. Reuse across vehicle programmes is the same at larger scale: a manual call, someone with the old report and the new spec side by side.
Cevelar holds method and effort on the requirement itself, not as a side list. Suspect links in DOORS are the right alert. They do not say which bench still holds, which vehicle trial must be redone, and which occupancy then shifts.
Change request 19 on the door control
A door control, SIL 2. Requirement SYS-0218 requires release only below a speed threshold. Evidence was recorded on bench and vehicle trial against 5 km/h, spec Rev. C. All figures in this section are demo data.
The operator sends change request 19 (CR-19). The threshold becomes 3 km/h. In DOORS the links on SYS-0218 go suspect. That is the right alert. It stops there. It does not say whether bench report V&V-0312 can still be used, whether the vehicle trial must be set up again, or whether only the boundary-condition documentation needs updating.
What remains open is what the recorded evidence is still worth. The bench was set up against 5 km/h. The new threshold changes the condition, not necessarily the setup. Whether the evidence still holds depends on what was actually measured on the stand, not on the requirement text alone.
Whoever re-tests wholesale after CR-19 binds a bench and a vehicle booked months ahead. Whoever leaves it standing carries the evidence situation into the next assessment round.
What Cevelar holds in the test plan
The stock comes from DOORS. Cevelar does not recapture the requirements. It reads the state (module, baseline, changes against the previous revision) and derives impact from the comparison. On the same requirement SYS-0218 then sit method, effort and the recorded evidence with revision and conditions.
After CR-19 it shows that the bench was run against 5 km/h and the condition changed; that the vehicle trial is bound to a software revision; what effort is set for a re-assessment or a repeat. Clauses from EN 50126 and, where software sits, EN 50128 or EN 50657 hang on the requirement, not in a folder. Whether to re-test, re-document or record a deviation stays your call.
- LinkSuspect — the tool is right
- MethodAttribute, not a plan
- EvidenceRecorded, validity open
- EffortNot in DOORS
- StockFrom DOORS, baseline Rev. C plus CR-19
- BenchV&V-0312, condition changed, re-assess
- VehicleBound to a revision: re-run or deviation
- EffortPlanning figure on the requirement
The same subsystem, next vehicle programme
The same door control runs in a second vehicle programme, often with its own spec revision and country variants. Evidence is reusable when it is clear against which requirement revision and under which conditions it was recorded. Without that anchor, only the report remains — and the memory that “something comparable already ran”. In Cevelar the anchor sits on the evidence.
EN 50126, the safety case, the assessment
EN 50126 sets the frame for verification and validation. EN 50129 requires the safety case with traceable chains. EN 50657 or EN 50128 apply where software sits in the subsystem. CSM-RA assesses the change, not the tool.
Cevelar hangs clauses from EN 50126, EN 50128, EN 50129 and EN 50657 on the requirement and keeps history and evidence chains. You write the safety case. You pass the ISA, AsBo or NoBo assessment. The platform does not promise type approval or an authorisation to place in service.
How this shows up on a live programme
On a change already in DOORS, and on the matching test plan. Which evidence still holds after the delta, which test must be re-run, which occupancy shifts. Not as a rollout — on the module you already maintain. Hosted in Germany, on-premise on request.
Built by engineers from test and validation, not from tool sales. Who we are