This document is downloaded from the

Digital Open Access Repository of VTT

Title Model Checking for Licensing

Support in the Finnish Nuclear
Industry
Author(s) Pakonen, Antti; Valkonen, Janne;
Matinaho, S; Hartikainen, M
Citation International Symposium on Future
I&C for Nuclear Power Plants
(ISOFIC 2014), Jeju Island, Republic
of Korea, 24 - 28 August 2014
Date 2014

Rights This article may be downloaded for

personal use only

VTT By using VTT Digital Open Access Repository you are

http://www.vtt.fi bound by the following Terms & Conditions.
P.O. box 1000 I have read and I understand the following statement:
FI-02044 VTT
Finland This document is protected by copyright and other
intellectual property rights, and duplication or sale of all or
part of any of this document is not permitted, except
duplication for research use or educational purposes in
electronic or print form. You must obtain permission for
any other use. Electronic or print copies may not be
offered for sale.
Model Checking for Licensing Support in the Finnish Nuclear
Industry
Antti PAKONEN1, Janne VALKONEN1, Sami MATINAHO2, Markus
HARTIKAINEN2
1. VTT Technical Research Centre of Finland, P.O. Box 1000, FI-02044 VTT, Finland ([email protected],
[email protected])
2. Fortum Power and Heat, P.O. Box 1, FI-00048 FORTUM, Finland ([email protected],
[email protected])

Abstract: This paper examines how model checking can be used to support the qualification of
digital I&C software in nuclear power plants, in a way that is consistent with regulatory demands –
specifically, the common position of seven European nuclear regulators and authorised technical
support organisations. As a practical example, we discuss the third-party review service provided
by VTT for the power company Fortum in the I&C renewal project of the Loviisa plant in southern
Finland.
Keywords: Model checking, verification and validation, digital I&C

1 Introduction methods can even be dangerous, as lack of legibility

Reliability of digital instrumentation and control may lead to difficulties in verification, and the
(I&C) software is a critical issue for nuclear power impossibility of expressing all types of requirements
plants, both in new-builds and modernisation projects. may lead to incompleteness or inconsistencies [2].
The inherent complexity of software-based control To meet these demands and challenges, VTT has been
systems means that the industry and regulatory bodies providing an independent, third-party I&C software
face challenges in ensuring that systems are error-free, verification service based on model checking. Model
and meet their requirements. checking is a formal, computer-assisted verification
The Finnish Regulatory Guides on nuclear safety method that is used to exhaustively check that a model
(YVL) state that with systems of considerable safety of a hardware or software system fulfils a set of
significance, “a safety assessment shall be carried out formalised functional properties [3]. Due to the
by an independent third-party organisation” [1]. Also, exhaustive analysis (taking into account all relevant
a common position of several European nuclear model states or behaviours), model checking can
regulators – including the Finnish regulator STUK – reveal design faults that are difficult to find using
is that for a software-based safety system “an more traditional verification and validation (V&V)
independent assessment of the system is essential to methods.
provide the degree of confidence in the design process, In this paper, we introduce the rationale and the
in the product and in the personnel involved. The challenges in using model checking for the
independent assessment ordered by the supplier of the verification of I&C application software in nuclear
system or by the licensee can be regarded as an power plants. We then discuss how model checking
important part of the evidence in the safety can support control software licensing in a way that is
demonstration” [2]. consistent with regulatory demands, using the
The common position report also presents the common position report as a reference. The I&C
consensus on the proper use of formal methods in renewal project of the Finnish nuclear power plant at
licensing of safety critical software. While certainly Loviisa is used as a case example, as we introduce the
useful and necessary, the use of formal methods is work process used by VTT in the independent model
always challenging, and each method is only limited checking service provided for the licensee Fortum.
to a specific aspect. Inappropriate use of formal

ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014 1

Antti PAKONEN, Janne VALKONEN, Sami MATINAHO, Markus HARTIKAINEN

