The Software and Systems Engineering Experts
US: +1 (610) 247-9595 / EU: +48 666 74 71 74
Home · Solutions · Nuclear
Solutions · Nuclear
Nuclear instrumentation and control with licensing‑ready traceability
IEC 61513 and IEC 60880 evidence from one connected IBM Engineering Lifecycle Management toolchain, set up by consultants who work with safety-critical engineering programs.
Nuclear
The nuclear sector
Reactor protection is now defined in software
The sector covers reactor vendors, utilities and plant operators, engineering companies, and the suppliers of instrumentation and control systems, components and software. New plants are licensed for 60 years of operation, built by international consortia and supervised by national regulators within the IAEA safety framework. Poland's first nuclear power program, based on the AP1000 design, brings this work to Polish industry.
More and more of what protects a plant is defined in software and programmable electronics. Every safety function has to be specified, classified, verified and shown to the regulator, and the evidence has to stay valid for the life of the plant.
ShiftNew build in new countries
New programs, including Poland's, need a licensing basis, a supply chain and qualified engineering processes built from the start.
ShiftDigital instrumentation and control
Analog protection systems are replaced by software-based and FPGA-based platforms, which IEC 60880 and IEC 62566 have to cover.
ShiftSmall modular reactors
SMR vendors aim for standard designs licensed in several countries, so one set of requirements has to serve several regulators.
ShiftLong-term operation
Existing plants extend their operating life, and every modernization of control systems needs the same evidence as the original design.
Engineering challenges
What this means for software and systems engineering
Licensing evidence across the life cycle
IEC 61513 and IEC 60880 ask for documented evidence at every phase, from plant safety requirements to system validation.
Safety classification
Functions and systems are categorized by safety importance, and the category drives the requirements and the depth of verification for each one.
Independence and defence in depth
Protection, control and diverse backup systems have to stay independent, and the requirements must show it.
Vendors, utilities and the regulator
Requirements move between the reactor vendor, the control system supplier, the utility and the regulator, in Requirements Interchange Format (ReqIF) or documents, under strict configuration control.
Computer security of the plant
Security of digital control systems has to be specified and verified alongside safety, on isolated networks.
Sixty years of change
A plant is licensed for 60 years. Every design change, obsolescence fix and modification needs the same trace as the original licensing basis.
What the regulator expects
Where nuclear teams lose time before a licensing review
Functions are categorized in the safety analysis, but the class is not an attribute on the system and software requirements that follow from it.
Independent verification produces reports per document. Linking each test and review back to the software requirement is done by hand before submission.
Licensing and security rules keep design data on isolated networks with strict access control per project and supplier.
RiskSafety software is verified to the wrong depth, and the regulator finds it in the review.
With Smarter ProcessSafety class is an attribute on every requirement, inherited along links, and drives views, reviews and test depth.
RiskThe licensing submission cannot show complete verification coverage for safety software.
With Smarter ProcessReviews and tests in IBM Engineering Test Management link to each software and FPGA requirement, with coverage per baseline.
RiskCloud-only tools are ruled out, and copies on laptops break configuration control.
With Smarter ProcessWe install and maintain IBM Engineering Lifecycle Management on your own servers, including isolated networks.
Compliance map
IEC 61513, IEC 60880 and IEC 62138, mapped to the toolchain
Pick a standard to see what it asks for, and where it lives in your toolchain once we have set it up.
IEC 61513 · System requirements specification
IBM Engineering Requirements Management DOORS NextIBM Engineering Systems Design Rhapsody
What it asks forSystem requirements derived from plant safety functions, with safety category and independence requirements
How we cover itPlant function, system and requirement modules with category attributes and allocation links
IBM Engineering Requirements Management DOORS Next
IBM Engineering Systems Design RhapsodyIEC 61513 · Configuration management
IBM Engineering Lifecycle Management Global Configuration ManagementIBM Engineering Workflow Management
What it asks forConfiguration management of all system life cycle items, with baselines and change control
How we cover itBaselines per licensing stage; modifications through change requests linked to the affected items
IBM Engineering Lifecycle Management Global Configuration Management
IBM Engineering Workflow ManagementIEC 60880 · Software requirements
IBM Engineering Requirements Management DOORS Next
What it asks forSoftware requirements traceable to system requirements, complete and verifiable
How we cover itSoftware requirement type with mandatory links up to system requirements, and gap views
IBM Engineering Requirements Management DOORS NextIEC 60880 · Software verification
IBM Engineering Test Management
What it asks forIndependent verification of each software life cycle phase, with test coverage of requirements
How we cover itReview records and test cases traced to every software requirement; coverage per release
IBM Engineering Test ManagementIEC 62138 · Category B and C software
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forRequirements, verification and configuration management in proportion to the safety category
How we cover itThe same chain as category A, with lighter link rules and review steps set by the category attribute
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementIEC 62566 · HDL requirements and verification
IBM Engineering Requirements Management DOORS NextGitLabIBM Engineering Test Management
What it asks forRequirements for FPGA-based functions traced to the HDL design and its verification
How we cover itHDL requirement modules linked to design items in GitLab and to simulation and test results
IBM Engineering Requirements Management DOORS Next
GitLabIBM Engineering Test Management10 CFR 50 Appendix B · Criteria III and VI
IBM Engineering Requirements Management DOORS NextIBM Engineering Workflow Management
What it asks forDesign control and document control, with design inputs, design verification and controlled changes
How we cover itDesign inputs as requirements, design verification linked to them, approvals through workflow
IBM Engineering Requirements Management DOORS NextIBM Engineering Workflow ManagementIAEA SSR-2/1 · Safety classification and defence in depth
IBM Engineering Requirements Management DOORS Next
What it asks forStructures, systems and components classified by safety significance, with defence in depth across levels
How we cover itSafety class and defence-in-depth level as attributes, with views per level and independence links
IBM Engineering Requirements Management DOORS NextBook a 30-min compliance gap review
Compliance is achieved by your organization and confirmed by your regulator. Tools hold the evidence; we set them up so the evidence is complete and easy to show.
Capabilities
What your team can do on day one
Baselines for every licensing stage
Freeze a configuration for each licensing submission or design review and compare it with the next one, item by item. The regulator sees exactly what changed and why.
- IBM Engineering Lifecycle Management Global Configuration Management
Safety class on every requirement
Category and class attributes flow down the links, so each view shows which requirements need which depth of verification.
- IBM Engineering Requirements Management DOORS Next
Architecture linked to requirements
SysML models of the control system architecture link to requirements, showing allocation and independence between systems.
- IBM Engineering Systems Design Rhapsody
Independent verification in one place
Reviews, analyses and tests are recorded against each requirement by an independent team with its own permissions.
- IBM Engineering Test Management
On-premise and isolated networks
The toolchain runs in your data center or on an isolated network, with access control per project and supplier.
- IBM Engineering Lifecycle Management
Licensing documents from live data
Requirement specifications, trace matrices and verification reports are generated from the tools, in your own templates.
- IBM Engineering Lifecycle Optimization – Publishing
- IBM Engineering Test Management
See every product we implement and support
IBM Engineering Lifecycle Management, HCL and GitLab: licences, set-up, training and support from one team.
All products →
Control system equipment roomHow we work
How we set up a nuclear engineering toolchain
We start from your licensing basis and the standards your regulator applies, define artifact types, safety class attributes and link rules, and set up IBM Engineering Lifecycle Management on your own infrastructure. Existing specifications are migrated and the team is trained on real project data.
Licensing basismapped to artifact types and links
Safety classas an attribute on every requirement
On-premiseon isolated networks
FAQ
Questions nuclear teams ask us
Do IBM Engineering Requirements Management DOORS Next and IBM Engineering Test Management need to be qualified under IEC 60880?
It depends on how their output is used. IEC 60880 expects software tools to be selected and assessed according to how much an error in the tool could affect the safety software. Requirements and test management tools do not generate code, and their output is checked in independent reviews, which keeps the qualification effort low. We document each use case, the tool version and configuration, and the checks that cover tool errors, as input to your software quality plan.
How do we exchange requirements with the reactor vendor, suppliers and the regulator?
Through ReqIF with vendors and suppliers whose tools support it, and through controlled documents for the regulator. Each partner gets only the modules and attributes it is allowed to see. Supplier answers come back into the same requirements, compared with the previous delivery, so deviations are visible before they are accepted. Documents for the regulator are generated from a baseline with IBM Engineering Lifecycle Optimization – Publishing, so the submission and the tool data always match.
How do we keep the licensing basis stable while the design keeps changing?
With baselines and streams in IBM Engineering Lifecycle Management Global Configuration Management. The licensing basis submitted to the regulator is a baseline that does not change. Design work continues in a stream, and each modification is a change request linked to the items it affects. Before the next submission, compare views show exactly what changed against the licensed baseline, item by item, which is the starting point for the impact analysis the regulator expects.
Our plant and system specifications are in IBM Engineering Requirements Management DOORS (9.x). How do we move without losing the licensing record?
Not all at once. We inventory modules, attributes, link types and DXL scripts first. When a project moves, modules move with their original IDs and links, and every baseline used in a licensing submission is kept as a baseline in IBM Engineering Requirements Management DOORS Next, so earlier submissions stay reproducible. Most DXL scripts become configuration, views or attribute rules. Projects near a licensing milestone can stay on IBM Engineering Requirements Management DOORS (9.x) until it passes.
Our software teams use Atlassian Jira and GitLab. Can they keep them for safety software?
For lower categories, often yes. Atlassian Jira issues and GitLab merge requests link to the software requirements they implement, so the trace comes from the tools. For category A software many teams prefer IBM Engineering Workflow Management, because change control, approvals and the link to requirements sit in one controlled system. We look at your categories and quality plan and set the boundary with you.
How do computer security requirements fit next to safety requirements?
In the same project, with their own artifact types and link rules. Security requirements for digital control systems link to the same systems, software requirements and tests as safety requirements, and the security zone of each system is an attribute. One change then triggers both safety and security impact analysis. Access control per project and supplier keeps sensitive security details visible only to the people who need them.
New · SmarterWidgets 2.0
Ready-made widgets for IBM DOORS Next
Add them to the ELM Mini Dashboard and hand repetitive requirements work over to them. Each one previews its changes first.
Browse all widgets- Content qualityClean text and glossary linksStyle Cleaner, Link Checker and more
- Links and traceabilityFix, move and inspect linksLink Remover, Module To Base Links and more
- Module structureBuild and repair module hierarchyModule Fill, Module Explorer 2.0 and more
- Configuration and governanceBaselines, data models and auditsBaseline Archiver, Compare Data Models and more
- Reporting and publishingCharts, maps and publishingPublishing URLs, Module Insights and more
- See all widgetsScreenshots and details for every widget
Watch and learn
Our Videos
Demos, tutorials and customer stories on requirements, traceability and test.
Talk to our consultants
Leave your details and we will get back to you, usually within one business day.
