Energy and utility systems with assessment‑ready safety and security evidence

Usually not to the highest level. IEC 61508-3 classes offline support tools as T1, T2 or T3. A requirements or test management tool that does not generate code is normally T1, with no qualification data needed. It moves toward T2 when you take credit for its output, such as coverage reports, without review. We go through each use case with you, record the class and the reasoning in the safety plan, and where needed add checks so the output is verified.

Each vendor gets only the modules and attributes for its scope, through ReqIF exchange or controlled access to a separate project area. Answers, deviations and clarifications come back into the same requirements, compared with the previous delivery, so you see what changed before you accept it. For vendors who work in documents, we set up import templates that keep requirement IDs stable, so the trace to FAT and SAT survives every exchange.

With streams and baselines in IBM Engineering Lifecycle Management Global Configuration Management. The standard design is one stream. Each site or project is a stream that reuses the standard and holds only its own changes. You compare a site with the standard item by item, decide which improvements to bring back, and keep a baseline per commissioning or modification, so the as-built state of each site stays reproducible years later.

Project by project, not all at once. Running assets often stay on IBM Engineering Requirements Management DOORS (9.x) until the next major modification, while new projects start in IBM Engineering Requirements Management DOORS Next. When a project moves, modules, attributes and links move with their original IDs, and assessed baselines are kept as baselines, so earlier assessment evidence stays reproducible. DXL scripts are inventoried first. Most are replaced by configuration, views or link rules.

Yes. Safety requirements stay in IBM Engineering Requirements Management DOORS Next, and Atlassian Jira issues or GitLab merge requests link to them through OSLC connectors or a synchronization we configure. Developers keep their tools, and the trace from SRS to commit and test result stays complete. For safety-related logic we add a rule that a merge request needs a linked, approved change request before it can be merged.

In the same project, with separate artifact types and link rules. Zones, conduits, target security levels and security requirements link to the same system requirements and tests as safety functions. A security patch or a new remote access path then triggers both security and safety impact analysis. NIS2 and NERC CIP controls are kept as requirements with owners and evidence links, so audits draw on the same data as the functional safety assessment.