2 Model checking of I&C software control flow. While the design of an individual
2.1 Basics of model checking elementary function block type can be proven
Model checking [3] is a formal method that can be error-free through rigorous unit testing, verification of
used to exhaustively prove that a model of a (software complex function block diagrams is often only based
of hardware) system fulfils a specified property. A on manual inspection and review. Testing and
software tool called a model checker is used to verify simulation can also be used, but the amount of input
that no state or execution of the system model violates combinations, feedback loops, and internal memory
any stated property. Typically, formalised properties makes it impossible to analyse all execution paths.
can be divided in two main types [4]: safety properties Arguments for error-free software are then supported
state that an undesired scenario never happens, while by referring to operational experience and quality of
liveness properties state that a desired scenario keeps software development practices. Model checking, on
happening. the other hand, enables exhaustive (but still quite fast)
If a model execution contrary to a property is found, it analysis.
is indicated to the user as a counterexample (error Model checking of I&C software function blocks has
trace). Analysis of the counterexample can then reveal been an active research topic for at least 15 years [8][9].
a design error in the system, but also an error in the In the nuclear industry, researchers of the Korea
model or the property formulation. It can therefore be Advanced Institute of Science and Technology
said that the method is self-repairing to a certain (KAIST) and the Konkuk and Korea universities in
degree. Seoul have applied model checking in the verification
Despite the obvious advantage of exhaustive analysis, of function block based control software of the reactor
a key challenge in model checking is the state protection system (RPS) of the APR-1400 reactor [10].
explosion problem. The number of possible model In Finland, VTT has been studying the use of model
states grows exponentially as new model inputs and checking in the nuclear domain together with the Aalto
components are introduced [3]. The problem is University under the Finnish Research Programme on
addressed using symbolic verification, based on the Nuclear Plant Safety since the year 2007 [11][12][13].
manipulation of Boolean formulas. Several tools use After early success in industrial pilot cases, the method
binary decision diagrams (BDD) to allow the was quickly put to practical use. VTT has consulted the
verification of systems whose extremely large state Finnish Radiation and Nuclear Safety Authority
spaces would make it impossible to perform explicit (STUK) on evaluating NPP I&C system designs using
enumeration [5]. Typically, the model is based on a model checking as early as 2008. When the Finnish
finite state machine (FSM), and a temporal logic Ministry of the Employment and the Economy
language is used for formulating the system launched the new nuclear safety research programme
properties. in 2010 and published the new framework plan, the use
The popular open source tool NuSMV [6] is a of formal modelling methods in nuclear power plant
BDD-based symbolic model checker for verifying automation was stated to be one of the clear success
finite state systems, using a discrete representation of stories in the previous research programme [14].
time. Properties can be specified using Linear On safety-critical domains other than nuclear, model
Temporal Logic (LTL) or Computation Tree Logic checking has also proven very useful. For a list of
(CTL) [3], and there is also limited support for the references, see, e.g., [11].
more human readable Property Specification
2.3 Challenges
Language (PSL) [7].
Many practical challenges in model checking of
2.2 Rationale function block diagrams have to do with the lack of
Function blocks are a common programming language dedicated tools for the domain. Research attempts on
for implementing safety-classified I&C systems. automating the process have focused on standard
Function block diagrams specify a clear input-output function block languages like the IEC 61131-3 [9],
mapping, making it relatively easy to understand which are hardly universally adopted, especially in the

2 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014

 Model Checking for Licensing Support in the Finnish Nuclear Industry3

