Railway systems with SIL‑ready traceability

It depends on how you use them. EN 50716 puts support tools into classes T1, T2 or T3 by how their output can affect the software. Requirements and test management tools do not generate executable code, so they are not T3. Uses where you rely on a tool output for verification, such as trace or coverage reports, are usually treated as T2. We list each use, agree the class with your assessor and prepare the justification and evidence that class requires.

Through ReqIF, agreed per partner. We set up an exchange definition for each partner: which modules and attributes go out, which come back and who may edit them. Their answers are imported next to the previous delivery, so you see what changed before you accept it. Status and comments from suppliers stay on the same requirements and links, and nothing is copied into a separate document. Where a partner only works in documents, we generate them from the same data.

With configurations instead of copies. The generic application is one stream with its own baselines and safety evidence. Each specific application is a configuration that reuses the generic items and adds its own data and parameters. When the generic application changes, IBM Engineering Lifecycle Management Global Configuration Management shows which projects use the old version, and each project takes the change on purpose, with a record for its own safety case.

Project by project, not all at once. Projects close to an assessment often stay on IBM Engineering Requirements Management DOORS (9.x) until their next baseline, 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 each baseline cited in a safety case is kept, so earlier evidence stays reproducible. DXL scripts are inventoried first and most are replaced by configuration or views.

No. Safety requirements, hazards and verification stay in IBM Engineering Lifecycle Management, where the assessor needs them. Development work stays in Atlassian Jira and code in GitLab. We link work items and merge requests to the requirements they implement, through OSLC-based integrations or a synchronization we configure for your process. The trace from hazard to code is then complete, and developers keep working in the tools they already use.

In the same project, with separate artifact types and link rules. Zones, conduits, threats and security requirements link to the same system functions, subsystem requirements and tests as hazards and safety requirements. One change then triggers both safety and security impact analysis. Where a security measure affects a safety function, the link is explicit, so the assessor sees both sides of the decision in one place.