A risk monitor normally represents the risk for core damage (level 1 probabilistic safety assessment, PSA, model) – a full set of fault trees and/or event trees for the desired scenario(s) and an algorithm for evaluation (generating minimal cut sets) of the model.
In addition, an online risk monitor also requires a user interface in which the fault/event trees are embedded, and which permits changing plant status. Often the plant status input needs to be taken directly from plant monitoring systems and variables such as outage schedule. It should be possible to update the plant model status by reading information in the plant/component status database.
A risk monitor should have functions to control the status of the plant as it is represented in the risk monitor model. The following characteristics need to be controlled:
•Operational status.
•System configurations (for example, which trains are in operation).
•Component availability (components are out of service or being restored).
•Environmental factors (changes in the environment causing increased failure rate/probability, such as a higher probability of loss of off-site power in case of storm).
•When periodic tests are performed.
Presentation of results and interface with the operator could include the following:
•Indication of current risk level at a given time point in the form of a number (relative or absolute risk), and in the form of colour indication.
•Qualitative “defence-in-depth” status, which shows whether systems, sub-systems and components are available, degraded or unavailable.
•A risk curve showing the risk level over time.
•Risk curves for alternative (“what if?”) event histories.
•Comparison of different risk curves.
•Importance measures showing how important components and systems are in terms of contributing to current risk, or in terms of possible reduction of current risk.
The RiskSpectrum RiskWatcher software is used for calculating current risk at nuclear plants. RiskWatcher is used in conjunction with RiskSpectrum PSA Professional (PSAP). Any data changes are performed within PSAP prior to RiskWatcher being used. This principle simplifies the process of going from a living PSA baseline model to a functional risk monitor model and greatly simplifies continuous update work – maintaining a true living PSA model.
Data in the RiskWatcher is stored in a Microsoft Access database. Therefore automated data capture from plant monitoring systems and, for example, outage schedule is limited to data format transfer. The purpose is to link the risk monitor to other systems in the plant, such as equipment tagging systems or electronic operator logs and test and maintenance scheduling software.
Special issues
In designing the RiskWatcher software, special attention was paid to a number of important issues.
User friendly interface
When designing risk monitor software, the target group must be defined. The software should be general – the product is not in itself specific for each plant, but the interface is adaptable to each plant’s specific requirements with regard to defining system configuration, defence-in-depth, and so on. This is very important for maintaining the software.
Calculation speed
A risk monitor must be able to perform calculations very fast. It is possible to use a MCS (minimal cut set) list for risk-monitor calculations, but this is not recommended since scenarios that the baseline calculation are based on (such as core damage) would not be complete when changing, say, the plant operating mode.
One method of speeding up the calculations is to pre-process the PSA model when converting it to the risk monitor model.
The RiskWatcher Model Compiler is used for converting a PSA model in PSAP format to fit the RiskWatcher format. The Model Compiler pre-processes the complete PSA model and restructures the data to a format that can be interpreted by the user friendly interface in RiskWatcher. The change to the risk monitor does not affect the level of detail that is used in the calculation.
The Model Compiler is also designed to minimise the time it takes to generate MCS lists.
Component availability
Importance factors help the user to investigate what impact the availability of a component or a system has on the result from an MCS analysis.
The following importance measures are of interest:
•Fractional contribution (FC) for systems and components.
•Risk increase factor (RIF) for systems and components.
•”Restoration Worth” (RWF) – the risk decrease factor if a component, which was out of service, is restored.
•”Test Worth” – the risk decrease factor if a certain test procedure is carried out at the current time point.
The FC tells you to what fraction a component or a system contributes to the risk for any given configuration. Components or systems with high FC indicate that they play a big role in the risk profile at a specific configuration.
The RIF for components and systems indicate how much the risk would increase if they were taken out of service. This information can be used for supporting decisions about planned activities. You may, for example, want to take all available precautions to make sure that components with high RIF, in a certain configuration, are available before entering that configuration.
The RWF ranks components and systems out of service with regard to risk. This information can support your decisions when prioritising which components to restore prior to taking others out of service.
Components and systems are normally tested on a regular basis at a nuclear plant. The test worth factor indicates which component or system would benefit the most (with regard to risk) from testing.
Conversion from PSA model
Most nuclear plants today work at maintaining their PSA model to reflect changes in the plant – in other words, maintaining a living PSA. Updating the PSA model means that also the risk monitor model has to be updated. Unless it is possible to automatically update the risk monitor model with the changes made in the PSA model, two models have to be kept updated, one being the PSA model and the other being the risk monitor model.
A risk monitor should include functions that let the user specify the status of the plant. This can be achieved in two ways:
•Include functions in the risk monitor that allow you to model the status of the plant by changing the logic in the model.
•Add the possibility to model status of the plant in the PSA model.
The first option includes modelling the status of the plant in the risk monitor after converting the PSA model.
In the second alternative, plant status is modelled in the PSA model prior to conversion. The direct and complete usage of a baseline PSA model is the best option for an online risk monitoring application. This is because one single PSA model is developed and maintained in the PSA software and there is no need for updating a separate risk monitor model. Instead, the monitor model is updated by running the PSA model through a model compiler as soon as it has been changed.
In RiskWatcher, all data is edited in the model in PSAP and no changes need be introduced “afterwards” in the separate RiskWatcher model.
One difficult issue is to handle the calculation of, for example, the risk curve as a function of time when the base line model is changed. When a change in plant design is implemented, the PSA model is updated to reflect this change. The updated model is then converted to the risk monitor model and the online risk is recalculated. The risk curve should reflect the change from the date it was implemented and before that date the “old model” should be used.
In RiskWatcher this is solved in the following way. Two types of updates can be defined:
•Plant update: The PSA model is updated to reflect a change in plant design.
•Model update: The PSA model is improved or an error is corrected.
Common cause failure
The effect of staggered testing for components being subject to the same common cause failure (CCF) is of importance. In PSAP, CCF event probabilities are calculated based on the most recently tested component in each CCF.
When a component, being subject to CCF is taken out of service – how should other components being subject to the same CCF be treated in the risk monitor model?
One could argue that if the component is taken out of service due to a failure, the unavailability of the other CCF events should be based on the fact that one of the components could have failed due to a CCF and the probability of losing the others has increased according to the specified CCF model and factors.
Preventive maintenance, on the other hand, is not included in the statistics of CCF and should not affect the CCF event probabilities.
In RiskWatcher, CCF event probabilities are calculated based on the most recently tested component in the CCF event. Whether corrective and preventive maintenance will be treated differently is still under investigation. In the first version of the software all maintenance is considered preventive.
Time dependent components
Can the risk monitor reflect the time dependent behaviour of component reliability data?
First of all, the calculation model for components in the PSA model must include time dependent variables. Also, the calculation algorithm used for generating MCS must be able to include time dependent variables in the analyses.
A risk monitor should be able to deal with test procedures, test schedules and maintenance schedules. Test procedures – groups of components or systems that are tested together according to the plant’s technical specifications – are implemented in the PSAP model and included in the conversion to the RiskWatcher model. Test schedules as well as maintenance schedules are input to the risk monitor, either by automatic import from test and maintenance scheduling applications or manually.
Related ArticlesRiskSpectrum owner to be bought by Lloyd’s Register