nuclear domain. Error-prone manual work and ad hoc constructed in the way that different failure
solutions are therefore needed in construction of the mechanisms of the underlying I&C hardware are taken
model. A significant amount of work is also needed into account, such models easily become too complex.
for the interpretation of counterexamples [15], which While specific issues can be checked by introducing
are visualised, at best, using trend graphs. VTT has additional model variables, systemic examination of
solved these issues with in-house tool development hardware failure modes is currently unfeasible.
based on NuSMV [9] (See chapter 5.4).
Formalising the properties to be verified is also a 2.5 General limitations
challenging issue. I&C requirements based on natural Although model checking can be used to exhaustively
language can often be vague and ambiguous, whereas prove that a model of a (software) design fulfils a
model checking depends on exact formal given property, evidence gained with model checking
representation. Also, high expertise is needed to grasp is not a conclusive proof of a fault-free design. The
the details of temporal logic. One proposed solution is model is representative of the actual system only to a
to capture oft-occurring requirement constructs in certain degree (see chapter 2.6 for I&C specific
templates or patterns that map a natural language issues).
representation to corresponding formulas suited for Despite the extensive analysis, it is also difficult to
verification [16]. guarantee that all necessary properties have been
Thankfully, errors made in both system modelling and taken into account. The requirement specification
property formalisation are typically revealed through serving as a starting point might not be complete, and
“false” counterexamples that demonstrate, e.g., effort is needed from the modeller to consider all
unrealistic model behaviour, or a scenario that should necessary aspects.
not be contrary to a stated property, were the property It is also theoretically possible, although unlikely, that
correctly formulated. both the model and the properties contain errors that
will hide an actual design error and result in a false
2.4 Scope positive.
When applying model checking to the verification of a Furthermore, although model checkers such as
function block diagram (based on non-standard, I&C NuSMV are based on standard and well-known
system vendor-specific function blocks), it is important algorithms, the correctness of the model checker
to note that what is being verified is that the way the cannot be exhaustively proved.
blocks are used in the diagram does not result in
unwanted execution paths. Other aspects of the design 2.6 I&C software specific limitations
are outside the scope. Since the model is typically expressed as a type of
It is assumed that the elementary function blocks are finite state machine, model checking can only be
free of errors, which can usually be proven via rigorous effectively applied to systems that can easily be
unit testing. Since the source code for the expressed in simple, discrete terms. For I&C, this
vendor-specific function blocks is typically not means that designs containing arithmetically complex
available (black box), the modelling is based on control loops (e.g. PID or model predictive control)
functional descriptions [9]. Even if the source code is cannot be verified. When it comes to more
available, it is likely that the programming language in straightforward binary logic, however, the method
use would make model checking challenging. scales very well. Analysis times for FSMs with as
The code that is actually compiled and run on the many as 1040 states are still in the range of minutes, if
hardware platform is based on lower-level languages not seconds. Simple math is also not a problem for
such as C. It is assumed that the code generation will tools such as NuSMV. Problems can arise from, e.g.,
operate flawlessly, since any faults introduced at this excessive use of feedback, or function blocks storing
point cannot be considered in model checking. number data into memory, leading to state explosion.
Fault tolerance is an important aspect of I&C software When modelling function block diagrams, some
design in NPPs. While theoretically, the model can be aspects may require specific attention. For timing

ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014 3

Antti PAKONEN, Janne VALKONEN, Sami MATINAHO, Markus HARTIKAINEN

blocks, the modeller needs to assign a certain number the task force’s position on issues of mutual interest
of model “cycles” to represent the length of the delay. [2].
Large values can easily lead to state explosion [10], In the following, we individually address the common
while small values might prevent relevant execution positions on the use of formal methods, as stated in
paths. section 1.9 of the report.
Analogue signal values must also be discretised, since
NuSMV can only handle integer data. For analogue 3.1 Common position 1.9.3.1
inputs, the modeller should limit the possible values to “No credit can be taken in a safety demonstration for
avoid state explosion while, again, allowing for all the use “per se” of a formal method without due
relevant model executions. Some scaling back and consideration being given to the specific evidence
forth of signal values is also sometimes necessary to brought in by this use, and to its contribution to the
properly model simple arithmetic. safety demonstration of the system.”
(There exists model checkers other than NuSMV that A design error revealed though model checking is a
support, e.g., real variables or continuous time, but non-disputable piece of evidence. Concluding the
VTT’s experience has shown that such tools may not value of a verification task that does not reveal any
be as efficient for the verification of function block errors is less simple. Careful analysis of the inherent
diagrams [13].) limitations is recommended (see chapters 2.5 and 2.6).
It is noteworthy that it may be tempting to construct a
closed loop model. By modelling also aspects of the 3.2 Common position 1.9.3.2
environment (dynamics of the controlled plant), the “Whatever (combination of) method(s) and
state space can be reduced. Without an environment notation(s) is used to describe the system
model, the analyst may also have to spend extra time requirements, this description shall be based on a
processing counterexamples that are not possible in the definition of the system boundaries and on a
context of the controlled process. The downside is that systematic capturing of the functional and
inaccuracy in the environment model may result in non-functional properties of the system. These
actual design errors ending up undetected. From a boundaries and properties shall be explicitly,
safety point of view, open loop analysis is more unambiguously and accurately documented.”
reliable. The basic idea of model checking makes it absolutely
necessary to explicitly and accurately define both the
3 Regulatory demands on the use of system requirements and the model boundaries.
As all verified requirements must be stated in terms of
formal methods
system model inputs, outputs, and internal variables, it
At the request of the Western European Nuclear may be difficult to systematically capture
Regulators’ Association (WENRA), a task force non-functional variables that cannot be accurately
consisting of nuclear regulators and authorised specified in those terms.
technical support organisations of Finland, Sweden,
Germany, UK, Spain and Belgium has identified 3.3 Common position 1.9.3.3
common technical positions on licensing issues “Selection of methods and tools with respect to their
regarding the use of computer based systems in the intended application for formal descriptions and
implementation of safety functions in NPPs. Their mathematical analysis shall be justified. The
report [2] is intended to guide the regulators’ national justification shall be in accordance with the safety
policies on technical viewpoints, among other uses. demonstration.”
The U.S. Nuclear Regulatory Commission (NRC) has The use of model checking is justified by the benefits
also participated in the meetings of the task force. over more conventional verification methods, as well
Although the NRC does not officially endorse the as the applicability of the method for analysing
report, it plans to continue informing the task force of function block diagrams (consisting mostly of binary
NRC’s technical positions, and informing the NRC of logic). See chapter 2.2.

4 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014

 Model Checking for Licensing Support in the Finnish Nuclear Industry5

3.4 Common position 1.9.3.4 Due to the strict, specific formalism of temporal logic
“There shall be objective evidence of a successful use languages, it is difficult to find prior analysis that
of the formalisms and methods used in an application would support validation. Nevertheless, most
with comparable properties.” semantic errors in requirement formalisation will be
Model checking has been used in the verification of revealed through “false” counterexamples. Such a
NPP I&C software in the Republic of Korea [10]. The counterexample can, for example, demonstrate a
method has also been successfully used for software scenario that would not be contrary to a correctly
verification in other safety-critical domains such as formalised property.
aviation or space. See chapter 2.2.
4 LARA: Loviisa NPP automation
3.5 Common position 1.9.3.5
renewal project
“The procedures and constraints for using the formal
methods and tools shall be documented.” Situated on the southern coast of Finland, and
See chapters 5.3, 2.5, and 2.6. operated by the power company Fortum, the Loviisa
NPP includes two pressurised water reactors of the
3.6 Common position 1.9.3.6 type VVER-440, with a joint capacity of 976 MW.
“Any limitations of the formal descriptions, methods Loviisa 1 started operation in 1977 and Loviisa 2 in
and tools used, and resulting descriptions, shall be 1980. In 2012, Loviisa produced 7.61 TWh of
explicitly documented. For example, any limitation in electricity. Key figures measuring plant safety and
describing and reasoning about non-functional performance reliability have been good throughout the
requirements, use of resources, or time critical events operational history.
shall be stated.” The old I&C systems at Loviisa consist of Russian
See chapters 2.5 for limitations in general and chapter and German technology from the 1970s. While the
2.6 for limitations in the context of NPP I&C ageing of the systems had not yet produced any
software. significant problems, concerns over the availability of
As all verified requirements must be stated in terms of spare parts and maintenance led to a decision in the
system model inputs, outputs, and internal variables, it early 2000s to start preparing the automation renewal
may be difficult to systematically capture project (LARA).
non-functional variables that cannot be accurately The new systems were to be delivered by a
specified in those terms. consortium of AREVA and Siemens, with safety I&C
based on AREVA platforms such as TELEPERM XS,
3.7 Common position 1.9.3.7 and operational I&C based on platforms of Siemens.
“The formalisms and the methods used for specifying However, in May 2014, Fortum decided to
the system requirements shall be unambiguous and discontinue the LARA project due to delays in the
understandable by all technical staff involved.” project implementation. At the same time, Fortum
In the verification service that VTT provides, the signed an agreement with Rolls-Royce regarding
formalisation of the requirements into temporal logic modernisation of the Loviisa Plant. Rolls-Royce will
is a task performed by VTT. Nevertheless, VTT deliver all the required I&C systems, with the Finnish
experts have been educating Fortum staff on company Metso acting as a sub-supplier of non-safety
formalisms such as LTL and CTL. systems. The aim is to implement the project by the
end of 2018.
3.8 Common position 1.9.3.8
“The formal description of the system requirements 5 Use of model checking in LARA
shall be validated against the results of a prior plant 5.1 Task description
safety analysis, and of other relevant analyses at the Model checking was used to verify the correct
plant level.” functionality of application I&C software in LARA
subsystems. Verification was performed by VTT as an

ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014 5

Antti PAKONEN, Janne VALKONEN, Sami MATINAHO, Markus HARTIKAINEN

independent, third-party verification service block library modelling is the basis of all later models,
commissioned by Fortum. Analysis was targeted at the specific care must be put into writing the code. The
selected I&C functions of each reviewed system. model checker is used to verify that the function block
The verification task was parallel with module level models are correct.
system tests carried out by the vendor.
Independently of the vendor, Fortum decided the I&C
functions to be verified. VTT experts provided
feedback and suggestions concerning which functions
should be included. Fortum then supplied the
necessary material (design sheets, requirement
specifications, and other relevant documentation) to
VTT.
VTT performed model checking, and reported any
findings to Fortum. Fortum then analysed the findings
– in particular assessing the safety relevance – and
informed the vendor if necessary.
Finally, VTT was to prepare detailed verification
reports that Fortum could have then submitted to the
Finnish regulator (STUK) as part of LARA subsystem
licensing. However, Fortum decided to discontinue
the LARA project, and start a new modernisation
project with Rolls-Royce. Fortum plans to continue
using model checking in the new project.

5.2 Scope of verification

Verification has covered I&C functions of several
LARA subsystems, including reactor protection,
preventive protection, and emergency diesel generator
functions. The analysed systems belong to the Finnish
safety classes SC2 (the highest safety class where
digital I&C can be applied) and SC3.
Fig 1. The work process for model checking in LARA
5.3 Work process
Based on previous experience on model checking NPP An efficient approach to model checking function
software, VTT has identified a set of practices and block based systems is to start by modelling a library
methods to efficiently and reliably carry out the of the elementary function blocks [9]. The modular
verification process. In Fig. 1, the work process is approach makes it very straightforward to construct the
described in a series of work phases, some of which models of different I&C functions. Since the function
include Fortum’s input. To ensure reliable results, at block library modelling is the basis of all later models,
least two VTT’s experts will be independently specific care must be put into writing the code. The
involved in all the work phases, so that the work results model checker is used to verify that the function block
of each expert are reviewed and inspected by another. models are correct.
An efficient approach to model checking function For the system being analysed, the next step is to select
block based systems is to start by modelling a library the functions for verification. Verification of all the
of the elementary function blocks [9]. The modular functions of each system is not feasible, since analysis
approach makes it very straightforward to construct the of complex control loops is not possible (see section
models of different I&C functions. Since the function 2.6), and some of the functions are so simple that

6 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014

 Model Checking for Licensing Support in the Finnish Nuclear Industry7

manual inspection is sufficient. Due to project In any case, the final result documentation – a
constraints, the analysis should also focus on functions verification report – will identify the method and tools
directly relevant to safety. The scope of verification is used in the analysis, the target system, the list of
decided by Fortum, with VTT experts providing documents used in constructing the model and
comments and recommendations. identifying the requirements, and the list of
I&C function modelling begins with the careful requirements that were verified.
specification of the model boundary. Specifically, the Discussion on the verification results will then take
modeller must consider incorporating “upstream” (i.e. place between VTT and Fortum. Particularly, it is up to
input) processing logic where necessary. Fortum to assess the safety significance of potential
The function modelling task is rather straightforward, findings. It is also possible that careful analysis of plant
with the modeller connecting “invoked objects” of the and I&C system characteristics will show that a
elementary function block “classes” in a way that reported issue is irrelevant.
reproduces the connections from the original diagrams. It should be noted that the work process is iterative. If a
VTT tools provide a graphical UI for diagram editing “false” counterexample reveals an error or an omission
(see chapter 5.4). Still, specific care is needed for, e.g., in the specified models or the requirement
proper handling of timing, and discretisation of formalisation, the modeller may have to revisit earlier
analogue signals (see chapter 2.6). work phases. Any modifications will again be
The next step is to identify the requirements for the reviewed by another expert.
modelled functions. The documentation that serves as
a starting point can be a textual requirement 5.4 Tools
specification document, or other kind of functional The open source model checker NuSMV [6] is used in
description. However, since model checking calls for the analysis.
strict formalisation, there is often a need to further VTT has developed a dedicated tool to support the
elaborate the requirements. Elaboration is a joint effort model checking of function block diagrams, based on
between VTT and Fortum. In a renewal project, it is the the open source modelling and simulation platform
licensee that has the best knowledge of plant Simantics [9][17]. The tool allows the user to specify
characteristics and functional requirements. As the the model with a graphical user interface, where
requirements need to be effectively communicated function blocks can be added in drag-and-drop fashion
among Fortum experts – not only I&C but also process and wired together. The resulting diagrams can be
engineers – informal textual representation can be used encapsulated within composite function block types,
at this point. and reused on a higher hierarchical level. The use of
At least two VTT experts will work in parallel on composite blocks is especially useful in the nuclear
property formalisation. LTL, CTL and PSL are used. context, where similar logic is repeated on parallel
The way that the checked properties are formalised can subsystems (redundancy principle). Manual coding is
sometimes be person-dependent, and a good way to only needed when first constructing the library of
ensure that different aspects of requirements are all elementary function block types. When formalising
taken into account is to have different experts working the requirements, references to exact model signals
independently. can be copied from the graphical view. The model can
Verification with NuSMV is also performed then be transformed into the input language used by
concurrently by at least two VTT experts. NuSMV, and verified.
If the model checker produces a counterexample that, A key advantage of the tool is that the counter-
upon closed inspection of the original design examples output by NuSMV are visualised using an
documents, indicates a potential design issue, another animation that highlights how model signal values
VTT expert will first ensure that the result can be change over time. The user is able to freely browse
duplicated. When confirmed, the issue is reported to the animation back and forth. Binary signal values are
Fortum in sufficient detail, so that Fortum experts can shown by changing the colour and thickness of the
reproduce and analyse the scenario. block connection wire. Other signal values are shown

ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014 7

Antti PAKONEN, Janne VALKONEN, Sami MATINAHO, Markus HARTIKAINEN

Fig 2. In VTT’s tools, function block diagrams are modelled with a graphical UI. The model is transformed into the input
language of NuSMV, the model checker is run, and the counterexamples are visualised with an animation.

with monitors attached to the input gates of each can argue that model checking is already a well-
block. established and integral part of software verification
Fig. 2 shows one frame (or time step) from a processes, used by both a licensee and the regulator.
counterexample animation. The example used for the Independent verification of software-based systems
figure is based on the stepwise shutdown logic commissioned by the either the licensee or the vendor
introduced in [12]. is required by several European regulators, among
them the Finnish STUK. Accordingly, VTT provides a
5.5 Results third-party service for Fortum, using model checking
In Fortum’s view, model checking has proved to be a to verify I&C application software in the Loviisa NPP
rigorous method for verifying complex I&C functions. automation renewal project.
The key benefit is exhaustive verification, covering all The obvious advantage of model checking is
possible input signal sequences. This means that also exhaustive analysis, which makes it possible to find
events occurring within very small time windows can errors that more conventional verification methods
be analysed, which is challenging when using more easily miss. Still, proper use of formal methods always
traditional verification methods. Furthermore, the calls for careful consideration of the procedures and
mere act of constructing the model (using the constraints involved, a point also emphasised by
precision required by the method) can reveal errors European regulators. In the I&C domain, the inherent
and inconsistencies in design documentation that are limitations mean that model checking is only a
easily missed upon manual review. supplementary (although valuable) V&V method, and
cannot replace, e.g., thorough testing procedures.
6 Conclusions Despite the benefits, model checking is far from
Model checking has been proven a valuable mainstream use when it comes to I&C. One reason is
verification tool in different safety critical domains, the manual work needed in constructing the model and
nuclear included. In the Finnish nuclear industry, we updating the model when the system design evolves.

8 ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014

 Model Checking for Licensing Support in the Finnish Nuclear Industry9

Domain specific tools – such as developed at VTT on A. Tacchella, “NuSMV 2: An OpenSource Tool for
Symbolic Model Checking,” International
the Simantics platform – aim at eventually integrating
Conference on Computer-Aided Verification (CAV
the method with existing I&C software development 2002). Copenhagen, Denmark, July 27~31, 2002.
tools. Currently, graphical tools make it easy to work [7] IEC/IEEE 2012. IEC 62531:2012, IEEE Std. 1850,
with the models, but direct model translation is still an Property Specification Language (PSL), June 2012.
[8] O. Rossi, P. Schnoebelen, “Formal Modeling of
issue for future work. Similarly, tools are needed to Timed Function Blocks for the Automatic
ease the formalisation of system properties. Verification of Ladder Diagram Programs,” The
Another reason why model checking is not universally 4th International Conference on Automation of
adopted is that generally, I&C engineers, end users, Mixed Processes (ADPM 2000), Dortmund,
Germany, Sep 18~19, 2000.
and regulators are simply unaware of the method. [9] A. Pakonen, T. Mätäsniemi, J. Lahtinen, T.
In the nuclear domain, model checking can be utilised Karhela, ”A Toolset for Model Checking of PLC
by the licensee, or the vendor, as well as the regulatory Software,” Proceedings of the 18th IEEE
International Conference on Emerging
body. Naturally, the earlier design issues can be
Technologies and Factory Automation (ETFA
identified, the better. In the case of a renewal project, 2013), Cagliari, Italy, Sep. 10~13, 2013.
the best knowledge of the plant characteristics and [10] J. Yoo, S. Cha, E. Jee, “Verification of PLC
control system requirements lies with the licensee. As Programs Written in FBD with VIS,” Nuclear
Engineering and Technology, Vol. 41, pp. 79-90,
the method calls for strict formalisation of functional 2009.
properties, cooperation between Fortum and VTT on [11] J. Lahtinen, J. Valkonen, K. Björkman, J. Frits, I.
requirement elicitation has been one key to successful Niemelä, K. Heljanko, “Model checking of safety
application. critical software in the nuclear engineering domain,”
Reliability Engineering and System Safety.
Elsevier. Vol. 105, pp. 104-113, 2012.
Acknowledgement [12] K. Björkman, J. Frits, J. Valkonen, K. Heljanko, I.
Niemelä, “Model-Based Analysis of a Stepwise
To a great extent, VTT’s research on model checking Shutdown Logic – MODSAFE 2008 Work Report,”
has been funded by the Finnish Research Programme VTT Working Papers 115, VTT, 2009.
on Nuclear Power Plant Safety 2011-2014 [13] J. Lahtinen, K. Björkman, J. Valkonen, J. Frits, I.
(SAFIR2014). Niemelä, ”Analysis of an emergency diesel
generator control system by compositional model
checking – MODSAFE 2010 Work Report,” VTT
References Working Papers 156, VTT, 2010.
[14] National Nuclear Power Plant Safety Research
2011-2014, SAFIR2014 Framework Plan, The
[1] Guide YVL B.1, Safety Design of a NPP, draft L5, Ministry of the Employment and the Economy,
31.5.2013, STUK 2013. 2010.
[2] Licensing of safety critical software for nuclear [15] E. Jee, S. Jeon, S. Cha, K. Koh, J. Yoo, G. Park, P.
reactors, Common position of seven European Seong, “FBDVerifier: Interactive and Visual
nuclear regulators and authorised technical support Analysis of Counter-Example in Formal
organisations, Revision 2013, BEL V, BfS, CSN, Verification of Function Block Diagram,” Journal
ISTec, ONR, SSM & STUK 2013. of Research and Practice in Information
[3] E. M. Clarke, Jr., O. Grumberg, D. A. Peled, Model Technology, Vol. 42, pp. 171-188, 2010.
Checking, The MIT Press, 1999. [16] T. Tommila, A. Pakonen, “Controlled natural
[4] L. Lamport, “Proving the correctness of language requirements in the design and analysis of
multiprocess programs,” IEEE Transactions on safety critical I&C systems,” Research report
Software Engineering. Vol. 3, pp. 125-143, 1977. VTT-R-01067-14, VTT, 2014.
[5] J. Burch, E. Clarke, K. McMillan, D. Dill, L. [17] T. Karhela, A. Villberg, H. Niemistö, “Open
Hwang, “Symbolic Model Checking: 1020 States Ontology-Based Integration Platform for Modeling
and Beyond,” Information and Computation, Vol. and Simulation in Engineering,” International
98, pp. 142-170, 1992. Journal of Modeling, Simulation, and Scientific
[6] A. Cimatti, E. M. Clarke, E. Giunchiglia, F. Computing, Vol. 3, 2012.
Giunchiglia, M. Pistore, M. Roveri, R. Sebastiani,

ISOFIC/ISSNP 2014, Jeju, Korea, August 24~28, 2014 9