n - システム検証研究センター

算譜科学研究速報
Programming Science Technical Report
AIST-PS-2008-002
第四回
システム検証の科学技術シンポジウム
講演論文集
Proceedings of the 4th Symposium
on Science and Technology for System Verification
会 期 2007年11月5日
（月）−7日
（水）
November 5-7, 2007
会 場 名古屋大学 野依記念学術交流館 カンファレンスホール
Nagoya University Noyori Conference Hall
■主催 ●日本ソフトウェア科学会ディペンダブルシステム研究会
■共催 ●産業技術総合研究所システム検証研究センター
●名古屋大学大学院情報科学研究科
■協賛 ●科学技術振興機構
●情報処理学会
●電子情報通信学会
●ネオクラスター推進共同体（事務局：財団法人関西情報・産業活性化センター）
●情報処理推進機構ソフトウェアエンジニアリングセンター
●国際数理科学協会
●日本応用数理学会
●組込みソフト産業推進会議
●宇宙航空研究開発機構情報・計算工学センター
●NPO 法人 TOPPERS プロジェクト
●JasPar
独立行政法人
産業技術総合研究所
システム検証研究センター
Research Center for
Verification and Semantics
目　次
●函館ワークショップ特別講演●
Comparison of the Expressive Power of Language-based Access Control Models・・・・・・・・・・
1
関 浩之（奈良先端科学技術大学院大学 ), 高田喜朗（高知工科大学）
●一般講演●
モデルベース開発におけるテスト自動化フレームワーク ・ ・・・・・・・・・・・・・・・・・・・
6
黒岩正司 ( 富士設備工業株式会社 )
システム検証の事例報告集の作成・ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 16
渡邊 宏，奥野康二，高井利憲（産業技術総合研究所）
An Algorithm for Bounded Multi-Valued Model Checking・ ・・・・・・・・・・・・・・・・・・・ 22
Jefferson O. Andrade, Yukiyoshi Kameyama（University of Tsukuba ）
環境ドライバを用いたモデル検査による検証事例 ・ ・・・・・・・・・・・・・・・・・・・・・・ 32
高井利憲 ( 産業技術総合研究所 ), 古橋隆宏 ( 矢崎総業株式会社 ), 尾崎弘幸 , 大崎人士 ( 産業技術総合研究所 )
n 点通過テストのためのモデル検査技法・ ・・・・・・・・・・・・・・・・・・・・・・・・・・ 43
小池憲史 ( 矢崎総業株式会社 )，大崎人士 ( 産業技術総合研究所 )
Real-Time Maude によるモデル検査事例と検査式およびモデルの修正方法 ・ ・・・・・・・・・・・ 53
中野昌弘 , 高井利憲 ( 産業技術総合研究所 )
アセンブラプログラムのモデル検査によるバグ解析事例
・ ・・・・・・・・・・・・・・・・・・ 65
吉田　聡 , 高井利憲 ( 産業技術総合研究所 )
記号モデル検査による自己安定アルゴリズムの安定時間の計測 ・・・・・・・・・・・・・・・・・ 71
木本雅博 , 土屋達弘 , 菊野 亨（大阪大学大学院）
リアクティブシステム仕様の強充足可能性判定問題の計算量について・ ・・・・・・・・・・・・・ 81
島川昌也 , 萩原茂樹 , 米崎直樹（東京工業大学）
オーバーラップ制御の設計と検証 ・ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 90
藤倉俊幸 ( イーソル株式会社 )
●システム検証研究センター研究紹介●
機能安全のためのソフトウェア認証制度普及に向けた取り組みの紹介 ・ ・・・・・・・・・・・・・ 94
長谷部 浩二（産業技術総合研究所）
研修コース研究開発・ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 97
西原秀明（産業技術総合研究所）
MLAT
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 99
田辺良則（産業技術総合研究所）
AgdaIVE の実用問題への適用・ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 101
加藤紀夫（産業技術総合研究所）
図示記法・ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 104
吉田　聡（産業技術総合研究所）, 小池憲史（矢崎総業株式会社）, 竹内　泉 , 大崎人士（産業技術総合研究所）
業務システム開発検証ツール・ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 107
髙木　理（産業技術総合研究所）
第四回システム検証の科学技術シンポジウム
1
Comparison of the Expressive Power of
Language-based Access Controls
Hiroyuki Seki∗1 and Yoshiaki Takata∗2
This paper compares the expressive power of five language-based access control models. In particular, we
show that the expressive power of HBAC (Abadi and Fournet’s history-based access control) is greater than
the other four subclasses under the weak trace equivalence while the expressive power of HBAC is greater
than neither R-SI (stack inspection based on regular patterns) nor SHA (Fong’s shallow history automata)
under the strong trace equivalence.
depend on all the methods executed so far. Verification of HBAC programs are also discussed in
[2] [3] [10]. Meanwhile, Schneider [9] defines security
automata, and later Fong [5] defines shallow history
automata as a subclass of finite-state security automata. However, the relations among the control
models mentioned so far have not been clarified.
In this paper, we first define five of the existing control mechanisms in a simple and uniform
framework based on control flow graph. Next, we
introduce weak and strong trace equivalence relations among programs, and compare the expressive
power of the five subclasses of programs. In particular, we show that the expressive power of HBAC
is greater than the other four subclasses under the
weak trace equivalence. It is also shown that the
expressive power of HBAC is greater than neither
R-SI (stack inspection based on regular patterns)
nor SHA (Fong’s shallow history automata) under
the strong trace equivalence.
1 Introduction
To protect secure information against malicious
access, it is desirable to incorporate a runtime access control mechanism in a host language. This
approach is called language-based access control,
and a few models have been proposed [1] [5] [6] [9].
A common feature of these models is that the history of execution such as method invocation and
resource access is used for access control. Stack inspection provided in JVM [6] is one of the bestknown such control mechanisms. A set of permissions is assigned statically to each method and
when the control reaches a statement for checking
permissions, it is examined whether every method
onto the runtime stack has the permissions specified by the statement. Stack inspection has been
extended in several ways. For example, stack
pattern can be specified by LTL formula in [7]
and regular language in [4] [8]. Automatic verification methods for a program with stack inspection are also discussed in [4] [7] [8]. Abadi and Fournet [1] pointed out the problem of stack inspection, which completely cancels the effect of the finished method execution. They proposed a new control mechanism called history-based access control
(HBAC). In HBAC, current permissions are modified each time a method is invoked, and they may
2 Definitions
2. 1 HBAC program
An HBAC program is a tuple π = (Mhd , f0 , {Gf |
f ∈ Mhd }, PRM ) where M hd is a finite set of
method names, f0 ∈ Mhd is the main method
name, Gf (f ∈ Mhd ) is a control flow graph of f defined below and PRM is a finite set of permissions.
Gf is a directed graph (NO f , TG f , IS f , IT f , SP f )
where NO f is a finite set of nodes, TG f ⊆ NO f ×
NO f is a set of transfer edges, IS f : NO f →
アクセス制御つき言語の表現能力の比較
∗1
関 浩之, Nara Institute of Science and Technology
∗2
高田 喜朗, Kochi University of Technology
5
第四回システム検証の科学技術シンポジウム
2
コンピュータソフトウェア
{call g [PG , PA ] | g ∈ Mhd , PG ⊆ SP f , PA ⊆ SP f } ∪
{check [P ] | P ⊆ PRM } ∪ {return, nop} is the labeling function for nodes, IT f ∈ NO f is the initial
node, which represents the entry point of method
f , and SP f ⊆ PRM is a subset of permissions
assigned to f before runtime (static permissions).
NO f is divided into four subsets by IS f as follows:
• IS f (n) = call g [PG , PA ]. Node n is a call node
that represents a call to method g. Parameters
PG and PA are called grant permissions and
accept permissions, respectively.
• IS f (n) = return. Node n is a return node that
represents a return to the caller method.
• IS f (n) = check [P ] where P ⊆ PRM . Node n
is a check node that represents a test for the
current permissions. For p ∈ PRM , check [{p}]
is abbreviated as check [p].
• IS f (n) = nop. Node n is a nop node with no
effect.
In the figures, a dotted arrow denotes a transfer
edge and a solid arrow connects between a call node
and the initial node of the callee method. Also, a
method is surrounded by a rectangle and a set beside the rectangle denotes the static permissions of
the method.
A state of π is a pair hn, Ci of a node n ∈ NO f
and a subset of permissions C ⊆ PRM . A configuration of π is a finite sequence of states, which
is also called a stack. The concatenation of state
sequences ξ1 and ξ2 is denoted as ξ1 : ξ2 . The
semantics of an HBAC program is defined by the
transition relation → over the set of configurations,
which is the least relation satisfying the following
rules.
IS (n) = call g [PG , PA ]
hn, Ci : ξ → hIT g , (C ∪ PG ) ∩ SP g i : hn, Ci : ξ
IS (m0 ) = return, IS (n) = call g [PG , PA ], n → n0
hm0 , C 0 i : hn, Ci : ξ → hn0 , C ∩ (C 0 ∪ PA )i : ξ
IS (n) = check [P ], P ⊆ C, n → n0
hn, Ci : ξ → hn0 , Ci : ξ
IS (n) = nop, n → n0
hn, Ci : ξ → hn0 , Ci : ξ
The rule of nop for the other program subclasses
in the following subsections is the same as above
and will be omitted below. For a configuration
hn1 , C1 i : . . . : hnk , Ck i, the stack top is hn1 , C1 i
where n1 and C1 are called the current program
point and the current permissions of the configura∪
tion, respectively. Let NO = f ∈Mhd NO f . The
main {pA,pB}
n0
call
call
n1A
A {pA}
n1B
check[pA]
m0A
call n2A
m1A
Figure1
B {pB}
check[pB]
m0B
n3
n2B
call
m1B
An HBAC program
trace set of π is defined as [[π]] = {n0 n1 . . . nk |
n0 = IT f0 , C0 = SP f0 , ξ0 = ε, ∃C1 , . . . , Ck ⊆
PRM , ∃ξ1 , . . . , ξk ∈ (NO×2PRM )∗ , hni , Ci i : ξi →
hni+1 , Ci+1 i : ξi+1 for 0 ≤ i < k} , where ε denotes
the empty sequence. For a set S of sequences, let
prefix(S) denote the set of all nonempty prefixes of
sequences in S.
Example 1 Chinese wall policy is a policy such
that a user has access permission to any resources,
but once the user has accessed one of the resources,
(s)he loses access permission to the resources belonging to competing parties. A simplified Chinese wall policy can be represented by program π
in Fig 1. If n1A calls A, the current permissions
lose permission pB . Thus, if n2B calls B afterward, the check at m0B fails. The same situation
occurs when B and A are called in this order. In
fact, [[π]] = prefix(
n0 n1A m0A m1A (n2A m0A m1A n3 + n2B m0B )
+n0 n1B m0B m1B (n2B m0B m1B n3 + n2A m0A )),
where the argument of ‘prefix’ is specified by a regular expression and + denotes the union operator.
2
2. 2 JVM and R-SI programs
A program with Java stack inspection (abbreviated as JVM program) has a form π =
(Mhd , f0 , {Gf | f ∈ Mhd }, PRM , PRV ) similar to an HBAC program where Gf
=
(NO f , TG f , IS f , IT f , SP f ) where each component
of Gf is the same as that of an HBAC program,
except that label IS f (n) of each call node n is simply call g (g ∈ Mhd ) without PG or PA , and a set of
∪
privileged nodes PRV ⊆ f NO f is specified. The
semantics of π is defined as follows.
IS (n) = call g , n 6∈ PRV
hn, Ci : ξ → hIT g , C ∩ SP g i : hn, Ci : ξ
6
第四回システム検証の科学技術シンポジウム
Vol. 0 No. 0
IS (n) = call g , n ∈ PRV ∩ NO f
hn, Ci : ξ → hIT g , SP f ∩ SP g i : hn, Ci : ξ
IS (m0 ) = return, n → n0
hm0 , C 0 i : hn, Ci : ξ → hn0 , Ci : ξ
A regular stack inspection (R-SI) program π =
(Mhd , f0 , {Gf | f ∈ Mhd }) is introduced in [4] [8]
as an extension of a JVM program where Gf =
(NO f , TG f , IS f , IT f ). Its semantics is given by
the following rules.
IS (n) = call g
n : ξ → IT g : n : ξ
IS (m0 ) = return, n → n0
m 0 : n : ξ → n0 : ξ
IS (n) = check [R], n : ξ ∈ R, n → n0
n : ξ → n0 : ξ
where R ⊆ (NO)∗ is a regular language.
2007
3
JVM).
(S2) Delete grant permissions and accept permissions from a call node (if α=HBAC); and
(S3) Delete the designation of a privileged node
(if α=JVM).
A method d is a dummy method with call to a
method g if d consists of only two nodes, say n1
and n2 with IT d = n1 , IS d (n1 ) = call g (possibly
with grant/accept permissions), IS d (n2 ) = return,
n1 → n2 . An α program π is a weak α extension
of a basic program π0 if π0 is obtained from π by
repeating the above operations and the following
operations finite times.
(W1) Delete a dummy method d with call to a
method g, and change the label IS f (n) = call d
of each node n to IS f (n) = call g .
(W2) If there are nodes n1 , n2 , n and n0 such
that n1 → n, n → n2 , n1 → n0 , n0 → n2 with
IS f (n) = IS f (n0 ) = call g , then delete node n0
and transfer edges n1 → n0 , n0 → n2 .
Let nc be a homomorphism over the set of nodes
defined by nc(n) = n for a call or return node n and
nc(n) = ε for a check or nop node n. Exception: for
a call node n0 deleted in (W2), nc(n0 ) = n. Let π1
and π2 be strong (rsp.weak) extensions of a basic
program π0 . We say that π1 is strongly (rsp.weakly)
trace equivalent to π2 if nc([[π1 ]]) = nc([[π2 ]]).
Let us denote the class of α programs by α. For
S
classes of programs α and β, we write α −→ β (rsp.
W
α −→ β) if for an arbitrary α program π1 there is
a β program π2 strongly (rsp.weakly) trace equivalent to π1 (we say that π1 can be simulated by
S
W
π2 ). If α −→ β (rsp. α −→ β), we also say that α
can be simulated by β under the strong (rsp. weak)
S
W
trace equivalence. Both of −→ and −→ are reflexive
S
W
and transitive. We write α −→
6
β (rsp. α −→
6
β)
S
W
if α −→ β (rsp. α −→ β) does not hold. Note
S
W
that α −→ β implies α −→ β but the converse
S
does not always hold. By definition, SHA−→FS
W
SA. It is known that JVM−→R-SI [8], R-SI6−→SHA,
W
S
SHA6−→R-SI [5] and JVM−→HBAC [10].
W
W
Theorem 1 R-SI −→ JVM and F-SA −→ HBAC.
W
Proof Sketch: (R-SI −→ JVM) Let π be a given RSI program. For simplicity, assume that there is
only one regular language R such that check [R] is
used as a node label in π. Let N = (NO, S, s0 , σ) be
a deterministic finite automaton such that L(N ) =
R. We can transform π to a JVM program π 0
2. 3 F-SA and SHA Programs
A finite security automaton (F-SA) [9] is just a
deterministic finite automaton M = (Σ, Q, q0 , δ)
without final states where Σ is a finite set of input symbols, Q is a finite set of states, q0 ∈ Q is
the initial state and δ is a state transition function, which is a partial function from Q × Σ to
Q. We write δ(q, a) = ⊥ if δ(q, a) is undefined.
A shallow history automaton (SHA) [5] is an FSA M = (Σ, Q, q0 , δ) such that Q = 2Σ and if
δ(q, a) 6= ⊥ then δ(q, a) = q ∪ {a}.
An F-SA program is a tuple (Mhd , f0 , {Gf |
f ∈ Mhd }, M ) without permissions or check nodes
where Gf = (NO f , TG f , IS f , IT f ) (f ∈ Mhd ) and
M = (Σ, Q, q0 , δ) is an F-SA such that Σ = {f, f |
f ∈ Mhd }. The semantics of an F-SA is defined as
follows.
IS (n) = call g , δ(q, g) 6= ⊥
hn : ξ, qi → hIT g : n : ξ, δ(q, g)i
IS (m0 ) = return, m0 ∈ NO g , n → n0 , δ(q, g) 6= ⊥
hm0 : n : ξ, qi → hn0 : ξ, δ(q, g)i
3 Expressive Power
A program without check nodes, permissions or
privileged nodes is called a basic program. Let
α ∈ {HBAC, R-SI, JVM, F-SA, SHA}. An α program π is a strong α extension of a basic program
π0 if π0 is obtained from π by repeating the following operations finite times:
(S1) For a check node n and transfer edges
n1 → n, n → n2 , delete n and replace these
two edges with n1 → n2 (if α=HBAC, R-SI or
7
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
4
f
g
f
call
n1
S
d {s2}
call
n0
check[s1] l1
n0
m
g
S
f
call
...
n2
call
l2
return
n2
R-SI with σ(s1,g)=s2
f
n1
f
return n2
transition
function
l1:privileged
JVM
W
F-SA −→
6
SHA
Figure4
Figure2
f
f
nop
n0
m
W
R-SI −→ JVM
f
nop
f
n0 nop
n0
g
check[m0n2]
m0
m1 return
call n1
n1call
n2
call
n2 check[n2(n1n1)*]
return n3
n3return
S
R-SI −→
6
HBAC
Figure5
Figure3
W
R-SI −→
6
F-SA
f
nop
weakly trace equivalent to π as follows: The permisCG
sion set of π 0 is defined as S; Each call edge n → m
in π is transformed into a fragment of π 0 as shown
in Fig 2 where s1 , s2 ∈ S satisfy σ(s1 , g) = s2 . We
can show that the current permission of a configuration of π 0 is {s} for some s ∈ S if and only if
σ(s0 , ξ) = s where ξ is the corresponding configuration of π.
W
F-SA −→ HBAC can be shown in a similar way. 2
W
Corollary 1 R-SI −→ HBAC.
S
Proof: By Theorem 1 and JVM −→ HBAC [10]. 2
W
Theorem 2 R-SI −→
6
F-SA.
Proof Sketch: The R-SI program in Fig 3 cannot be simulated by any F-SA program. Note that
when the control reaches m0 , the configuration is
m0 n2 n∗1 . Thus, the check at m0 succeeds if and
only if g has been called just before the last return
from f , which cannot be simulated by any F-SA. 2
W
Theorem 3 F-SA −→
6
SHA.
Proof Sketch: In the program shown in Fig 4, a
return from f is permitted only when f has been
called an odd number of times. This program cannot be simulated by any SHA program due to the
monotonicity: s ⊆ δ(s, a) whenever δ(s, a) 6= ⊥. 2
Some of the positive results under the weak trace
equivalence do not longer hold under the strong
trace equivalence.
S
S
Theorem 4 R-SI6−→HBAC and SHA6−→HBAC.
S
Proof Sketch: (R-SI6−→HBAC) The R-SI program
in Fig 5 cannot be simulated by any HBAC program. An HBAC program cannot distinguish be-
n0
g
call
call n2
m
n1
return
n3return
f
{ }
f
{f}
f
g
{f,g}
Figure6
g
f
{f,f}
transition
function
f
{f,g,g} f {f,f,g,g}
S
SHA −→
6
HBAC
tween even and odd numbers since there is only one
method f , no dummy method can be inserted and
hence the current permissions cannot be altered.
S
(SHA6−→HBAC) In the SHA program in Fig 6, a
call to g is permitted only when a return from f has
never occurred. This program cannot be simulated
by any HBAC program by a reason similar to the
S
case of R-SI6−→HBAC.
2
Known results and new results are summarized
in Figure 7. For both of weak and strong trace
equivalences, and program classes A and B, eiα
α
ther A −→ B or A −→
6
B with α = W, S has
been proved. In the figure, an arrow is missing
α
between program classes A and B, if A −→ B or
α
A −→
6
B with α = W, S can be implied by other
W
relations. For example, HBAC6−→R-SI is implied
W
W
W
by SHA−→F-SA, F-SA−→HBAC and SHA6−→RS
SI. Also, for any program classes A and B, A −→ B
W
W
S
implies A −→ B and A −→
6
B implies A −→
6
B by
definition.
8
第四回システム検証の科学技術シンポジウム
Vol. 0 No. 0
HBAC
R-SI
Th2
Th4
gram are the rules obtained from the original
rules in 2. 2 by replacing the first and second
rules with the following two rules.
IS (n) = call g [PG ], n 6∈ SET
hn, Ci : ξ → hIT g , (C ∪ PG ) ∩ SP g i : hn, Ci : ξ
IS (n) = call g [PG ], n ∈ SET
hn, Ci : ξ → hIT g , PG ∩ SP g i : hn, Ci : ξ
The definition of weak trace equivalence is the same
as the one in section 3 except the followings.
• (S3) is replaced with: Delete the designation of a set node (a node being in SET ) if
α=HBAC or JVM.
• (W1) is prohibited.
For this version of weak trace equivalence, we can
prove the relations exactly same as those shown in
Figure 7.
Th4
F-SA
Th3
R-SI
[10]
F-SA
[8]
Th1
JVM
[5]
SHA
JVM
SHA
weak trace equivalence
strong trace equivalence
bold arrow: new result
A
B : A can be simulated by B
Figure7
5
• The semantic rules for an extended JVM pro-
HBAC
Th1
Cor1
2007
Comparison of the expressive power
4 Conclusion
The expressive power of five subclasses of programs with access control was compared. In particular, it was shown that HBAC has the strongest
expressive power under the weak trace equivalence.
The definition of weak trace equivalence using
dummy method might be a little awkward. Instead of using dummy method, we can define a version of weak trace equivalence by slightly extending the permission based languages (HBAC and
JVM) as follows. Note that an HBAC or JVM
program cannot remove a permission from the current permissions unless it takes the intersection of
the current permissions and the static permissions
of a callee method. Thus, we introduce a subset
SET of PRM such that if n ∈ NO f ∩ SET and
IS (n) = call g [PG , PA ] in HBAC or call g [PG ] in
JVM, then n replaces the current permissions with
PG before taking the intersection of the current permissions and the static permissions of g.
The difference between the original and extended
languages are as follows.
• An extended HBAC or JVM program is π =
(Mhd , f0 , {Gf | f ∈ Mhd }, PRM , SET ).
• The form of a call node n of an extended JVM
program is IS(n) = call g [PG ], having a grant
permission PG .
• The semantic rules for an extended HBAC
program are the rules obtained from the original rules in 2. 1 by replacing the first rule with
the following two rules.
IS (n) = call g [PG , PA ], n 6∈ SET
hn, Ci : ξ → hIT g , (C ∪ PG ) ∩ SP g i : hn, Ci : ξ
IS (n) = call g [PG , PA ], n ∈ SET
hn, Ci : ξ → hIT g , PG ∩ SP g i : hn, Ci : ξ
References
[ 1 ] M. Abadi and C. Fournet, Access control based
on execution history, Network & Distributed System Security Symp., pp.107–121, 2003.
[ 2 ] A. Banerjee and D. A. Naumann, History-based
access control and secure information flow, CASSIS04, LNCS 3362, pp.27–48, 2004.
[ 3 ] M. Bartoletti, P. Degano, and G. L. Ferrari,
History-based access control with local policies, 8th
FOSSACS, LNCS 3441, pp.316–332, 2005.
[ 4 ] J. Esparza, A. Kučera, and S. Schwoon, Modelchecking LTL with regular variations for pushdown
systems, TACS01, LNCS 2215, pp.316–339, 2001.
[ 5 ] P. W. Fong, Access control by tracking shallow
execution history, IEEE Security & Privacy, pp.43–
55, 2004.
[ 6 ] L. Gong, M. Mueller, H. Prafullchandra, and
R. Schemers, Going beyond the sandbox: An
overview of the new security architecture in the
JavaTM development kit 1.2, USENIX Symp. on Internet Technologies and Systems, pp.103–112, 1997.
[ 7 ] T. Jensen, D. Le Métayer, and T. Thorn, Verification of control flow based security properties,
IEEE Security & Privacy, pp.89–103, 1999.
[ 8 ] N. Nitta, Y. Takata, and H. Seki, An efficient security verification method for programs with stack
inspection, 8th ACM Computer & Communications
Security, pp.68–77, 2001.
[ 9 ] F. B. Schneider, Enforceable security policies,
ACM Trans. on Information & System Security,
3(1), pp.30–50, 2000.
[10] J. Wang, Y. Takata, and H. Seki, HBAC: A
model for history-based access control and its model
checking, 11th ESORICS, LNCS 4189, pp.263–278,
2006.
9
第四回システム検証の科学技術シンポジウム
モデルベース開発におけるテスト自動化フレームワーク
黒岩 正司
富士設備工業株式会社
概要
納期への要求が強く，組込みソフトウェア開発の現場
要求仕様から実ターゲットまで開発プロセス全体
もこれらの課題解決が急務となっている．このような
に渡るテストの自動化フレームワークについて紹介
背景から，モデルベース開発においてフォーマルメソ
する．T-VEC ツールは，要求仕様を表形式でモデル化
ッドを利用し，システム要求のモデル検証からソフト
したもの（T-VEC Tabular Modeler : TTM）や，
ウェア検証までを統合的に扱う枠組みが求められて
Simulink に対しフォーマルメソッドを用いて解析し
いる．本稿では，要求モデル・デザインモデルに対し
モデル上の欠陥を検出する．この解析は，モデル上の
てフォーマルメソッドを用いて解析しテストベクタ
パスごとで取り得る入力範囲の境界値を攻めるテス
を生成する T-VEC ツールと，静／カバレッジ解析，
トベクタ（入力と期待値）を生成することで行われる．
テストドライバ生成機能を有する LDRA ツールを紹
このテストベクタは，フロート，ダブルなど各種デー
介し，それらを統合したテスト自動化フレームワーク
タ型，リニア／ノンリニア式にも対応し，実ターゲッ
について述べる．
ト環境での実行を通してモデルとコードの一致性の
検証が行える．実行結果のカバレッジは，LDRA ツー
2. T-VEC／LDRA
ルを用いてあらゆる組込みターゲットで動的に解析
2.1. T-VEC
される．これらテスト結果，カバレッジはテストベク
T-VEC ツールは，フォーマルメソッドを利用したモ
タを介して，要求仕様，Simulink とのトレーサビリ
デルベース検証ツールである．高信頼性ソフトウェア
ティが取られる．
の Verification & Validation をサポートする目的で
要求からテストのトレーサビリティによって得られ
開発された．航空機開発におけるガイドライン
る効果は，実装テストに於ける解析が迅速になること，
FAA/DO-178B,C に関わり，モデルベース開発とその
要求が十分にテストされたことの証明，プロジェクト
検証についてのガイドライン制定に貢献するなど実
進捗管理の為の計測など．
践的に産業界で使用されるツールである．例えば，次
世代スペースシャトル(Project Orion)の主契約企業で
1. はじめに
あるロッキードマーチン社は，このプロジェクトに
組込みソフトウェアは，私たちの身の回りにある
T-VEC の TTM 要求仕様モデルと Simulink のモデル
様々なシステムの中核を担い，多様な機能やサービス
検証機能をサブコントラクタも含めて採用すること
を提供している．そういった中で，システムの要求か
を表明している．
らソフトウェア設計，コード生成までの工程で，モデ
ルを用いるモデルベース開発手法が，ソフトウェア開
発プロセスに導入されてきている．一方で，要求に対
するモデルの検証，モデルとコードの一致性検証など
大規模なソフトウェア開発を考えた場合，時間とコス
トが課題になってくる．昨今の組込みシステムは，製
品競争の激化により，高機能，高品質，低コスト，短
10
第四回システム検証の科学技術シンポジウム
T-VEC は，以下の機能で構成される．
・ T-VEC Tabular Modeler（TTM）
・ Simulink Tester（SL2TVEC）
・ T-VEC Vector Generation System（VGS）
TTM は，要求管理を提供し，要求とモデリングを
サポートする．欠陥解析や自動テストケース生成のた
めに，要求仕様を表形式の GUI を用いてモデル化す
る（型，I/O などのインタフェースや状態，イベント，
遷移テーブルなど振る舞いをモデル化する）．VGS で
図 1. T-VEC モデル解析，検証基盤
モデル検証し，要求仕様に基づいたテストベクタを生
成する．DOORs 要求管理ツールなどと統合され，要
T-VEC は検証に先駆けて要求モデルやデザインモ
求仕様とテストのトレーサビリティをとる．テストで
デ ル (Simulink/Stateflow) を 独 自 の 階 層 的
問題が発生すれば，そのテストベクタ，モデル，要求
Disjunctive Normal Form(DNF)に変換する．この形
仕様と戻って解析できる．TTM に直接要求仕様を含
式に於ける各機能要求（入出力間の振舞い）の入力域
めることも可能で，同様に管理される．
に対するコンストレインツは Domain Conversion
Path(DCP)として抽出される．このパスに対し，テス
トベクタ生成システムは，上流の制約を受けて伝播さ
れてくる入力範囲で期待出力との組合せを生成する．
ここで，テストベクタを生成できない DCP は，モデ
ル上の矛盾として検出される（モデル検査）．また，
このテストベクタ生成機能は，フロート，ダブルなど
各種データ型，リニア／ノンリニア式に対応している
ため，矛盾無く生成されたテストベクタは，実システ
ムに対する入力と期待値としてテストに用いられ，モ
図 3. TTM による要求仕様のモデル化
デルに対するコードの一致性の検証が行える．[1]
このテストのカバレッジ解析（2. 2.
LDRA）を行
SL2TVEC は，デザインモデルである Simulink や
うことで，要求仕様，デザイン仕様，ソースコードの
Stateflow を変換し解析する．モデルを VGS で検証し，
一貫性も検証できる．
テストベクタ生成，実行，結果判定を行う．モデルか
ら自動生成されるソースコードに対するテストドラ
イバも自動生成される．VGS と統合することでテスト
プロセスの多くを自動化する．モデル上の欠陥（ゼロ
割やレンジオーバーフローなど）を検出することや，
アサーションによるモデルのセーフティプロパティ
の検証なども行える．
VGS は，モデル解析，テストベクタ生成，テストド
ライバ生成，テスト結果解析，結果レポート生成など
図 2. モデルベース検証の自動化
を行う．
11
第四回システム検証の科学技術シンポジウム
2.2. LDRA ツール
バレッジ解析をサポートする．
LDRA ツールには，静的解析／カバレッジ解析を行
う Testbed と，単体テスト，リグレッションテスト
を自動化する TBrun がある．LDRA ツールは，高信
頼性マーケットで 30 年に渡って使用されている．
3. 手法
上述で紹介したツールを使ったテスト自動化フレ
ームワークについて，下記要求仕様を基に述べる．実
LDRA Testbed は，ソースコードの静的解析とカバ
行環境は，GreenHills MULTI 統合環境が持つ，ルネ
レッジ解析を提供するツールである．静的解析では，
サス M32R CPU シミュレータ（MULTI M32R シミ
独自の構文解析エンジンを持ち，プログラミングスタ
ュレータ）を使用する．
ンダードチェック，複雑度解析，データフロー解析，
コードのビジュアル化（コールグラフ，フローグラフ）
や詳細レポートを生成する．LDRA ツールは，プログ
ラミングスタンダードルールである MISRA（Motor
Industry Software Reliability）に対応し，DO-178B
の認証に初めて利用されたツールでもある．カバレッ
ジ解析では予めタグをソースコードに埋め込み，テス
トデータを実行することでテストされていない領域
（未実行パスやデッドコード）を特定できる．ステー
トメント，ブランチ，MC/DC カバレッジなどを測定
できる．
LDRA TBrun は，テストハーネス／ドライバを自
動生成し単体テストを自動化する．追加のコーディン
グやスクリプトは不要で，ユニット単位のテスト実行
を容易にかつ効果的に行える．テストケース（入出力
図 4. テスト自動化フレームワーク
値と結果）は保存され，リグレッションテストに対す
る解析の自動化に利用される．ソースコードの変更箇
3.1. 要求仕様
所を自動検出し（関数の引数が増えた，型が変更され
温度センサーにより温度を監視し，温度に合わせて
たなど），保存されているテストに対して変更が必要
バルブの開閉を調整するフローレギュレータ
な部分はレポートされるため，テストデータのメンテ
(flowRegulator)装置を考える．
ナンスが効率よく行える．
・ 入力：温度（範囲：0~300）
TBrun は，Testbed による静解析から必要な情報
・ 定数：Low : 120，High : 180
（関数の引数，グローバル変数（入出力），戻り値，
・ 温度が Low より小さい時，バルブは Closed
変数の型，関数コールなど）を取得している．単体テ
・ 温度が High より大きい時，バルブは Open し，
ストでは，ある単体から別の単体へのコールがあり，
このようなコールで実体が記述されていない単体も
ある．この場合，TBrun はテスト内のコールに対す
るスタブを自動生成する．生成されるスタブは，グロ
ーバル変数やポインタ等の解決，関数戻り値の設定な
ど柔軟に使用される．TBrun は，ホスト間，ホストターゲット間など，あらゆる環境でのテスト実行とカ
12
温度が Low を下回るまで，バルブは開いている
第四回システム検証の科学技術シンポジウム
[Input 定義]
・temperature（型：temperatureType）：温度
図 5. フローレギュレータ
・local_SVs（型：local_SVs_type）：前回値
flowRegulator モデルは，2 つのサブシステムを持つ．
・ temperatureSensor
・ flowControlLogic
temperatureSensor は，入力温度の値に前回値を使
った処理(Y[n]=0.7U[n]+0.3Y[n-1]) を行い，その結果
を-100∼300℃の範囲でフィルタリングし出力する．
flowControlLogic は，temperatureSensor の値をチ
ェックする．それにより，flowRegulator バルブの開
[定数定義]
・ HIGH：温度
閉が調整される．バルブが Closed の時は出力値 0%，
バルブが Open の時，出力値は以下の方程式で表す．
Out=((sensorTemperature- 120) / (300 - 120))*100
・ LOW：温度
3.2. 要求モデリング−TTM
上述の要求仕様を TTM でモデル化する．要求仕様，
要件管理番号(Requirement-ID：以下 Req-ID)，デー
タ型，入力，定数，関数，テーブル，出力などを定義
・ HIGH_TEMP_LIMIT：フィルタ値
する．
[要求仕様定義]
要求内容と Req-ID を設定する．
・ LOW_TEMP_LIMIT：フィルタ値
[関数定義]
Functions テーブルでは，与えられたパラメータで，
構成された処理に応じた値が設定される．
firstOrderFilter：Y[n]=0.7U[n]+0.3Y[n-1] を関数の
ように使用する．
13
第四回システム検証の科学技術シンポジウム
の位置(0∼100%)，前回値を出力する．
[一時保持変数定義]
Terms 変数は，システムの入出力の中間値に相当する．
temperatureSensor：firstOrderFilter をコールし，
3.3.デザインモデリング−Simulink
上述の要求仕様を Simulink でモデル化する．
temperatureSensor 出力と前回値を取得する．
図 6. flowRegulator モデル
各ブロックのプロパティに，TTM で記述した Req-ID
を設定する．
temperatureSensor：図 7 参照.
[状態遷移定義]
[Saturation ブロック]
Mode Machine テーブルは，状態遷移を定義する．
・ -100 <= Y[n] <= 300 の時，Y[n] を出力
flowControlLogic：バルブが Closed の時に，温度が
・ Y[n] < -100 の時，-100 を出力
High を超えれば Open に遷移し，Open の時に，Low
・ Y[n] >300 の時，300 を出力
を下回れば Closed に遷移する．
図 7. temperatureSensor
[出力定義]
Outputs テーブルは，モデル全体の出力を定義する．
flowControlLogic と flowRegulator バルブの開閉：図
ValvePosition：上述の変数やテーブルを受け，バルブ
8 参照．temperatureSensor の値を入力とし，バルブ
14
第四回システム検証の科学技術シンポジウム
の開閉を調整する．
図 8. flowControlLogic
図 9. フォーマル言語
3.4. モデル検証
要求モデル，デザインモデルの検証結果から， DCP
VGS でフォーマル言語をビルドし，テストベクタを生
毎で取り得た入力と期待出力の組合せ（テストベク
成する．temperatureSensor サブシステムでは，6 件
タ），モデル対ソースコードのマップ情報，ソースコ
のテストベクタが生成される．
ードへのパス情報などを LDRA ツールが読み込める
形式（.tcf）にし，インポートさせる．LDRA/Testbed
でカバレッジ測定の為のタグ付けをソースコードに
行い，LDRA/TBrun でテストを実行するためのドラ
イバーを自動生成させる．これらは，ソースコードと
共にコンパイル・リンクされ，ターゲットにダウンロ
ードされ，実行される．結果は，ターゲット上のメモ
リに格納され，I/O あるいはデバッガなどを介してホ
スト上に吸い上げられ，テストの Pass/Fail 判定とカ
バレッジの解析が行われる．以上のせいかぶつ、ソー
スコードに対する一連のテストベクタ，ドライバー，
テスト結果は TBrun により管理され，リグレッショ
ンテスト時の自動化が支援されるようになる．
3.4.1. 要求モデル−TTM
TTM モデルを T-VEC フォーマル言語に自動変換す
図 10. temperatureSensor テストベクタ
る．
Req-ID により，要求からテストベクタへのトレーサ
ビリティが取れる．
15
第四回システム検証の科学技術シンポジウム
図 11. TTM とテストベクタの要求リンク
図 13. カバレッジ結果
上記で生成されたテストベクタを VGS の機能を用い
てテストドライバー化する．これは，TBrun にインポ
ートされ，テスト対象プログラムと共にコンパイル及
びリンクされ，MULTI M32R シミュレータにダウン
ロードされる．その後実行され，テスト，カバレッジ
の結果が解析される．
図 14. temperatureSensor テスト結果
3.4.2. デザインモデル−Simulink
SL2TVEC でモデルの Export，Translate を実行し，
T-VEC フォーマル言語に変換する．
図 12. テストドライバーファイルのインポート
テストのカバレッジは 100%となった．また，期待値
と実行値の比較結果は全て OK となり，要求モデルと
ソースコードの一致性が検証できた．
図 15. フォーマル言語
VGS でフォーマル言語をビルドし，テストベクタを生
成する．temperatureSensor サブシステムでは，8 件
のテストベクタが生成される．
16
第四回システム検証の科学技術シンポジウム
ンロードされる．その後実行され，テスト，カバレッ
ジの結果が解析される．
図 18. テストドライバーファイルのインポート
テストのカバレッジは 100%となった．また，期待値
と実行値の比較結果は全て OK となり，要求モデルと
ソースコードの一致性が検証できた．
図 16. temperatureSensor テストベクタ
Req-ID により，要求から，デザインモデル，テスト
ベクタへとトレーサビリティが取れる．
図 19. カバレッジ結果
図 17. Simulink とテストベクタの要求リンク
上記で生成されたテストベクタを VGS の機能を用
いてテストドライバー化する．これは，TBrun にイン
ポートされ，テスト対象プログラムと共にコンパイル
及びリンクされ，MULTI M32R シミュレータにダウ
17
図 20. temperatureSensor テスト結果
第四回システム検証の科学技術シンポジウム
T-VEC ツールは，DOORS 要求管理ツールを TTM 要求モ
4. 考察
デリングツール，更には Simulink デザインツールを
要求モデル，デザインモデルを解析してテストベク
介して統合し，モデルからのテスト生成，テストドラ
タを生成し，これらテストベクタをソースコードに対
イバー生成を一貫してサポートしている．これにより
して実行することで得られるテスト結果，カバレッジ
要求からテストに至るトレーサビリティが提供され，
結果から，モデルとソースコードの一致性の検証が行
産業界の実製品開発で実践的に用いられるようにな
えた．また，Req-ID によって，要求モデル，デザイ
っている．
ンモデル，テストベクタとトレーサビリティが取れ，
更にこのプロセスを通じて得られる以下の効果は，採
要求が十分にテストされたことが証明された．
用を動機付けるものとなっている．
また今回のレポートには，MULTI M32R シミュレー
タを使用したが，実ターゲット環境（ターゲット：ARM、
１. リンク付けを意識して要求をモデル化する作業．
ICE：ローターバッハ社）でも同様に実施したものも
モデルにリンクされていない要求は見出され，まだ
ある（下図 21）．これについては別途資料で説明する．
モデル化されていないだけなのか，あるいはモデル化
できない・テストできないなど改善が必要かを考察で
きる．
２. 漠然とした要求は，モデル化段階で明らかにされ
る．
例えばある要件をモデルの 1 テーブル全体や，複数
のテーブルに渡ってリンクしないといけない場合は
複雑になるので，テーブルの一要素ごとへリンクでき
るように要件を効率的に分解・整理する作業を通じて．
図 21. ターゲット環境
３. 要求へのリンクが存在しないモデルが明らかにな
る．
5. おわりに
デザインサイクル以降で追加された，要求仕様書へ
本稿で紹介したこのような開発プロセス全体に渡
含められるべき要件．
るテストの自動化フレームワークを実現するモデル
ベーステストでは，要求仕様の改善，より良いテスト
の生成，テスト自動化による効率など多くの成果が見
４. 要件がテストケースとリンクする．
実装のテスト結果が要求仕様にリンクされるので，
込まれるが，大規模なシステム，要求にも適用可能で
テストで明らかになったエラーの解析にかかる時間
あるかの証明がないと産業界では用いられることは
とコストを飛躍的に削減できる．要求モデル，デザイ
無い．ライフサイクルを通して適応可能であること，
ンモデルにハイパーリンクされる機能は，更なる効率
容易で柔軟に拡張が出来るモデリング環境と言語，あ
に貢献する．
らゆる環境におけるテスト実行までサポートできる
こと，更には投資対効果が早期に明らかになること．
５. プロジェクト，プロセスを計測し管理する．
これらの要件に加えて，要求管理ツールがモデルベー
モデルベース開発，テストで得られる成果物をメト
ステスト環境に統合されることが実製品開発では求
リクスとし，それらの要求へのトレーサビリティは進
められる．
捗管理の重要な情報となる．[2]
18
第四回システム検証の科学技術シンポジウム
[8] Chandramouli, R., M. R. Blackburn, Model-based
この資料で紹介したモデルベーステストによるトレ
Automated Security Functional Testing , 7th Annual
ーサビリティは，多くのユーザ事例によって支えられ
Workshop
ている．
on Distributed Objects and Components Security (DOCSEC),
TAF のモデルベーステストによるテスト自動化によ
Baltimore, MD, April 2003.
るコスト削減効果について[3, 4]，要求使用の早期欠
[9] Blackburn, M. R., R. Chandramouli, Using Model-Based
陥抽出による改訂作業削減効果[5]，高信頼性システ
Testing to Assess Smart Card Interoperability Conformance,
ムの欠陥を体系的に特定する方法論[6]，更に拡張し
International Conference on Computing, Communications
たデザインモデル検証法 [7]，セキュリティ分野への
and Control Technologies, Austin, August 2004.
適応事例 [8, 9].
リファレンス
[1] Blackburn, M.R., R.D. Busser, Automatic Generation of
Test Vectors for SCR-Style Specifications. Proceeding of
the 12th Annual Conference on Computer Assurance, June,
1997.
http://www.t-vec.com/download/papers/tvec_scr2tvec.pdf
TU
UT
[2] Blackburn, M.R., Objective Measures from Model-Based
Testing, STAREAST, Orlando, May 2004.
[3] Statezni, David, Industrial Application of Model-Based
Testing, 16th International Conference and Exposition on
Testing Computer Software, June 1999.
[4] Statezni, David. Test Automation Framework,
State-based and Signal Flow Examples, Twelfth Annual
Software Technology Conference, May 2000.
[5] Safford, Ed, L. Test Automation Framework, State-based
and Signal Flow Examples, Twelfth Annual Software
Technology Conference, May 2000.
[6] Blackburn, M. R., R.D. Busser, R. Knickerbocker, R.
Kasuda, Mars Polar Lander Fault Identification Using
Modelbased Testing, NASA Software Engineering Workshop,
November 2001. See
http://www.software.org/pub/taf/downloads/mars_polar_lan
TU
der_2001.pdf.
UT
[7] Busser, R.D., L. Boden, Adding Natural Relationships to
Simulink Models to Improve Automated Model-based Testing,
Digital Avionics Systems Conference, October 2004. See
http://www.software.org/pub/externalpapers/papers/busse
TU
r-2004-2.doc.
UT
19
第四回システム検証の科学技術シンポジウム
( 1 )
1
システム検証の事例報告集の作成
渡邊 宏, 奥野康二, 高井利憲
システム検証研究センターで行なわれている事例
報告集作成の取り組みを紹介する．
つの活動を行っている。科学研究とは数理的技法の
基盤となる算譜科学の基礎研究を行う活動であり、
フィールドワークは算譜科学の研究成果を社会や開発
1 はじめに
現場の問題解決に役立てようとする活動である。企
数理的技法 (形式技法) にもとづくシステム検証を
業などとの共同研究でモデル検査を始めとする数理
産業界へ広く普及させるという目的のためには、組
的技法を開発現場へ導入し問題解決をはかる活動は
織やコミュニティを越えた枠組みで事例報告データを
フィールドワークの一つである。
収集・蓄積し、有効性や実行可能性を産業界へ向けて
CVS/AIST でこれまで実施された数理的技法によ
アピールしていくことが必要であるだろう。このよう
るシステム検証の事例研究は、科学研究の一部として
な事例報告データ収集の取り組み (1.2) は、ツール単
行われたもの、フィールドワークとして行われたもの
位、手法単位で行われているものは良く知られている
の二種類存在し、1999 年ごろ (前身のシステム検証
が、それよりも大きいコミュニティが行っているもの
研究ラボ時代) から実施されてきた。既にさまざまな
はほとんど存在せず、あまり知られていない。特に日
事例が蓄積され、また現在実施中の事例もある。しか
本国内でこのような取り組みは発表者の知る限りま
し、これまで CVS/AIST 全体でどれくらいの数の事
だない。
例に取り組み、どれくらいの量の知見が蓄積されてい
本発表では、産業技術総合研究所システム検証研究
センター内で始めたシステム検証の事例報告集作成
の取り組み、および現在まで収集した事例報告データ
の概要を紹介する。
るといった客観的な情報は把握されておらず、これら
を全部まとめて外部へ公開する仕組みもなかった。
もちろん論文、会議などでの口頭発表や算譜科学
研究速報 [1] などで外部発表されている事例について
は、産総研全体の成果報告発表データベース [2] から
1.1 経緯
担当者名や論文など詳しい情報へのポインターを得
システム検証研究センター (以下 CVS/AIST) は、
ることはできる。しかし、成果報告発表 DB からは
システム検証の数理的技法を産業界へ普及させるこ
CVS/AIST が取り組んだ事例の全体像は得られない。
とを目的に、2004 年 4 月に 6 年間の時限付きで設立
このように CVS/AIST 内に事例自体は日々蓄積さ
された研究組織である。
CVS/AIST では科学研究とフィールドワークの二
れていくが、新たなプロジェクトの設立と廃止、メン
バーの変遷とともに事例の情報は散逸しつつあった。
これではメンバーの間でも得られた経験や知見が効
Hiroshi Watanabe, Koji Okuno, Toshinori Takai, 独
立行政法人産業技術総合研究所 システム検証研究セン
ター，AIST, CVS/AIST
果的に伝わらず効率的ではない。したがって、個々の
事例を説明する詳しい情報へのポインターをまとめ
20
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
2
て事例報告集を作成するのはたいへん有意義である
と考えられた。
( 2 )
通りである。
1. CVS/AIST 内で行われたシステム検証の事例
さらに大学等から CVS/AIST への要望が事例報告
研究を詳しく説明する論文などへのポインター
集を作成する動機の一つになった。大学等からは、検
をまとめて、CVS/AIST 内に蓄積された事例の
証の事例が十分集まっていることを産業界へ見せられ
散逸を防ぐ。
ないかといった要望や、事例の集まりをデータベース
2. 数理的技法を用いたシステム検証の事例が蓄積
化して実証的研究へ提供してほしい、実証的研究へ
されていることを産総研外部へ紹介、アピールす
向けたデータベース作りを先導してくれないかといっ
るための資料を作る。
た要望がこれまで何度かあった。
3. 新たな事例へ取り組むさいに活用できる参考資
以上の経緯のもと、CVS/AIST 内に蓄積された事
例の散逸を防ぐため、また将来外部と連携してデータ
料を作成する。
4. 将来的に外部と連携した事例報告データベース
ベースを構築することも視野に入れ、我々は 2007 年
を作るための試案を準備する。
6 月から CVS/AIST でのシステム検証の事例報告集
の作成を開始した。
2.2 開発体制とスケジュール
事例報告集の作成には、発表者の三名と広報担当一
1.2 関連する取り組み
名の四名からなる事例報告データベース班を組織し、
システム検証の事例報告集作成にあたり、次の二つ
2007 年度は次のスケジュールで活動している。
1. 企画 事例報告データ収集する範囲を決定し、
のポイントに絞り情報を探して参考にした。
1. 研究組織などが作成した数理的技法の事例報
収集方法を検討する。
2. 事例報告データの収集 メンバーから事例報告
告集、
2. 数理的技法にもとづく検証ツール、手法の適用
データを収集する。
3. データの整理 集めたデータを整理する。デー
事例報告集、
前者 1 に関しては、次の情報だけしか見つからな
タによっては関係者から公開許諾を得る。
4. 事例報告集の編集・出版 集めたデータをまと
かった。
• Formal Methods Europe の 適 用 報 告 の Web
ページ [3]†1 。
めて事例報告集を編集し、テクニカルレポート化
後者 2 については次の情報を見つけて参考にした。
する。
する。また、web ページで公開することも検討
• CADP Toolset の適用事例集 [4]、
5. データベース化の検討
• Uppaal の適用事例集 [5]、
• モデル検査ツールためのベンチマーク集 [7]
• Promela モデルのデータベース [6]、
2.3 現在の状況
2007 年 10 月現在、スケジュール 2 のデータの収集
の段階を一区切り付け、3 のデータ整理を行っている
2 事例報告集の作成
ところである。これまでに 24 件のデータが集まった。
CVS/AIST で作成中の事例報告集の概要を紹介
する。
2.4 収集する事例とその範囲
収集する事例は、システム検証研究センターあるい
2.1 目的
はその前身のシステム検証研究ラボで行われた数理
システム検証の事例報告集を作成する目的は次の
的技法によるシステム検証の事例研究および関連す
†1 既にこのページのデータは更新されておらず、残念な
がらページは保守されていないように見える
る事項とした。数理的技法を用いた「システム検証の
事例」の定義は厳密に与えないが、次のような手法を
21
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
実問題へ適用した案件を想定した。
• モデル検査、
1983
3
3.1 事例名
事例の名前の一覧は表 6 のとおりである。
• 定理証明・対話型検証、
• 形式仕様記述、
3.2 実施年度
事例によっては失敗したものや途中で止まっているも
各年度ごとの実施件数は表 1 のとおりである。現
のもあるが、それらも集めることにした。それから本
在のところ、昔 (2002 年、2003 年) のデータはまだ
事例報告では、一つの事例は一つのプロジェクトを指
十分集まっていないと考えられる。
すわけでなく、課題、論文、成果単位などトピックに
切り分けたものを指すこととした。集めるデータの範
3.3 題材の分類と形態
囲は、外部公開可能な情報、既に外部公開した情報の
みに限ることとした†2 。したがって、秘密保持すべき
ある。組み込みに関してはまだまだ報告されていない
情報や、特許出願前のデータは当然集めない。
ものがあり、件数は増える予定である。
2.4.1 事例報告データ項目の策定
各事例で検証した題材を領域分けしたのが表 2 で
各事例の題材について、設計過程の上位の仕様書で
事例報告の中身である事例報告データ項目として
あるかそれとも下位のソースコードであるのか題材
表 7 を用意した。データ項目は以下の五つの部分に
の形態を区別し、形態ごとに件数をまとめたのが表 3
分かれていて、それぞれ次の内容が書けるようになっ
である。
ている。
表題 事例の名前、概要、実施年度、担当者、共同
研究相手などの寄与。
事例題材のデータ 検証題材の領域、形態、規模な
3.4 手法とツール
検証で使用された手法は表 4、ツールは表 5 にまと
められる。
ど題材の説明。
表1
検証のデータ 手法、ツールや検証内容の説明。
情報源 テクニカルレポート、論文など事例の詳し
い情報へのポインター。
年度ごとの実施件数 (年度の重複あり)
年度
02
03
04
05
06
07
件数
2
3
5
6
7
3
他 作成者、修正者など管理用データ。
表2
このデータ項目の作成には、Formal Methods Europe
の適用報告の Web ページ [3] と CADP Toolset の事
例報告 [4] を参考にした。参考にした事例報告 [3], [4]
と我々のデータ項目を比較すると、我々の方がデータ
項目数が多い。これはできるだけ色々な視点から事例
を特徴付けるデータを抽出するために試みたことで
ある。†3
題材の領域
領域名
件数
組み込み
4
Web アプリケーション、業務系システム
5
通信プロトコル
5
アルゴリズム
7
その他
4
表3
3 収集した事例報告データの概要
最後にこれまで収集した事例報告データの概要を
紹介する。
形態
形態名
件数
仕様書
9
ソースコード
†2 ただし、共同研究相手など関係者には公開前に公開許
諾を取る予定である。
†3 しかし、データ提供者に全部の項目を埋めることを強
制するつもりはない。
その他
22
11
3
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
4
4 まとめ、課題および今後の活動
本発表では、システム検証研究センターで作成中の
事例報告集の概要と進捗状況を紹介した。まだデータ
を整理している段階であり、今後も引き続きデータを
収集、整理、更新していく。今年度中にテクニカルレ
ポート化するのが当面の目標である。
今後の課題としては、自動化、作業の軽減化があげ
られる。まだまだデータ収集、整理など、手作業で試
行錯誤している段階である。収集方式の自動化、作業
のシステム化、データベース化を検討したい。
他機関との連携データベース化についてはまだ白紙
Koukai.Top
[ 3 ] Formal Methods Europe, Applications,
http://www.fmeurope.org/manasite/mas/fme/
applications/641.html
[ 4 ] CADP, Case Studies Achieved using the CADP
Toolset,
http://www.inrialpes.fr/vasy/cadp/casestudies/
[ 5 ] Uppaal Examples,
http://www.it.uu.se/research/group/
darts/uppaal/examples.shtml
[ 6 ] Alberto Lluch Lafuente, Database of Promela
Models,
http://www.albertolluch.com/
index.html?x=promelamodels.html
[ 7 ] BEEM: BEnchmarks for Explicit Model checkers,
http://anna.fi.muni.cz/models/
である。もし事例報告を連携させることにに賛同・協
力いただける方、事例報告のデータを提供いただける
方がいれば積極的かつ柔軟に連携を考えていきたい。
参考文献
[ 1 ] 独立行政法人産業技術総合研究所 システム検証研
究センター, 算譜科学研究速報 (テクニカルレポート),
http://unit.aist.go.jp/cvs/techrep.html
[ 2 ] 独立行政法人産業技術総合研究所 研究成果発表デー
タ ベ ー ス, http://www.aist.go.jp/RRPDB/system/
表4
手法
手法名
件数
モデル検査
13
定理証明・対話型検証
8
その他
3
表5
ツール
ツール名
件数
SMV, NuSMV
3
Spin
5
Uppaal
5
PRISM
1
MLAT
2
Agda
5
PVS
2
AIST workflow verifier
1
Jex
1
その他 (人手など)
1
( 4 )
23
第四回システム検証の科学技術シンポジウム
( 5 )
Vol. 0 No. 0
表6
1983
事例一覧
通信プロトコル設計へのモデル検査適用事例
Web アプリケーションの基本設計書の検証
Web アプリケーションの画面遷移仕様のモデル検査
Web アプリケーションのクラス設計仕様に対するモデル化と検証
自動検針システム仕様書のモデル検査
遷移系抽象化アルゴリズムの検証
モデル検査支援装置の基本デザインの検討
アセンブラで記述された組込みシステムのモデル検査
一般公開で用いた LEGO 用プログラムの検証
確率モデル検査による 1 次元イジングモデルの検証
便益性評価のためのデータ収集実験と評価
相互再帰的に定義された文字列を翻訳処理するプログラムの検証
たし算かけ算プログラムのコンパイラの正当性証明
非自動はかりの重量データ処理プログラムのモデル検査適用事例
Hoare 論理の健全性の Agda による検証
Deutsch-Schorr-Waite マーキングアルゴリズムの Agda-MLAT 連携による検証
ソフトウェア更新システムプロトコルの BAN Logic による安全性検証
リスト反転アルゴリズムの Agda-MLAT 連携による検証
TACC 業務フロー図の検証
環境ドライバを用いた組込みシステムのソースコードモデル検査
検証期間の調査のための車載組込みシステムに対するモデル検査実験
Java の例外処理の SPIN による検証
ソフトウェア更新システムのモデル検査器を使った安全性の検証
24
5
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
6
表7
( 6 )
事例報告データ項目 (一部)
表題
11. 事例番号
12. 項目名 (必須)
事例の名前
13. 実施年度 (必須)
14. 概要 (必須)
15.CVS/AIST 担当者 (必須)
17. 寄与
共同研究相手、CVS/AIST 外の研究者名など。
18. 関連する項目の事例番号
事例題材のデータ
21. 領域
組込み、Web アプリケーション、業務系システム、
通信プロトコル、アルゴリズムなど
22. 検証対象詳細
23. 形態
仕様書、ソースコードなど
24. 言語
C 言語、日本語など
25. 規模
2000 行、100 ページ
26. 題材に関する情報源
検証のデータ
31. 目的
32. 検証内容
33. 結果
34. 検証手法
モデル検査、定理証明・対話型検証、形式仕様記述など
35. モデル化法
ソースコードから自動生成、ドキュメントから手動、半自動など
36. 使用ツール
37. スケジュール
労力、時間など 二人で 3ヶ月、モデル作成 10 時間、
検査 5 時間、反例解析 3 時間、(不明) など
情報源
41. 算譜科学研究速報 (テクニカルレポート)
42. 論文発表
論文になっていればその書誌情報
43. 口頭発表
口頭発表していたらその情報
44. 知財
特許出願の番号、産総研ノウハウの番号
他
25
第四回システム検証の科学技術シンポジウム
(1)
1
An Algorithm for Bounded
Multi-Valued Model Cheking
Jeerson O. Andradey
1
Yukiyoshi Kameyamaz
Introdution
It is not unommon, during software speiation, to nd ontraditory speiations or unertainty in requirements. Current speiation tehniques and tools lak the proper treatment of these
problems. We want to be able to reate and verify models that inorporate unertainty and disagreement. This is not done naturally using lassi 2-valued logis. Thus we propose the use of
multi-valued logis [14℄ [15℄ to express models (requirements) as well as model properties (speiations), and to apply model heking [11℄ to verify
the model properties.
More speially we are interested in eÆiently
applying bounded model heking (BMC) [2℄ [1℄, that
has shown to be more eÆient on nding ounterexamples, to solve the multi-valued model heking problem. Until now, all the work related to
multi-valued model heking in the literature extended symboli model heking (SMC) [18℄ based
on ROBDD [6℄ to the multi-valued ase, and none
seems to have applied BMC to multi-valued model
heking. As long as we know, this paper is the
Dotoral Program in Computer Siene, Graduate
Shool of Systems and Information Engineering,
University of Tsukuba.
z Department of Computer Siene, Graduate
Shool of Systems and Information Engineering,
University of Tsukuba.
y
rst suh work.
On this work we present an original translation from the multi-valued model heking problem to multi-valued propositional satisability and
from that to two-valued propositional satisability.
Then we ompare our translation method to the
naive method for solving the problem, i.e. sliing
the multi-valued model on many two-valued models
and verifying them separately.
The rest of the artile is organized as follows.
Setion 2 disusses other attempts to solve the
multi-valued model heking problem found in
the literature. Setion 3 introdues multi-valued
Kripke strutures (MVKS) and the semantis of
mv-LTL, as well as multi-valued model heking. Setion 4 desribes the naive problem sliing method and also the diret translation from
multi-valued model heking problem to multivalued propositional satisability. Setion 5 gives
some results from preliminary experiments with
a prototype implementation of our diret translation method, and ompares it to the naive sliing method. Setion 6 gives onlusion and future
work.
2
Related Work
In reent years a number of researhers have
shown interest in the problem of multi-valued
model heking, and many distint approahes have
been proposed. Bruns and Godefroid [3℄[4℄ dened
26
第四回システム検証の科学技術シンポジウム
2
コンピュータソフトウェア
(2)
translations of a 3-valued model heking prob- the desription of the system's properties. Then
lem for CTL* and the modal -alulus to a stan- the speiation is veried against MVKS. On this
dard model heking problem. A restrited ver- work, from the range of the algebra of truth valsion of the problem with a 2-valued transition re- ues and temporal logis available, we will fous on
lation in the model was onsidered. Another ap- Linear-time Temporal Logi (LTL).
proah was adopted by Chehik et al. A new model
3.1 Boolean Algebra
heking algorithm for a multi-valued version of
In this paper, we take Boolean algebras as the
CTL was dened exploiting mv-BDD's [9℄ for unrestrited interpretations and MTBDD's [7℄ for nite many-valued struture used as logial domains of
quasi-Boolean algebras. Still, a model heker for interpretation for formulas in multi-valued logis.
mv-LTL under restritive interpretations (2-valued We do this in order to fous on algorithmi and
transition relation and totally ordered sets for the implementation issues. Extension to more general
propositions) have been implemented based on a strutures are left for future work.
translation to (mv-)Buhi automata [8℄. A transla- Denition 3.1 (Lattie). A lattie is a partially
tion from a negation-free mv-CTL* to CTL* model ordered set L = (L; v) suh that, for any two eleheking for model over nite quasi-Boolean lat- ments x; y 2 L, the following elements exist:
Their greatest lower bound (xuy), alled meet.
ties was shown by Konikowska and Penzek [19℄,
Their least upper bound (x t y), alled join.
who later revised their tehnique to make use of
A lattie is alled distributive if it satises the
designated values in omplete latties [20℄. Also,
model heking algorithms for mv-CTL over multi- distributive laws x t (y u z) = (x t y) u (x t z) and
valued interpretations featuring dierent notions of x u (y t z) = (x u y) t (x u z).
Denition 3.2 (Relative Pseudo-Complement).
negations were onsidered by Chehik et al. [10℄.
Let L = (L; v) be a lattie. If an element 2 L is
3 Multi-Valued Model Cheking
the greatest member of L suh that a u v b, then
Model heking an be summarized as an auto- we all the pseudo-omplement of a relative to b,
mated tehnique to verify temporal properties on denoted by a ) b.
For nite distributive latties the relative pseudonite systems.y1 Standard model-heking usually
reeives as input a system's model desribed by omplement aways exists [14℄.
a Kripke struture (requirements) and a temporal Denition 3.3 (Boolean Algebra). A Boolean Allogi desription of the system's properties (spei- gebra is a distributive lattie (L; v) with a maxations). The speiation is veried against the imum element >, a minimum element ?, and a
Kripke struture to see if it holds or not. If the unary operator , suh that, for any x 2 L:
xu x = ?
Law of Non-Contradition
speiation does not hold, a ounterexample is
xt x = > Law of the Exluded Middle
produed.
A nite Boolean Algebra has 2n elements for
On the other hand, multi-valued model heking
reeives as input a multi-valued Kripke struture some natural number n. Figure 1 illustrates a 24
(MVKS), i.e. a multi-valued nite transition sys- valued Boolean Algebra. We say it is an \order 4"
tem as an extension of the Kripke struture, and Boolean Algebra.
We heneforth assume that L is a nite Boolean
y1 There is an inreasing interest in model heking
for innite systems, though.
Algebra.
27
第四回システム検証の科学技術シンポジウム
(3)
Vol. 0 No. 0 1983
図
1 An order 4 Boolean Algebra.
3.2 Multi-Valued Kripke Struture
We dene the onepts of multi-valued Kripke
strutures and paths on a Kripke struture. The
extension of the lassial notion of Kripke strutures to the multi-valued one (MVKS) is straightforward. Note that some authors [8℄[5℄ perform
multi-valued model heking on MVKS where the
prediates take values from an mv-algebra [8℄ [5℄,
but they keep the transition relation dened over
2-valued lattie (order 2 Boolean algebra), while
others onsider also mv-transition relations (for instane, [21℄). On this work, we follow the seond,
more general, approah.
Denition 3.4 (Multi-Valued Kripke Struture).
A Multi-Valued Kripke Struture (MVKS) is the
tuple M = hS; S0 ; R; AP ; L; Oi with omponents
dened as follows:
S is a nite set of states.
S0 S , the set of initial states.
R : S S ! L is a funtion alled mvtransition relation.
AP is a nite set of atomi propositions.
L is an mv-algebra (in our ase, nite Boolean
algebra), dened as hL; u; t; ; ?; >i.
O : S AP ! L is a funtion that maps a
pair (s; a) 2 S AP to some l 2 L.
3
Denition 3.5 (Path on a Kripke struture). Let
M = hS; S0 ; R; AP ; L; Oi be a MVKS. A path is
a mapping : N ! S . Note that, in MVKS, any
sequene of states is a path. Obviously, not all sequenes of states are useful.
For a path , j denotes the j -th suÆx (path),
that is, j (i) = (i + j ) for i 0.
When there is no onfusion, we may also write a
path as s0 ; s1 ; s2 ; : : :, having the intended meaning that (0) = s0 ; (1) = s1 ; (2) = s2 ; : : :.
Denition 3.6 (Initialized path). We all a path
an initialized path i (0) 2 S0 . We dene the
set of paths 0 = f j (0) 2 S0 g.
3.3 Linear-time Temporal Logi
(LTL) is a logi that
allows one to refer to the future [11℄ [16℄.y2 We
slightly extend the syntax of LTL formulas so that
a lattie value l 2 L beomes a formula. We all
this extension mv-LTL.
Denition 3.7 (Syntax of mv-LTL). Let AP be a
set of atomi propositions. Let p 2 AP and l 2 L.
The syntax of mv-LTL is dened as follows:
; ::= l j p
j : j ^ j _ j !
j X j F j G j U j R
l 2 L is alled a truth value.
By onvention, to simplify the use of parenthesis,
we assume that the unary onnetives (:, X, F and
G) bind most tightly. Next ome U, R, ^, _ and
!, in the order.
The meaning of the standard logial operators
(:, ^, _, !) remains the same as in lassial twovalued logi. They assert about the urrent state.
The temporal operators (X, F, G, U and R) assert
about future states.
Informally, X states about the next state, i.e. X Linear-time Temporal Logi
y2
28
There is an extension of LTL, LTL with Past Operators (PLTL), that allows to refer to the past as
well.
第四回システム検証の科学技術シンポジウム
4
コンピュータソフトウェア
(4)
means \ holds at the next state". F states about f j(0) 2 S0 g. The (universal) model heking
sometime in future, i.e. F means \ holds at some problem, M j= , in LTL is dened as
future state". G expresses a permanent property of
M j= def
= 820 :( j= )
the model, i.e. G means \ always holds". U is and also, aording to the semantis of LTL the
G with a limit, i.e. U means \ holds at evfollowing equivalene holds.
ery state until holds, and holds at some future
820 :( j= ) :(920 :( j= :))
state." R is a dual of U.
.
We then give the semantis of an mv-LTL forThen, in order to solve the universal model hekmula with respet to an MVKS.
ing problem for a given we show that the existenDenition 3.8 (Semantis of mv-LTL). Let tial model heking problem for : has no solution.
M = hS; S0 ; R; AP ; L; Oi be an MVKS. Let =
Following the 2-valued denition, we dene the
s0 ; s1 ; s2 ; : : : be a path on M. Then, the semantis multi-valued model heking problem as the probof an mv-LTL formula is reursively dened by the lem of verifying, for a MVKS M, if for all initialvalidity relation j= as follows:
ized paths , j= is valid for a given speiation
1. ( j= l) = l, for l 2 L.
. However, not all initialized paths are useful and
2. ( j= p) = O((0); p), for p 2 AP .
it is not the ase that a path is either ompletely
3. ( j= :) = ( j= ).
useful or ompletely useless, therefore, we must re4. ( j= ( ^ )) = ( j= ) u ( j= ).
ne this intuition in some way. Namely, we should
5. ( j= ( _ )) = ( j= ) t ( j= ).
take into aount the degree of \usefulness" of a
6. ( j= ( ! )) = (( j= )) ) ( j= ).
path . Here we take essentially the same deni7. ( j= X ) = (1 j= ).
tion as [21℄.
8. ( j= F ) = Fi0 i j= .
Denition 3.10 (Weight of a Path). Let M =
d
i
9. ( j= G ) = i0 j= .
hS; S0 ; R; AP ; L; Oi be an MVKS, and is a path
F
d
i
j
10. ( j= U ) = i0 (( j= ) u ( j<i j= over M. We dene the weight of as an element
)).
of the lattie L by: l
11. ( j= R ) = di0 ((i j= ) t (Fji j j=
Weight ( ) =
R( (i); (i + 1)):
i0
)).
.
We say that is not valid along if j= is ?
If Weight () = >, it is a valid path. If
and that is valid along if j= is >. Other- Weight () = ?, it is an invalid (useless) path. Bewise, for ( j= ) = l we say that has validity \l" sides these, there may be paths whose weights are
along .
not ? nor >.
We an now dene the validity of an mv-LTL for3.4 Multi-Valued Model Cheking Prob- mula relative to a MVKS M as follows.
lem
Denition 3.11 (Multi-Valued Validity). Let
On two-valued LTL model heking the (univer- M = hS; S0 ; R; AP ; L; Oi be an MVKS. The vasal) model heking problem is dened as the prob- lidity of an mv-LTL
l formula is dened by:
lem of verifying if a formula is valid for all ini(M j= ) =
((Weight ()) t ( j= ))
20
tialized paths of a given model M. [1℄
.
Denition 3.9 (Model-Cheking Problem). Given
Note that this denition oinides with the defa Kripke struture K = hS; S0 ; AP ; Oi, let 0 = inition for two-valued validity given in [2℄ when
29
第四回システム検証の科学技術シンポジウム
(5)
Vol. 0 No. 0 1983
5
L = f?; >g. Note also that, if Weight ( ) = ?, equality above holds.
then suh a path does not aet the validity of a
4 Strategies of Multi-Valued Model
formula.
Cheking
The denition above gives the exat truth value
of an mv-LTL formula with respet to a MVKS
As we stated in the introdution, our aim is to exM, i.e. the exat degree of validity of w.r.t. M. plore the possibility of using the BMC tehnique in
Rather than omputing the exat degree of validity multi-valued model heking. For this purpose, the
of , we may want to do more general queries. For most basi method is \sliing", whih essentially
instane, we may want to know if (M j= ) w l for onverts one 2n -valued model heking problem to
some lattie value l 2 L. This kind of queries an n 2-valued ones, orresponding to eah \bit" of a
be redued to an \exat" query sine (M j= ) w l lattie value.y3
is true i l ) (M j= ) is >, and this is equivalent
Assuming that we an extend the two-valued
to M j= (l ! ). Hene we only onsider the stan- bounded model heking [1℄ to the multi-valued
dard speiation, and our model heking problem ase, we an do sliing in various stages:
is whether M j= equals > or not. Unfortumately
We slie the multi-valued model heking
this result does not generalize to other relational
problem (MVKS and mv-LTL formula) into n
operations.
2-valued model heking problems.
We slie the multi-valued propositional for3.5 The Notion of Counterexample
mula, obtained by translating the multi-valued
Next, we should onsider what is a ounterexammodel heking problem, into n propositional
ple in this setting. What we want to do is to hek
formulas. Or,
if M j= is >. This is equivalent to hek if for
We slie the multi-valued CNF, obtained from
all path 2 0 , the value Weight ( ) t ( j= ) is
the multi-valued propositional formula, into n
>. Then a ounterexample of this assertion is any
2-valued CNF.
path 2 0 suh that Weight () t ( j= ) >.
We laim that the hoie aets the eÆieny
If suh a ounterexample exists then M j= is not of mv-bounded model heking, sine at eah stage
>.
we an employ dierent styles of optimizations. On
Denition 3.12 (Counterexample). Let M = the following setions we ompare the rst two aphS; S0 ; R; AP ; L; Oi be a MVKS. Let be an mv- proahes indiated above.
LTL formula to be interpreted as an speiation
over M. We all a path 2 0 a ounterexample
4.1 Problem Sliing
for M j= i
What we proposed, as a rst attempt, is to enWeight() t ( j= ) >
ode the logi values of a Boolean Algebra with 2n
.
values in a vetor of n bits. A more interesting inWhen the lattie is Boolean algebra (or quasi- terpretation arises when we think of a multi-valued
Boolean algebra) we an take negation, so model as a struture representing the overlaying
:Weight () t ( j= ) > is equivalent to of many dierent 2-valued models, eah 2-valued
Weight ( ) u ( j= :) A ?. So, in the mv-BMV
model orresponding to one layer of the nal model.
algorithim we will rst negate the speiation fory3 We reall that an element of 2n -valued Boolean
Algebra is represented by n bits.
mula , and look for some path suh that the in-
30
第四回システム検証の科学技術シンポジウム
6
(6)
コンピュータソフトウェア
8
<
図2
Model with multiple viewpoints
inorporated.
We may think about eah \bit" of the logi value
as a layer of the model. The idea of an mv-model
as a omposition of standard model is illustrated
in Figure 2, where the transitions of the model are
labeled with 3-bit lattie values, indiating 3 omposing layers.
Then we slie the model on its many layers and in
this way generate many 2-valued models, as show
in Figure 3.
One immediate onsequene of this view is the
possibility to express dierent viewpoints in the
same omposite model. Eah viewpoint standing
for one layer in the model. Of ourse, ombinations
of more than one layer are possible.
The denition of sliing for models (MVKS) and
speiations (mv-LTL formulas) is very straightforward.
Denition 4.1 (Model Sliing). Given a MVKS
M = hS; S0 ; R; AP ; L; Oi, we say that the slie index i of M is the (standard 2-valued) Kripke struture M(i) = hS (i) ; S0(i) ; R(i) ; AP (i) ; O(i) i as dened
below:
S (i) = S
S0(i) = S0
R(i) = f(s; t) j bi (R(s; t)) = 1g
AP (i) = fp(i) j p 2 APg
O(i) (s; p(i) ) = : >; if bi (O(s; p)) = 1
?; otherwise
Where bi : L ! f0; 1g is a funtion that maps
a lattie value to its \bit" of order i, assuming a
binary enoding for lattie values.
Denition 4.2 (Speiation Sliing). Given an
mv-LTL formula , we all the slie index i of the (two-valued) LTL formula (i) dened by the
indutive denition below:
l(i) = bi (l)
p(i) = pi
(:)(i) = :((i) )
( ^ )(i) = (i) ^ (i)
( _ )(i) = (i) _ (i)
( ! )(i) = (i) ! (i)
(X )(i) = X (i)
(F )(i) = F (i)
(G )(i) = G (i)
( U )(i) = (i) U (i)
( R )(i) = (i) R (i)
.
Where pi 2 AP (i) and AP (i) is dened as
AP (i) = fpi j p 2 APg.
Denition 4.3 (Problem Sliing). Let L = hL; vi
be a boolean lattie of order n. Given a standard
multi-valued model-heking problem P = M j= ,
where M is a MVKS, is a mv-LTL formula, we
dene P (i) , the slie index i of P , as the (2-valued)
model heking problem, given by the expression
below:
P (i) = M(i) j= (i)
.
The following lemma sumarizes the method of
naive multi-valued model heking problem sliing.
Lemma 4.1. For a multi-valued model-heking
problem P = M j= l, based on a boolean lattie
of order n, the following equivalene holds:
M j= , #[M(n 1) j= (n 1) ;
M(n 2) j= (n 2) ;
:::;
M(0) j= (0) ℄
31
第四回システム検証の科学技術シンポジウム
(7)
Vol. 0 No. 0 1983
図
3 Three dierent \slies" of the original model.
.
4.2 Diret Translation + Sliing
The seond approah we present for solving the
problem is a diret translation designed following very losely the one proposed in [2℄, but with
the neessary modiations to preserve the multivalued semantis of models (MVKS) and speiations (mv-LTL formulas).
In the following we always onsider that image of
the equality relation is restrited to f?; >g.
Denition 4.4 (Unfolding the Transition Relation). Let M = hS; S0 ; R; AP ; L; Oi be a MVKS.
Let fsi ji 2 Ng be a set of state variables. We dene
the mv-propositional formula [ M℄ k that enodes
the transition relation of M as:
Where,
[ M℄ k := I (s0 ) ^
I (si ) :=
and
.
T (si ; sj ) :=
_
k^1
i=0
_
s2S0
7
T (si ; si+1 )
(si = s)
bound k, i 2 N, with i k, the translation [ ℄ ik of
for a path without a loop is indutively dened
as:
[ l℄ ik := l
[ p℄ ik := p(si)
[ :p℄ ik := :p(si)
[ ^ ℄ ik := [ ℄ ik ^ [ ℄ ik
[ _ ℄ ik := [8℄ ik _ [ ℄ ik
i+1
<
[ X ℄ ik := : [ ℄ k ; if i < k
?;
otherwise
Wk
j
i
[ F ℄ k := j=i [ ℄ k
[ G ℄ ik := ?
[ U ℄ ik := Wkj=i ([[ ℄ jk ^ Vjn=1i [ ℄ nk )
[ R ℄ ik := Wkj=i ([[℄ jk ^ Vjn=i [ ℄ nk )
.
Denition 4.6 (Suessor in a loop). Let k; l; i 2
N, with i k and l k. The suessor su (i) of i
in an (k; l)-loop is 8
< i + 1; if i < k
su (i) =
: l;
otherwise
.
Denition 4.7 (Translation of an mv-LTL formula
for a loop). For an mv-LTL formula , a bound k,
i; l 2 N, with i; l k, the translation l [ ℄ ik of for
(si = u ^ sj = v) ^ l
hu;v;li2R
Denition 4.5 (Translation of an mv-LTL formula without a loop). For an mv-LTL formula , a
32
第四回システム検証の科学技術シンポジウム
8
コンピュータソフトウェア
(8)
a (k; l)-loop path is indutively dened as:
Hene, we take disjuntion of formulas generated
[l l℄ ik := l
by sliing, and hek its satisability by an ordi[l p℄ ik := p(si )
nary, two-valued SAT-solver.
i
l [ :p℄ k := :p(si )
i
i
i
5 Experimental Results
l [ ^ ℄ k := l [ ℄ k ^ l [ ℄ k
i
i
i
l [ _ ℄ k := l [ ℄ k _ l [ ℄ k
We have implemented a bounded multi-valued
(i)
[l X ℄ ik := l [ ℄ su
model heker prototype, that an employ the two
k
[l F ℄ ik := Wkj=min(i;l) l [ ℄ jk
methods we disussed. The prototype outputs a
Vk
j
i
[
℄
l
l [ G ℄ k :=
propositional formula in DIMACS format [17℄ for
k
j =min(i;l)
Wk j ^ Vj 1 [ ℄ n _
i
[
℄
l [ U ℄ k :=
l
l
k
satisability problems. This is the input format
k
j =i 0
n=i
1
Vk
j
n
[ ℄ k ^ n=i l [ ℄ k ^ A
Wi 1
aepted by the MiniSAT tool [13℄, that was the
l
Wj 1
j =l
n
SAT solver we used in the tests.
n=l l [ ℄ k
Vk
j
i
It's easy to note that our approah generate a
l [ R ℄ k :=
j =min(i;l) l [ ℄ k _
Wk Vj
j
n
very spei kind of formulas, by omposing formuj =i 0l [ ℄ k ^ n=i l [ ℄ k _ 1
Vk
j
n
las that are greatly similar in struture, but eah
[ ℄ k ^ n=i l [ ℄ k ^ A
Wi 1
l
Vj
j =l
n
with its own set of variables. Here we remember
n=l l [ ℄ k
.
that (a) for the naive sliing method, after generatDenition 4.8 (Loop Condition). For k; l 2 N, let
ing the propositional formulas enoding eah slie
Wk
l Lk := T (sk ; sl ), and Lk = l=0 l Lk .
we take the disjuntion of these formulas, and (b)
Denition 4.9 (General Translation). Let be an
for the diret translation method, we take the dismv-LTL formula, M an MVKS and k 2 N. Then, juntion of the propositional formulas generated by
sliing the multi-valued formula that enodes the
[ M; ℄ k := [ M℄ k ^ [ ℄ k
multi-valued model heking problem.
Where,
We expeted that the strutural similarity would
k
lead to better performane for the SAT solvers. A
_
[ ℄ k := :Lk ^ [ ℄ 0k _ l Lk ^ l [ ℄ 0k
ording to our experiments, that is not the ase.
l=0
.
We measured the performane of the SAT solver
It is important to note that Weight () is auto- by ombining inreasing numbers of largely similar
matially enoded in [ ℄ k , as l Lk or Lk . So hek- but unrelated formulas. Figure 4 shows the average
ing the following property for k:
performane behavior for ombining unrelated unThere is a path suh that Weight () u
satisable formulas. Figure 5 shows the average
( j= :) A ?.
performane behavior for ombining unrelated satRedues heking the following one:
isable formulas. In both ases the performane
There are states s0 ; s1 ; : : : ; sk suh that
of the SAT solve was approximately linear on the
[ ℄ k A ?
size of the resulting formulas, does not showing any
By sliing, this nal property redues to heking gain due to the strutural similarity.
(for a xed k):
The diret translation and the naive sliing methThere are states s0 ; s1 ; : : : ; sk suh that
ods generated CNF of roughly the same size, as
there is some slie i for whih bi ([[℄ k ) = 1
we should expet. So we have not ahieved any
(i.e. non-zero).
improvement in this area, but the runtime for the
33
第四回システム検証の科学技術シンポジウム
(9)
Vol. 0 No. 0 1983
9
80000
Checking Unrelated Isomorphic Formulas (Test 1)
Naive slicing
mvBMC translation
0.9
70000
0.8
60000
0.7
50000
Time (ms)
Time
0.6
0.5
40000
30000
0.4
0.3
20000
0.2
10000
0.1
0
0
10000
20000
30000
40000
50000
60000
70000
80000
90000 100000 110000
0
Variables
100000
200000
300000
400000
500000
600000
700000
800000
900000
Size of propositional formula
4 Average performane behavior for
ombining unrelated unsatisable formulas.
図
6 Comparison of the translation time of
naive sliing and diret mv-BMC translation.
図
mane of MiniSAT is approximately linear on the
size of the input.
Checking Unrelated Isomorphic Formulas (Test 2)
1
0.9
0.8
6
0.7
Time
0.6
0.5
0.4
0.3
0.2
0.1
5000
10000
15000
20000
25000
30000 35000
Variables
40000
45000
50000
55000
60000
5 Average performane behavior for
ombining unrelated satisable formulas.
図
translation algorithm itself was slightly shorter for
the diret translation method, as shown in Figure
6. By analyzing our translation algorithm it seems
that this dierene will get even larger when we
use non-Boolean latties, but the veriation of this
onjeture is left for future work.
We have not yet done enough tests to measure
the performane of the SAT solver for the resulting CNF of the two methods, but we antiipate
that even in the worst ase the performane of the
diret mv-BMC translation will be approximately
equivalent to separately heking the n CNF for the
n slies of the original problem, sine we know by
our experiments (Figures 4 and 5) that the perfor-
Conlusion and Future Work
We have shown that the appliation of Bounded
Model Cheking to systems models build over
multi-valued strutures based on Boolean Algebras
is possible, and that the translation of the multivalued models to 2-valued models is very straightforward.
Despite of that, two are still muh ground for further improve this work. At least three points must
be addressed in the short term.
1. Improve our prototype tool so that we an
investigate more meaningful examples
2. Extend our approah to over more general logis like pseudo-boolean algebras and,
maybe, Heyting algebras.
Aomplishing these improvements will provide
the means to ondut experiments with realisti appliations of multi-valued logis. Topis that an be
further investigated inlude:
1. Denition of requirements expressing the unertainties or disagreements about them. The
possibility to nd ounterexamples will later
make possible to demonstrate, if neessary,
that some of these disagreements must be
34
10
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
solved and/or some unertainties must be dismissed to grant the validity of the speiations. [12℄
2. The apaity of bounded model heking to
eÆiently nd ounterexamples and the possibility that multi-valued temporal logi provides
to express disagreement will ertainly provide
powerful tools to reason about model renement. [22℄
3. The possibility to replae parts of a model for
a \maro-state" with all logi variables having value \unknown" and hek the resulting
model against the speiation an lead to
new tehniques model abstration and partial
model veriation. [3℄
参考文献
[ 1 ℄ A. Biere, A. Cimatti, E. Clarke, O. Strihman,
and Y. Zhu. Bounded model heking, 2003.
[ 2 ℄ A. Biere, A. Cimatti, E. Clarke, and Y. Zhu.
Symboli model heking without bdds. Leture
Notes in Computer Siene, 1579:193{207, 1999.
[ 3 ℄ G. Bruns and P. Godefroid. Model heking partial state spaes with 3-valued temporal logis. In
Computer Aided Veriation, pages 274{287, 1999.
[ 4 ℄ G. Bruns and P. Godefroid. Generalized model
heking: Reasoning about partial state spaes. Leture Notes in Computer Siene, 1877:168+, 2000.
[ 5 ℄ G. Bruns and P. Godefroid. Model heking with
multi-valued logis, 2003.
[ 6 ℄ R. E. Bryant. Symboli Boolean manipulation
with ordered binary-deision diagrams. ACM Computing Surveys, 24(3):293{318, 1992.
[ 7 ℄ M. Chehik, B. Devereaux, S. Easterbrook, Y. C.
Lai, and V. Petrovykh. Eient multiple-valued
model-heking using lattie representations. Leture Notes in Computer Siene, 2154:441{455,
2001.
[ 8 ℄ M. Chehik, B. Devereux, and S. Easterbrook. Implementing a multi-valued symboli model
heker. In Proeedings of 7th International Conferene on Tools and Algorithms for the Constrution
( 10 )
and Analysis of Systems (TACAS'01), volume 2031
of Leture Notes in Computer Siene, pages 404{
419. Springer, 2001.
[ 9 ℄ M. Chehik, B. Devereux, and A. Gurnkel.
Model-heking innite state-spae systems with
ne-grained abstrations using SPIN. Leture Notes
in Computer Siene, 2057:16+, 2001.
[10℄ M. Chehik and W. MaCaull. Ctl modelheking over logis with nonlassial negations,
2003.
[11℄ E. M. Clarke, O. Grumberg, and D. A. Peled.
Model Cheking. The MIT Press, 1999.
[12℄ S. Easterbrook and M. Chehik. A framework for
multi-valued reasoning over inonsistent viewpoints.
In International Conferene on Software Engineering, pages 411{420, 2001.
[13℄ N. Een and N. Sorensson. An extensible satsolver [ver 1.2℄.
[14℄ M. C. Fitting. Many-valued modal logis. Fundamenta Informatiae, XV:235{254, 1991.
[15℄ M. C. Fitting. Many-valued modal logis II. In
Pro. LFCS'92. Springer-Verlag, 1992.
[16℄ M. Huth and M. Ryan. Logi in Computer
Siene: Modelling and Reasoning about Systems.
Cambridg University Press, Cambridg, UK, 2nd edition, 2004.
[17℄ D. S. Johnson and M. A. Trik, editors. Cliques,
Coloring and Satisability: Seond DIMACS Implementation Challenge, volume 26 of DIMACS Series In Disrete Mathematis and Theoretial Computer Siene. AMS, 1996.
[18℄ J.R. Burh, E.M. Clarke, K.L. MMillan, D.L.
Dill, and L.J. Hwang. Symboli Model Cheking:
1020 States and Beyond. In Proeedings of the Fifth
Annual IEEE Symposium on Logi in Computer
Siene, pages 1{33, Washington, D.C., 1990. IEEE
Computer Soiety Press.
[19℄ B. Konikowska and W. Penzek. Reduing
model heking from multi-valued tl* to tl*, 2002.
[20℄ M. C. Konikowska. On designated values in
multi-valued tl* model heking, 2004.
[21℄ K. Nishizawa, Y. Kameyama, and Y. Kinoshita. Simulations of multi-valued models for
modal -alulus.
Tehnial Report AIST01J00022-68, National Institute of Advaned Industrial Siene and Tehnology (AIST), Japan, 2007.
http://unit.aist.go.jp/vs/tehrep.html.
[22℄ Y. Tatsumi and Y. Kameyama.
Towards
modeling-error detetion using multi-valued model
heking. In IPSJ Transations on Programming,
volume 47, July 2006.
35
第四回システム検証の科学技術シンポジウム
( 1 )
1
環境ドライバを用いたモデル検査による検証
事例
高井 利憲∗
古橋 隆宏∗∗
尾崎 弘幸∗
大崎人士∗
概要. 本稿では，組込みソフトウェアに対してモデル
発プロセス・ハードウェア・ソフトウェアの 3 つの観点
検査を用いた検証事例を紹介する．検査の対象は，周
から，対象製品の安全度水準 (SIL; Safety Integrity
期駆動 (cyclic executive) 型の組込みシステムのソー
Level) を 4 つのレベルに分類する．最高レベルの
スコードである．コードは，MISRA-C のコーディン
SIL4 では 50 個を超える手法が「推奨」されており，
グ規約に準じて記述されている．検証実験では，既知
形式的手法は「強く推奨」されている．ところが，実
のソフトウェアのバグを検出し，詳細原因を突き止め
際の開発現場では未だ，形式手法が積極的に取り入れ
た．状態爆発を回避しながら，効率よいモデル化工程
られているとは言い難い．テストやデバッグ工程の大
を実現するため，我々は，環境ドライバの概念にもと
部分は依然人手に頼っており，システム開発全体にか
づく独自の手法を採用した．本稿で紹介する検証事
かるコストにも大きな影響を与えている．技術の進歩
例，考察および環境ドライバを用いたモデル化手法
と現場との隔たりは，時間とともに少なくなりつつあ
は，企業との共同研究を通じて得られたものである．
るが，技術移転のための本質的な問題は置き去りにさ
1 はじめに
組込みシステムが社会の至る所に入り込み，動作の
安定が社会の安定を支えるようになるのに合わせて，
組込みシステムの開発技術も急速に進歩してきた．近
年では，計算機科学にもとづくシステム開発技術が発
達し，長年の開発経験がなくても高度な設計技術を現
場で活用することが可能になりつつある．しかし技術
の進歩は，デバイスの集積化も加速させた．組込みシ
ステムのソフトウェア規模が増大し，機能が複雑にな
ることによって，職人的技術だけでは品質の確保が難
しくなってきている．そこで，従来の開発技術を補う
新技術として，形式的手法に対する期待が，現在急速
に高まっている [5]．
品質確保の問題だけではない．機能安全規格への対
応という要因もある．国際規格 IEC61508 [4] では，開
∗ (独)
∗∗
産業技術総合研究所システム検証研究センター
矢崎総業 (株) 技術研究所
れたままという印象は否めない．
著者らの研究グループでは，共同研究のパートナー
企業の協力のもと，組込みソフトウェアの開発現場
に，モデル検査を中心とした数理的技法を導入するた
めの実験と考察を繰り返してきた．本稿で紹介するモ
デル化技法は，限られた期間内でも効果的なモデル化
工程を実現するための方法を模索する過程で得られた
知見にもとづく．既存の開発工程を大幅に変更するこ
となく，モデル検査をソフトウェア評価法として使う
という趣旨でも，現場技術者のニーズに叶っている．
我々のモデル検査実験では，開発の上流工程および
下流工程の両者への検査の適用を試みて，効果を比
較検討した．その結果，ソースコードを検証対象とす
るモデル検査が，コストの点でも品質向上の点でも，
最も効果的であるという結論を得た．上流工程でモデ
ル検査を導入すると，設計や分析に使用する従来の
ツールまでも変更するという導入コストの問題，仕様
書からモデルを作成するためにかかる人的コストの
36
第四回システム検証の科学技術シンポジウム
2
コンピュータソフトウェア
問題を解決できないという理由も大きい．
本稿で紹介する検証事例で採用した「環境ドラ
( 2 )
は環境ドライバと呼ぶ．モデル検査が成功するか否か
は，この環境ドライバの作り方に大きく依存する．
イバ」を用いたモデル化手法は，コーディング規約
我々のモデル検査手順では，次の二段階のプロセス
MISRA-C (Guidelines for the Use of the C Lan-
を踏む：(1) 検査対象タスクに対し，タスクが一回実
guage in Vehicle Based Software) で開発される周期
行されたときの振る舞いを解析するための環境ドラ
駆動型組込みシステムを対象としている．周期駆動
イバを作成して，検査を行う．ここでの検査は，予備
型 (cyclic executive) 組込みシステム [1] とは，無限
検査と呼ばれる．この予備検査を通じて，タスク単体
ループの構造を持つメインルーチンから，複数のタ
の機能の確からしさを検証するとともに，検査対象タ
スクが定期的に呼び出されるようなシステムである．
スクのバグ原因の候補を列挙する．(2) 前段階で得ら
小型機器を制御するためのソフトウェアアーキテク
れたバグ候補の真偽を確かめられる程度の環境ドラ
チャとしてよく見られる．こうしたソフトウェアを
イバを作成する．つまり最終的なモデルは，検査対象
コードレベルでモデル検査する際に問題となるのが，
タスクの振る舞いについて，バグ候補を観察するのに
状態爆発である．従来のモデル化手法では，モデル
必要最低限の機能だけを有する．この段階でモデルの
化と抽象化を往復して状態爆発を回避しようとした．
サイズが大きすぎるようであれば，検査項目がモデル
この方法では，検査可能なモデルを得るまでにかかる
検査に向かないことになる．また，必要最低限の機能
時間の見積もりが難しいため，開発に遅延をもたらす
からなるモデルであれば，抽象化可能な部分はあまり
リスクが常ににつきまとう [12]．本手法では，現場の
多くない．
開発プロセスを乱すことなく効果的にモデル検査を
本稿で紹介する検査プロセスは，著者らが報告し
行うことを目的とし，モデル化と抽象化の往復を極力
た別の事例論文で提案した周期タスク型モデル検査
減らすことを目指している．
法 [6] と一致している．周期タスク型モデル検査法が，
ソースコードのモデル検査を行う際に，モデルの粒
対象を特定して抽象化なども含めた詳細な方法論を
度にばらつきができるのは自然な現象である．逆に，
展開しているのに対し，本稿では，より一般的なモデ
対象全体をモデル化した後に，抽象化を施すと，モデ
ル化工程について述べる．また，周期タスク型モデル
ル全体の粒度が下がるため，バグ原因が隠れてしまい
検査法においても二段階のモデル検査手順を踏むが，
やすくなる．また，必要部分のコードだけを抜き出し
第一段階のモデル検査の役割として，本稿ではバグ候
てモデル検査することは難しく，必要部分に意味のあ
補の列挙を重視するのに対し， [6] の周期タスク型モ
る振る舞いをさせるための環境が不可欠である．我々
デル検査法では，モデルの妥当性を確かめるための予
のモデル化の方針では，詳細モデル (対象コードモデ
備検査を行うためのモデルであることを強調してい
ル) と抽象モデル (アーキテクチャモデル) を同時に
る．著者らが報告している他の事例として，アセンブ
作成して，組み合わせるというモデル化方針を採用し
ラ・プログラムへの適用例など [11] [12] があるが，本
ている．結果的に，モデルの粒度にばらつきが生じる
稿では，モデル検査プロセスを詳細に紹介し，環境ド
現象は著しくなる．また，この方針でモデル化を行う
ライバという概念を導入する．
と，モデルは使い回しがきかない．したがって，まず
本稿の構成は以下の通りである．関連研究について
検査項目を選別し，検査項目ごとにモデルの設計方針
解説した後，次節では，本稿で取り上げる検査対象の
を検討する．一つのモデルであらゆる性質を調べる
概要を説明する．第 3 節では，環境ドライバの概念
のではなく，検査したい機能やタスクだけを忠実にモ
とともに，我々が採用する検査手法について述べる．
デル化し，その他の外部要因は，検査対象タスクに影
第 4 節では，検査実験の一部について，その詳細を
響がある副作用だけを「環境」としてモデル化する．
紹介する．本稿に載せた検査対象のソースコードなど
検査対象タスク以外のものとしては，他のタスクや外
は，実際の事例から変数名などを改変し，説明のため
部環境などがあり，これらのモデルを総合して，我々
若干簡略化した．最後に考察を述べる．
37
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
1983
3
関連研究
ᯏ⢻㩷㪽
ಣℂ㩷㪠㩷䉁䈢䈲
形式手法をソフトウェアの開発現場に適用した事例は
他にもいくつか報告されているが，上流工程への適
౉ജାภ
ಣℂ㩷㪠㪠㩷䉕ታⴕ
㫆㫅㩷䉁䈢䈲㩷㫆㪽㪽
用が多い [2] [8] [9]．村石らの報告 [13] は，大規模な組
込みソフトウェアに対するモデル検査事例である．テ
㩿㪈㪀㩷ኻ⽎䉲䉴䊁䊛
ストでは発見困難と予想されるバグの検出にも成功
]
ಣℂ 㪠
している．ただし，もともとの開発工程で実行可能な
10
UML が導入されており，モデル検査に使うモデルも
ಣℂ 㪠䌉
UML から作成されている．自然言語で書かれた仕様
書しか存在しない開発現場への適用は，対象外であ
1((
る．モデル検査をデバッグに応用する試みとして，篠
6
6
㩿㪉㪀㩷౉ജାภ䈮ኻ䈜䉎ಣℂ㩷㪠㩷䈍䉋䈶㩷㪠㪠㩷䈱ታⴕ䉺䉟䊚䊮䉫㩷
崎らの報告 [10] がある．モデル化も含め，検証に要し
た作業時間の詳細な内訳も報告されている．本稿で
図1
検証対象システムの概要
は，事例紹介に加え，状態爆発を避けるためのモデル
化方針について，経験的な考察も述べる．
...
Task_f() {
...
}
モデル検査の現場導入を考える際，モデル化以外に
も，検査項目を LTL などの時相論理に翻訳する手続
きを検討する必要がある．開発者らの心理的敷居は，
モデル化よりも，むしろ LTL 検査式作成のほうが高
main() {
while (1) {
Task_A();
Task_B();
...
Task_f();
...
}
}
く，モデル検査の現場導入に対する大きな阻害要因に
なっている．我々の研究グループでは，図示記法 [7]
と呼ばれる LTL 式の図的な表現を独自に開発し，検
査式作成の効率化も目指している．
2 検査対象
対象システムを A，検査対象機能である A の機能を
図2
検査対象ソフトウェアの基本構造
f と呼ぶ．システム A の機能 f には既知のバグが含
まれており，これを α と呼ぶことにする．システムの
応するタスクを Task f とすると，ソフトウェアの基
検証対象部分の要求仕様は以下の通りである: 機能 f
本的な構造は図 2 のように表せる．システム全体の
は，一つの on/off の値をとる入力を持ち，連続した
ソースコードは，数万行程度で，Task f は，数百行
on の入力時間により，二つの処理 I と II を行う．具
程度である． ここで，マイナサイクルは，TM とす
体的には，時間 T1 以上 T2 未満の間 on の値が連続
ると，各タスクに対応する呼出しは，TM ごとに実行
すれば処理 I を行い，時間 T2 以上 on が連続すれば
されるか否か決定される．タスクのスケジューリング
処理 II を行う．ここで，実際の処理 I は，off になっ
はハードコーディングされているため，呼出しが実行
てからさらに時間 T1 以上経過後に実行される．
されるタイミングが決まっており，整数型のカウンタ
システムはコーディング規約 MISRA-C を満たす
変数によって時間を扱える．例えば，入力信号が on
C 言語で記述された組込みソフトウェアである．ソ
になってから数え始めるカウンタ変数を用意するこ
フトウェア・アーキテクチャは周期駆動型で，一定時
とにより，その変数の値が T1 /TM 回以上 T2 /TM 回
間 (マイナサイクルと呼ぶ) ごとにいくつかのタスク
未満のときに入力信号が off になった場合に，処理 I
呼び出しが行われる．今回検査対象とした機能 f に対
を始めるということができる．
38
第四回システム検証の科学技術シンポジウム
4
( 4 )
コンピュータソフトウェア
検査項目は，モデル検査実験時にはいくつかあった
࠮ࡦࠨ࡯
が，本項では以下の検査項目に対する検査プロセスを
紹介する．
ࠪࠬ࠹ࡓ
入力として T1 以上 on が連続すると，
処理 I または処理 II のどちらか一方が
ੱ߆ࠄߩ౉ജ
(1)
ઁߩࠪࠬ࠹ࡓ
実行される
ᄖㇱⅣႺ
C
3 検査手法
以降では，モデル検査ツールとして，Spin [3] を使用
ࠪࠬ࠹ࡓ
することを前提として，モデル検査の工程を説明す
ࡔࠗࡦ࡞࡯࠴ࡦ
る．我々が採用した検査工程は，これまでに繰り返し
行われてきたモデル検査実験を通じて得られた知見
࠲ࠬࠢ
࠲ࠬࠢ
を元に考案された．本稿で紹介するモデル検査実験の
㧭
㧮
当初の目的は，その検査工程の有効性を確かめること
࠲ࠬࠢ
࡮࡮࡮
ᬌᩏኻ⽎એᄖ
であった．
H
ᬌᩏኻ⽎࠲ࠬࠢ
D
3.1 環境ドライバ
モデル検査では，検査対象のシステムの振る舞いかた
図3
を網羅的に検証することが可能である．時間の経過と
ともに好ましくない振る舞いかたをするか，または想
定外の状況に陥らないかについて調べることができ
る．このため，一部のソースコードだけを検査の対象
とする場合でも，対象コード以外のシステムの部分も
モデル化を行う必要がある．システムが，外部環境と
情報をやりとりする場合には，外部環境のモデル化
も行わなければならない (図 3 (a)) ．この際の外部
環境は，忠実なモデルである必要はなく，例えば，取
り得る値のすべてを非決定的に選択するようモデル
であれば十分である． しかし，コードにあらわれる
変数の取りうる値を忠実にモデルとして表現すると，
状態爆発が生じる．こうした問題を回避するために
は，システムの振る舞いに影響を与える可能性のあ
る値のみ (閾値) のみを，モデルの取りうる値とする
などの工夫を行う．また，検査対象部分を絞り込み，
必要最小限の部分だけを取り上げる．(図 3 (b)) ．例
えば，複数のタスクからなる組込みシステムの場合で
あれば，特定のタスクの性質のみを対象とし，他のタ
スクや，メインルーチンなどは，タスクに影響を及ぼ
す可能性のある副作用のみをモデル化する．
以上のように，外部環境のモデルや，検査対象以外
環境ドライバがモデル化する部分
のタスクのモデルを総合して「環境ドライバ」と呼
ぶ．環境ドライバは，ソースコードに忠実なモデルで
ある必要はなく，あくまで検査対象部分を動かすため
の環境にすぎない．検査対象部分と受け渡しする値
は，モデル検査の網羅性を考慮した閾値周辺の値と
し，大域変数への非決定的な代入としてモデル化す
る．取り得る値をすべて非決定的に選択可能にする
と，偽反例が多くなり，検査の効率を著しく下げる．
環境の振る舞いについては，検査に費やせるコストと
のバランスを考えながら，受け渡す値がある一定時
間同じであり続ける，疑似並行タスクの切り替えの
タイミングを制限するなどの，想定 (シナリオ) を織
り込む．常識的な制限をモデルに加えることにより，
非常識な反例に煩わされる機会は減少するが，意外な
反例は得られにくくなる．
環境ドライバの典型的な二つの例を図 4 に記す．
いずれも，二値を取り得る外部信号が，大域変数
(CHK_INPUT_ON) の値 (on と off) として参照できる
場合をモデルとして表現した環境ドライバである．た
だし，(a) は一回だけの代入，(b) は任意のタイミン
グで任意回の代入を行う環境ドライバである．この
39
第四回システム検証の科学技術シンポジウム
( 5 )
Vol. 0 No. 0
1983
active proctype main() {
byte p;
p = _nr_pr;
run init(); p == _nr_pr;
unsigned CHK_INPUT_ON:uchar;
proctype drvINPUT () {
if
:: true -> CHK_INPUT_ON = 0
:: true -> CHK_INPUT_ON = 1
fi
}
(a)
do
:: true ->
drv_INPUT(); p == _nr_pr;
...
Task_f(); p == _nr_pr;
od
unsigned CHK_INPUT_ON:uchar;
proctype drvINPUT () {
do
:: true -> CHK_INPUT_ON = 0
:: true -> CHK_INPUT_ON = 1
od
}
(b)
図4
5
}
(a)
active proctype main() {
byte p;
p = _nr_pr;
run init(); p == _nr_pr;
環境ドライバの例
run drv_INPUT();
do
:: true ->
...
Task_f(); p == _nr_pr;
od
入力信号を処理するタスクが Task f の場合，メイン
ルーチンのモデルは，例えば図 4 (a) に対しては図
5 (a)，図 4 (b) に対しては図 5 (b) のように記述す
}
る．Task f 内部での入力信号の取り扱い方によって
(b)
は，4 (a),(b) 以外の表現を取りうる場合もある．
図5
状態数については，一般に，(a) の方が状態数は少
環境ドライバの使用例
なくなるが，外部環境からの入力が対象システムと独
3. ワンパスモデルへのモデル検査適用
立であれば，(b) の方を採用する必要がある．今回の
4. 周期モデル用環境ドライバの作成
検査対象では，外部からの入力は，検査対象タスクが
5. 周期モデルへのモデル検査適用
実行する前に，すべて対応するポート (大域変数) に
1 の対象コードモデルの設計方針は，
「ソースコード
反映され，タスク実行中は，それらの変数の値が変わ
と同程度の精度のモデル」を目指す．同程度の精度の
ることがないという仕様であったため，図 4 (a) の環
モデルとは，ソースコードの振舞いを保つように，C
境ドライバを利用し，骨格構造としては，図 5 (a) に
コードと Promela コードとの一対一の対応を保っ
類する環境ドライバを利用した．
て変換することを意味する．ただし，検査対象タスク
の振る舞いとは，変数同士の依存関係のないコード
3.2 検査の流れ
本手法では，MISRA-C に準じた C 言語で記述され
た周期駆動型組込みシステムの特定のタスクの振る
は，モデルの対象から除外できる．詳細について，以
下順に説明する．
1. 検査対象機能を，忠実に対応する Promela 表現
舞いを，モデル検査することを想定している．また，
に変換する．MISRA-C に準じた C 言語は，Promela
検査対象タスクは，C 言語上の関数 (呼出し) として
の制御構造と非常に似ており，文は代入，分岐，繰り
表現されているものとする．以下，検査対象タスクに
返し，関数呼び出しからなる．つまり，C 言語の代入
対応する関数を検査対象機能と呼ぶ．
文は Promela の代入文に，分岐文は if 文に，ルー
本手法を用いた検査の流れは，以下の通りである:
プ文は do 文にそれぞれ変換する．Promela では，
1. 対象コードモデル (詳細モデル) の作成
関数呼出しを直接扱えないので，プロセスを用いて
2. ワンパスモデル用環境ドライバの作成
実現する．表 1 は，C 言語から Promela への変換
40
第四回システム検証の科学技術シンポジウム
6
( 6 )
コンピュータソフトウェア
C 言語
種類
代入
分岐 1
Promela
x = exp
x = exp
if (c) {
if
st1
::c -> st1
} else {
::else -> st2
st2
fi
}
分岐 2
if (c) {
if
st1
::c -> st1
}
::else -> skip
fi
分岐 3
繰り返し 1
繰り返し 2
switch (y) {
if
case A: st1 ; break;
::(y==A) -> st1
case B: st2 ; break;
::else -> if ::(y==B) -> st2
...
...
}
fi;fi
for(;;) {
do
st
::true -> st
}
od
for(exp1 ;c;exp2 ) {
exp1 ;
st
do
}
::c -> st; exp2
::else -> break
od
関数呼び出し
run foo(); (p==_nr_pr) ->
foo()
表1
C 言語から Promela の変換例
例である． 両者を比較すると，プログラムの基本的
出力として取り得る値を，非決定的に対応する大域変
な制御構造は同じであることが分かる．なお，この変
数に代入するモデルを作成する．
換によって得られたモデルだけでは動作しないので，
図 4 は，図 10 に示した Promela モデルのモデ
この時点では，シミュレーションによる動作確認はで
ル検査を実施するための環境ドライバの一つである．
きない．
変数 CHK INPUT ON は，入力信号の on/off のデータ
2. モデル検査を実施するコードに影響を及ぼす他
を格納する大域変数である．入力信号が時間とともに
のタスクや外部環境を抽出し，環境ドライバを作成
変化するのと同様に，格納されるデータも変化する．
する．1 で作成したタスクのモデルの基本的な振る舞
本来のシステムでは，入力信号に対して，ノイズ除去
いを見るために，タスクが一回だけ実行されるよう
処理などを行い，その結果を変数 CHK INPUT ON に格
な環境ドライバを作成する．以下，他のタスクと外部
納するが，今回の環境ドライバでは，そうした処理を
環境をまとめて環境と呼ぶ．環境をモデル化する際，
省略し，単に 0 か 1 のどちらかが代入される仕様と
それらの処理過程をすべてモデル化する必要はない．
した．代入される値は，モデル検査時には網羅的な組
41
第四回システム検証の科学技術シンポジウム
( 7 )
Vol. 0 No. 0
1983
active proctype main () {
byte p;
p = _nr_pr;
/* initialize */
run init (); (_nr_pr == p);
/* drive environment drivers */
run drv_A (); (_nr_pr == p);
run drv_B (); (_nr_pr == p);
...
1: active proctype main () {
2:
byte p;
3:
p = _nr_pr;
4:
/* initialize */
5:
run init (); (_nr_pr == p);
6:
/* drive environment drivers */
7:
run drv_A (); (_nr_pr == p);
8:
run drv_B (); (_nr_pr == p);
9:
...
10:
11:
/* run task */
12:
do
13:
:: true ->
14:
/* drive environment drivers */
15:
run drv_a (); (_nr_pr == p);
16:
run drv_b (); (_nr_pr == p);
17:
...
18:
/* run task */
19:
run Task_f (); (_nr_pr == p);
20:
od;
21: }
/* run task */
run Task_f (); (_nr_pr == p);
}
図6
7
ワンパスモデルのメインルーチン
み合わせが選択される．また，シミュレーション時に
は，疑似非決定的に 0 か 1 が選択されるため，環境
ドライバと検査対象機能のモデルを合わせることに
より，ランダム・シミュレーション可能なモデルが得
られる．以下では，このモデルをワンパスモデルと呼
図7
周期モデルのメインルーチン
ぶ．ワンパスモデルのメインルーチンを図 6 に示す．
初期化処理用プロセス (環境ドライバ) を init，その
他の環境ドライバを drv A, drv B, · · ·，検査対象機能
の詳細モデルを Task f とする．
周期モデルでバグのあぶり出しを行う．
4. 検査対象タスクを周期的に起動する環境ドライ
バを作成する．ここで作成した環境ドライバを検査対
ワンパス用の環境ドライバは，検査対象タスクに影
象タスクのモデルをつなぎ合わせたものを周期モデ
響を与える大域変数の値をすべて非決定的に選択で
ルと呼ぶ．ここでは，3 で得られたバグ候補が，検査
きるよう作成する必要があるため，比較的作り込みに
対象タスクが周期的に起動する場合でも起きうるか
は労力を要する．
否かを確かめられる程度に詳細な環境ドライバを作
3. 検査項目を LTL 論理式で記述し，2 で作成した
成する．周期モデルをモデル検査すると，状態爆発が
ワンパスモデルに対し，モデル検査を行う．ワンパス
起こりやすいため，必要最小限のモデル化を行うた
モデルでは扱えないシステムの振る舞いに関する検
めに，ワンパスモデルに対するモデル検査で得られ
査項目もある．例えば，ループ一回の処理では完結し
たバグ候補の情報を使うことが本手法の特徴である．
ない応答性などの性質は，そのまま LTL 式で表した
周期モデルのメインルーチンを図 7 に示す．
としても，ワンパスモデルでは意図しない反例が出力
5. 最後に，周期モデルに対して検査を行う．ワン
される．こうした場合は，第 4 節で詳しく解説する
パスモデルで反例が出たとしても，周期モデルで反
が，検査式を工夫する必要がある．
例が出るとは限らない．ワンパスモデルでは，大域変
ワンパスモデルのメインルーチンはループ構造でな
数の値をランダムに環境ドライバが格納する．した
いことから，状態爆発は起きにくい．実行列も比較的
がって，繰り返しタスクを起動した場合には格納され
単純なため，検査結果を得やすく，投入する検査式の
ないパターンで値を格納するかもしれない．すると，
検討も容易である．ここで得られた反例は，変数に代
たとえワンパスモデルで反例が出たとしても，その状
入された値の組み合わせなど，実際には起こりえない
態が到達不能ならば，周期モデルでは反例が出ない．
状況を表している可能性があるが，設計者の想定から
ゆえに，単純なワンパスモデルで反例が出た場合，そ
外れた状況によって発生するバグ候補が得られる機会
の反例が周期モデルでも出るかどうかを確認するこ
でもある．ここで得られたバグ候補を列挙しておき，
とが重要である．また，ここで得られた反例もあくま
42
第四回システム検証の科学技術シンポジウム
8
( 8 )
コンピュータソフトウェア
1: if (CHK_INPUT_ON) {
2:
if (InputOnCnt < max_II_Cnt) {
3:
InputOnCnt++;
4:
} else {
5:
FunctionFlags |= FUNC_II;
6:
}
7:
InputOffCnt = 0U;
8: } else {
9:
if (InputOffCnt < max_I_Cnt) {
10:
InputOffCnt++;
11:
} else {
12:
if(global_mode == MODE1) {
13:
if(InputOnCnt >= max_I_Cnt) {
14:
FunctionFlags |= FUNC_I;
15:
}
16:
} else {
17:
if ((max_I_Cnt <= InputOnCnt) &&
18:
(InputOnCnt < max_II_Cnt)) {
19:
FunctionFlags |= FUNC_I;
20:
}
21:
}
22:
InputOnCnt = 0U;
23:
}
24: }
図9
if
:: (CHK_INPUT_ON) ->
if
:: (InputOnCnt < max_II_Cnt) ->
InputOnCnt++;
:: else ->
FunctionFlags = FunctionFlags | FUNC_II;
fi;
InputOffCnt = 0;
:: else ->
if
:: (InputOffCnt < max_I_Cnt) ->
InputOffCnt++;
:: else ->
if
:: (global_mode == MODE1) ->
if
:: (InputOnCnt >= max_I_Cnt) ->
FunctionFlags = FunctionFlags | FUNC_I;
:: else -> skip;
fi;
:: else ->
if
:: ((max_I_Cnt <= InputOnCnt) &&
検査対象機能 Task f の主要部分
(InputOnCnt < max_II_Cnt)) ->
FunctionFlags = FunctionFlags | FUNC_I;
:: else -> skip;
でバグ候補であり，反例が表す実行パスを，実際のシ
fi;
ステム上で実際に起きうるかどうかを判定する反例
fi;
InputOnCnt = 0;
解析も行う．
fi;
4 検査事例
fi;
図 10
Promela に変換された Task f の主要部分
今回取り上げる検査対象システムのモデル化について
説明する．前節で紹介した環境ドライバにもとづくモ
調べ，一定時間以上経過していなかったら (9 行目)，
デル化手法に従い，検査対象機能 Task f のモデル化
off になってからの時間を表すカウンタ InputOffCnt
を行う．関数 Task f のコードの主要部分は，図 9 に
を増やす (10 行目) ．off になってから一定時間以上経
示す．また，対応する部分を変換した Promela コー
過していた場合，on になってからの時間が T1 を超え
ド (詳細モデル) を図 10 に示す．この Promela コー
ていたら (13 行目，17 行目) ，変数 FunctionFlags
ドは，表 1 の変換規則に従い，検査対象機能 Task f
に処理 I を始めることを表すビットを立てる (14 行
の C ソースコードから得られたものである．
目，19 行目)．変数 FunctionFlags の初期値は 0，時
図 9 のコードをもとに検査対象機能 Task f の機
能説明を行う: 入力信号が on であるか調べ (1 行
間 T1 に対応する定数は，max I Cnt，T2 に対応する
定数は，max II Cnt である．
目)，on ならば 2 行目から 7 行目のコードが実行さ
実験の際に投入した検査項目のうち，本稿では，
「入
れる．2 行目では，入力信号が on になってからの時
力信号が T1 以上 on が続けば，処理 I または II のど
間が T2 を超えたか否かを調べ，超えていたら，変数
ちらかが必ず実行される」という検査項目についての
FunctionFlags に，処理 II を始めることを表すビッ
みを説明する．
トを立てる (5 行目) ．入力信号が off のときは (8 行
検査の手順に従い，はじめに，ワンパスモデル用の
目以降) ，まず入力信号が off になってからの時間を
環境ドライバを作成する．検査対象機能から変換され
43
第四回システム検証の科学技術シンポジウム
( 9 )
Vol. 0 No. 0
ᬌᩏኻ⽎એᄖߩⅣႺ
1983
ᬌᩏኻ⽎࠲ࠬࠢ
ᬌᩏ㗄⋡
⹦⚦ࡕ࠺࡞
.6.ᑼ
ࡢࡦࡄࠬ↪ⅣႺ࠼࡜ࠗࡃ
9
ࡢࡦࡄࠬࡕ࠺࡞
ࡕ࠺࡞ߪᬌᩏ㗄⋡ߏߣߦ૞ᚑ
ࡃࠣ୥⵬
๟ᦼࡕ࠺࡞
図8
採用した検査プロセスの概要 (周期モデル作成まで)
たプロセス Task f の主要部分を参考にしながら，環
と ，InputOnCnt が ちょう ど 定 数 max II Cnt で ，
境ドライバで非決定的な値の割り当てを行う変数を
CHK INPUT ON が off のとき，FunctionFlags が 0
列挙する．ここでは，以下の変数がそれに該当する:
のままである，という反例が得られる．すなわち，
CHK INPUT ON global mode
InputOnCnt InputOffCnt
InputOnCnt が max II Cnt となるときが，バグ候補
であると分かる．
例えば，変数 CHK INPUT ON は，入力信号に対応する
ため，on,off の 2 値を非決定的に代入するプロセス
を作成する．また，図 6 に示したメインルーチンを
作成し，ワンパスモデルに対するモデル検査を実施す
る．ここでの検査項目は，次の通りである:
するかを調べるための周期モデル用環境ドライバを
作成する．メインルーチンは図 7 の骨格を元にする．
環境ドライバ内で，非決定的に値の割り当てを行う変
数は，以下の 2 つだけである．
入力信号が T 1 以上 on が続いた後
さらに T1 以上 off が続けば，
次に，このバグ候補が，実際のソフトウェアで再現
CHK INPUT ON
(2)
必ず処理 I または II が実行される
global mode
変数 InputOnCnt および InputOffCnt の値は，初期
本来，無限ループ構造をもつソフトウェアであって
化処理した後は，検査対象機能のモデルのなかで増減
も，ワンパスモデルでは，1 回のループだけを再現す
を行うため，環境ドライバ内で，値の操作を行う必要
る．このため，複数回以上のループ実行で真偽を判定
はない．
する検査項目 (1) をそのまま検査に使用するのでは
検査対象機能について要求仕様では，処理 I が，入
なく，上記 (2) のように，タスクの入力時と出力時
力信号が T1 以上 T2 未満 on が続いた場合に実行さ
の変数の値に関する性質を問う検査項目に修正する．
れ，処理 II が T2 以上続いた場合に実行されると定
検査項目 (2) は，以下の検査式に翻訳される．
めている．つまり，本来の検査項目 (1) は，要求仕様
˜(b → (p ∧ q ∧ s)) → ˜(c → r)
ここで，各命題変数は以下のように定義されている．
#define
#define
#define
#define
#define
#define
b
s
p
q
c
r
main@LABEL1 /* タスク f の実行前 */
(CHK_INPUT_ON == false)
(InputOnCnt >= max_I_Cnt)
(InputOffCnt >= max_I_Cnt)
main@LABEL2 /* タスク f の実行後 */
(FunctionFlags != 0)
こ の 検 査 式 を 用 い て ，モ デ ル 検 査 を 実 施 す る
であると言える．この検査項目をモデル上の変数を用
いた言葉で表すと，以下の通りである:
変数 InputOnCnt の値が，定数 max I Cnt
以上になれば，いつかは変数 FunctionFlags
の値が 0 でなくなる
定数 InputOnCnt によって，入力信号が on になってか
らタスクが呼び出された回数が，経過時間に相当する
44
第四回システム検証の科学技術シンポジウム
10
コンピュータソフトウェア
( 10 )
実装になっているため，定数 max I Cnt は T1 に対応
らに，環境ドライバ作成と対象コードモデル作成を，
する．また，処理 I または II は，変数 FunctionFlags
分業化する実験も行っている．
の特定のビットが 1 になっていることを参照して実
本実験の対象システムのソースコードは数万行あ
行する．以上を考慮すると，検査項目は，以下の LTL
り，単純なモデル化では状態爆発を引き起こす．また，
式に翻訳される:
ソースコードの振る舞いに忠実なモデルを作り，次に
˜(p → ♦r)
ここで，p および r は次のように定義されている．
#define p InputOnCnt >= max_I_Cnt
#define r FunctionFlags != 0
上の検査式を用いた周期モデルのモデル検査では，
抽象化を施すという従来のモデル化手法では，モデル
化工程だけに長い時間を要するおそれがあり，モデル
検査の実践的な利用には適さない．いっぽうで，本実
験は，環境ドライバの着想を得てからの初の適用実験
であったことや，分業化の実験を同時に行ったことも
ワンパスモデルでの検査と同様に，InputOnCnt が
あり，本実験の結果からだけでは，モデル化作業が効
ちょうど定数 max II Cnt のときに，FunctionFlags
率的だったとは言い難い．結果的に，実際にモデル化
が 0 のままであるような反例が得られる．この反例
と検査に要した期間は，2 人×2ヶ月程度であった．
を，実際のシステム上での振る舞いに対応させて考
しかし，検査工数は着実に短縮している．本実験の
えると，図 9 をもとに，以下のような実行パスが考
後，環境ドライバの概念を基にしたモデル化手法を用
えられる: 入力信号が on の状態が，しばらく続き，
いた同規模のソフトウェアを対象としたモデル検査実
InputOnCnt の値が max II Cnt となったとする．こ
験では，4 人×9 日を実現させた [6]．モデル検査工程
こで，入力信号が off になった場合，Task f が実行
で手に負えない状態爆発に至らず，着実にバグの検出
されると，4 行目で偽になるため 11 行目以降が実行
が行えること，分業化と作業の効率化が行えることか
さる．しかし，InputOnCnt の値が max II Cnt のと
ら考えて，環境ドライバを用いたモデル検査の有効性
きは，15 行目の条件が偽であれば，21 行目の条件を
は，実験的に確かめられつつあると考えている．
満たさないため，FunctionFlags は 0 のままとなる．
実験初期に得られた考察として，以下のことが挙げ
この問題を修正する方法として，図 9 の 21 行目の
られる．周期モデルの検査の際，ループ回数が大きく
条件式が < ではなく，<= に変更すれば，この問題は
なるほど検査する状態空間が広くなり，検査が終わら
回避されるが，この修正では他の部分で別のバグを引
ない可能性が出てくると予想し，カウンタ変数を導入
き起こすことも，モデル検査により確認されている．
してループ回数を制限できるようモデル化していた．
実験ではその後，システム A の後継機種であるシ
しかし，カウンタ変数を一つでも新しく導入してしま
ステム B に対しても，本稿で説明した検査プロセス
うと，そのために状態爆発が起こりやすくなる事が検
に従ってモデル検査を実施した．この検査では，上記
査過程で判明した．現在では，ループ回数の制限を行
検査項目では反例無しの結果を得た．
わずに周期モデルに対するモデル検査を行っている．
5 考察
ワンパスモデルの役割についても，新たな考察が
得られた．当初，ワンパスモデルは，周期モデルに対
今回の検証実験では，環境ドライバを用いたモデル化
する補助的な役割のみを期待していた．しかし実験
手法を採用することにより，既知のバグを検出した．
を重ねた結果，周期モデルでは状態爆発により検査
実験前にはバグの詳細原因までは，知らされておら
できない場合でも，ワンパスモデルを用いることで，
ず，現象から推測してモデルの設計方針を立てた．
ある程度の検査結果が期待できることが分かった．周
今回の検証実験には 2 名が参加し，それぞれワン
期タスク型システムをモデル検査する場合に，ソフ
パスモデルと周期モデルを別々に担当した．モデル検
トウェア・アーキテクチャに忠実にモデルを構成しよ
査の現場導入を想定した，モデル検査工程の分業化
うとして，状態爆発を制御できない場合がある．モデ
を試みるための実験的な措置である．本実験の後，さ
ル化工程に，ワンパスモデルの作成を入れることで，
45
第四回システム検証の科学技術シンポジウム
( 11 )
Vol. 0 No. 0
モデル化の手間は増えるが，モデル検査で結果が得ら
れる可能性は高くなる．
本稿で紹介したワンパスモデルおよび周期モデルに
よるモデル検査は，古橋らの別の事例紹介論文 [6] で
提案されている「周期タスク型モデル検査法」におけ
るモデル単体テストおよび周期モデル検査とほぼ一致
している．しかし，提案するモデル検査法での検査工
程の目的が，それぞれやや異なる．周期タスク型モデ
ル検査法では，モデル単体テストは，作成したモデル
の妥当性検証のために行い，また，モデルを作成した
後でモデルの抽象化を行うことにより状態爆発の回
避を試みるのに対し，本稿で提案した手法では，ワン
パスモデルにおいてもある程度の検証を行い，また，
あらかじめ状態爆発が起きないようモデルの作成を進
めること試みている．ソフトウェア開発現場のエンジ
ニアの立場に立って考えたときに，最終的なモデルの
正当性を優先するか，モデル検査の適用可能性を優先
するかは，状況により異なる．したがって，それぞれ
のモデル検査工程が果たす役割や目的の相違点につ
いて，その是非を本論文では議論しないことにする．
謝辞. 本研究は，矢崎総業株式会社およびグループ各
社と独立行政法人産業技術総合研究所システム検証
研究センターによる共同研究「車載ソフトウェアのモ
デル検査に関する研究」(2005 年 4 月から 2007 年 3
月まで) にて実施された．共同研究に携わった各位に
感謝する．
参考文献
[ 1 ] Baker, T. P. and Shaw, A. C.: The Cyclic
Executive Model and Ada, Real-Time Systems,
Vol. 1,No. 1(1989), pp. 7–25.
1983
11
[ 2 ] 早水公二, 篠崎孝一, 高橋孝一, 渡邊宏: モデル検
査器を用いた自動検針システムの仕様検証, 情報処理
学会論文誌プログラミング, Vol. 44,No. SIG15(2003),
pp. 67.
[ 3 ] Holzmann, G. J.: The SPIN Model Checker:
Primer and Reference Manual, Addison-Wesley,
2004.
[ 4 ] IEC/SC65A/WG14: Functional safety and IEC
61508, September 2005.
http://www.iec.ch/zone/fsafety/.
[ 5 ] Katayama, T., Nakajima, T., Yuasa, T., Kishi,
T., Nakajima, S., Oikawa, S., Yasugi, M., Aoki,
T., Okazaki, M., and Umatani, S.: Highly Reliable
Embedded Software Development Using Advanced
Software Technologies, IEICE Transactions On Information and Systems, Vol. E88-D,No. 6(2005),
pp. 1105–1116.
[ 6 ] 河本孝久, 小池憲史, 古橋隆宏, 鈴木伸一: 周期タス
ク型モデル検査法と車載組込みシステムへの適用事例,
組込みシステムシンポジウム (ESS2007), 東京, 情報処
理学会, 2007.
[ 7 ] 小池憲史, 吉田聡, 大崎人士: LTL モデル検査の為の
図示記法, 第 14 回ソフトウェア工学の基礎ワークショッ
プ (FOSE2007), 下関, 日本ソフトウェア科学会, 2007
年 11 月.
[ 8 ] 丸山陽太郎, 岸知二, 片山卓也: 組込みソフトウェア
設計へのモデル検査適用手法の提案と実験・評価, 組込
みソフトウェアシンポジウム (ESS2005), 東京, 情報処
理学会, 2005, pp. 64–71.
[ 9 ] 水口大知, 渡邊宏: 組み込みソフトウェア開発にお
けるモデル検査の適用事例, コンピュータソフトウェア,
Vol. 22,No. 1(2005), pp. 70–90.
[10] 篠崎孝一, 太田弘, 早水公二, 星野光勇: モデル検査
のデバッグへの適用, ソフトウェアテストシンポジウム
(JaSST’06 in Tokyo), 東京, 2006 年 1 月.
[11] 高橋孝一, 高井利憲: システム検証における数理的
手法の紹介 – 組込みシステムへの適用事例–, システム/
制御/情報, Vol. 51,No. 9(2007), pp. 393–398.
[12] 高井利憲, 吉田聡: アセンブラプログラムのモデル検
査による検証事例, 第 5 回ディペンダブルシステムワー
クショップ (DSW2007), 函館, 日本ソフトウェア科学
会, 2007 年 7 月.
[13] 村石理恵, 服部彰宏, 野村秀樹, 山本訓稔: Model
Checking を適用した実践的非同期制御検証 – Go with
the Early Bird –, ソフトウェアテストシンポジウム
(JaSST’07 Tokyo), 東京, 2007 年 1 月.
46
第四回システム検証の科学技術シンポジウム
( 1 )
1
n 点通過テストのためのモデル検査技法
小池 憲史
大崎 人士
概要. モデル検査ツールを使用して，n 点通過テス
かの確認をしながら，徐々にモデルを作り上げていく
トを行うための検査方法について考察する．n 点通
場合が多い．モデルが意図通りの振る舞いをするかと
過テストとは，モデル記述中の任意の n 点について，
いう動作確認のための検査を，我々は予備検査と呼ぶ
各点を通過する実行列が，正順 (forward) 条件を満
[3]．例えば，プログラム中のいくつかの箇所につい
たしているかの検査である．本論文では，正順条件
て，特定の条件のもとでは，その注目箇所を想定した
をさらに一般化し，逆順 (backward) 条件や正順逆順
順序で通過するものとする．こうしたソフトウェアの
(forward-backward) 条件の概念を導入し，通常の解
振る舞いを模したモデルが，同様の振る舞いをするか
析ツールによる検査よりも，さらに踏み込んだ検証
どうかという検査は，予備検査の代表的な例である．
が，モデル検査では可能であることを示す．なお，本
さらに検査の際，我々は，特定条件を検査式として表
稿で紹介する手法は，モデル検査ツール SPIN とモ
現する場合もあるが，探索空間が著しく大きくなる場
デル記述言語 Promela の使用を前提とする．
合は，環境ドライバ [6] 等を用いて想定モデルを作成
し，予備検査を実施する．このような，モデル中の複
1 まえがき
数の箇所を想定順序通りに通過するかの確認作業を
近年，ソフトウェア開発，特に組込みソフトウェア開
我々は通過テストと呼ぶ．通過する箇所の「個数」を
発において，モデル検査の重要性が高まりつつある．
明示したい場合は，n 点通過テスト (n > 1) と呼ぶ．
大規模化，複雑化するソフトウェアに対し，タイミン
本稿では，Holzmann らが開発するモデル検査ツール
グ依存の処理や例外処理の動作をもれなく検証する
SPIN [1] とそのモデル記述言語 Promela を対象と
には，あらゆる実行パスを網羅的に検証する必要があ
して，n 点通過テストの具体的方法について述べる．
る．モデル検査は，有限モデルとして表現されたソフ
例えば，1 点通過テストであれば，Promela の持
トウェアの振る舞いを，網羅的に検証するための非常
つラベル機能と以下の LTL 検査式を用いる．検査に
に有効な手段である．しかし，ソフトウェア開発工程
より反例が検出されれば，ラベルで指定した箇所を通
の一部にモデル検査を組み込むには，まだ課題が多く
過することがありうる事を確認できる:
2¬p
残されている．その一つに，モデル化作業が挙げられ
る．モデル化作業では，ソフトウェアにおけるデバッ
ただし p は，以下の通り定義された原子述語とする:
グ作業と同様に，作成したモデルが意図通り動作する
#define p (プロセス名@ラベル名)
ここで検査した性質は，一般に到達可能性といわれ
Satoshi KOIKE, 矢崎総業 (株), Yazaki Corporation
Hitoshi OHSAKI, (独) 産 業 技 術 総 合 研 究 所, National Institute of Advanced Industrial Science and
Technology(AIST)
る．任意の n 点 (n > 1) のラベルを順序通りに通過
する検査を行う場合には，各ラベル通過の順序関係
を，LTL 検査式として表現しなければならない．と
47
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
2
ころが，Promela のラベル機能は，前述の例からも
init
分かる通り，
「モデルを構成する各ローカルプロセス
{
の状態」に依存している．それに対し LTL 検査式で
( 2 )
do
の記述は，モデル全体のグローバルな状態空間を対象
:: true ->
としている．この違いは本質的であるため，一般的な
L1:
場合を考えると，LTL 検査式のみでラベルの到達順
skip;
skip;
序を指定することは難しい．
L2:
注目箇所が 2 点以上の場合は，さらに考察すべき
skip
od
}
点がある．組込みソフトウェアに多く見られる周期駆
動型 (cyclic executive) システムを例に，モデル 1 を
モデル 1
無限周期駆動型システム
用いて解説する．モデル 1 では，無限周期内にラベ
ル L1, L2 が付与されている．この 2 点を順序通りに
通過するテストを考える．実行列中のラベルの出現順
条件と，それに対応する検査を以下に示す．
1. 正順 (forward) 検査:
序は，初期状態から見た場合には L1,L2,L1,L2· · · と
いう無限列である．n 点通過テストの表現にすると，
Li 通過の直後に，Li+1 を通過する．
2. 逆順 (backward) 検査:
「最初に L1 を通過」し，
「L1 通過の直後に，
（再び L1
を通過する前に）L2 を通過」し，かつ「L2 通過の直
Li+1 通過の直前に，Li を通過する．
3. 正順逆順 (forward-backward) 検査:
後に，L1 を通過」することに相当する．
Li を通過するならば，かつ，そのときに限り，
ここで，上述の表現は，
「L1 通過の後に，L2 を通過」
その直後に，Li+1 を通過する．
(応答性) ではないことに注意されたい．また，L1 を
前提条件として，さらに，各注目箇所へ到達可能であ
通過した後に，L2 を通過するまで，
「L1 通過」が成り
ることを保証しなければならない．この検査は，n 点
立ち続けてもいない．つまり，与えられた Promela
通過テストとは，別途実施する必要がある．n 個の各
記述に対して，イベントの順序を LTL 式の工夫だけ
点への到達性については，第 7 節で解説する．
で正確に表現するには，困難や工夫を伴う場合が多い．
こうした問題は，ソフトウェア開発現場へのモデル
3 2 点間の正順逆順検査
検査導入の阻害要因となる．モデルの設計方針を大
はじめに，単純な検査の一例として，2 点間の正順逆
きく変えることなく，モデル中の任意の点について，
順 (forward-backward) 検査の方法を紹介する．例と
n 点通過テストを実施することを目的として，各点通
して取り上げるモデル 2 は，初期状態から最初にラ
過の状態を表すカウンタ変数の具体的な導入方法と，
ベル L1 を通過し，直後にラベル L2 を通過するもの
それに伴う LTL 式フォーマットを，本稿では紹介す
とする．以降，L1 通過直後に，ラベル L2 を通過し，
る．我々の手法は，すでにモデル検査で使用した過去
しかも，L1 を通過しない限り L2 を通過しない（L2
のモデルに対しても適用可能で，かつ大きな変更を加
通過直前に，L1 を通過する）ものとする．
えることなく n 点通過テストが実施可能なことも利
点である．
一般に，実行列中に出現する連続する 2 つのラベ
ル L1 と L2 の組み合わせには，以下の 4 通りある．
1. L1，L2 の順序で出現，
2 検査方法の種類
2. L2，L1 の順序で出現，
通過テストの用語を定義する．n 点通過テストには以
3. L1，L1 の順序で出現，
下の 3 種類の検査がある:
4. L2，L2 の順序で出現．
モデル中に L1 , L2 , . . . Ln (n > 1) というのラベルが
モデル 2 の場合，実行開始時点から観測して，最初に
存在するとき，各 i (1 6 i 6 n) について成立すべき
通過するラベルが L1 であれば，以降，任意の時点で
48
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
/*
2 点通過テスト 正順逆順検査
1983
3
後となる．実際にモデル 2 の例では，2 ビット変数 f
を導入して，区間を表現する．
モデルの実行列について，初期状態からみて，最初
#define a (f == 2)
#define b (f == 1)
のラベルに到達するまでの f の値を 1 （区間 1 のと
き，f を 1）とする．もし，最初に到達したラベルが
検査式: [] (a || b)
*/
L1 ならば，f に 1 を加えるが；もし，最初に到達し
unsigned f:2 = 1;
に到達するラベルが L1 ならば，f に 1 を加えるが；
たラベルが L2 ならば，f から 1 を減ずる．以降，次
次に，到達したラベルが L2 ならば，f から 1 を減ず
active proctype p()
{
do
:: true ->
skip;
L1: atomic {
f = f + 1; /* border of region */
skip;
}
od
}
る，を繰り返す．ただし，ラベルで指定した動作は，
f への加減算と併せて不可分な動作 (atomic action)
とする．
f = 1 のときの任意の観察点で，前述の場合分けに
従って f の値の遷移を表現すると，図 3 から図 6 の
ようになる．ちなみに，これらの図は，我々が提案し
た図示記法 [4] を用いて記述している．
同様に，f = 2 のときの任意の観察点で，前述の場
合分けに従い，f の値の遷移を表現することもでき
る．場合分けによる以上の考察から，プロセス p，q
active proctype q()
{
do
:: true ->
skip;
L2: atomic {
f = f - 1; /* border of region */
skip;
}
od
}
モデル 2
2 点間の正順逆順検査
から生成されるグローバル状態の実行列中の f の値
について，以下の性質が満たされれば，仕様が満たさ
れたことになる:
2 ( f == 1 || f == 2)
以上をまとめると，2 点通過テストの正順逆順検査
を行う場合のモデルへの変更点は，2 ビット変数 (f)
の導入，初期値を 1 に設定，ラベルで指定した動作と
f への加減算を不可分動作に指定の 3 点である．モデ
ルの妥当性を検査するには，次の手順で検査を行う:
• 先に到達するラベルの直後に，f = f + 1 を追加．
• 後に到達するラベルの直後に，f = f - 1 を追加．
観測したとき，1 または 2 が仕様上の制約を満たす．
• 投入する LTL 検査式は 2(a ∨ b) の形式．
しかし先の考察でも述べた通り，ネクスト (X) 演算子
よりも疎な「直後」の概念を厳密に扱うには，
「区間
4 2 点間の逆順検査，正順検査
(region)」の概念を導入する必要がある．こうした場
前節での考察にもとづき，次に，2 点通過テストの逆
合，一般には，初期状態から最初のラベルに到達する
順検査，正順検査の具体的な方法について述べる．
までを区間 1，このラベル通過直後から次のラベルに
到達するまでを区間 2，· · · ，のように離散時間の空
間を，ラベルによって分割し，連続した区間を構成し
4.1 逆順検査
2 点間の逆順検査は，
ていく．区間の構成から明らかなように，次の区間の
開始時点が，直前の区間に含まれるラベルの通過直
L2 通過の直前に，L1 を通過する
という検査項目である．正順逆順検査と異なる点は，
49
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
4
( 4 )
ことを示す．ループ回数が 0 のとき，つまり，f が初
期値 1 のときに，L1 を通過すると，f に 1 を加える
（f = 2 になる）．もし，L1 を通過せずに，L2 を通過
すると f から 1 を減じて（f = 0 になり），逆順条件
を満たしていないことを検出可能にする．ループ回
数 k (k > 1) のときは，f = 1 と f = 2 の場合につい
図3
正しい順序
て考える．f = 1 の場合は，ループ回数 0 の場合と同
様である．f = 2 の場合に，L1 を通過すると，f は不
変である．もし，L1 を通過せずに，L2 を通過すると
f から 1 を減じる（f = 1 になる）．いずれの場合も，
帰納法の仮定より，ラベル通過までは，逆順条件を満
たしているので，ラベル通過後も逆順条件を満たす
ことになる．さらに，f の値の範囲は 0 から 3 である
図4
プロセス q の実行が優先
が，f が 3 になることはない，という考察も得られる．
逆順条件が満たされているかの判定には，第 3 節
の正順逆順検査と同様に，2(a ∨ b) の形式の LTL 検
査式を用いればよい．
4.2 正順検査
2 点間の正順検査は，
図5
L1 通過の直後に，L2 を通過する
プロセス q の実行が優先
という検査項目である．この検査も，2 点間の逆順検
査の場合と同様に，
L2 通過の直前に，L1 を通過するとは限ら
ない．
つまり，実行列中のラベルの出現が，L1 , L2 , L2 , . . .
や，L2 , L2 , L2 , . . . も許容される．
正順検査を行うためにモデルに導入するカウンタ操
図6
プロセス p, q, q の順序で実行
作部分のうち，正順逆順検査のモデルと異なる部分を
モデル 8 に示す．このモデル中のラベル L2 では，カ
L1 通過の直後に，L2 を通過するとは限ら
ウンタ操作（f への減算）を，f == 2 の場合に限定
ない
する．この変更の正当性については，逆順検査の場合
という事である．例えば，実行系列中のラベルの出現
と同様に，ループ回数に関する帰納法を用いて，次の
が，L1 , L1 , L2 , . . . であっても問題はない．こうした
性質を示すことができる．
条件の緩和に伴って，モデルに導入するカウンタ操作
常に f = 1 または f = 2 ならば，モデルは
部分を，モデル 7 のように変更する．
ラベル L1 では，カウンタ操作を行う場合を，f == 1
の場合のみに限定する．この変更の正当性について，
ループ回数に関する帰納法を用いて，
「常に f = 1 ま
たは f = 2 ならば，モデルは逆順の条件を満たす」
正順の条件を満たす．
さらに，いかなる実行列でも f が 0 になることはな
いことを示すこともできる．
正順条件が満たされているか，という判定には，第
3 節の正順逆順検査と同様に，2(a ∨ b) の形式の LTL
50
第四回システム検証の科学技術シンポジウム
( 5 )
Vol. 0 No. 0
L1: atomic {
if
:: (f == 1) -> f = f + 1;
/* border of region */
:: else
-> skip;
fi;
skip;
}
モデル 7
2 点間逆順検査
1983
5
注目箇所が 2 点の場合（n = 2 の場合）の正順，逆
順，正順逆順検査については．すでに第 3，4 節で解
説した．また，n > 2 の到達可能性の検証について
は，第 7 節で述べる．
5.2 n > 3 の場合
帰納的に n 点通過テスト (n > 3) を定義する．ラベル
L1 , . . . , Li のいずれの連続した 2 点の組み合わせに
ついては，それぞれ正順，逆順，または正順逆順の条
L2: atomic {
if
:: (f == 2) -> f = f - 1;
/* border of region */
:: else
-> skip;
fi;
skip;
}
モデル 8
2 点間正順検査
件を満たすか，どの条件も満たさない（don’t care）
とする．ここでは，正順，逆順，正順逆順条件が，ラ
ベル L1 , . . . , Li に対し混在する状況を想定する．
次に，ラベル Li+1 と Lk (1 6 k 6 i) について，必
要な 2 点間の正順，逆順，正順逆順検査を行う．各検
査の方法は，第 3，4 節で解説した通りである．
ここで，正順，逆順，正順逆順条件の連鎖性（con-
catenativity）について考察する．正順条件が連鎖的
検査式を用いる．
であるとは，Lx1 と Lx2 ，. . . ，Lxm−1 と Lxm の間
で正順条件が成り立つとき（各 j (1 6 j < m) につ
5 n 点通過テスト
いて，Lxj 通過直後に，Lxj+1 を通過するならば），
前節までに説明した 1 点および 2 点間の通過テスト
Lx1 通過直後に，Lx2 , . . . , Lxm の順に各ラベルを通
の検査方法を踏まえて，n 点通過テスト (n > 1) の
過することを意味する．逆順条件の場合は，Lxm の
実現方法について述べる．
通過直前には，Lx1 , . . . , Lxm−1 の順に各ラベルを通
以降では，n = 1 または 2 の場合 (base case) と，
過していることを意味する．いずれの条件について
n > 3 の場合 (induction case) に分けて，n 点通過テ
も，定義より明らかに連鎖的である．また，正順条件
ストでの正順，逆順，正順逆順検査の具体的な実施方
を満たすラベルの列 Lx1 , . . . , Lxm と，逆順条件を満
法について解説する．
たすラベルの列の逆順列 Ly1 , . . . , Lyn が，共通する
部分列をもつとき，その共通部分列は，正順逆順条件
5.1 n = 1 または 2 の場合
を満たすことが示せる．
注目箇所が 1 点の場合（n = 1 の場合），通過テスト
さらに，正順，逆順，正順逆順条件はいずれも，第
は，到達可能性の検査である．ラベルが 1 つのみの
2 節の定義により，それぞれ排他性（exclusiveness）
ため，正順，逆順，正順逆順条件は，いずれも満たさ
をもつ．すなわち，Lx と Ly ，Lx と Lz が正順条件
れる．したがって，残る「注目箇所」への到達可能性
を満たすとき，y ≡ z である．逆順，正順逆順条件に
を 1 点通過テストにより検証する．
ついても同様である．
モデル中のプロセス p のラベル L に注目した場合，
原子述語 a を次のように定義する:
#define a (p@L)
正順，逆順，正順逆順条件の連鎖性と排他性により，
すでに成り立っている L1 , . . . , Li の間の条件と，Li+1
と Lk (1 6 k 6 i) に成り立つ条件から，
（ L1 , . . . , L i
このとき，LTL 検査式として，2¬a を用いて反例が
が don’t care の関係を含まないならば）L1 , . . . , Li
検出されれば，L を通過する実行系列が存在すること
に対して一意に Li+1 を加えることができる．
を確認できる．
よって以上の手続きにより，n = i + 1 の場合につ
51
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
6
atomic {
Li :
#define a1 (f1 == 1)
( 6 )
fi−1 = fi−1 - 1;
#define a2 (f2 == 1)
.
.
.
fi = fi + 1;
<本来の命令>;
#define an−1 (fn−1 == 1)
}
#define b1 (f1 == 2)
モデル 10
#define b2 (f2 == 2)
.
.
.
L1 :
正順逆順検査のカウンタ操作
atomic {
f1 = f1 + 1;
#define bn−1 (fn−1 == 2)
<本来の命令>;
検査式:
n−1
^
}
i=1
モデル 11
2(
( ai ∨ bi ))
式9
正順逆順検査のラベル L1
通過テストの検査式
Ln :
atomic {
いて，n 点通過テストの正順，逆順，正順逆順検査が
fn−1 = fn−1 - 1;
実施できる．ラベル L1 , . . . , Ln に対して，そのラベ
<本来の命令>;
ルの順序で正順検査（または，逆順検査，正順逆順検
}
査）のみを行う場合は，2 点間の正順検査を逐次的に
モデル 12
正順逆順検査のラベル Ln
行う必要はなく，並列に正順検査を実施すればよい．
6.1.1 正順逆順検査
6 検査方法
ラベル Li (2 6 i 6 n − 1) における正順逆順検査のカ
本節では，実践的な n 点通過テストの利用のために，
ウンタ操作の例をモデル 10 に示す．先頭ラベル L1
モデル中の n 点のラベル L1 , L2 . . . Ln を注目箇所と
と最終ラベル Ln では，操作するラベルは 1 つのみで
し，ラベルの順序通り正順逆順（または，正順，逆
あるため，それぞれモデル 11 とモデル 12 のように
順）の条件のみを判定するための検査方法について述
カウンターを導入する．
べる．
6.1.2 逆順検査
各 i (1 6 i < n) について，ラベル Li と Li+1 の 2
逆順検査では，カウンタの加算に対して条件を緩和す
点間の検査に対し，2 ビット変数 fi を導入し，初期
る必要があるため，各ラベル Li (2 6 i 6 n − 1) で
値を 1 に設定する．投入する検査式は，正順，逆順，
のカウンタ操作は，モデル 13 のようになる．先頭ラ
正順逆順の検査の種類によらず，式 9 に示す LTL 式
ベル L1 と最終ラベル Ln でのカウンタ操作は，先の
フォーマットを用いる．
正順逆順検査と同様に，操作するラベルは 1 つのみ
である．それぞれの場合について，モデル 14 とモデ
6.1 モデル中のカウンタ操作
各ラベルで操作するカウンタは，前後のラベルとの検
ル 15 に例を示す．
6.1.3 正順検査
査と合わせて，最大 2 つある．ぞれぞれのカウンタ
正順検査では，カウンタの減算に対して条件を緩和
操作は，ラベルを付与した動作とともに，不可分動作
する必要がある．各ラベル Li (2 6 i 6 n − 1) での
(atomic action) に指定する．カウンタの導入と操作
カウンタ操作は，モデル 16 に示す通りである．また，
の具体的な方法については，以降で解説する．
先頭ラベル L1 と最終ラベル Ln でのカウンタ操作に
ついては，モデル 17 とモデル 18 にその例を示す．
52
第四回システム検証の科学技術シンポジウム
( 7 )
Li :
Vol. 0 No. 0
atomic {
Li :
7
atomic {
fi−1 = fi−1 - 1;
if
if
::(fi−1 == 2) fi−1 = fi−1 - 1;
::(fi == 1) -> fi = fi + 1;
::else -> skip;
::else -> skip;
fi;
fi;
fi = fi + 1;
<本来の命令>;
<本来の命令>;
}
}
モデル 13
L1 :
1983
逆順検査のカウンタ操作
モデル 16
atomic {
L1 :
if
atomic {
f1 = f1 + 1;
::
(f1 == 1) -> f1 = f1 + 1;
<本来の命令>;
::
else -> skip;
}
fi;
モデル 17
<本来の命令>;
}
Ln :
モデル 14
Ln :
正順検査のカウンタ操作
正順検査のラベル L1
atomic {
if
逆順検査のラベル L1
(fn−1 ==2))fn−1 = fn−1 - 1;
atomic {
<本来の命令>;
fn−1 = fn−1 - 1;
::else -> skip;
<本来の命令>;
fi;
}
}
モデル 15
逆順検査のラベル Ln
6.2 例題
モデル 18
正順検査のラベル Ln
ID が，各プロセスに振られる．フラグ数はプロセス
例題を用いて通過テストを解説する．ここで取り上げ
数-1 となる．このモデルでのフラグのインデックス
るモデル 19 は，定数 PROC 個のプロセスがトークン
は，1 ∼ PID − 1 となる．
T を介して協調動作を行う．20 行目もしくは 22 行目
プロセス ID 0 の場合のフラグ 0(f[0].f) と，プロ
で，チャンネル c からの T の受信を試み，受信でき
セス ID PROC-1 の場合のフラグ PROC(f[PROC].f) の
た場合に処理を行う．各プロセスが行う処理は，38
操作は必要ないので，このモデルでは if 命令と pid
行目の printf() 命令であるとする．処理が終了後，
の値を用いて処理を判別している．また，このモデル
再度 T を c へ送信する (40 行目)．
では，逆順検査のフラグ操作をモデル化している．他
このモデルでは，Promela の記法を用いて，一つ
のプロセス定義 p で複数のプロセスを生成している．
の検査の場合でも，前節までで述べた方法でモデル化
できる．
そのため，各プロセスでのラベル通過フラグを，変
モデルの動作は定数 ORDER によって変化する．ORDER
数名で区別する事ができない．したがって，typedef
が設定されている (0 以外の値である) 場合には 15 行
命令と配列を用いたフラグ f[_pid].f を使用してい
目の処理が有効となり，チャンネル c から受信する際
る． pid は，Promela の予約変数で，各プロセス
に，自分のプロセス ID( pid) 宛てに送信されたトー
の ID を参照できる．この場合には，0 ∼ PID − 1 の
クンのみ受信する． pid は各プロセスで固有なので，
53
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
8
トークンを受信する事ができるプロセスは，常に一つ
となる．送信する際には，ID が pid+1 のプロセス
(PROC-1 の場合には 0) に送信する (36 行目)．しかし
ORDER が設定されていない (値が 0) の場合には 17 行
目が有効となる．この場合には，どの宛先へのトーク
ンも受信が可能となる．どのプロセスが受信するかは
非決定的に選択される．Promela の各命令の詳細に
ついては，参考文献 [1] を参照されたい．
モデル検査を行うための検査式は PROCS の値によっ
て変わるが，ここでは PROCS = 3 の場合を例として
挙げる．その場合の式は，式 20 となる．この検査を
行うと，ORDER が設定されている場合には valid，設
定されていない場合には not valid となり反例を得る
事ができる．
7 最終ラベルへの到達可能性の検査
前節までの検査は，n 点間のラベルの通過順序につい
て，正順，逆順，または正順逆順の条件を満たすか
という検証である．すでに第 2 節でも述べたように，
通過順序の検証に加えて，各注目箇所への到達可能
性についても検査を行う必要がある．前節で説明し
た実践的な n 点通過テストに即して考えると，ラベ
ル L1 , L2 , . . . , Ln の順序で正順条件が成り立つ場合，
「先頭ラベル L1 通過後いつでも，いずれは最終ラベ
ル Ln を通過する」ことを検証する必要がある．つま
り，n 個の注目点すべての通過を 1 サイクルと考える
と，サイクルが途中で途切れていないことの保証に
相当する．逆順条件，正順逆順条件の場合も同様に，
ラベルの出現順序についての条件を満たしながら，サ
イクルが途中で途切れていないことを保証する必要
がある．この検証には，以下の LTL 検査式を用いれ
ばよい:
2 ( L1 → 3Ln )
(1)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
この検査式 (1) と，前述の各検査で用いる検査式を
( 8 )
#undef ORDER
#define PROCS 3
typedef flag_t {
unsigned f:2 = 1;
};
flag_t f[PROCS];
#define T true
chan c = [0] of { int, bit };
active [PROCS] proctype p()
{
byte i; /* dummy */
do
::
#ifdef ORDER
c?eval(_pid),T;
#else
c?i,T;
#endif
L:
atomic {
if /* Label i */
:: _pid == 0 -> skip /* 0 */
:: else->f[_pid].f = f[_pid].f-1
fi;
if /* Label i+1 */
:: _pid == (PROCS-1) -> skip
:: else ->
if
:: (f[_pid+1].f == 1)
->f[_pid+1].f=f[_pid+1].f+1
:: else -> skip
fi;
fi;
/* original routine */
printf("proc(%d):rcv\n", _pid);
}
c!((_pid+1)%PROCS),T
od
}
init {
c!0,T;
}
モデル 19
サンプルモデル
論理積 (∧) で組み合わせることにより，
「モデル中の
n 箇所のラベルは，先頭ラベルから想定順序でラベル
#define a1 (f[1].f==1||f[1].f==2)
を通過し，最終ラベルまで順序条件を満たす」かどう
#define a2 (f[2].f==1||f[2].f==2)
かの検証が可能になる．
検査式: 2 ( a1 ∧ a2 )
モデル 20
54
LTL 検査式
第四回システム検証の科学技術シンポジウム
( 9 )
Vol. 0 No. 0
8 関連研究
1983
9
9 まとめ
Dwyer らは，様々な論理の検査式を収集 · 分類した
本稿では，n 点通過テストの具体的な検査方法につい
検査式集 (スペックパターンと呼ぶ) を作成している
て解説した．
[5]．その中には，通過テストの十分条件に相当する検
査式が，いくつか収録されている．
は，モデル内の命令にラベルを付与し，LTL 検査式中
例えば，応答性と呼ばれる以下の検査式は，
2(p → 3s)
モデル検査ツール SPIN の記述言語 Promela で
でラベルを引用する事ができる．このラベルは，ロー
(2)
カルプロセスの振る舞いを捉えるのに有効である．し
原子述語 p，s をそれぞれ次のように定義する事によ
かし複数のプロセスが，それぞれラベルの付与され
り，プロセス proc における，ラベル L1，L2 の弱い
た動作定義を含んでいるとき，ラベル通過の「直前」
意味での 2 点正順検査である:
や「直後」を表現するには，かなりの工夫を要する．
#define p (proc@L1)
また，組込みソフトウェアで多く見られる無限周期駆
#define s (proc@L2)
動型のアーキテクチャでも同様に，ラベルの通過順序
ラベル L1 の通過後，いつかは L2 を通過するかを検
を，LTL 式のみでの表現するのは困難を伴うことが
証するというこの検査式は，2 点間の正順検査を行う
多い．本稿で提案したモデル化手法により，モデルの
前の予備検査として用いることができる．
設計方針を大きく変えることなく，n 点通過テストを
優先性 (precedence) と呼ばれる以下の検査式は，
¬p UW s (UW : weak until)
(3)
前述の p，s の定義を用いて，L1，L2 の逆順検査の予
備検査として用いることができる．
可能にすることで，モデル検査の実践的利用を後押し
することに貢献したと考える．
我々の提案する方法は，2 点間の正順逆順検査を基
本にしている．2 ビットのカウンタ変数の導入，初期
崔らは，画面遷移仕様に対するモデル検査の適用研
値の設定，ラベル通過の際のカウンタ操作という，き
究を行った [7]．崔らの研究では，Web 画面の遷移関
わめてシンプルなアイデアをもとに，n 点通過テス
係の仕様と，そのプログラム処理を表現したフロー
トと順序条件の検証方法を具体的に紹介した．また，
チャートとの間の整合性を，モデル検査ツールを用い
ローカルプロセスの振る舞いを捉えるためのラベル機
て形式的に検証した．画面遷移の順序の正しさとは，
能を，グローバル状態でもラベルを有効に活用して，
ラベルの通過順序の正しさ言い換えることができるの
LTL 検査式に反映可能であることを示した．
で，本研究との類似点を見いだすことができる．実際
検査で用いる LTL 式は，正順，逆順，正順逆順の
に，画面 a から b への遷移が仕様上に記されている
条件判定，いずれの場合も同じ LTL 式フォーマット
場合，それがフローチャートに記載されていること，
を使用する．また，カウンタ変数の値が常に 1 (また
逆に，画面 c から d への遷移がフローチャートに記
は 2) であるという原子命題も，条件判定の種類によ
載されている，相当する遷移が仕様上にも記されて
らず，同じ定義を使用する．さらに，各点への到達可
いる事を検査している．いずれの場合も，正順検査で
能性を判定するための LTL 式も，n > 2 の場合は，
ある．
同じ LTL 式フォーマットを用いることができる．こ
こうした事例からも分かるように，本稿で紹介した
うした LTL 検査式の再利用性は，モデル検査に対す
n 点通過テストのためのモデル検査技法は，広く応用
るソフトウェア開発者らの心理的な障壁を低くするの
することができる．また，正順，逆順，正順逆順条件
に効果的である．
という概念とともに，こうした条件を検証するための
本研究の方法では，2 点間の通過テストをもとに n
具体的な方法を紹介することは，モデル検査ツールの
点通過テストの議論を行っている．説明を簡単にする
利便性を，ますます高めることにつながると考える．
ため，n 点間の通過テストでは，(n − 1) 個の 2 ビッ
ト変数を用いている．しかし複数の異なる変数を用い
55
第四回システム検証の科学技術シンポジウム
10
コンピュータソフトウェア
る代わりに，2(n − 1) ビットの 1 変数を用いて，演
算を簡略化することで，簡潔なモデルを得ることも可
能である．
正順，逆順条件の判定では，2 点間の通過テストに
3 状態を要するという考察を上述の変更に加味すると，
n 点間の正順，逆順条件の判定には，d(n − 1) log2 3e
ビット変数を用いればよいことが分かる．2 ビットの
(n − 1) 変数を使用する場合に比べ，注目箇所が 4 以
上の場合には，状態空間の圧縮に役立つ．
謝辞. 本研究は，矢崎総業株式会社およびグループ各社と
独立行政法人産業技術総合研究所システム検証研究センター
による共同研究「車載ソフトウェアのモデル検査に関する研
究」(2005 年 4 月から 2007 年 3 月まで) にて実施された．
共同研究に携った各位に感謝する.
( 10 )
参考文献
[1] G.J. Holzmann:
The SPIN Model Checker:
Primer and Reference Manual, Addison-Wesley
Publishing Company, 2003.
[2] 米田友洋, 梶原誠司, 土屋達弘: ディペンダブルシステ
ム—高信頼システム実現のための耐故障・検証・テスト
技術—, 共立出版, 2005.
[3] 河本孝久，小池憲史，古橋隆宏，鈴木伸一: 周期タス
ク型モデル検査法と車載組込みシステムへの適用事例,
組込みシステムシンポジウム (ESS2007), 情報処理学
会, 2007. (採録済)
[4] 小池憲史，大崎人士，吉田聡: LTL モデル検査の為の
図示記法, 第 14 回ソフトウェア工学の基礎ワークショッ
プ (FOSE2007), 日本ソフトウェア科学会, 2007. (採
録済)
[5] M.B. Dwyer, G.S. Avrunin and J.C. Corbett:
Property Specification Patterns for Finite-state
Verification, Proc. of 2nd Workshop on Formal
Methods in Software Practice (FMSP), Clearwater
Beach (Florida), pp. 7–15, ACM Press, 1998.
[6] 高井利憲，古橋隆宏，尾崎弘幸，大崎人士: 環境ドラ
イバを用いたモデル検査検証事例, 草稿, 2007. (第 4 回
システム検証の科学技術シンポジウム 投稿準備中)
[7] 崔銀惠, 河本貴則, 渡邊宏: 画面遷移仕様のモデル検
査, コンピュータソフトウェア, 第 22 巻 3 号, 146–153
頁, 日本ソフトウェア科学会, 2005.
56
第四回システム検証の科学技術シンポジウム
( 1 )
1
Real-Time Maude によるモデル検査事例と
検査式およびモデルの修正方法
中野 昌弘
高井 利憲
本稿では、モデル検査器として Real-Time Maude
モデル検査により脆弱性が発見された場合の、脆弱性
を用いたモデル検査検証事例を報告する。検査対象
を修復するための検査対象システムに対する修正で
は、実際の事例を大幅に改変して作成した架空の組込
ある。前者におけるモデルの修正は、プログラムのデ
みシステムの仕様書である。その仕様は状態遷移図で
バッグ工程と類似しており、プログラミング経験のあ
記述され、遷移条件に時間制約が含まれる。このシス
る技術者であればある程度対応できる。また、モデル
テムには、要求仕様に対する脆弱性が含まれており、
検査を用いることにより、モデルの妥当性を確かめる
モデル検査実験では、その脆弱性を検出することに成
こともできる。これは予備検査とよばれる [5] [2]。し
功した。また、今回の実験では、モデル検査で得られ
かし、検査式作成は、プログラミングやモデル作成と
た反例の情報から、モデル、検査式およびシステムの
は別の経験を要するものである。本稿では、モデル検
修正方法の指針を得た。考察では、モデル検査におけ
査を繰り返すことにより、反例に基づき検査式を修正
る脆弱性の系統的な修正方法についても検討する。
しながら、実際に調べたいことを表す検査式を求める
過程を報告する。
1 はじめに
さらに、実験の後半では、発見した脆弱性を修復す
ソフトウェアの仕様に対してモデル検査を適用する
るための検査対象システムに対する修正案を、モデル
ことは、仕様の誤りの発見や誤りの修正の正しさの確
検査を用いて検討する過程も報告する。モデル検査
認などが期待される。モデル検査による検証プロセス
により脆弱性が特定された後に、修正方法を検討し、
は、モデル化、モデル検査、反例解析、モデルおよび
その修正方法をモデルに反映し、さらにモデル検査を
検査式の誤り修正の 4 つの工程を繰り返すことによ
行うことにより、修正方法の妥当性のを確かめること
り実施される (図 1)。モデル検査を現場導入するた
はしばしば行われる [7]。本稿では、脆弱性を表す反
めには、モデル化手法や検査式の作成などにも克服す
例を発見するだけでは、どのような修正方法を選択す
べき課題があるが、本稿では上記 4 つの工程のうち、
ればよいか不明な場合でも、修正方法を検討するため
モデルおよび検査式の誤り修正に注目する。
のモデル検査を行うことにより、修正方法の選択にも
誤り修正には二つの意味がある。一つは、モデル検
査のために作成したモデルや検査式が、実際に調べ
たいことを反映しない場合の修正であり、二つ目は、
モデル検査が有効であることを示す。
検証実験では、モデル検査器として Real-Time
Maude を用いた。Maude は、書換え論理に基づく仕
様記述言語であり、プログラム言語としての側面も持
Masahiro Nakano, (独) 産業技術総合研究所 システム検
証研究センター, [email protected]
Toshinori Takai, (独) 産業技術総合研究所 システム検証
研究センター, [email protected]
つ。SRI およびイリノイ大学で開発されている [6]。
また、partial order reduction も実装された LTL に
対するモデル検査器である Maude Model Checker
57
第四回システム検証の科学技術シンポジウム
2
コンピュータソフトウェア
( 2 )
動、v6 は終了と対応する。以下、安定値出力システ
ムに関連する仕様を列挙する。
修正済み
検査対象
各種誤り修正
反例解析
修正済み
モデル
モデル化
検査対象
モデル検査
検査式へ変換
要求仕様
修正済み
検査項目
れぞれ、v0 は停止、 v1 は初期化、 v2 から v5 は稼
1. 10 ミリ秒毎にセンサー値やスイッチの入力を読
み取り、状態を更新。
2. 電源スイッチが off の時のみ、α へ原料を追加
可能。ただし今回は、簡単のため v0 においての
み追加可能と仮定した。
3. 稼動状態でのみ、加工スイッチF2 は on となる
図1
ことが許可される。
モデル検査による誤り修正プロセス
4. 電源スイッチ F1 が off のときは、加工スイッ
を備える。 Maude のプログラム言語の機能により、
Maude で記述された Real-Time Maude [4] は、組み
チF2 が on となることは許可されない。
5. 一定時間経過することで、遷移可能となる遷移
込みシステムの記述のために Maude に時間の概念を
加えてあり、モデル検査器も利用できる。
規則がある。
6. センサー V の値は、F2 が on のときは安定せ
ず不正確であり、off になっても 600 ミリ秒経過
検査対象は、実際の組込みソフトウェアに対して
行ったモデル検査実験を元に作成した、同様の誤りや
修正が必要な仮想的な組込みシステムである。
するまでは不正確である。
7. 終了処理では、停止状態 での B の値を安定値に
するため、600 ミリ秒待つ。
検査式作成の効率化としては、著者らの研究グルー
プでは、図示記法と呼ばれる時相論理式の図的な表記
8. α は 0 ∼ 30 の値をとり、7 以上 α が増えた場
法を開発している [3]。図示記法は時相論理の論理式
合、安定値出力システムは増加を検出する。
の直感的な理解を目指しているのに対し、本稿では、
9. 安定値出力システムの内部状態は、α の 2 時点
モデル検査の反例から検査式の修正を行う過程を紹
の値から増加検出するために 0∼30, -1∼30 の値
介している。
を取る変数 A, B と、ロケーション L、タイマ T1 ,
T2 , T4 , T6 、増加フラグ J からなる。B の -1 は不
2 対象システム
検査対象は、ある生産システムの機能の一部であ
安定な値を表す。
10. 安定値を計測できたとき、その値を出力する。
る、安定値出力システムの仕様である。システム全体
図 3 の遷移のガード条件と、 3 種類のアクション:
の構成図を図 2 に示す。この生産システムは、電源
A 更新、B 更新、その他のアクションを表 1 にまとめ
スイッチ (F1 ) を持ち、電源スイッチが off のときだ
た。ここで、A 更新、B 更新は、それぞれ以下のこと
け、観測対象 α に原料を追加し、加工して排出する。
を行う。
対象 α に対するセンサー (V) は、原料の量を計測す
• A 更新 : A の値を、V の値で更新する。 A := V
る。ただし、加工スイッチ (F2 ) を on にしてから off
• B 更新 : J の条件の検査と、 B の値の更新、タ
イマ T6 の更新を行う。ここで定数 unstable は、
後の一定時間は、正確な値を計測できない。安定値出
-1 である。
力システムは、不正確な値を除去し、正確な値のみを
出力する (安定値出力)。また一定量以上原料が増加
したことも検出する (J)。
安定値出力システムは、大まかに停止、初期化、稼
動、終了のロケーションを持ち、その状態遷移図を
図 3 に示す。ここで各ロケーション v0 から v6 はそ
{J := (F2 = off ) ∧ (B = unstable) ∧ A = B + 7};
if F2 = on
then {B := unstable; T4 := 0}
else { if L = v6 ∧ T6 < 600
then {T6 := T6 + 経過時間 }
else {T6 := 0; B := V}
fi } fi
58
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
への追加/排出
観測対象
電源 Sw
センサー
1983
3
増加検出
安定値出力
安定値出力
システム
加工 Sw
表1
遷移名
L00
L01
L10
L11
L12
L22
L23
L26
L33
L34
L36
L43
L44
L45
L53
L55
L60
L61
L66
図2
生産システムの簡略化した構成図
図3
安定値出力システムの状態遷移図
安定値出力システムのガード条件 / アクション表
ガード条件
F1 = off
F1 = on
F1 = off
F1 = on ∧ T1 < 100
F1 = on ∧ T1 ≥ 100
F1 = on ∧ T2 < 250
F1 = on ∧ T2 ≥ 250
F1 = off
F1 = on ∧ F2 = off
F2 = on
F1 = off
F2 = off
F2 = on ∧ T4 < 1000
T4 ≥ 1000
F2 = off
F2 = on
F1 = off ∧ T6 ≥ 600
F1 = on
F1 = off ∧ T6 < 600
アクション
A 更新
B 更新
T1 := 0
T1 := T1 + 経過時間
T1 := 0
T2 := T2 + 経過時間
T2 := 0
T2 := 0
X
X
X
X
X
X
X
X
X
X
X
X
X
T4 := 0
T4 := T4 + 経過時間
T4 := 0
T6 := 0
T1 := 0
上述の生産システムに対する要求仕様のうち、次の
経過時間 ( ミリ秒)
10
10
10
任意 (≤ 100 − T1 )
10
任意 (≤ 250 − T2 )
10
10
任意 (≥ 10)
10
10
10
任意 (≤ 1000 − T4 )
10
10
10
10
10
任意 (≤ 600 − T6 )
観測対象 α に一定量の増加があったとき、
(1)
稼動状態で増加検出を行う。
ロケーション v2 に到達後
(2)
600 ミリ秒未満で v0 へ到達することはない。
二つを検査項目とする。
59
第四回システム検証の科学技術シンポジウム
4
コンピュータソフトウェア
検査項目 (1) は、増加検出の機能そのものである。
(2) は、少しわかりにくいが、システムの動作が終了
する場合には、必ずセンサーの値が安定するまで待
ち、安定値が得られる 600 ミリ秒経過した後に、停
止状態へ遷移することを表している。
2.1 生産システムのモデル化
図 3 および 表 1 をもとに、安定値出力システムの
( 4 )
crl [L12] :
{system(v1, A, B, t1(R), T2, T4, T6, J),
sensor(on, F2, V), PrevV, TL}
=>
{a-upate (system(v2, A, B, t1(0), t2(0),
T4, T6, false),
sensor(on, F2, V), V, TL)}
in time 10
if (R >= 100) and not(B = unstable) .
図4
Real-Time Maude による遷移規則の記述例
モデル化を行う。まず、安定値出力システムの内部状
態を system(L, A, B, T1 , T2 , T4 , T6 , J) で表し、遷
移規則を表 1 で与える。
3 モデル検査
さらに、システムの振る舞いを再現するために、入
まず調べたい性質をモデル検査する前に、モデルが
力などの環境をモデル化する。安定値出力システム
意図通りに記述されているかを検査する。仮に誤った
に対し、入力を電源スイッチF1 、加工スイッチF2 、セ
モデルに対し、モデル検査で true が返ってきてしま
ンサー V の 3 つとし、sensor(F1 , F2 , V) で表す。α
うと、誤っていることに気づかない。このリスクを避
への追加は V の値を増やす遷移規則として与え、排
けるために、初めにモデルを十分検査する。これを予
出は検査項目に関係しないのでモデル化しない。環境
備検査 [5] [2] と呼ぶ。ここでは、各遷移規則が起こり
に関する遷移規則を表 2 で与えた。
うるか、A 更新や B 更新が、意図した遷移でのみ起こ
ここでは生産システムの 1 回の動作を、任意回の
るか等の検査を行う。モデルの妥当性を十分検査した
環境の更新と、安定値出力システムの 1 回の動作と
後、2 節で示した (1) および (2) の検査項目のモデル
してモデル化した。α への原料の追加は、時間がかか
検査を行う。実験の詳細に入る前に、大まかな流れを
る作業であるが、ここでは L00 と v0-add の組み合わ
述べる。
せにより表す。
さらに、増加したことを論理式で表すために直前の
初めに、3.1 節において、検査項目 (1) の検査を
行う。この実験は、検査 1 から 検査 6 からなり、検
V の値を持つ変数 PrevV と、時間に関する性質を調べ
査 1 から検査 2 は、偽反例から、入力した検査式が
るために、タイマのリスト TL を、モデルでの状態に加
適切でないことがわかり、それを修正している過程で
える。 PrevV は遷移 L00 と、環境に関する遷移では値
ある。検査 3 において、検査対象システムの脆弱性
を変えず、それら以外の全ての遷移で V の直前の値へ
が発見されている。検査 4 から 6 は、検査 3 で発見
更新するものとする。TL は 3.4 節まで空リスト none
された脆弱性以外の脆弱性が存在しないかを調べる
であるので、後で詳しく説明する。初期状態 init を、
ための検査である。ここでは、検査 3 の脆弱性に対
{system(v0, 0, 0, t1(0), t2(0), t4(0), t6(0), false),
するシステムの修正方法を検討するための検査でも
sensor(off, off, 0), 0, none} とする。
ある。3.2 節において、 3.1 節でのモデル検査の結果
以上のモデルを Real-Time Maude で記述する。例
をふまえて、システムの修正を検討し、それをモデル
えば、L12 の遷移規則を図 4 のように記述する。遷移
に反映させている。次の 3.3 節では、修正モデルに対
は、=>の左辺にマッチする状態で、かつ if 文の条件
する検査項目 (1) の検査であり、反例なしの結果を得
を満たすとき、右辺の状態へ書き換えることで行う。
ており、脆弱性が正しく修正されていることを確認し
このとき、in time で与えられた時間 10 を経過す
ている。 3.4 節で、検査項目 (2) に対するモデル検
る。また a-update は状態から状態の関数で、A 更新
査を実施し、反例なしの結果を得ている。この検査項
を行う関数である。
目は、本実験に先立ち実施された同じ検査対象に対す
る Spin によるモデル検査では、状態爆発により検査
60
第四回システム検証の科学技術シンポジウム
( 5 )
Vol. 0 No. 0
表2
遷移名
v0-add
F1 -on
F1 -off
F2 -on
F2 -off
1983
5
安定値出力システムに対する環境の遷移規則
ガード条件
L = v0 ∧ V < 30
F1 = off
F1 = on
F1 = on ∧ F2 = off
F1 = on ∧ F2 = on
アクション
V := V + x
F1 := on
F1 := off ; F2 := off
F2 := on
F2 := off
経過時間 ( ミリ秒)
0
0
0
0
0
x : 一回の追加量。ここでは 7 とする。
できなかったものである。3.5 節の検査は、(1) に対
上限を指定できる。短い時間のパスに限ることで、モ
する検査であるが、環境を変更し、観測対象 α の増
デル検査が容易で、反例があるとき、単純な反例が得
加量を、より細かくしたときの振る舞いを調べたもの
られやすいという利点がある。この LTL 論理式を、
である。それまでの検査では、システムの典型的な動
50 ミリ秒以内のパスに対してモデル検査した結果、
作時の振る舞いを調べるために、 α の増加量を多め
L00 や v0-add を繰り返し、 v0 にとどまる反例が得
に設定していたが、より一般的な場合を想定して調べ
られた。しかし α へ追加後、v1 での初期化処理が完
るために、α の増加量を、モデルにおける最小単位と
了するまでは、システムは稼動しておらず、 “観測対
した。このモデル検査実験でも新たな脆弱性が発見さ
象 α に一定量の増加があったとき、稼動状態で増加
れた。
検出を行う” 満たさないパスではない。つまりこの反
例は、検査式が検査したいことを正確に表していない
3.1 検査項目 (1) に対するモデル検査
ことに起因する。
検査 1
実際の反例の出力例は、検査 3 で紹介する。
α に一定量の増加があった時に (α に対するセン
検査 2
サー値 V の値が、その直前の値を表す PrevV に比べ
検査 1 に対する反例解析より、最後にロケーショ
て一定以上増えていた場合)、電源スイッチを入れて
ン v0 または v1 にとどまり続けるパスは、この検査
システムを稼動させると、増加したことを検出できる
の対象外であることがわかった。これを LTL 論理式
(J が真になる) かを検査する。この条件を次のように
に次のように反映させた。
(¬32(in-v0 ∨ in-v1))
-> 2(V = PrevV + 7 -> 3J)
表した。
2(V = PrevV + 7 -> 3J)
(3)
(4)
この LTL 論理式は、
「ロケーション v0 または v1 にと
V = PrevV + 7 が α に一定量の増加があったことを、
どまり続けないパスに関しては、式 (3) の性質が成り
J は増加したことを検出することを表す。ここで、2,
立つ」 ことを表している。まず 32(in-v0 ∨ in-v1)
3 を簡単に説明する。状態の列 σ が、モデルの初期
という論理式でモデル検査を行い、 v0 , v1 で終わら
状態から始まり、定義した遷移規則でつながるとき、
ないパスが存在することを確かめた。次に式 (4) を、
σ をモデルのパス、または単にパスと呼ぶ。 p を命
400msec 未満のパスに対してモデル検査した結果、
題としたとき、2 p は、パス σ に対し p がパスの各
v0 から v6 まで遷移し、最後に F1 の on/off を繰り
状態で成り立っていることを表す。 3 p は、パスに対
返す反例が得られた。これは、環境の更新を独立し
し p が成り立つ状態がいつか現れることを表す。し
た遷移規則で与えたことにより生じた反例で、F1 の
たがってこの論理式は、「パスの各状態において、V=
on/off の動作に必要な時間を 0 としてモデル化した
PrevV+ 7 ならば、いつか J が起こる」 ことを表し
ことから生じた非現実的な実行系列を表している。す
ている。モデル検査器は、モデルの全てのパスに対し
なわち、検査式 (4) も、検査したいことを表してい
て、与えられた論理式が成り立つかを検査する。
ないことを意味する。
Real-Time Maude では、モデル検査で経過時間の
61
第四回システム検証の科学技術シンポジウム
6
コンピュータソフトウェア
( 6 )
rewrites: 23317 in 270ms cpu (274ms real) (86359 rewrites/second)
Result ModelCheckResult :
counterexample(
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,0),0,none},
’v0-add}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,7),0,none},
’v0-add}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,14),0,none}, ’v0-add}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,21),0,none}, ’v0-add}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,28),0,none}, ’v0-add}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,30),0,none}, ’L00}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,30),0,none}, ’F1-on}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,30),0,none},
’L01},
{{system(v1,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,30),30,none}, ’L11}
{{system(v1,0,0,t1(40),t2(0),t4(0),t6(0),false),sensor(on,off,30),30,none}, ’L11}
{{system(v1,0,0,t1(80),t2(0),t4(0),t6(0),false),sensor(on,off,30),30,none}, ’L11}
{{system(v1,0,0,t1(100),t2(0),t4(0),t6(0),false),sensor(on,off,30),30,none},’L12}
{{system(v2,30,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,30),30,none}, ’F1-off}
{{system(v2,30,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,30),30,none},’L26}
{{system(v6,30,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,30),30,none},’F1-on}
{{system(v6,30,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,30),30,none}, ’L61})
図5
式 5 に対する反例
検査 3
各行は、状態、次に行う遷移規則名から成り立ってい
検査 2 では検査対象の上限時間が短く、v6 で終わ
る。行の最後にカンマのある行があり、それ以降の行
る反例が得られているが、時間を長くしても L00 があ
るので時間を調整してしまい、結局同じ反例しか得ら
は、遷移のループを表す。
この反例では、初期状態より v0 から v1 へ遷移し、
れなかった。そこで対象時間を指定しないで検査を行
その後 v1 → v2 → v6 → v1 → v2 → v6 と繰り返し
うことにする。対象時間を指定する場合、 Real-Time
ている。 v1 → v2 → v6 の遷移では、V の増加判定を
Maude は可能な限りその時間まで経過するパスを探
行う B 更新を行わないため、 J が真となることはな
すが、指定しない場合は、時間に長短にかかわらず任
い。これは、繰り返しタイミングよく操作することが
意の無限長のパスを検査する。検査 2 の反例のよう
必要であるものの、仕様の誤りである。
に、トグル動作するスイッチは、容易に無限長のパス
反例を解析して、誤りの本質的な原因を発見し、モ
を生成する。したがって、検査 2 で既に得られてい
デルの修正と再検査をすることで、誤りを正すことが
る、電源スイッチの on/off の繰り返しによる無限長
できたか確認できる。しかしながら、時として非常に
のパスを検査対象から除外することにする。これを次
長くなる反例から、本質的な原因を発見することは容
の論理式で表した。
易ではない。誤りの不正確な理解は、誤った修正案に
((¬32(in-v0 ∨ in-v1)) ∧
(¬32((F1-on ∧ F1-off) ∨
(F1-off ∧ F1-on))))
-> 2(V = PrevV + 7 -> 3J)
繋がる可能性がある。そこで我々は、反例となる全て
(5)
のパスを列挙することで、誤りの本質的な原因を推測
することにする。
ここで p を命題としたとき p は、p が次の状態で
検査 4
成り立つとき真となる。F1 -on, F1 -off は、それぞれ
検査 3 以外の反例が存在しないかを検査する。つ
F1 が on, off のときに真となる。この論理式でモデ
まり、LTL 式の中で、最後に v1 → v2 → v6 と遷移
ル検査した結果、図 5 の反例が得られた。
を繰り返すようなパスを除外する。具体的には、検査
このモデル検査は 274 ミリ秒で完了し、反例が得
式を 「V= PrevV+ 7 となったときに、いつか J が起
られている。ここでは、 1 行で 1 つの状態、次に行
こるか、または、いつか以下の 3 条件を満たす」 と、
う遷移規則を表し、全体で 1 つの反例を表している。
修正する。
62
第四回システム検証の科学技術シンポジウム
( 7 )
Vol. 0 No. 0
1983
7
1. いつでも、v1 へ着くと次に v2 へ行く。かつ、
こ れ に よ り、(v1 → v2 → v6 → v1 → v0 )、
2. いつでも、v2 へ着くと次に v6 へ行く。かつ、
(v1 → v2 → v6 ) に現れる任意の遷移の組み合わ
3. いつでも、v6 へ着くと次に v1 へ行く。
せのパスを除くことができる。これを元に、以下の論
すなわち、「いつか v1 → v2 → v6 という遷移を繰り
理式を作成した。
((¬32(in-v0 ∨ in-v1)) ∧
(¬32((F1-on ∧ F1-off) ∨
(F1-off ∧ F1-on))))
->
2(V = PrevV + 7 -> (3J ∨
3(2(in-v1 -> (in-v1 U
(in-v0 ∨ in-v2))) ∧
2(in-v0 -> (in-v0 U in-v1)) ∧
2(in-v2 -> (in-v2 U in-v6)) ∧
2(in-v6 -> (in-v6 U in-v1)))))
返す」ことを表す。以下の論理式は、この条件に基づ
いて修正した検査式である。
((¬32(in-v0 ∨ in-v1)) ∧
(¬32((F1-on ∧ F1-off) ∨
(F1-off ∧ F1-on))))
->
2(V = PrevV + 7 -> (3J ∨
3(2(in-v1 -> (in-v1 U in-v2)) ∧
2(in-v2 -> (in-v2 U in-v6)) ∧
2(in-v6 -> (in-v6 U in-v1)))))
(6)
ここで p U q は、q が成り立つまで p が成り立ち続
け、かつ q はいつか成り立つことを表す。
初めに式 (6) の下線部分を除いた論理式に反例が
存在することを確認し、その後上記の論理式をモデ
ル検査した。その結果、v0 から v1 へ遷移した後、
v1 → v2 → v6 → v1 → v0 → v1 → v0 を繰り返す反
例 が得られた。ループ部に v1 → v0 , v0 → v1 の遷移
も含まれるているが、これらの遷移でも B 更新が起こ
らない。このため、 J の条件を満たすが、 J の更新
が起こらない。これも検査 3 と同様、タイミングよく
繰り返し入力する必要があるものの、仕様の誤りであ
る。また、同じ原因から、v1 → v2 → v6 → v1 → v0
を繰り返す遷移も反例となることが分かる。
検査 5
検査 3, 検査 4 以外の誤りが存在するかを検査す
る。検査 3 と同様に、v1 → v2 → v6 → v1 → v0 を
繰り返す反例も取り除く LTL 論理式を作成すること
も可能であるが、ここではもう少し考察を深める。
誤りの原因は、これらの遷移には B 更新が含まれ
ていないからであるので、これらの遷移だけを使っ
た、より複雑な繰り返しをするパスも反例となること
が分かる。したがって、これまで得られた不正な遷移
の任意の組み合わせによるパスを除くこととする。
1. いつでも、v0 へ着くと次に v1 へ行く。かつ、
2. いつでも、v1 へ着くと次に v0 または v2 へ行
(7)
この論理式をモデル検査した結果、図 6 の反例が
得られた。ただし反例は長いので、一部省略した。
この反例は、これまでと大きく異なる。特に重要
な遷移は、図 7 に示した 4 つの遷移で、まず v3 で B
が unstable となった後、 v0 で V に一定量の増加が
ある。B 更新を行う時に B が unstable であると、差
を検出できないので、J は false となり、増加検出が
起こらない。
この例において、B が unstable となるのは、F2 を
on にすることで正確な値を読むことができないため
であり、正常な動作である。ただしこの例が示すよう
に、B が unstable であるときに V を一定量追加して
も、その後の B 更新で検出することができない。さ
らにこのとき、B は現在の V の観測値で更新される
ので、PrevV との差がなくなり、これ以後検出でき
ない。
そもそも仕様として、「 7. 終了処理では、v0 での
B の値を安定値にするため、600 ミリ秒待つ。」とし
ており、v0 では B が unstable ではないことを前提と
している。しかし検査項目からは漏れており、この誤
りを発見するのに多くの時間を必要とした。
検査 6
さらに、検査 3 から 検査 5 で得られた誤りと異な
る反例が存在するかを調べる。検査 5 で得られた反
例を取り除くため、ロケーション v0 で B が unstable
とならないパスに対してのみ検査するよう、下記のよ
く。かつ、
3. いつでも、v2 へ着くと次に v4 へ行く。かつ、
4. いつでも、v4 へ着くと次に v1 へ行く。
63
第四回システム検証の科学技術シンポジウム
8
コンピュータソフトウェア
( 8 )
counterexample(
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,0),0,none},
’v0-add}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,21),0,none},
’L00}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,21),0,none},
’F1-on}
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,21),0,none},
’L01}
{{system(v1,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,21),21,none},
’L11}
{{system(v1,0,0,t1(100),t2(0),t4(0),t6(0),false),sensor(on,off,21),21,none},
’L12}
{{system(v2,21,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,21),21,none},
’L22}
{{system(v2,21,21,t1(0),t2(250),t4(0),t6(0),true),sensor(on,off,21),21,none},
’L23}
{{system(v3,21,21,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,21),21,none},
’F2-on}
{{system(v3,21,21,t1(0),t2(0),t4(0),t6(0),false),sensor(on,on,21),21,none},
’L33}
{{system(v3,21,unstable,t1(0),t2(0),t4(0),t6(0),false),sensor(on,on,21),21,none},
’F1-off}
{{system(v3,21,unstable,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,21),21,none},
’L36}
{{system(v6,21,unstable,t1(0),t2(0),t4(0),t6(10),false),sensor(off,off,21),21,none}, ’L66}
{{system(v6,21,unstable,t1(0),t2(0),t4(0),t6(310),false),sensor(off,off,21),21,none}, ’L66}
{{system(v6,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(off,off,21),21,none}, ’F1-on}
{{system(v6,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(on,off,21),21,none}, ’L61}
{{system(v1,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(on,off,21),21,none}, ’F1-off}
{{system(v1,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(off,off,21),21,none}, ’L10}
{{system(v0,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(off,off,21),21,none}, ’v0-add}
{{system(v0,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(off,off,30),21,none}, ’L00}
{{system(v0,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(off,off,30),21,none}, ’F1-on}
{{system(v0,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(on,off,30),21,none}, ’L01}
{{system(v1,21,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(on,off,30),30,none}, ’L11}
{{system(v1,21,unstable,t1(100),t2(0),t4(0),t6(600),false),sensor(on,off,30),30,none},’L12}
{{system(v2,30,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(on,off,30),30,none}, ’L22}
{{system(v2,30,30,t1(0),t2(250),t4(0),t6(0),false),sensor(on,off,30),30,none},
’L23}
図6
式 (7) の反例
{{system(v3,21,unstable ,t1(0),t2(0),t4(0),t6(0),false),sensor(on,on,21),21,none},
’F1-off}
・
・
・
{{system(v0,21,unstable ,t1(0),t2(0),t4(0),t6(600),false),sensor(off,off,30),21,none}, ’L00}
・
・
・
{{system(v2,30,unstable,t1(0),t2(0),t4(0),t6(600),false),sensor(on,off,30),30,none}, ’L22}
・
・
・
{{system(v2,30,30,t1(0),t2(250),t4(0),t6(0),false),sensor(on,off,30),30,none},
’L23}
図7
図 6 の反例の抜粋
た。その結果、モデル検査器は 約 10 秒で true を返
うに修正した。
((2(in-v0 -> ¬(B = unstable))) ∧
(¬32(in-v0 ∨ in-v1)) ∧
(¬32((F1-on ∧ F1-off) ∨
(F1-off ∧ F1-on))))
->
2(V = PrevV + 7 -> (3J ∨
3(2(in-v1 -> (in-v1 U (in-v0 ∨ in-v2)))∧
2(in-v0 -> (in-v0 U in-v1)) ∧
2(in-v2 -> (in-v2 U in-v6)) ∧
2(in-v6 -> (in-v6 U in-v1)))))
した。これにより、これまでに得られた誤り以外の
反例が存在しないことが分かった。したがって、得ら
れた誤りが無くなるように修正すればよいことが分
(8)
-> の前までである、パスの前提条件を満たすパスが
存在することをを確認した後、式 8 をモデル検査し
かった。
3.2 モデルの修正
これまでのモデル検査の結果を踏まえて、モデルを
修正する。
モデル検査の結果得られた反例以外に、反例が存在
64
第四回システム検証の科学技術シンポジウム
( 9 )
Vol. 0 No. 0
するかを検査するため、これまで繰り返し検査式を
1983
9
3.3 検査項目 (1) に対するモデル検査 (修正モ
デル)
修正してきた。この修正した検査式が、モデルをどの
ように修正すべきかを表している。仕様の誤りを発
修正モデルに対し、検査 3 から 5 で発見された誤
見した、検査 3 から検査 5 で得られた反例を除くた
りが修正されたかをモデル検査により確認する。ま
め、以下の論理式を加えた。
ず、検査 5 で発見した、以下の論理式を検査し、約 3
1. 3(2(in-v1 -> (in-v1 U (in-v0 ∨ in-v2))) ∧
秒で true が得られた。
2(in-v0 -> (in-v0 U in-v1)) ∧
2(in-v0 -> (B = unstable))
(9)
2(in-v2 -> (in-v2 U in-v6)) ∧
2(in-v6 -> (in-v6 U in-v1)))
2. 2(in-v0 -> ¬(B = unstable))
検査 3 および 4 より、1 が示すパスを通るときにも
また、検査 3 から検査 5 で発見された誤りが修正で
きたことを以下の論理式に対して、 約 3 秒で true が
得られることから確認した。
((¬32(in-v0 ∨ in-v1)) ∧
(¬32((F1-on ∧ F1-off) ∨
(F1-off ∧ F1-on))))
-> 2(V = PrevV + 7 -> 3J)
B 更新を行い、増加検出を可能なように修正する。検
査 5 より、v0 で B が unstable とならないように遷
移規則を修正する。そしてこれらの修正で、この性質
に関する全ての誤りが修正されることが、検査 6 の
(10)
これにより、全ての誤りを修正したモデルが得られた
ことを確認した。
結果より期待できる。
修正後モデルを、図 8 に示す。図 3 と比べ、太字
の遷移規則を修正、または追加し、B 更新も修正し
た。その修正した遷移を表 3 にまとめた。
仕様の修正は、誤りの修正だけでなく、v6 で安定
3.4 検査項目 (2) に対するモデル検査
v0 へ戻るときに、L60 により安定値の書き込みが
起こるかを検査するための項目である。この項目を論
理式で次のように表した。
値が得られている場合にも、不要な安定値待ちをし
2((in-v2 ∧ 3in-v0)
-> (¬ in-v0 U 600-msec-passes))
ていた点も修正した。この修正は、モデル検査によっ
(11)
て仕様のより深い理解が得られたので、行うことがで
ここで 600-msec-passes は、v2 に到達後、600 ミリ
きた。修正項目は以下のとおりである。
秒経過したかを表す述語で、この述語を利用するため
1. v1 → v2 → v6 等のループ時にも B 更新が起こ
るように L26 で B 更新を行うように修正
2. v0 で B が unstable とならないように L10 を
に TL に v2 から v0 までの経過時間を計るタイマを状
態表現に加えてある。このタイマは、600 ミリ秒経過
の判定のみに用いるので、タイマの上限を 600 ミリ
秒に抑えた。
修正
3. v6 において、B が unstable 時のみ、センサー
の値が安定するまで待機
4. v6 での待機時間を、F2 = off ∧ B = unstable と
なってからの時間に修正。
5. B 更新を次のように修正。
{J := (F2 = off ) ∧ (B = unstable) ∧ A = B + 7};
if F2 = on
then {B := unstable; T6 := 0}
else { if B = unstable ∧ T6 < 600
then {T6 := T6 + 経過時間 }
else {T6 := 0; B := V}
fi } fi
この論理式は、L60 の仕様修正によって、待ちが不
要な場合では成り立たたなくなっており、モデル検
査でもそれを確認できる。そこで、v6 において B =
unstable となる遷移では、安定値の書き込みが起こ
ることを確認する。これを以下のように表した。
2((in-v6 ∧ (B = unstable) ∧ 3in-v0)
->(¬ in-v0 U 600-msec-passes))
(12)
初期状態から v6 に到達する時、v2 を経由している
ことに注意されたい。モデル検査の結果、約 90 秒で
true を返した。
同様のモデル検査を、同じ計算機上で Spin を用い
て行ったが、状態爆発のために検査できなかった。
65
第四回システム検証の科学技術シンポジウム
10
( 10 )
コンピュータソフトウェア
図8
表3
L10
L16
L26
L60
L66
システムの状態遷移図 (修正後モデル)
ガード条件 / アクション 表 (修正後モデル 差分)
ガード条件
F1 = off ∧ ¬(B = unstable)
F1 = off ∧ (B = unstable)
F1 = off
F1 = off ∧ (B = unstable ∨ T6 = 600)
F1 = off ∧ T6 < 600 ∧ B = unstable
3.5 環境をより詳細にモデル化した場合の、検査
項目 (1) に対するモデル検査
アクション
T1 := 0
T1 := 0
T2 := 0
T6 := 0
A 更新
B 更新
X
X
X
X
X
X
経過時間 ( ミリ秒)
10
10
10
10
任意 (≤ 600 − T6 )
ている。その結果、全部で 7 以上の追加を行っても、
一度も増加検出が行われていない。一度に 7 以上追
生産システムをモデル化するとき、 v0-add の一回
加すれば問題ないことは、 3.3 小節の結果より確認さ
の追加量を、一回の追加で増加検出ができるように、
れているので、PrevV の更新を増加検出に成功した時
7 と仮定して行ってきた。ここでは、一回の増加量を
のみ行うことで、これまでの論理式でも誤りを発見す
1 として再検査する。検査式は 13 のように修正した。
ることができる。
V = PrevV + 7 から下線部のように修正した理由は、
このモデルにおいて V = PrevV + 7 が真になること
上記のように環境を修正したモデルに対し、以下の
論理式が true を返すことを確認した。
((¬32(in-v0 ∨ in-v1)) ∧
(¬32((F1-on ∧ F1-off) ∨
(F1-off ∧ F1-on))))
->
2((V = PrevV + 7 ∧ B = PrevV) -> 3J)
は無いからである。修正した検査式では、初期状態で
は V = 0 であるので、追加を繰り返せば、V = 7 がい
つか真となる。
((¬32(in-v0 ∨ in-v1)) ∧
(¬32((F1-on ∧ F1-off) ∨
(F1-off ∧ F1-on))))
->
2(V = 7 -> 3J)
(14)
これは、B の値を修正した PrevV の値と修正するこ
(13)
この検査式に対しモデル検査した結果、図 9 の反例
とを示唆している。ただし、B は不安定な値を表す
unstable も取るので、不安定な値を表す専用のフラ
グを状態表現に追加する。
が得られた。反例は長いので、一部省略した。この反
以上のように修正したモデルでは、追加量の多寡に
例では、V に 4 追加、B 更新、 V に 4 追加 B 更新と行
かかわらず、合計して一定量以上 α へ追加すれば増
うことで、増加検出に成功しなくとも B が更新され
加検出できることを、モデル検査により確認した。
66
第四回システム検証の科学技術シンポジウム
( 11 )
Vol. 0 No. 0
1983
11
rewrites: 160833 in 1470ms cpu (1467ms real) (109410 rewrites/second)
Result ModelCheckResult :
counterexample(
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,0),0,none},
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,4),0,none},
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,4),0,none},
{{system(v0,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,4),0,none},
{{system(v1,0,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,4),4,none},
{{system(v1,0,0,t1(100),t2(0),t4(0),t6(0),false),sensor(on,off,4),4,none},
{{system(v2,4,0,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,4),4,none},
{{system(v2,4,4,t1(0),t2(250),t4(0),t6(0),false),sensor(on,off,4),4,none},
{{system(v3,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,4),4,none},
{{system(v3,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,4),4,none},
{{system(v6,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,4),4,none},
{{system(v6,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,4),4,none},
{{system(v1,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,4),4,none},
{{system(v1,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,4),4,none},
{{system(v0,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,4),4,none},
{{system(v0,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,8),4,none},
{{system(v0,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,8),4,none},
{{system(v0,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,8),4,none},
{{system(v1,4,4,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,8),8,none},
{{system(v1,4,4,t1(100),t2(0),t4(0),t6(0),false),sensor(on,off,8),8,none},
{{system(v2,8,4,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,8),8,none},
{{system(v2,8,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,8),8,none},
{{system(v2,8,4,t1(0),t2(0),t4(0),t6(0),false),sensor(off,off,8),8,none},
{{system(v2,8,4,t1(0),t2(0),t4(0),t6(0),false),sensor(on,off,8),8,none},
{{system(v2,8,8,t1(0),t2(40),t4(0),t6(0),false),sensor(on,off,8),8,none},
図9
’v0-add}
’L00}
’F1-on}
’L01}
’L11}
’L12}
’L22}
’L23}
’F1-off}
’L36}
’F1-on}
’L61}
’F1-off}
’L10}
’v0-add}
’L00}
’F1-on}
’L01}
’L11}
’L12}
’F1-off}
’F1-on}
’F1-on}
’L22}
’F1-off}
式 13 の反例
3.6 実験に対する考察
2(φ → 3ψ) の反例として、2(φ → (¬3ψ ∧ 32p))
検査式の修正
を満たすような実行パスが得られた場合、すなわち、
検査 1 および 2 では、得られた反例は、仕様上問
φ が成り立った後に、ψ は成り立たないが、ある時点
題のない実行パスを表していたり、モデル化によって
から p が成り立ち続けるような場合には、検査式を
混入した、実際のシステムではあり得ない実行パスを
2(φ → (3ψ ∨ 32p))
表していた。そのような場合の検査式の修正方法は、
と修正しモデル検査を行っている。これも、得られ
得られた実行パスも真とするよう修正した。例えば、
た反例を真とするような変更である。ここで、検査
検査式 φ の反例として、ある時点から命題 p が成り
式 (15) と (16) の命題 p は、ともに今回の実験では
立ち続ける実行パスが得られ、それが仕様上問題ない
ロケーションに関する命題であった。p の取り方は任
のであれば、検査式を、
意であり、対象システムに依存すると考えられる。
¬32p → φ
(15)
と修正した。
(16)
得られた反例に対しこのような修正を加えること
より、異なる原因による複数の脆弱性の検出が可能に
検査対象の修正方法
なる。これらの脆弱性をすべて列挙した後に検査対象
検査 3 では、検証対象仕様の脆弱性を表す反例が
仕様の修正方法を検討することにより、誤りのない修
得られた。実験では、ここで直ちにモデルの修正を
正が可能になると考える。
行うのではなく、検査 3 で得られた脆弱性以外の脆
弱性が仕様に含まれているか否かを調べるための検
査を、検査 4 から 6 で行っている。例えば、検査式
67
第四回システム検証の科学技術シンポジウム
12
コンピュータソフトウェア
( 12 )
6. 正しくモデルを修正できたかを確認 (修正モデ
4 おわりに
ルに対する検査)。
Real-Time Maude によるモデル検査により、仕様
3.4 節で行った検査は、Spin によるモデル検査実
やモデル、検査式にある誤りを発見・修正する過程
験では、状態爆発により 24 時間、32Gbyte のメモリ
を、事例に基づいて説明した。特に、反例から検査
でも検査を完了しなかった。このモデルでは最大 3
式の修正、誤りを全て避ける検査式からモデルの修
つのタイマが同時に作動し、状態を爆発させる原因
正、修正モデルに対する再検査のプロセスに焦点を当
となっている。しかしながら Real-Time Maude で
てた。
は、非常に早い時間、少ないメモリ (1G 未満) で検査
モデル検査により、検査項目の曖昧性や、意図した
を完了できた。これまで Maude Model Checker は、
ことを正確に表していなかったことに気づく。今回の
Spin の半分程度の性能と言われてきたが [1]、問題に
事例では、モデル検査の反例を解析することで、以下
よっては Spin よりも効果的に解くことができること
のことを行うことができた。
を確認した。
1. 曖昧・不正確な検査式の修正 (検査 1、検査 2)。
意図通りの論理式の記述は難しく、またモデル化
法により実際には起こらない反例も得られる。論
理式の修正により、こうした問題に対処した。
2. 仕様に、検査項目を満たさない誤りがあること
を検出 (検査 3)。
モデル検査により、入力のタイミングに強く依存
謝辞. 本研究は，矢崎総業株式会社と独立行政法人産
業技術総合研究所システム検証研究センターによる
共同研究「車載ソフトウェア開発プロセスへのモデ
ル検査技術の現場導入のための研究」(2007 年 4 月か
ら 2008 年 3 月まで) にて実施された．共同研究に携
わった各位に感謝する．
する、テストでは発見困難な誤りを検出した。
3. 他の誤りを発見するための検査式の修正 (検
査 4、5、6)。
誤りの修正は、場当たり的に行うよりも、問題の
全体像を把握した上で行うほうが、適切な修正
を行いやすい。検査式の修正を繰り返すことで、
異なる反例を探す方法を適用した。検査 6 では、
異なる反例が得られなくなり、その後この結果を
元に、モデルの修正を行った。
4. 漏れていた重要な検査項目を発見 (検査 5)。
反例解析を通じて、設計に隠された不変式 (v0 で
は常に B = unstable) を発見した。不変式はモ
デル検査の項目として効果的であり、設計やテス
ト、仕様の修正においても利用価値の高い情報で
ある。
5. 他の誤りを発見するために修正を繰り返した検
査式から、モデルの修正。
誤りのため除去したパスが、起こらないようにモ
デルを修正する。または、そのパスにおいても誤
りにならないように、修正する。
参考文献
[1] Eker, S., Meseguer, J., and Sridharanarayanan,
A.: The Maude LTL Model Checker, WRLA ’02,
Electronic Notes in Theoretical Computer Science,
Vol. 71, 2002.
[2] 河本孝久, 小池憲史, 古橋隆宏, 鈴木伸一: 周期タスク
型モデル検査法と車載組込みシステムへの適用事例, 組
込みシステムシンポジウム (ESS2007), 情報処理学会
組込みシステム研究会, 2007. (採録決定済).
[3] 小池憲史, 吉田聡, 大崎人士: LTL モデル検査の為の
図示記法, 第 14 回ソフトウェア工学の基礎ワークショッ
プ (FOSE2007), 下関, 日本ソフトウェア科学会 ソフ
トウェア工学の基礎研究会, 2007 年 11 月. (採録決定
済).
[4] Ölveczky, P. C. and Meseguer, J.: Specification
and Analysis of Real-Time Systems Using RealTime Maude, FASE 2004, LNCS, Vol. 2984, 2004,
pp. 354–358.
[5] 高井利憲, 古橋隆宏, 尾崎弘幸, 大崎人士: 環境ドライ
バを用いたモデル検査による検証事例, 第 4 回システム
検証の科学技術シンポジウム, 名古屋, 2007 年 11 月.
(投稿中).
[6] URL: http://maude.cs.uiuc.edu/.
[7] 村石理恵, 服部彰宏, 野村秀樹, 山本訓稔: Model
Checking を適用した実践的非同期制御検証 – Go with
the Early Bird –, ソフトウェアテストシンポジウム
(JaSST’07 Tokyo), 2007 年 1 月.
68
第四回システム検証の科学技術シンポジウム
( 1 )
1
アセンブラプログラムのモデル検査によるバ
グ解析事例
高井 利憲
吉田 聡
概要. 詳細なフローチャートによる設計仕様書が存在
想される原因を，短期間で究明されたことを報告され
するアセンブラプログラムに対して行った, モデル検
ている [2] [4]．今後，数理的技法がソフトウェア開発
査による不具合解析事例を報告する．事前の検査によ
現場へ導入される場合には，不具合解析手法としての
り発見されたソースコード上の脆弱性が，不具合に繋
導入も費用対効果の面でも有力候補であると考える．
がるか否かを調べるために，フローチャートをスライ
しかし，モデル検査による不具合解析においても，
シングし，ソースコード上の脆弱性を再現できる程度
「反例なし」の結果が得られた場合には，そのシステ
の抽象的なモデルを作成した．そのモデルに対し，モ
ムに対しては不具合の原因について何も言えないこ
デル検査を行い，不具合解析を行った．結果として，
とが多い．本稿では，
「反例なし」の結果が得られた
不具合の原因究明には至らなかったが，モデル検査
場合でも，適切に抽象化したモデルを用いたモデル検
は，不具合時の振る舞い解析に対し，有効な手段であ
査であれば，不具合解析に対して有力な情報が得られ
ることがわかった．本事例は企業との共同研究により
ることがあり得ることを示す．
実施された．
本報告では，ある組込みシステムに対してモデル検
査を用いた不具合解析を行った事例について報告す
1 はじめに
る．すでに著者らが発表している事例の後半部分 [3]
組込みシステムに対して，数理的技法を用いた不具
であり，前回は，ソースコードを忠実にモデル化した
合解析事例がすでにいくつか報告されている [2] [4]．
モデルによる検証実験であるのに対し，今回はその
組み込みシステムの不具合は，その原因がハードウェ
過程で発見された脆弱性が，実際の不具合に繋がる
アにあるのかソフトウェアにあるのか明らかではな
か否かを調べるために作成した抽象モデルによるモ
い場合，その解析にかかるコストは，見積もりが難し
デル検査の実験報告である．結果として，抽象モデル
い．特に，ソフトウェアに関しては，系統的な解析方
によるモデル検査では，反例が得られず，原因究明ま
法が確立されているとはいい難く，どこまで何を検査
でには至らなかったが，モデル化の対象であるフロー
すれば，どんなことが言えるのかが明らかではない．
チャートで記述された仕様に対しては，原因がないこ
すでに報告されている数理的技法，特にモデル検査を
とがいえた．また，モデル検査は，不具合発生時のシ
用いた組み込みシステムの不具合解析事例では，テス
ステムの振る舞いを反例として再現することが容易
トやレビューなどのなどの従来手法では発見困難と予
であり，不具合時の振る舞い解析に対し，有効な手段
であることがわかった．
Toshinori Takai, (独) 産業技術総合研究所システム検証
研究センター
Satoru Yoshida, (独) 産業技術総合研究所システム検証
研究センター
アセンブラプログラムに対するモデル検査による検
証の先行事例として，宇佐見らの報告がある [1]．宇
佐見らの報告でも，アセンブラプログラムから「半自
69
第四回システム検証の科学技術シンポジウム
2
( 2 )
コンピュータソフトウェア
動的」にモデルの生成を行っている．さらにアセンブ
࠮ࡦࠨ
ラプログラムの詳細モデル，つまりレジスタの振る舞
A
いを再現するレベルのモデルでの検証は，状態爆発
により困難であると述べられているが，本稿で報告
する事例でも，同じ結論が得られている [3]．宇佐見
ࡐ࡯࠻
㧔౉ജ㧕
%27
ࡐ࡯࠻
㧔಴ജ㧕
ㆫ⒖ࠬࠗ࠶࠴
࠮ࡦࠨ࡯ࠬࠗ࠶࠴
らの報告ではモデル検査器として，MuSMV を用い
ており，アセンブラプログラムの性質を記述するため
には，CTL が適していることを示している．本報告
࠮ࡦࠨ
B
の事例では，モデル検査器として SPIN を用いたが，
検査したい性質は，システムレベルの性質が多かった
図1
検証対象システムの概要
ため，LTL でも記述可能であった．
合 Y が発生し，それに伴いシステムが休止モードに
2 検査対象システム
遷移し，不具合 α を引き起こしていると予想されて
検査対象は，著者らがすでに報告している事例報
いた．
告 [3] と同じ，ある組込みシステムである．今回，モ
ソースコードはアセンブラで記述され，約 1 万行
デル検査の対象とした不正代入にかかわる機能の概
である．また，要求仕様やハードウェアの仕様を含む
要は次の通りである．A と B という 2 つの状態があ
仕様書があり，さらに，ソースコードのプログラム構
り，それらは交互に遷移する．CPU のポートについ
造をほぼ忠実に表現する A4 で 20 ページ程の詳細な
て，出力は状態を遷移させるスイッチと，各状態にあ
フローチャートが存在した．
ることを確認するセンサーのスイッチに対して割当て
られおり，入力はセンサーからの信号に対して割当て
3 モデル検査による検証
られている．なお，ポートには，特定の変数が対応付
3.1 概要
けられており，それらの変数への書込みによりポート
モデル検査による検証は 2 段階に分けて行った．
への出力を行ったり，それらの変数からの読込みによ
図 2 に全体の流れを示す．はじめに，ソースコード
りポートへの入力を行う (図 1)．また，システム全体
を忠実にモデル化した詳細モデルを作成し，シュミ
としては，正常動作を表す通常モードと，ハードウェ
レーションによる検査を行った．このモデル化の過程
アを保護するための休止モードからなる．休止モード
で，値とアドレスを取り違える不正代入を発見した．
は，ハードウェアが期待する動作を行わなかった場合
以降ではこの脆弱性を，脆弱性 X と呼ぶことにする．
に，遷移する仕様となっており，遷移した場合には，
以上の検証実験については，すでに発表した著者ら
以降では状態 A および B の遷移は行われなくなる．
の報告 [3] に説明している．詳細モデルのモデル検査
要求仕様として，
「システムは A または B にとど
は，モデルが巨大になりすぎて，状態爆発によりモデ
まり続けることはない」というものがある．しかし，
ル検査はおわらなかった．
実際のシステムは，動作を初めてしばらくすると，シ
次に，この不正代入が不正な振る舞いを引き起こす
ステムが B にとどまり続けてしまう現象が報告され
か否かを調べるために，この不正代入が関係する機能
ている．この不具合を不具合 α と呼ぶことにする．
の振舞いを仕様書におけるフローチャートから抜粋
ハードウェアに対する不具合解析では，不具合 α が
し，それを基に抽象モデルを作成した．
観察された時点の実機を解析してみたところ，ポート
に関する不具合が確認されている．この不具合をポー
3.2 準備
トの不具合 Y と呼ぶことにする．モデル検査による
本研究において与えられた抽象モデルは, 最初に与
検証を始める前では，何らかの原因でポートの不具
えられたフローチャートに対して適当な抽象化を行
70
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
࠰࡯ࠬࠦ࡯࠼
ਇᱜઍ౉ߦ㑐ଥߔ
ࠆᯏ⢻ߩࡈࡠ࡯
࠴ࡖ࡯࠻
図2
ࡕ࠺࡞ᬌᩏ
࠴ࡖ࡯࠻
᛽⽎ࡕ࠺࡞
⹦⚦ߥࡈࡠ࡯
ਇᱜઍ౉߇ਇౕวߩ
ᄖㇱⅣႺߩࡕ࠺࡞
ߩ઀᭽ᦠ
ේ࿃߆ุ߆ߩ⚿ᨐ
ࡂ࡯࠼࠙ࠚࠕ
ਇᱜઍ౉ߩ⊒⷗
ࠕ࠮ࡦࡉ࡜ߩ
ࠪࡒ䳡࡟䳦ࠪ䳢ࡦ
๮઎ߏߣߩࡕ࠺࡞
⹦⚦ࡕ࠺࡞
ࠕ࠮ࡦࡉ࡜ߩฦ
઀᭽ᦠ
ඨ⥄േ⊛ߥᄌ឵
ࠕ࠮ࡦࡉ࡜ߩ
1983
3
p,q
p,q
p,!q
p,q
p,!q
p,!q
p,!q
!p,!q
!p,!q
!p,!q
!p,!q
!p,!q
モデル検査の流れ
(p,q は原始命題. !p, !q は p,q の否定)
い, そこで得られたフローチャートから与えたモデル
図3
である. その抽象化されたフローチャートから得られ
足踏同値な２つのパス
たモデルが表現するクリプキ構造は, 最初に与えた詳
であるという: ともに初項が 0 である２つの狭義単調
細モデルが表現するクリプキ構造に対してある変数
増加自然数列 {ik } と {jk } が存在して,
L(sik ) = L(sik +1 ) = · · · = L(sik+1 −1 )
に関してスライシングすることで得られたものであ
り, 以下に述べる足踏同値と呼ぶ同値性を持つもので
ある. その同値性を持つ 2 つのモデルに対し, 様相記
=
L(rik ) = L(rik +1 ) = · · · = L(rik+1 −1 )
を満たす. 図 3 は足踏同値な２つのパスの例である.
号 next を含まない LTL 検査式が一方のモデルにお
与えられた LTL 式 f が足踏同値な２つのパス π と
0
いて valid であるとき, かつそのときのみ, もう一方
π に関して足踏不変 (invaliant under stuttering) で
のモデルにおいてもその LTL 式は valid である, と
あるとは, f が π で valid なときの必要十分条件が f
いうことが成立つ. 以下, 足踏同値を定義し, そのフ
が π 0 において valid であることである. 次に, 等しい
ローチャートの静的スライシング [7] と呼べる本稿で
初期状態の集合を持つ 2 つのクリプキ構造 M と M 0
の抽象化の仕方を述べる.
が足踏同値 であるとは, 次のことを満たすことであ
る: (1) 任意に初期状態 s0 が与えられたとき, s0 か
足踏同値性
ら始まる任意の M のパス π に対して s0 から始まる
クリプキ構造 M = (S, R, S0 , L) は次を満たす４
M 0 のパス π 0 で π と足踏同値なものが存在する. (2)
組である：S は空でない有限集合であり, その元は
逆に, 任意に初期状態 s0 が与えられたとき, s0 から
状態と呼ぶ. S0 は S の空でない部分集合であり, そ
始まる M 0 のパス π 0 に対して M のパス π で π 0 と
の元は初期状態と呼ぶ. ラベル関数（付値)L は S
足踏同値なものが存在する. そして, 与えられた LTL
から命題変数の集合のべき集合への関数である. そ
式 f が足踏同値な 2 つのクリプキ構造 M と M 0 に対
して, R は S 上の全域的な関係である. すなわち、
して足踏不変であるとは, 次のことを満たすことであ
R ⊆ S × S であり, かつ, 任意の s ∈ S に対してある
る: (1) 任意の M のパス π に対して足踏同値な M 0
s0 ∈ S が存在して (s, s0 ) ∈ R を満たす. 本稿では,
のパス π 0 が存在して, π と π 0 に関して f が足踏不変
(s, s0 ) ∈ R の代わりに s −→ s0 と書く. 状態 s からの
である. (2) 逆に, 任意の M 0 のパス π 0 に対して足踏
パス π = s0 −→ s1 −→ · · · とは, 有限もしくは無限の
同値な M のパス π が存在して, π 0 と π に関して f
状態からなる列 {sk } で, s0 := s かつ, 任意の k に対し
が足踏不変である. 特に, f が様相記号 next を含まな
て sk −→ sk+1 を満たすものであある. 2 つの状態の
い LTL 式であるとき, 足踏同値な 2 つクリプキ構造
パス σ = s0 −→ s1 −→ · · · と ρ = r0 −→ r1 −→ · · ·
に対して, f は足踏不変であることが示される [6].
は次を満たすとき足踏同値 (stuttering equivalence)
71
第四回システム検証の科学技術シンポジウム
4
( 4 )
コンピュータソフトウェア
x=10, y=0
x=10, y=0
x=11, y=0
x=11, y=0
x=11, y=0
x=11, y=0
x:=x+1
x:=x+1
No
y>0?
Yes
y<10?
z:=y
z:=z+1
Yes
No
Yes
x:=x-1
No
y:=y+1
x=11, y=0
y:=y+1
x:=x-1
No
y<10?
No
x=0?
x=10, y=1
x=11, y=0
Yes
x=10, y=1
x=0?
Yes
図4
フローチャートのスライシング
図6
図 5 のクリプキ構造におけるパス
足踏同値
x = 10, y = 0, z = 0 である場合の図 5 のそれぞれの
x:=x+1
y>0?
Yes
x:=x+1
No
クリプキ構造における変数の振舞いについて, 図 6 の
Y<10?
No
Yes
z:=y
z:=z+1
Y<10?
Yes
x:=x-1
No
y:=y+1
No
2 つのパスのように, 対応する 2 つのパスを比較する
とそれらは足踏同値になることが分かる.
x:=x-1
y:=y+1
No
x=0?
x=0?
Yes
Yes
なお, 図 5 における 2 つのクリプキ構造は足踏同値
だが, いわゆる模倣 (simulation) ではない. したがっ
て, 2 つのクリプキ構造における LTL 式の妥当性に
ついて, 様相記号 next を含む LTL 式についての同値
図5
図 4 のフローチャートから得られるクリプキ構造
性は保証されない.
フローチャートのスライシング
3.3 検査
本研究において行ったフローチャートのスライシン
詳細モデルに対するモデル検査実験により，ソース
グについて, 具体例を用いて述べる.
コードレベルでは，意図しないタイミングで，セン
図 4 の左側のフローチャートにおいて, 与えられて
サースイッチの OFF が行われる可能性があることが
いる 3 つ変数のうち, x と y に着目し, z に関してス
わかった [3]．そこで，まず，センサー，センサース
ライシングを行うこと考える. そのフローチャートか
イッチ，状態 A と B を遷移させるスイッチのみの振
ら x と y の値に影響を及ぼさない箇所を除いて得ら
る舞いを，仕様書に含まれるフローチャートから抜き
れるフローチャートが図 4 の右側のフローチャート
出した．次に，状態 A と B の遷移だけに着目したフ
である. 次に, 図 4 の 2 つのフローチャートから図 5
ローチャートと外部環境のモデルをあわせ，抽象的な
における 2 つクリプキ構造を次のように与える. 状態
モデルを作成し，モデル検査を行った．その際, 足踏
は, 図 4 のフローチャートにおいて箱形で与えられる
不変性を確保するため, LTL 検査式としては様相記号
命令の実行順を示す矢印線と, ひし形で与えられる判
next を含まないものを選んだ. なお, 抽象的なモデル
定である. ただし, ひし形を導く矢印線はそのひし形
は 約 200 行程度であり，状態爆発も発生せず，モデ
の判定と合わせて一つの状態とする. 状態同士の関係
ル検査を行うことができた．以下詳しく説明する．
は命令の実行順によって定める. ラベル関数は各矢印
モデル化
または判定に対して, その時の x と y の値の組のみを
モデル化は，フローチャートから手動で 3.2 節にお
対応させる. このとき, 2 つのクリプキ構造は足踏同
いて述べたスライシングを行った．スライシング基
値となることが確認できる. 例えば, 変数の初期値が
準 (slicing criteria) とする変数は，状態 A および B
72
第四回システム検証の科学技術シンポジウム
( 5 )
Vol. 0 No. 0
1983
を遷移させるためのポート変数であり，それらの振
工数
る舞いを保存するようフローチャート中で必要な操
実験に要した工数は以下の通りである．
作や分岐を抽出し，抽象化を行った．休止モードは，
• 検査対象理解:
状態 A, B の遷移が休止されるため，抽象化後のフ
ローチャートにも，休止モードは含まれている．でき
2 週間 × 2 人
• 実験 1 および実験 2 のモデルの作成:
2日×2人
あがった抽象的なフローチャートのなかに，脆弱性
X に対応する箇所に，非決定的にセンサースイッチ
• 実験 1 および実験 2 のモデル検査:
の OFF を行う操作を挿入したモデルを Promela で
記述し，モデル検査で使用する抽象モデルとした．
5
3日×2人
実験環境は，CPU Xeon 3.0 G × 2，メモリ 9G で
実験 1
ある．なお，本稿での実験に先立ち，同じ検査対象に
はじめに，
「脆弱性 X が不具合 α に繋がるか否か」
対して，詳細モデルによるモデル検査実験も行われて
を調べるためのモデル検査を行った．まず，不具合
おり [3]，そこでの工数は以下の通りである．
α の直接的な引き金は，不正に休止モードに遷移す
• アセンブラ学習:
るために引き起こされると予想されていたため，休
1 週間 × 2 人
止モードに遷移するか否かを assert 文を用いて表し，
• 検査対象理解:
Spin でモデル検査を行った．結果は，反例無しが得
られた．また，休止モードを経由せずに，不具合 α
1 週間 × 2 人
• アセンブラの各命令のモデル化:
に繋がるか否かを LTL 式で表し，こちらも反例無し
が得られた．結果として，3.2 節で述べたことから，
1日×1人
• 詳細モデルのモデル化 (半自動変換プログラムの
作成も含む): 1 週間 × 1 人
フローチャートの範囲では，ソフトウェアには不具合
の原因はないことが示せた．
• 詳細モデルのモデル検査:
1日×2人
このモデル検査結果を受けたソースコードのレ
ビューでは，センサースイッチの ON/OFF は，ソー
このように，モデル化やモデル検査よりも，検査対象
スコード中でまめに行っていたため，この問題が不具
理解にコストがかかることがわかる．モデル検査を開
合に繋がることはなかったという考察を得ている．
発現場に導入する際には，検査対象をよく知る技術者
実験 2
がモデル検査を実施できるようになるのが理想であ
次に，不具合 α の直接の原因と予想される，ポー
るといえる．
トの不具合 Y がどのように不具合 α に繋がるかを見
るためのモデル検査を行った．まず，ポートの不具合
4 まとめ
Y を再現するような環境をモデルに追加した．次に，
本稿では，組込みシステムの不具合解析にモデル検
このモデル上で，セーフモードに不正に遷移するか
査を適用した事例を報告した．結果として原因究明に
否かを調べるためのモデル検査を行い，反例を得た．
至らなかったが，考察として，モデル検査を不具合解
反例を解析したところ，予想通りの実行パスが得られ
析に適用することの利点がいくつか得られた．一つ
た．次に，休止モードを経ずに，不具合 α が再現す
は，きちんと抽象化を行っていれば，モデル検査の結
るか否かを調べるための検査を行い，これも反例を
果として反例無しが得られた場合でも，不具合に対し
得た．このように，モデル検査は，不具合解析におい
てある程度のことが言えることである．今回の場合で
て，不具合の原因を発見するだけでなく，不具合発生
あれば，フローチャートに関しては，不具合の原因が
時の振る舞いを再現するなどの振る舞い解析に有効
ないことが言えた.
であるという考察を得た．
73
第四回システム検証の科学技術シンポジウム
6
コンピュータソフトウェア
参考文献
[ 1 ] 宇佐美雅紀, 藤倉俊幸: アセンブラのモデル検査にお
けるモデルの自動生成について, 情報処理学会研究報告,
組込みシステム, Vol. 2007, No. 52 (2007), pp. 5–10.
[ 2 ] 篠崎孝一, 太田弘, 早水公二, 星野光勇: モデル検査
のデバッグへの適用, ソフトウェアテストシンポジウム
(JaSST ’06 in Tokyo), 東京, 2006 年 1 月.
[ 3 ] 高井利憲, 吉田聡: アセンブラプログラムのモデル検
査による検証事例, 第 5 回ディペンダブルシステムワー
クショップ (DSW2007), 函館市 (北海道), 2007.
( 6 )
[ 4 ] 高橋孝一, 高井利憲: システム検証における数理的手
法の紹介—組込みシステムへの適用事例—, システム/
制御/情報, Vol. 51,No. 9(2007), pp. 393–398.
[ 5 ] 情 報 処 理 技 術 者 試 験 出 題 範 囲; 独 立 行 政 法 人
情 報 処 理 推 進 機 構 情 報 処 理 技 術 者 試 験 セ ン タ ー.
http://www.jitec.jp/
[ 6 ] E. M. Clarke, Orna Grumberg, Doron Peled,
Model Checking, MIT Press, 1999.
[ 7 ] Mark Weiser: Program Slicing, IEEE Trans.
Software Eng. Vol. 10, No. 4 (1984), pp. 352–357.
[ 8 ] Spin. http://spinroot.com/
74
第四回システム検証の科学技術シンポジウム
( 1 )
1
記号モデル検査による自己安定アルゴリズム
の安定時間の計測
木本 雅博, 土屋 達弘, 菊野 亨
自己安定アルゴリズムは任意の状態から安定状態
ズムの性能を評価する上で重要な指標である．これを
へと遷移し，安定状態を維持する性質を持つ．このた
求めることで，より安定時間の短いアルゴリズムの設
めデータ破損などの過渡的な故障への耐故障性があ
計に役立てることができ，より耐故障性の高い分散シ
る．任意の状態から安定状態に遷移するまでに要する
ステムを設計することが可能になる．
時間の最大値を安定時間と呼ぶ．安定時間はアルゴ
しかし，自己安定アルゴリズムの中には安定時間の
リズムの性能を評価する重要な指標である．しかし，
解析的な評価が困難なものも存在する．例えば，最初
解析的に安定時間を求めることが困難なアルゴリズ
の自己安定アルゴリズムである Dijkstra の 3 状態相
ムも存在する．本研究では記号モデル検査を利用し，
互排他アルゴリズム [3] は未だに厳密な安定時間が評
自動的，効率的に状態空間を探索することで，解析的
価されていない．その理由はこのアルゴリズムは単調
に安定時間を求めることが困難なアルゴリズムの安
に安定状態に収束しないためである [1]．
定時間を求める手法を提案する．
本研究ではこのように安定時間の解析的な評価が
困難なアルゴリズムに対し，記号モデル検査を用いた
1 はじめに
自動的な評価手法を提案する．記号的な状態探索に
複数のプロセッサやプロセスから構成されるシステ
よる安定時間の計測の可能性は，特定のアルゴリズ
ムにおいて，システムを任意の状態から特定の状態に
ムを対象に文献 [7] に示されていたが，提案法はモデ
収束，安定させるアルゴリズムを自己安定アルゴリ
ル検査器の使用を前提とした，アルゴリズムに依存
ズムと呼ぶ．また，収束する状態を安定状態と呼ぶ．
しない一般的な手法である．そして適用実験として，
その性質から，システムの初期化が不要である，デー
Dijkstra の提案した自己安定アルゴリズム [3] である
タ破損などの過渡的な故障から自動的に復旧できる，
3 状態アルゴリズムと K 状態アルゴリズムの安定時
といった利点がある．
間を求め，その評価を行う．
これまでにいくつもの自己安定アルゴリズムが提
案され，その証明やモデル検査による検証が行われて
2 自己安定アルゴリズム
いる [8]．
2.1 システムモデル
安定時間は任意の状態から安定状態に遷移するま
N 個のプロセス p0 , p1 , · · · , pN −1 から構成される
でに要する時間の最大値である．安定時間はアルゴリ
分散システムを仮定する．そして，プロセスが隣接す
るプロセスと通信し，その状態を直接取得することが
Masahiro Kimoto, Tatsuhiro Tsuchiya, Tohru Kikuno,
大阪大学 大学院情報科学研究科, Graduate School
of Information Science and Technology, Osaka
University
できる状態通信モデルを仮定する．
プロセスは与えられたアルゴリズムを実行するこ
とで動作する．アルゴリズムはガードコマンド言語
75
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
2
( 2 )
[4] を用いて記述する．ガードコマンド言語では，ア
2.2 自己安定アルゴリズム
ルゴリズムは以下のような動作のリストとして表現
自己安定アルゴリズムは次のように定義される．
される．
ある論理式 P を満たす状態を，安定状態と呼ぶ．P
は自己安定によって達成したい条件を示す．例えば相
if<動作>[] · · · []<動作>fi
互排他であれば，詳しくは後述するが，動作可能なプ
[] は動作の区切りである．動作は以下のように記述
される．
ロセスがただ一つである状態において，真となるよう
な式となる．
そして，L を安定状態の集合とすると，以下の二つ
<動作> ::= <ガード条件> −→ <文>
の性質を満たすアルゴリズムを自己安定アルゴリズ
状態通信モデルを仮定しているので，ガード条件は
プロセスと隣接プロセスの状態についての論理式で
ムと呼ぶ．
1. 収束性
ある．文はプロセスの状態遷移を表し，ガード条件が
任意の状態 g0 ∈ G から始まる全てのアルゴリズ
真であるときに実行される．
ムの実行 g0 g1 · · · について，gk ∈ L(k ≥ 0) を満
複数のガード条件が成り立つ場合，プロセスはどれ
か一つの動作を非決定的に選択し，その文を実行す
たす整数 k が存在する．
2. 閉包性
る．また，少なくとも一つのガード条件が成り立つプ
システムの任意の状態 g ∈ L について，g → g ′
ロセスは，動作可能であるとう．
ならば，g ′ ∈ L である．
複数の動作可能なプロセスがある場合，動作する
自己安定アルゴリズムの安定時間 r は，任意の状
プロセスがどのように選択されるかと言うセマンティ
態から安定状態に到達するまでに要するアルゴリズ
クスに関しては，C デーモンと D デーモンの二種類
ムの実行ステップ数の最大値であり，以下のように表
の仮定を考える．
される．
• C デーモン (central daemon)
動作可能なプロセスから，一つが選ばれて実行さ
r=
max
g0 g1 ···∈M
ȷ
ff
min{i : gi ∈ L}
i≥0
ここで，M は任意の初期状態 g0 から始まるアル
れる．
• D デーモン (distributed daemon)
ゴリズムの実行の集合である．
動作可能なプロセスから，少なくとも一つが選ば
れて実行される．
2.3 自己安定アルゴリズムの例
システムの状態は全プロセスの状態の組で表現さ
ここでは，自己安定アルゴリズムの例として，Di-
れる．プロセス pi が取り得る状態の集合を Si とす
jkstra の 3 状態相互排他アルゴリズムについて説明
ると，システムの状態集合 G は以下のように表現さ
する．システムは図 1 のようにリング状に接続され
れる．
ているものとする．
各プロセスの状態は変数 S で表され，S は 0 ≤
G = S0 × · · · × SN −1
S < 3 を 満 た す 整 数 値 を 取 る ．プ ロ セ ス pi は
動作可能なプロセスが実行されることで，状態
′
′
pj (j = i − 1 mod N ) と pk (k = i + 1 mod N ) に
g ∈ G から状態 g ∈ G に遷移することを g → g で
隣接し，それぞれの状態を L，R で参照することと
表現し，これを 1 ステップとして数える．アルゴリズ
する．
ムの実行は，システム状態の列 g0 g1 g2 · · · で表現さ
れる．ここで，gi → gi+1 (i ≥ 0) である．
このアルゴリズムでは，プロセスに応じて，3 種類
の異なる動作を規定している．p0 は bottom と呼ば
れ，その動作は次の通りである．
76
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
1983
3
2.3.1 3 状態相互排他アルゴリズムの実行例
表 1 は 3 状態相互排他アルゴリズムの実行例を示し
ている．プロセス数は 5 で，初期状態が (0, 0, 1, 0, 1)
である場合の実行を示している．デーモンは C デーモ
ンを仮定している．動作可能プロセスの中から，動作
プロセスの一つが選択され，次状態に遷移していく．
この例では，最終的に動作可能プロセスが p2 のみ
になるので，相互排他状態，つまり安定状態に遷移し
たことが分かる．
3 記号モデル検査
図1
モデル検査はシステムを有限状態機械で表現し，そ
リングネットワーク
の状態空間を自動的に全探索し，与えられた性質が満
たされるかどうかを検査する形式的検証手法の一つ
if (S + 1) mod 3 = R −→ S := (S − 1) mod 3 fi
である．この手法で問題となるのが，状態空間が膨大
となり全探索が不可能となる，状態爆発である．
次に，pN −1 は top と呼ばれ，その動作は次の通り
である．
記号モデル検査 [2] では，二分決定グラフ (Binary
Decision Diagrams : BDD) を用いて状態空間を表現
if L = R ∧ (L + 1) mod 3 ̸= S −→ S := (L + 1) mod 3 fi
その他のプロセスの動作は次の通りである．
し，効率的な状態の圧縮を可能にしている．
3.1 CTL
一般に，記号モデル検査では，CTL (Computa-
if
(S + 1) mod 3 = L −→ S := L[]
(S + 1) mod 3 = R −→ S := R
fi
tional Tree Logic) という論理を用いて，システムが
満たすべき性質を与える．CTL 式では，通常の論理
演算子に加え，経路修飾子と時相演算子を組み合わせ
た演算子が用いられる．
このアルゴリズムの目的は相互排他を実現するこ
とである．よって，その安定状態とは相互排他が実現
されている状態，つまり動作可能なプロセスが唯一で
ある状態である．安定状態を示す論理式 P は次のよ
うに表せる．
P =
CTL 式は状態に対して評価される．今，状態 g0 を
評価対象の状態とする．状態 g0 で CTL 式 q が成り
立つことを，g0 |= q と表記する．経路修飾子には A
と E がある．A は g0 で始まる任意の実行 g0 g1 · · ·
で，という意味を持つ．E は初期状態 g0 で始まるあ
N_
−1 „
^
Ei ∧
i=0
¬Ej
«
0≤j<N
j̸=i
任意の i について，Ei はプロセス pi が動作可能で
あることを示す．これは Ci をプロセス pi のガード
る実行 g0 g1 · · · で，という意味を持つ．
時相演算子には，X，F，G，U，R がある．その
意味は，以下の通りである．
• Xq
次状態 g1 で q が成り立つ．
条件の集合とすると，次のように表される．
• Fq
Ei =
_
c∈Ci
q が成り立つ状態 gk (k ≥ 0) が存在する．
c
• Gq
任意の状態 gi (i ≥ 0) で q が成り立つ．
77
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
4
表1
( 4 )
3 状態アルゴリズムの実行例
ステップ
p0
p1
p2
p3
p4
動作可能プロセス
動作プロセス
0
0
0
1
0
1
p1 , p3
p1
1
0
1
1
0
1
p0 , p3
p0
2
2
1
1
0
1
p1 , p3
p1
3
2
2
1
0
1
p2 , p3
p2
4
2
2
2
0
1
p2 , p3
p2
5
2
2
0
0
1
p1 , p3
p1
6
2
0
0
0
1
p0 , p3
p0
7
1
0
0
0
1
p1 , p3
p3
8
1
0
0
1
1
p1 , p2 , p4
p2
9
1
0
1
1
1
p1 , p4
p4
10
1
0
1
1
2
p1 , p3
p3
11
1
0
1
2
2
p1 , p2
p2
12
1
0
2
2
2
p1 , p2
p2
13
1
0
0
2
2
p1 , p3
p1
14
1
1
0
2
2
p2 , p3
p2
15
1
1
1
2
2
p2
–
• zUq
えられた性質が成り立つ，といった定量的なステップ
q を満たす状態 gk (k ≥ 0) が存在し，0 ≤ i < k
数に関する性質を与えることは不可能だった．この
について，gi で z が成り立つ．
ような定量的な性質を表現できるように拡張された
• zRq
任意の j について gi (i < j) で z が成り立たない
ならば，gj で q が成り立つ．
よって，CTL では，命題論理の演算子に加え，AX
と EX，AF と EF，AG と EG，AU と EU，AR
CTL が，RTCTL (Real Time CTL) [5] である．
RTCTL では，通常の CTL に加え，A(pU≤k q) や
E(pU≤k q) といった表現ができる．それぞれの意味
は以下のようになる．
• A(pU≤k q)
g0 から始まる任意の実行 g0 g1 · · · について，q
と ER の 10 種類の演算子が用いられる．
を満たす状態 gi (0 ≤ i ≤ k) が存在し，gj (j < i)
自己安定アルゴリズムの性質は，システム全ての状
態について以下の CTL 式が成り立つことと表現でき
る．ここで P は安定状態を示す論理式である．
では p が成り立つ．
• E(pU≤k q)
• 収束性
g0 から始まるある実行 g0 g1 · · · で，q を満たす
AFP
状態 gi (0 ≤ i ≤ k) が存在し，gj (j < i) では p
• 閉包性
AG(P → AXP )
が成り立つ．
AF≤k q は，A(trueU≤k q) と表すことができ，そ
の他の演算子も，双対形を用いることで表現できる．
3.2 RTCTL
CTL では「いつか」成り立つ，という定性的な性
これらの演算子を用いると，安定時間は以下のよう
に記述される．
質の検証はできたが，例えば gk (k < 50) までに，与
78
第四回システム検証の科学技術シンポジウム
( 5 )
Vol. 0 No. 0
1983
5
いる．top や bottom のプロセスの記述は，その他の
r = max min{k|g |= AF
g∈G
k
≤k
P}
プロセスとほぼ同様なので，付録の図 7 と図 8 を参
照されたい．
4 NuSMV を用いたモデル検査
ガードコマンド言語で記述されたプロセスの動作
4.1 モデル化の概要
は，ほぼ直接的に NuSMV プログラムに変換される．
NuSMV は RTCTL での検証をサポートしたモデ
まず以下のように，DEFINE 部でガード条件が成り
ル検査ツールである．本研究では，このツールを用い
立つかどうかを示すマクロ guardn を定義する．
て安定時間の計測を行う．
DEFINE
検証対象のシステムやアルゴリズムは NuSMV の
マクロ名 := 定義;
入力言語で記述される．これを，NuSMV プログラ
そして，ASSIGN 部では，guardn が真の場合，そ
ムと呼ぶ．NuSMV プログラムは，図 2，図 3 のよう
のガード条件に対応した文に従い，各変数の次状態で
に， メインモジュールといくつかのモジュールに分
の値を指定する．
割される．
プロセスはメインモジュールの変数として定義され
モジュールはいくつかの変数を持ち，その変数の初
る．図 2 では，bottom モジュール，other モジュー
期値と次状態での値を指定することで，初期状態と遷
ル, top モジュールの変数としてそれぞれ p0 ，p1 ，p2
移関係を指定する．特に，メインモジュールはシステ
を定義し，引数として，通信に用いるプロセスの変数
ム全体を構成する変数やその遷移関係を記述する．
を渡している．
変数の初期値や次状態の値は，図 3 の 11 行目から
のように ASSIGN 部で指定する．init(x) は変数 x の
4.2 デーモンのモデル化
初期値を指定し，next(x) は変数 x の次状態での値を
NuSMV では，モジュールは同期して状態遷移す
指定する．次状態での値の指定には，case 文を用いて
ることを仮定しているので，各プロセスを一つのモ
特定の条件ごとの値を指定することもできる．例えば，
ジュールで記述する場合，C デーモンや D デーモン
図 3 では，以下のように run&guard1 が真であると
を明確に表現する必要がある．
き，state の次状態での値は L になり，run&guard2
まず図 3 のように，次の遷移において動作するプ
が真ならば R になる，と指定している．特に条件が
ロセスを表すために，run という 2 値の変数を導入す
満たされない場合，最後の 1 で指定された値になる．
る．run の値が真の場合，そのプロセスは動作するプ
next(state) := case
ロセスである．したがって，run が真となるのはプロ
run & guard1 : L;
セスが実行可能であるときに限られる．この条件は以
run & guard2 : R;
下の記述により表現できる．
1
: state;
INVAR
esac;
この case 文では，先に記述されている条件を満た
す値が優先される．
変数の初期値が指定されていない場合，非決定的に
初期値が決定される．また，変数の次状態での値の指
定が無い場合も，非決定的に次状態での値が決定さ
れる．
図 2，図 3 は，3 状態相互排除アルゴリズムを記述
run -> priv
priv はプロセスが動作可能であることを示す論理
式である．INVAR で指定した式は常に真であって，
偽となる状態への遷移が存在しないことを NuSMV
に指定する．
次に，動作可能プロセスがあれば，動作するプロセ
スが存在することを保証する．これは次のように表現
される．
した NuSMV プログラムの一部である．図 2 はメイ
INVAR
ンモジュール，図 3 はその他のプロセスを記述して
(p0.priv | p1.priv | p2.priv) ->
79
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
6
(p0.run | p1.run | p2.run)
この時点で，動作プロセスから少なくとも一つが
選択されて実行される D デーモンの仮定が表現され
たことになる．C デーモンを表現するには，動作プ
ロセスがただ一つであることを保証する式をメイン
モジュールに INVAR で追加すれば良い．図 3 は C
デーモンを仮定した状態になっている．
4.3 NuSMV を用いた安定時間の計測
以下の仕様で，真となる最小の k を求めることで，
NuSMV を用いて安定時間を計測することが出来る．
SPEC ABF 0 .. k P
ABF 0 .. k P は，RTCTL 式 AF≤k を表す．しかし，
このようにしなくても，図 2 の 25 行目のように，
COMPUTE 文を用いることで k を求めることが出
来る．COMPUTE 文は，以下のように記述される．
COMPUTE MAX(MIN) [ 初期状態, 終了状態 ]
初期状態，終了状態はその状態が満たす条件とし
( 6 )
MODULE main
VAR
p0 : bottom ( p1 . s t a t e ) ;
p1 : o t h e r ( p0 . s t a t e , p2 . s t a t e ) ;
p2 : top ( p1 . s t a t e , p0 . s t a t e ) ;
DEFINE
P := (
( p0 . p r i v & ! p1 . p r i v & ! p2 . p r i v ) |
( ! p0 . p r i v & p1 . p r i v & ! p2 . p r i v ) |
( ! p0 . p r i v & ! p1 . p r i v & p2 . p r i v )
);
INVAR
( p0 . p r i v | p1 . p r i v | p2 . p r i v ) −>
( p0 . run | p1 . run | p2 . run )
INVAR
−− C デーモンの保証
( ! ( p0 . run & p1 . run ) ) &
( ! ( p0 . run & p2 . run ) ) &
( ! ( p1 . run & p2 . run ) )
−− 収束性の検証
SPEC AF P
−− 閉包性の検証
SPEC P −> AX P
−− 安定時間の計測
COMPUTE MAX [ 1 , P ]
て，RTCTL 式で表される．COMPUTE 文は初期状
態から終了状態に到達するまでのステップ数の最大値
図2
ソースコード : main
(最小値) を求める．
図 2 では初期状態が満たす条件は真 (1) である．
アルゴリズムとほぼ同じだが，プロセスの状態は
よって，任意の状態が初期状態となる．終了状態には
0 ≤ S < K の範囲になる．よって，K = 3 のときは
安定状態を示す論理式 P が与えられている．従って，
3 状態相互排他アルゴリズムと同様のシステムとなる．
任意の初期状態から安定状態に到達するまでの時間，
しかし，K 状態相互排他アルゴリズムでは K ≥ N と
つまり安定時間が求められる．
いう制約がある．プロセス数が増えると，3 状態アル
ここで MIN を用いると，安定時間の最小値を求め
ゴリズムでは状態数は高々3N であるが，K 状態では
ることができるが，初期状態に安定状態が含まれるた
状態数は少なくとも N N であり，プロセス数が増え
め，結果は常に 0 となる．
ると，状態数が爆発的に増加する．ここでは K = N
初期状態として，例えば，以下のように初期状態を
指定すれば，特定の状態から安定状態に到達するまで
の安定時間の最大値や最小値を求めることもできる．
COMPUTE MAX [ p0.state = 1, P ]
としている．K 状態相互排他アルゴリズムについて
は図 4 にアルゴリズムを示す．
また，自己安定アルゴリズムの中には，初期状態を
特定の状態に限定した場合，より短いステップ数で安
定状態に到達することを保証するものが存在する [6]．
5 適用実験
3 状態および K 状態相互排他アルゴリズムに関して，
実験として 3 状態相互排他アルゴリズムの安定時
初期状態ごとの安定時間を求めることで，この手法が
間と，その計測にかかった時間を求める．また，比較
そういったアルゴリズムとの比較を行う場合にも利用
対象として，同じく Dijkstra が提案した K 状態相互
できることを示す．
排他アルゴリズム [3] の安定時間と計測時間を求める．
K 状態相互排他アルゴリズムは，3 状態相互排他
具体的には，初期状態における動作可能プロセス数
を限定し，その数ごとに安定状態に到達するまでのス
80
第四回システム検証の科学技術シンポジウム
( 7 )
Vol. 0 No. 0
1983
7
MODULE o t h e r ( L , R)
VAR
state : { 0 , 1 , 2 };
run
: boolean ;
DEFINE
guard1 := ( s t a t e + 1 ) mod 3 = L ;
guard2 := ( s t a t e + 1 ) mod 3 = R;
p r i v := guard1 | guard2 ;
INVAR
run −> p r i v
ASSIGN
n e x t ( s t a t e ) :=
case
run & guard1 : L ;
run & guard2 : R;
1
: state ;
esac ;
図3
図5
ソースコード : other
テップ数を計測した．この値は，形式的には以下のよ
うに表され，COMPUTE 文を用いて求めることが出
来る．
最悪時安定時間
結果として，安定時間は C デーモン，D デーモン
共に同じであったため，区別せずに記述している．
また，図 6 は初期状態における動作可能プロセス
数に関する安定時間についてのグラフである．計測に
≤k
max min{k|g |= AF
g∈G(m)
k
P}
よって得られた値は表 4 および表 5 にある．
G(m) は動作可能プロセス数が m である状態の集
合を表す．
5.1 実験結果
実験は，Vine Linux 3.3.2，Intel(R) Xeon(TM)
CPU 2.80GHz 上で行った．
表 2，表 3 はそれぞれ，K 状態および 3 状態相互
排他アルゴリズムの最悪時の安定時間と，その計測時
間を示している．図 5 は表 2 および表 3 の値をグラ
フ化して比較したものである．計測時間は，C デーモ
ンを仮定した場合の時間である．
図6
0≤S<K
動作可能プロセス数に関する安定時間の変化
プロセス p0
if L = S −→ S := (S + 1) mod K fi
その他のプロセス
if L ̸= S −→ S := L fi
5.2 考察
表 2 および表 3 を見ると，K 状態相互排他アルゴ
リズムでは，プロセス数の増加に伴い状態数が爆発
図4
K 状態相互排他アルゴリズム
的に増えるため，計測時間も 2 週間近くかかってい
81
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
8
表2
プロセス数
安定時間
計測時間 (秒)
3
1
0
表3
プロセス数
安定時間
計測時間 (秒)
3
2
0
4
13
0.01
( 8 )
3 状態相互排他アルゴリズムの安定時間と計測時間
4
10
0.02
5
22
0.01
6
39
0.03
7
57
0.06
8
79
0.3
9
109
0.9
10
137
2.4
11
170
5.8
12
212
14.2
13
250
37.4
14
296
104.3
K 状態相互排他アルゴリズムの安定時間と計測時間 (K = N )
5
24
0.04
6
38
0.2
7
55
1.5
8
75
7.6
るが，3 状態相互排他アルゴリズムは状態数が少ない
ため，約 2 分で終わっている．一方，安定時間につい
9
98
48.5
10
124
258.5
11
153
460.3
12
185
1517.3
13
220
5505.6
14
258
20770.2
めた．
今後の課題としては最悪時の安定時間のみならず，
ては，プロセス数が増えるにつれ，K 状態相互排他
初期状態を特定した場合の最小の安定時間や，安定
アルゴリズムの方が小さくなっていることが分かる．
時間の期待値などを求めることが考えられる．また，
これは図 5 からも明らかである．
3 状態相互排他アルゴリズムにおいて，安定時間が減
この図 5 を見ると，3 状態相互排他アルゴリズムの
少する状態についても，より詳細な調査を行いたい．
2
安定時間はほぼ N に従って増加している． [1] では
厳密な解を解析的に求めることは困難であると指摘さ
れているが，必ずしもそうでは無いようにも思える．
次に，図 6 を見ると，K 状態相互排他アルゴリズ
ムではほぼ一定に安定状態までのステップ数が増加し
ている．これに対し，3 状態相互排他アルゴリズムで
は増加量は一定しない．また，N − 1 個のプロセス
が動作可能な場合には安定状態までのステップ数が
減少している．直感的にはステップ数は増加するか，
変化しないはずである．このことから， [1] で述べら
れているように，3 状態相互排他アルゴリズムは，単
調に安定状態に収束するのでは無いことが分かる．
ステップ数が減少する状態については，その理由を
追及することで，より安定時間が短い自己安定アルゴ
リズムを設計するのに役立つ可能性がある．
6 まとめ
本研究では，記号モデル検査を用いることで，自動
的に自己安定アルゴリズムの安定時間を求める方法
を提案した．記号モデル検査は全数探索を行うため，
解析的に安定時間を求めることが困難なアルゴリズ
ムに対して，正確な安定時間を求めることができる．
実験として，Dijkstra の 3 状態および K 状態相互
排他アルゴリズムにこの手法を適用し，安定時間を求
参考文献
[1] J. Beauquier and O. Debas. An optimal selfstabilizing algorithm for mutual exclusion on bidirectional non uniform rings. In the Second Workshop on Self-Stabilizing Systems, pages 17.1–17.13,
1995.
[2] Edmund M. Clarke, Orna Grumberg Jr., and
Doron A. Peled. Model Checking. MIT Press.
[3] Edsger W. Dijkstra. Self-stabilizing systems in
spite of distributed control. Communications of the
ACM, 17(11):643–457, November 1974.
[4] Edsger W. Dijkstra. Guarded commands, nondeterminacy and formal derivation of programs.
Communications of the ACM, 17(18):453–457, August 1975.
[5] E. Allen Emerson, Aloysius K. Mok, A. Prasad
Sistla, and Jai Srinivasan. Quantitative temporal
reasoning. In Proceedings of the 2nd International
Workshop on Computer Aided Verification, pages
136–145, London, UK, 1991. Springer-Verlag.
[6] Yoshiaki Katayama, Eiichiro Ueda, Hideo Fujiwara, and Toshimitsu Masuzawa. A latency optimal
superstabilizing mutual exclusion protocol in unidirectional rings. Journal of Parallel and Distributed
Computing, 62(5):865–884, 2002.
[7] Tatsuhiro Tsuchiya, Shin’ichi Nagano, Rohayu Bt
Paidi, and Tohru Kikuno. Symbolic model checking
for self-stabilizing algorithms. IEEE Transactions
on Parallel and Distributed Systems, 12(1):81–95,
January 2001.
[8] Tatsuhiro Tsuchiya, Yusuke Tokuda, and Tohru
Kikuno. Computing the stabilization times of selfstabilizing systems. IEICE Transactions on Funda-
82
第四回システム検証の科学技術シンポジウム
( 9 )
Vol. 0 No. 0
mentals of Electronics, Communications and Computer Sciences, E83-A(11):2245–2252, November
2000.
A 付録
−− p r o c e s s o r p0
MODULE bottom (R)
VAR
state : { 0 , 1 , 2 };
run
: boolean ;
DEFINE
guard1 := ( s t a t e + 1 ) mod 3 = R;
p r i v := guard1 ;
INVAR
run −> p r i v
ASSIGN
n e x t ( s t a t e ) :=
case
−−
( s t a t e − 1 ) mod 3
run : ( s t a t e + 2 ) mod 3 ;
1
: state ;
esac ;
図7
1983
9
−− p r o c e s s o r p ( n − 1 )
MODULE top ( L , R)
VAR
state : { 0 , 1 , 2 };
run
: boolean ;
DEFINE
guard1 := (L = R) &
( ( L + 1 ) mod 3 != s t a t e ) ;
priv
:= guard1 ;
INVAR
run −> p r i v
ASSIGN
n e x t ( s t a t e ) :=
case
run : (L + 1 ) mod 3 ;
1
: state ;
esac ;
図8
bottom モジュール
83
top モジュール
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
10
表4
プ
ロ
セ
ス
数
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
2
10
22
34
46
58
70
82
94
106
118
130
142
154
166
3
表5
プ
ロ
セ
ス
数
4
5
6
7
8
9
10
11
12
13
14
3
5
7
9
11
13
15
17
19
21
23
2
( 10 )
3 状態相互排他アルゴリズムの安定時間と動作可能プロセス数の関係
17
39
56
73
90
109
128
147
166
185
204
223
242
4
35
57
76
99
122
146
170
194
218
242
266
290
5
57
79
108
132
156
180
205
231
257
283
309
6
74
109
136
166
197
228
259
290
321
352
7
102
137 137
169 170
158
202 212
212
235 245
249
269 279
292
306 314
333
344 354
374
382 395
415
8
9
10
動作可能プロセス数
202
250
295
338
381
427
11
250
296
347
391
435
12
278
348
395
451
13
335
396
454
14
396
455
15
K 状態相互排他アルゴリズムの安定時間と動作可能プロセス数の関係
12
17
22
27
32
37
42
47
52
57
62
3
13
23
30
37
44
51
58
65
72
79
86
4
24
37
46
55
64
73
82
91
100
109
5
38
54
65
76
87
98
109
120
131
6
55
74
75
87
97
98
100
112
123
124
113
127
140
152
126
142
157
171
139
157
174
190
152
172
191
209
7
8
9
10
動作可能プロセス数
84
153
184
205
226
11
185
219
242
12
220
257
13
258
14
431
16
第四回システム検証の科学技術シンポジウム
( 1 )
1
リアクティブシステム仕様の強充足可能性判
定問題の計算量について
島川 昌也
萩原 茂樹
米崎 直樹
線形時間論理によって記述されたリアクティブシス
売機等がある．さらには，原子力発電所のコントロー
テムの動作仕様の満たすべき性質として，強充足可
ルシステムや航空管制システム等，安全性が強く求
能性が森らによって導入されている．強充足可能性と
められるシステムもある．このようなリアクティブシ
は，
「環境からの任意の要求イベント列に対して，そ
ステム仕様に求められることは，単に無矛盾（充足可
の仕様を満たす応答イベント列が存在する」という
能）であることだけではない．環境に対して開いたリ
性質であり，充足可能性（無矛盾性）の十分条件，実
アクティブシステムでは，その振る舞いは環境の振る
現可能性の必要条件である．これまでに強充足可能
舞いに依存し，環境の振る舞いをシステムはコント
性の判定手続きは提案されているが，その判定問題
ロールすることができない．加えて，システムは過去
の計算量については明らかにされていなかった．本研
の要求履歴より現在の応答を決定しなければならな
究では，線形時間論理によって記述されたリアクティ
い．したがって，リアクティブシステム仕様は，
「環境
ブシステム仕様の強充足可能性判定問題の計算量に
からのどのような要求イベントがどのような順序で
ついて考察し，それが EXPSPACE 完全であること
生起しても，仕様を満たすような応答を過去の要求履
を示した．さらに，時間演算子のネストの深さを制
歴より決定できる」という性質を満たす必要がある．
限した場合の強充足可能性判定問題の計算量につい
この性質は，実現可能性 [1] [8] として導入され，これ
て，その深さを 2 までと制限しても計算量は下がら
にまでに様々な研究が行われている．
ず，EXPSPACE 完全であることを明らかにした．
そのうちの一つとして，森らによる実現不能なリ
アクティブシステム仕様の分類 [5] がある．そこでは，
1 はじめに
実現不能な仕様の原因を分析するために，線形時間
システムの仕様段階での分析は，開発プロセス全
論理により記述されたリアクティブシステム仕様の
体を通じてのコストの低減の観点からは，作成後の
（充足可能性よりも強い）実現可能性の必要条件がい
システムの検証よりも重要であるといわれている [4]．
くつか導入されている．
システムには様々なものがあるが，その中でもリアク
本研究では，そのうちの一つの性質である強充足可
ティブシステムは，環境とのインタラクションの維持
能性に焦点をあてる．強充足可能性とは，
「環境からの
を目的とするシステムである．リアクティブシステム
任意の要求イベント列に対して，その仕様を満たす応
の例としては，エレベータのコントローラや，自動販
答イベント列が存在する」という性質である．この性
Masaya Shimakawa, Shigeki Hagihara, Naoki
Yonezaki, 東京工業大学大学院情報理工学研究科計
算工学専攻, Tokyo Institute of Technology, Graduate School of Information Science and Engineering,
Department of Computer Science.
質は，実現可能性の必要条件ではあるが，実用的なリ
アクティブシステム仕様の多くが，強充足可能である
ならば実現可能でもある [6] との議論もあり，リアク
ティブシステムの満たすべき重要な性質であると我々
85
第四回システム検証の科学技術シンポジウム
2
コンピュータソフトウェア
( 2 )
は考えている．これまでに [15] [3] で強充足可能性の
は，他の性質（充足可能性と実現可能性）の判定問題
判定手続きが， [6] でその性質が満たされないときの
の計算量との違いを述べる．最後に 6 章で本稿をま
原因の導出法が提案されている．
とめる．
しかしながら，これまでに強充足可能性判定問題の
計算量については明らかにされていない．それゆえ，
2 リアクティブシステムとその動作仕様
充足可能性判定問題や実現可能性判定問題との計算
2.1 リアクティブシステム
量の違いも分かっていない．このような判定問題の計
リアクティブシステムとは，環境とのインタラクショ
算量（問題の本質的な難しさ）は，判定手続きの効率
ンの維持を目的とするシステムであり，RS = hX, Y, ri
化や効率的に判定を行える入力制限などを考える際
と形式化できる．ここで，
の有効な指針となりえる．したがって，それを分析・
• X は環境が生起する要求イベントの集合である．
解明することは，工学的にも重要なことである．
• Y はシステムが生起する応答イベントの集合で
そこで本研究では，線形時間論理によって記述され
ある．
たリアクティブシステム仕様の強充足可能性判定問題
• r : (2X )+ → 2Y は，リアクション関数である．
の計算量について考察し，それが EXPSPACE 完全
ここで，(2X )+ は有限長の要求イベント集合の
であることを示す．上界については，仕様のサイズに
列の集合である．この関数により，以前の要求イ
対して指数の領域を使って判定可能な，ω-オートマト
ベントの生起に対してシステムがどのような応
ンを用いた強充足可能性判定手続きを与えることで，
答イベントを生起させるかを決定する．
この問題が EXPSPACE に属することを示す．下界
については，その計算量が EXPSPACE 完全である
本稿では，イベント集合 X ∪ Y の部分集合の無限
長の列を振る舞いと呼ぶ．
と知られている EXP–CORRIDOR TILING 問題が
強充足可能性判定問題の補問題へ多項式帰着可能で
2.2 リアクティブシステムの動作仕様
あることを示すことにより，強充足可能性判定問題
リアクティブシステムの動作仕様は，システムの可
が EXPSPACE 困難であることを明らかにする．こ
能な振る舞いの集合を定める．可能な振る舞いを定め
こで与える結果により，強充足可能性判定問題が，そ
る手段としては，任意のものが考えられるが，本稿で
の計算量が PSPACE である充足可能性判定問題より
は，リアクティブシステムの仕様記述言語として，線
も真に難しく，2EXPTIME である実現可能性判定問
形時間論理（Linear Temporal Logic, 以下 LTL）を
題以下の難しさであることが分かる．
用いる．LTL による仕様記述は，記述しようとして
さらに本研究では，リアクティブシステム仕様の時
いるシステムのイベント集合（要求イベント集合と
間演算子のネストの深さを制限した場合の強充足可
応答イベント集合）を命題変数とし，それらからなる
能性の計算量についても考察する．そして，その深さ
LTL 式を記述することで行う．
を 2 までと制限しても強充足可能性の計算量は落ち
ず，EXPSPACE 完全であることを明らかにする．
本稿の構成は次の通りである．まず，2 章でリアク
ティブシステムとその動作仕様の記述言語としての線
本稿で扱う LTL は，時間演算子として X, U を持
つものである．要求イベントの集合 X と応答イベン
トの集合 Y が与えらたとき，LTL 式は以下のように
定義される．
形時間論理 LTL を紹介する．そして，リアクティブ
• p ∈ X ∪ Y ならば，p は LTL 式である．
システム仕様が満たすべき性質である強充足可能性
• ϕ, ψ が LTL 式ならば，¬ϕ, Xϕ, ϕ ∧ ψ, ϕUψ
について述べる．3 章で，強充足可能性判定問題の計
も LTL 式である．
算量が EXPSPACE 完全であることを示す．4 章で
略記として，⊥, >, ∨, →, ⊕, ↔ を通常のように用い
は，時間演算子のネストの回数を制限した場合の強充
る．また，時間演算子 F, G をそれぞれ Fϕ ≡⊥ Uϕ,
足可能性判定問題の計算量について考察する．5 章で
Gϕ ≡ ¬F¬ϕ のように導入する．
86
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
LTL 式は，振る舞い, つまり X ∪ Y の部分集合の
無限列上に解釈される．
（無限列の i 番目の要素は，そ
1983
は無限長の応答イベント集合列である．ã = a0 a1 . . .，
b̃ = b0 b1 . . . のとき，
hã, b̃i = (a0 ∪ b0 )(a1 ∪ b1 ) . . .
の時点で生起するイベントの集合であり，そこに含ま
れないイベントはそこで生起しないことを意味する．
）
ϕ を LTL 式とし，σ ∈ (2
X∪Y ω
) を振る舞いとする.
振る舞い σ が ϕ を満たすことを σ |= ϕ と表し，以下
3
とする．
例として，エレベータの仕様の一部である次のよう
な式を考える．
G(BOpen → Open) ∧ G(BClose → ¬Open).
のように再帰的に定義する．
• σ |= p iff p ∈ σ[0],
ここで，BOpen および BClose は要求イベントであり，
• σ |= ¬ϕ iff σ 6|= ϕ,
それぞれ「開ボタンが押される」「閉ボタンが押され
• σ |= ϕ ∧ ψ iff σ |= ϕ and σ |= ψ,
• σ |= Xϕ iff σ[1 . . .] |= ϕ,
• σ |= ϕUψ iff (∃j ≥ 0)
る」ことを表す．また，Open は応答イベントであり，
「ドアを開く」ことを表す．この式の意図するところ
“
”
∀k(0 ≤ k < j) σ[k . . .] |= ϕ .
σ[j . . .] |= ψ and
は，
「動作中，常に開ボタンが押されたらドアを開き，
閉ボタンが押されたらドアを閉める」である．この仕
ここで，σ[i] は σ の i 番目の要素を，σ[i . . .] は σ の
様は，何も問題のないようにみえるが，充足可能性で
i 番目以降の振る舞いを表す．
はあるが，強充足可能でない（つまり，実現可能でも
LTL 式 ϕ を満たす振る舞い σ が存在するとき，ϕ
ない）．開ボタンと閉ボタンが同時に押されると，シ
ステムは仕様を満たすように振る舞えないためであ
は充足可能であるという．
実現可能性とは，
「どのような要求イベントがどの
る．例えば，
G(BOpen → Open) ∧
ような順序で生起しても，仕様を満たすように応答で
きるようなリアクティブシステムが存在する」という
G(BClose ∧ ¬BOpen → ¬Open)
性質であり，次のように形式化される．仕様 Spec が
のように変更すると，強充足可能になる（同時に押さ
以下を満たすとき，Spec は実現可能であるという．
れたら「開」を優先する）．
∃RS ∀ã.(behave RS (ã) |= Spec).
続いて，強充足可能性と実現可能性の違いをみるた
X ω
ここで，ã は無限長の要求イベント集合列（(2 ) の
め，次のような仕様を考える．
Fx ↔ y
要素）である．behave RS (ã) は ã に対する RS の振る
舞いであり，ã = a0 a1 . . . のとき，
behave RS (ã) = (a0 ∪ r(a0 ))(a1 ∪ r(a0 a1 )) . . .
ここで，x は要求イベントであり，y は応答イベント
である．この仕様は，x の如何なる生起パターンに対
しても仕様を満たす応答パターンは存在するため，強
と定義される．
充足可能である．しかし，実現可能ではない．リアク
2.3 強充足可能性
ティブシステムが観測できるのは，すでに生起したイ
ここでは，実現可能性の必要条件である強充足可能
ベントだけである．この仕様のように将来の入力イベ
性について， [5] より紹介する．
強充足可能性とは，
「環境が将来生起する要求イベ
ントの生起が分からなければ現在の出力を決定でき
ない仕様は，実現不能となる．
ント集合列が予めわかるならば，仕様を満たすように
このように，強充足可能性と実現可能性との違い
生起させる応答イベントの列を決定できる」という性
は，
「システムは環境の将来起こす要求を知ることがで
質であり，次のように定義される．
きない」という制約を考慮しているかどうかにある．
定義 2.1 (強充足可能性). 仕様 Spec が以下を満たす
とき，Spec は強充足可能であるという．
∀ã∃b.(hã, b̃i |= Spec)
ここで，ã は無限長の要求イベント集合列であり，b̃
3 強充足可能性判定問題の計算量
本章では，LTL で記述されたリアクティブシステ
ム仕様の強充足可能性判定問題が EXPSPACE 完全
87
第四回システム検証の科学技術シンポジウム
4
コンピュータソフトウェア
A0 = h2X , Q, q0 , δ 0 , F i を 構 成 す る ．こ こ で ，
であることを示す．すなわち，強充足可能性判定問
p(n)
( 4 )
) の領域（こ
δ 0 = {(q, a, q 0 )|∃b.(q, a ∪ b, q 0 ) ∈ δ} である．
こで p(n) は n の多項式関数）を使って解ける問題の
• L(A0 ) = {ã|∃b̃.hã, b̃i |= Spec} となる．
題が決定性チューリング機械で O(2
クラス EXPSPACE に属すること，及び，そのクラ
3. A0 の全受理判定（L(A0 ) = (2X )ω であるかの判
ス EXPSPACE に属する任意の問題が強充足可能性
定）を行い，全受理であるならば「強充足可能」
判定問題に多項式帰着可能であること（EXPSPACE
と判定し，そうでない場合，
「強充足可能でない」
困難性）を示す．
と判定する．
A は， [13] 等で与えれている通り，O(2|Spec| ) の
3.1 上界
領域を用いて，O(2|Spec| ) のサイズで構成可能であ
まず，強充足可能性判定問題の計算量の上界，すな
る．A0 は，A の遷移関係の射影操作で得られるため，
わち，この問題が EXPSPACE に属することを示す．
O(|A|) の領域を用いて，O(|A|) のサイズで構成可能
ここでは，O(2p(n) ) の領域を使って判定可能な Büchi
である．非決定性 Büchi オートマトンの全受理判定
オートマトンを用いた強充足可能性手続きを定義し，
は PSPACE である [12] ため，決定性チューリング機
それを示す．ここで与える手続きは， [3] によって提
械で O(p(|A0 |)) の領域を使って，ステップ 3 の判定
案された強充足可能性判定手続きに変更を加えたも
のである†1 ．
を行える．
非決定性 Büchi オートマトン A = hΣ, Q, q0 , δ, F i
したがって，決定性チューリング機械で O(2p(|Spec|) )
の領域を使って，強充足可能性の判定を行える．よっ
は，Σ：アルファベット，Q：有限の状態の集合，q0 ∈ Q：
て，強充足可能性問題は EXPSPACE に属する．
初期状態，δ ⊆ Q × Σ × Q：遷移，F ⊆ Q：受理条件
定理 3.1. LTL によるリアクティブシステム仕様の
より構成される．Σ 上の ω 語 α の行程とは，状態の
強充足可能性問題は，EXPSPACE に属する．
無限列 % で， %[0] = q0 ，かつすべての i ≥ 0 におい
て (%[k], α[k], %[k + 1]) ∈ δ となるものである．ω 語
3.2 下界
α に対して，inf (%) ∩ F 6= ∅ を満たす行程 % が存在す
次に，強充足可能性判定問題の計算量の下界，すな
るとき，A は α を受理するという．ここで，inf (%)
わち，この問題が EXPSPACE 困難であることを示
は % 中に無限回出現する状態の集合である．A が受
す．ここでは，その計算量が EXPSPACE 完全であ
理する ω 語の集合を A の受理言語といい，L(A) で
ると知られている EXP–CORRIDOR TILING 問題
表す．
Spec を LTL によるリアクティブシステム仕様とす
る．Spec の強充足可能性の判定は，次の手順で行う
ことができる．
1. Spec を満たす振る舞いをちょうど受理する，つ
（ [14] など）が強充足可能性判定問題の補問題へ多項
式帰着可能であることを示し，強充足可能性判定問題
が EXPSPACE 困難であることを示す．
EXP–CORRIDOR TILING 問題とは，(T, H, V,
tinit , tfinal , m) （ こ こ で ，T は 有 限 の タ イ ル 集 合 ，
まり，L(A) = {σ|σ |= Spec} となる非決定性
H, V ⊆ T × T はそれぞれ横の隣接制約，縦の隣接制
Büchi オートマトン A = h2X∪Y , Q, q0 , δ, F i を
約であり，tinit , tfinal ∈ T はそれぞれ初期タイル，最
構成する．
終タイル，m は自然数である）に対して，ある k ∈ N
2. A を も と に ，ア ル ファベット を 要 求 イ ベ ン ト
が存在し，以下の条件を満たすタイルの割り当て関数
のみに制限した非決定性 Büchi オートマトン
f : [0, . . . , (2n − 1)] × [0, . . . , k] → T が存在するかを
決定する問題である．
†1
[3] では，Muller オートマトンを用いた判定手続きが
提案されている．本稿では，より小さな計算コストで
判定を行える Büchi オートマトンによる判定手続き
を定義する．
• （初期タイルの条件）
：f (0, 0) = tinit である．
• （最終タイルの条件）：f (2m − 1, k) = tfinal で
ある．
88
第四回システム検証の科学技術シンポジウム
( 5 )
Vol. 0 No. 0
• （横に隣接するタイルの条件）
：任意の 0 ≤ i <
2
m
1983
• end ：その時点でタイリングが終了しているか
− 1, 0 ≤ j ≤ k において，(f (i, j), f (i +
を表す．つまり，格子のマス目 (i, j) においてタ
イリングが終了しているかを時点 i + (2m ) · j に
1, j)) ∈ H である．
• （縦に隣接するタイルの条件）
：任意の 0 ≤ i ≤
2
m
5
− 1, 0 ≤ j < k において，(f (i, j), f (i, j +
おいて end が生起しているかに対応させる．
• c0 , . . . cm−1 ：m ビットのカウンタとして用い
1)) ∈ V である．
る．はじめは値が 0 で，1 単位時間ごとにその値
m
直感的には，横が 2 ，縦が非有界の格子に対して，
が 1 づつ増えるようにし，その時点において着
m
ある k ∈ N が存在し，0 ≤ i < 2 , 0 ≤ j ≤ k の各
目しているマス目が何番目の列であるかを特定
マス目 (i, j) に 4 つの条件，つまり，初期タイル条件
するのに用いる．
（最左上のマス目は tinit ），最終タイル条件（最右下
応答イベント
のマス目は tfinal ），横の隣接条件（横に隣接するマ
応答イベントとしては，以下を用意する．
ス目に置かれるタイルは H を満たす），縦の隣接条
• y0 , . . . ym−1 ：縦の制約を記述する際，着目する
件（縦に隣接するマス目に置かれるタイルは V を満
たす）を満たすようにタイルを置くことができるか，
ということである．
上述のタイリング問題から強充足可能性判定問題
列を特定するのに用いる．
式： ϕtiling
式 φtiling を以下の式 (1)–(6) の論理積の否定とす
る．ただし，次を略記として用いる．
の補問題への多項式還元，すなわち，タイリング問題
(T, H, V, tinit , tfinal , m) に対して，その答えが「yes」
c=0 ≡
c = 2m − 1 ≡
な ϕtiling の構成方法について述べる．
求イベント集合列が存在する」部分に対応させる．そ
^
ci
0≤i<m
∃ã∀b̃.(hã, b̃i |= ¬ϕtiling )
「あるタイリングが存在する」ことを上式の「ある要
¬ci
0≤i<m
であるとき，かつそのときにのみ，以下を満たすよう
ここで述べる帰着では，タイリング問題における
^
c=y
≡
^
(ci ↔ yi )
0≤i<m
• m0
ビットカウンター
c0 , . . . cm−1 の制約．
1
^
@
¬ci A ∧
のタイリングに対応する要求イベント集合列につい
1
00≤i<m
„
«
^
^
@
G (ci ⊕
cj ) ↔ Xci A (1)
ては，任意の応答イベント集合列に対して LTL 式を
「はじめは c̄ の指す値が 0 であり，1 単位時間ご
して，
「そのタイリングが条件を満たす」ことを「そ
0≤i<m
0≤j<i
満たすことがない」に対応させる．つまり，タイリン
とにその値が 1 づつ増える」ことを表す．
グ問題に対して，要求イベント集合列でその１つの
• マス目に張られるタイルを一つにする制約．
0
1
^
^
G @xt →
¬xt0 A ∧
タイリングを表現するように要求イベントを定める．
そして，そのタイリングが条件を満たすことを，応答
t∈T
イベント集合列について全称束縛される式として表
G ¬end →
現するように応答イベント及び LTL 式を定める．
!
xt
(2)
t∈T
「各マスに張られるタイルは高々一つ，かつ，そ
要求イベント
こでタイリングが終了していないならば，いずれ
要求イベント集合列によって，ある一つのタイリン
かのタイルが張られる」ことを表す．
グを表現できるように，以下のような要求イベントを
用意する．
t0 6=t
_
• 初期タイルの制約．
xtinit
• xt （t ∈ T ）：格子のマス目 (i, j) においてタイ
(3)
「マス目 (0, 0) にタイル tinit が置かれる」ことを
ル t が置かれるかを，時点 i + (2m ) · j において
表す．
xt が生起しているかに対応させる．
89
第四回システム検証の科学技術シンポジウム
6
コンピュータソフトウェア
( 6 )
• 最終タイルについての制約．
“
”
¬endU ¬end ∧ c = 2m − 1 ∧ xtfinal ∧ XGend
CORRIDOR TILING 問題は EXPSPACE 完全であ
(4)
「2m − 1 の列のどこかのマス目に最終タイルが置
難であり，強充足可能性問題は co–EXPSPACE 困難
かれ，タイリングが終了する」こと表す．
• 横の制約．
„
G c 6= 2m − 1 ∧ ¬end →
_ `
´
xt ∧ Xxt0
るため，強充足可能性判定の補問題は EXPSPACE 困
である．EXPSPACE=co–EXPSPACE であること
より，強充足可能性問題は EXPSPACE 困難である．
«
2
4 時間演算子のネストの深さを制限した場合
(t,t0 )∈H
(5)
「タイリングが終了しておらず，かつ，現マス目
が2
m
− 1 の列でない（右にマス目が存在する）
ならば，現マス目に置くタイルと右マス目に置く
タイルとが横の制約を満たす」ことを表す．
• 縦の制約．
„ ^
«
G(yi ↔ Xyi ) →
0≤i<m
„“
”
G c = y ∧ XF(¬end ∧ c = 0)
→
«
_ “
`
´”
xt ∧ X (c 6= y)U(c = y ∧ xt0 )
(t,t0 )∈V
(6)
「y が不変であるならば，その y が示す列のマス
において，その下のマスでもタイリングが終了し
ないとき，現マスと下のマスとが縦の制約を満た
す」ことを表す．ここで，
「現マスと下のマスと
が縦の制約を満たす」を，
「現マスに置くタイル t
と，次に再び列が y となる最初のマス，すなわ
ち，同じ列にある直下のマスに置くタイル t0 と
が (t, t0 ) ∈ V を満たす」として記述している．
これにより，∀ỹ. (. . . |= (6)) が，
「すべての列の
おいて，縦の制約を満たす」，つまり，
「配置され
るすべてのタイルが，縦の制約を満たす」を表す
ことになる．
定理 3.2. LTL によるリアクティブシステム仕様の
強充足可能性問題は，EXPSPACE 困難である．
証明
上 で 示 し た よ う に ，EXP–CORRIDOR
TILING 問題の答えが，
「yes」ならば，かつそのと
きに限り，強充足可能でない式 ϕtiling を構成すること
ができる．ϕtiling はもとの問題に対して多項式のサイ
ズであり，その式は多項式時間で構成可能となる．す
なわち，EXP–CORRIDOR TILING 問題は強充足
可能性判定の補問題に多項式帰着可能となる．EXP–
の計算量
式の時間演算子のネストの深さを制限した場合の
強充足可能性判定問題の計算量について考える．
式 ϕ の時間演算子のネストの深さ td(ϕ) は，以下
のように再帰的に定義される．
• td(p) = 0
• td(¬ϕ) = td(ϕ)
• td(Xϕ) = td(ϕ) + 1
• td(ϕUψ) = max (td(ϕ), td(ψ)) + 1
また，td(ϕ) を k 以下と制限した LTL の部分体系を
LTL(k) とする．
本稿では，時間演算子のネストの深さを 2 以下と
した場合の強充足可能性判定問題の計算量について
考え，このような制限を与えた場合でも，その計算量
が落ちないこと，つまり，EXPSPACE 完全であるを
明らかにする．ここでは，LTL の強充足可能性判定
問題が，LTL(2) の強充足可能性判定問題へ多項式帰
着可能であることを示し，それを証明する．
まず準備として，次のような補題を与える．
補題 4.1. Spec を要求イベント集合 X と応答イベン
ト集合 Y からなる仕様とする．このとき，任意の振
る舞い σ ∈ (2X∪Y )ω ，ϕ ∈ sub(Spec)（Spec の部分
式）について，
σ |= Spec ⇐⇒ ∃c̃.hσ, c̃i |= Spec[c/ϕ] ∧ G(c ↔ ϕ)
である．ここで，c 6∈ X ∪ Y であり，c̃ は (2{c} )ω の
要素である．また，Spec[c/ϕ] は Spec 内に出現する
ϕ を c に置き換えた式である．
証明 （⇒）
：σ |= Spec を仮定する．ここで，次のよ
うに定義される 8
c̃ を考える．
>
<∅
（σ[i . . .] 6|= ϕ とき）
c̃[i] =
>
:{c} （σ[i . . .] |= ϕ とき）
c̃ の定義より，hσ, c̃i |= G(c ↔ ϕ) である．また，仮
定より hσ, c̃i |= Spec であり，かつ，任意の i におい
90
第四回システム検証の科学技術シンポジウム
( 7 )
Vol. 0 No. 0
1983
7
0
て，hσ, c̃i[i . . .] |= ϕ のとき，かつそのときにのみ，
なる LTL(2) による仕様 Spec の構成法を示す．Spec
hσ, c̃i[i . . .] |= c であるため，hσ, c̃i |= Spec[c/ϕ] であ
を要求イベント集合 X と応答イベント集合 Y からな
る．したがって，hσ, c̃i |= Spec[c/ϕ] ∧ G(c ↔ ϕ) で
る LTL 仕様とする．Spec に対して，仕様 Spec 0 を次
ある．よって，∃c̃.hσ, c̃i |= Spec[c/ϕ] ∧ G(c ↔ ϕ) で
のように定義する．
• 要求イベント集合：X ．
ある．
（⇐）
：hσ, c̃i |= Spec[c/ϕ]∧G(c ↔ ϕ) を満たす c̃ が
• 応答イベント集合：Y ∪C ．ただし，C = {cϕ |ϕ ∈
存在すると仮定する．hσ, c̃i |= G(c ↔ ϕ) を満たすた
め，任意の i において，hσ, c̃i[i . . .] |= c のとき，かつ
sub(Spec)}．
• Spec 0 :
そのときにのみ，hσ, c̃i[i . . .] |= ϕ である．このことと，
cSpec ∧
ここで，ϕ0 は次のように定める．
2
– ϕ ∈ X ∪ Y とき，ϕ．
補題 4.2. Spec を要求イベント集合 X ，応答イベ
– ϕ = ¬ψ とき，¬cψ ．
ント集合 Y からなる仕様とする．Spec が強充足可
– ϕ = ψ ∧ ψ 0 のとき，cψ ∧ cψ0 ．
能であるとき，かつそのときにのみ，要求イベント
– ϕ = Xψ とき，Xcψ ．
集合を X ，応答イベント集合を Y ∪ {c} とする仕様
Spec[c/ϕ] ∧ G(c ↔ ϕ) は，強充足可能となる．
G(cϕ ↔ ϕ0 ).
cϕ ∈C
hσ, c̃i |= Spec[c/ϕ] であることより，hσ, c̃i |= Spec が
導かれる．よって，σ |= Spec である．
^
– ϕ = ψUψ 0 のとき，cψ Ucψ0 ．
Spec 0 は，補題 4.2 の変形を Spec の各部分式につい
証明
て，大きい式から順に適応させたものとみることがで
Spec は強充足可能である．
きる．したがって，Spec が強充足可能であるとき，か
⇐⇒ ∀ã∃b̃.(hã, b̃i |= Spec)
つそのときにのみ，Spec 0 は強充足可能である．ϕ0 は
⇐⇒ ∀ã∃b̃∃c̃.(hã, hb̃, c̃ii |= Spec[c/ϕ] ∧ G(c ↔ ϕ))
常に td(ϕ0 ) ≤ 1 であるため，Spec 0 は td(Spec 0 ) ≤ 2
（補題 4.2 より）
⇐⇒ Spec[c/ϕ] ∧ G(c ↔ ϕ) は強充足可能である．
2
である．また，G(cϕ ↔ ϕ0 ) のサイズは定数であり，
|C| ≤ |Spec| であるため，|Spec 0 | = O(|Spec|) である．
こ の よ う に ，LTL の 強 充 足 可 能 性 判 定 問 題 は ，
これより，強充足可能性を保存し，時間演算子の
LTL(2) の強充足可能性判定問題へ多項式帰着可能で
ネストの深さを下げる変換が可能となる．例えば，
ある．3 章で示した通り，LTL の強充足可能性判定問
Spec = xU(XFGy) は，
Spec 1 = xU(XcFGy ) ∧ G(cFGy ↔ FGy)
に ，強 充 足 可 能 性 を 保 存 し ，td(Spec) = 4 か ら
td(Spec 1 ) = 3 へ と ネ ス ト の 深 さ を 減 ら す よ う 変
題は EXPSPACE 完全である．その問題からの帰着
が可能であるため，LTL(2) においても強充足可能性
判定問題の EXPSPACE 困難性が成立し，その計算
量は EXPSPACE 完全となる．
2
換できる．
このような変形を繰り返し適応させることで，強充
足可能性を保存し，td(Spec 0 ) ≤ 2 である Spec 0 を得
られる．これより，LTL(2) における強充足可能性問
題が EXPSPACE 完全であることが導かれる．
定理 4.3. LTL(2) によるリアクティブシステム仕様
の強充足可能性問題は，EXPSPACE 完全である．
証明 LTL の強充足可能性判定問題から LTL(2) の強
充足可能性判定問題への多項式帰着法を示す．すなわ
ち，LTL による仕様 Spec に対して，Spec が強充足
5 他の性質判定問題の計算量
ここでは，リアクティブシステム仕様の満たすべき
他の性質，充足可能性と実現可能性の判定問題の計算
量との関係について述べる．
充足可能性判定問題の計算量は，PSPACE 完全で
あること [11]，また，実現可能性判定問題の計算量は，
2EXPTIME 完全であること [9] が，これまでに示さ
れている．ここで，PSPACE は決定性チューリング
機械で O(p(n)) の領域を使って解けるすべての決定
可能であるとき，かつそのときにのみ，強充足可能と
91
第四回システム検証の科学技術シンポジウム
8
コンピュータソフトウェア
問題のクラス，2EXPTIME は決定性チューリング機
械で O(2
2p(n)
) の時間で解けるすべての決定問題のク
ラスである．それぞれのクラスの関係は，以下のよう
になっている†2 ．
( 8 )
ない部分体系でなければ，強充足可能性判定の計算量
は落ちない．我々は，このようなことを指針として，
効率よく検証を行える部分体系を明らかにしていく
予定である．
PSPACE ( EXPSPACE ⊆ 2EXPTIME.
したがって，3 章で示した結果より，強充足可能性
判定問題は，充足可能性判定問題よりも真に難しく，
実現可能性判定問題以下の難しさであるといえる．
6 まとめ
本研究では，線形時間論理によって記述されたリ
アクティブシステム仕様の強充足可能性判定問題の
計算量が，EXPSPACE 完全であることを示した．こ
れにより，強充足可能性判定問題が，充足可能性判定
問題よりも真に難しく，実現可能性判定問題以下の難
しさであることが明らかになった．さらに本研究で
は，時間演算子のネストの深さを制限した場合の強充
足可能性判定問題の計算量についても考察し，ネス
トの深さを 2 以下と制限した場合も，その計算量は
EXPSPACE 完全であることが分かった．
今後の課題としては， [5] で導入されている他の性
質（段階的充足可能性，及び段階的強充足可能性）の
判定の計算量を明らかにすることが挙げられる．ま
た，構文を制限した LTL の部分体系での強充足可能
性判定問題の計算量の考察を深めることも今後の課
題である．効率よく検証を行える部分体系を見つけ
出すことは，実用上の観点からも大きな意味がある．
実現可能性については， [2] [7] [10] などによって，そ
のような部分体系が与えられている．我々は，強充足
可能性について同様な考察を行っていく予定である．
本研究で与えた結果は，そのための重要な指針とな
る．本稿では，強充足可能性判定問題が EXPSPACE
困難であることを証明するため，EXP–CORRIDOR
TILING 問題が強充足可能性判定問題の補問題へ帰
着できることを示した．計算量を落とすためには，そ
のような帰着が不能になるよう構文を制限する必要
がある．つまり，本稿で与えた ϕtiling の記述ができ
†2 EXPSPACE ⊆ 2EXPTIME が真部分集合の関係に
なるかは明らかになっていないが，多くの研究者は，
真部分集合の関係であると考えている．
参考文献
[ 1 ] Abadi, M., Lamport, L., and Wolper, P.: Realizable and Unrealizable Specifications of Reactive Systems, Proceedings of the 16th International
Colloquium on Automata, Languages and Programming, 1989, pp. 1–17.
[ 2 ] Alur, R. and Torre, S. L.: Deterministic generators and games for LTL fragments, ACM Trans.
Comput. Logic, Vol. 5,No. 1(2004), pp. 1–25.
[ 3 ] Hagihara, S. and Yonezaki, N.: Completeness
of Verification methods for Approaching to Realizable Reactive Specifications, Preliminary Proceedings of 1st Asian Working Conference on Verified
Software, 2006, pp. 242–257.
[ 4 ] Jackson, D.: Automating first-order relational
logic, Proceedings of the 8th ACM SIGSOFT international symposium on Foundations of software
engineering, 2000, pp. 130–139.
[ 5 ] Mori, R. and Yonezaki, N.: Several Realizability
Consepts in Reactive Objects, Information Modeling and Knowledge Bases, 1993.
[ 6 ] Mori, R. and Yonezaki, N.: Derivation of the
Input Conditional Formula from a Reactive System
Specifictaion in Temporal Logic, Formal Techniques
in Real-Time and Fault-Tolerant Systems, Lecture
Notes in Computer Science, Vol. 863, Springer,
1994, pp. 567–582.
[ 7 ] Piterman, N., Pnueli, A., and Sa’ar, Y.: Synthesis of Reactive(1) Designs, Verification, Model
Checking, and Abstract Interpretation, Lecture
Notes in Computer Science, Vol. 3855, Springer,
2006, pp. 364–380.
[ 8 ] Pnueli, A. and Rosner, R.: On the synthesis of
a reactive module, Proceedings of the 16th ACM
SIGPLAN-SIGACT Symposium on Principles of
Programming Languages, 1989, pp. 179–190.
[ 9 ] Rosner, R.: Modular Synthesis of Reactive
Systmes, PhD Thesis, Weizmann Institute of Science, 1992.
[10] 島川昌也, 萩原茂樹, 米崎直樹: 仕様の自動検証に適
した LTL フラグメント–実現集合を表す決定性オート
マトン構成の立場から–, 日本ソフトウェア科学会第 23
回大会講演論文集, 2006.
[11] Sistla, A. P. and Clarke, E. M.: The complexity of propositional linear temporal logics, J. ACM,
Vol. 32,No. 3(1985), pp. 733–749.
[12] Sistla, A. P., Vardi, M. Y., and Wolper, P.: The
complementation problem for Büchi automata with
applications to temporal logic, Theor. Comput. Sci.,
Vol. 49,No. 2-3(1987), pp. 217–237.
[13] Tauriainen, H.: On Translating Linear Tem-
92
第四回システム検証の科学技術シンポジウム
( 9 )
Vol. 0 No. 0
poral Logic into Alternating and Nondeterministic
Automata, Research Report A83, Helsinki University of Technology, Laboratory for Theoretical Computer Science, Espoo, Finland, December 2003.
[14] van Emde Boas, P.: The Convenience of Tilings,
Complexity, Logic, and Recursion Theory, Lecture
Notes in Pure and Applied Logic, Vol. 187, Marcel
1983
9
Dekker, 1997, pp. 331–363.
[15] Yoshiura, N.: Decision Procedures for Several
Properties of Reactive System Specification, Software Security - Theories and Systems, Lecture
Notes in Computer Science, Vol. 3233, Springer,
2003, pp. 154–173.
93
第四回システム検証の科学技術シンポジウム
オーバーラップ制御の設計と検証
藤倉俊幸
Toshiyuki Fujikura1
*1
イーソル株式会社リサーチ＆コンサルテーションサービス部
eSOL Co., Ltd. Research & Consultation Service Department
を図 1に示す。
概要
部分的に多重化したパイプライン制御を効率的
に設計・検証する手法について報告する。本手法
では、多重度に対応したインスタンスレベルの動
作モデルを最初に作成し、モジュール分割、内部
動作の隠蔽、抽象化等のプロセス代数を利用した
形式的な処理により設計レベルの状態マシンを作
成する。この状態マシンは、システム構成に応じ
てハードウェアや RTOS 下のスレッド等のアーキ
テクチャ上の動作単位にマップし、詳細設計に落
とすことが出来る。
パイプライン設計
・ハード構成
・多重化決定
ターゲット
アーキテクチャ決定
全体動作モデル
作成
コンポーネント分割
抽象化全体モデル
コンポーネント
状態マシン作成
実装
コード生成
コンポーネント合成
検証
1. はじめに
複数工程をパイプライン的に連続して制御する
際に、各工程の処理時間が異なる場合には、処理
時間の長い工程を多重化してスループットを上げ
図 1 全体の流れ
ることができる。しかし制御プログラムは、並列
度が上がり複雑になるため効率的で正確な設計手
法が必要になる。一般に、製造工程で使用される
2. オーバーラップ制御とモデル化
工業用機器では、顧客の要望によりライン多重化
本手法が対象とするオーバーラップ制御につい
はオプションとして扱われることが多く、制御プ
ログラムは多様な多重化に対応できる必要がある。 て図 2を用いて説明する。
また、製造装置は正常時のスループットばかりで
袋に入
れる
100g
計る
なく、トラブル発生時の復旧に掛かる時間も短縮
A2
5sec
20sec
することが必要である。これらの要望に応えるた
A3
A1
_
めにプロセス代数をベースとした手法を開発した
ので報告する。
20sec
A4
A
本手法は、モデル検査ツール LTSA[1]をモデル
B
作成ツールとして使用する。LTSA がサポートす
B
る 、 双 模 倣 変 換 (minimal) 、 決 定 性 変 換
お煎餅
お煎餅
(deterministic)によって初期動作モデルを設計動
作モデルに変換する。最後に、LTSA のプロパテ
20sec に1ヶ
ィ検査により変換誤り等を検証する。全体の流れ
1
お煎餅
5sec
5sec に1ヶ
例えば、お煎餅を計量して袋詰めする工程を考
[email protected]
94
第四回システム検証の科学技術シンポジウム
える。この工程は、計量作業 A と袋詰め
態マシンとして、基本的には処理のスタート
(start)と処理自身(action)、処理の終了(end)を繰
図 2 オーバーラップ制御の例
り返す一般系を考える。対応するプロセスは
作業 B を直列に繋げることで構成される。工程と
LTSA で以下のように表現できる。これをパイプ
しては、一定時間に何袋製造できるかが重要であ
ラインを構成するコンポーネントのテンプレート
る。仮に、A に 20 秒掛かり、B に 5 秒掛かるとす
とする。
れば、A の作業を四重化して 5 秒ずつの時間差を
Pi = (startiÆactioniÆendiÆ Pi ).
持たせて並列に動作させると効率がよいことが分
かる。本報告ではこの様な制御をオーバーラップ
このプロセスを二つ連結したパイプラインを考
制御と呼んでいる。
図 2では処理 A、B のスタート/ストップの様な
える。多重化しない場合には図 3の様な構成にな
制御対象になる工程と、計量したお煎餅の自然落
る。ここでは簡単のために図 3の破線矢印で示し
下のような工程が混在している。制御対象外の工
たパイプライン全体に対する入出力は考えないこ
程は主に時間遅れとして初期動作モデルに含める
とにする。
ことが多い。その後、制御が必要な部分の切り出
P1 に対するトリガがなくなることから P1 は上
しをおこなう。実問題に対する初期モデルの作成
記の P プロセスではなく以下の Pf プロセスをテ
および検証は主にプロブレムフレーム[2]による問
ンプレートとして使用する。
題モデル作成後それを LTSA モデルに変換する手
Pf = (action1Æend1Æstart1Æ Pf ).
法を用いておこなう。
オーバーラップ制御を実現する場合、A と B の
多重化していないパイプライン全体の動作モデ
全体を一つのスレッドで実装する場合や、A をま
ル Pipe0 は以下のようになる。
とめて一つのスレッドに割り当てる場合、A1 から
A4 毎にスレッドを割り当てる場合などが考えられ
る。システムリソースに余裕があれば、スレッド
||Pipe0 = (p1:Pf||p2:P)
数を増やすことで設計を一見単純化することが出
/{ms/{p1.end, p2.start},
来るが、全体の状態が見えにくくなるので、緊急
me/{p1.start, p2.end} }.
停止などの対応が複雑になる。また、デバッグも
時間が掛かる場合がある。これらのトレードオフ
P1 の end を P2 の start に、P2 の end を P1 の
を考慮して実現方法を検討しなければならない。
start に接続することでパイプラインを構成する。
RTOS などの実装環境へのマッピングについては
また、接続したイベントをそれぞれ ms、me とす
る。これは、P2 から見たスタートメッセージ、終
了メッセージの意味である。
P1
P2
図 4 前段二重化パイプライン構成
次に、P1 処理を二重化したパイプライン(図 4)
文献[3]等で報告した。
について考える。この場合、{a.p1, b.p1}:Pf によ
3. 設計手順
簡単な例を使って設計・検証手順の説明をする。
a.p1
a.p1:Pf
aP1
図 3 パイプライン構成
0
m1s
1
P2
2
{m1s, m2s}
p2:P
m1e
パイプラインを構成する各コンポーネントの状
b.p1
b.p1:Pf
bP1
0
p2
1
{m1e, m2e}
m2s
1
m2e
95
0
2
2
第四回システム検証の科学技術シンポジウム
a.p1
a.p1
m2e
a.p1
Pipe1
Sys1
b.p1
0
m2s
1
p2
2
a.p1
m1s
3
4
5
p2
6
p2
7
m1s
8
p2
9
10
11
m2s
m2e
b.p1
b.p1
b.p1
m1e
m1e
図 5 全体動作モデル
って P1 プロセスのインスタンスを二つ生成する。
パイプライン全体の動作モデル Pipe1 は以下のよ
うになる。合成された動作モデルは図 5のように
Pipe1
なる。
a.p1
a.p1
m1s
||Pipe1 = ({a.p1,b.p1}:Pf||p2:P)
b.p1
Sys1P1Temp
/{m1s/{a.p1.end},
0
m2s
1
a.p1
2
m2e
3
m1s
4
5
6
7
b.p1
m2s/{b.p1.end},
m2e
m2s
{m1s,m2s}/p2.start,
m1e
m1e
m1e/{a.p1.start},
m2e/{b.p1.start},
p1
{m1e,m2e}/p2.end,
p1
p2satrt
p1
Sys1P1
a.p1/a.p1.act, b.p1/b.p1.act, // 前段処理
p2/p2.act} .
b.p1
0
2重
1
2
3
4
p2satrt
// 後段処理
p2end
aP1、bP1、P2 に対して個別にスレッドやハー
p2end
図 6 P1 状態マシンの導出過程
ドウェア等の並行・並列動作単位を割り当てるア
||Sys1P1Temp = (Pipe1) \{p2}.
ーキテクチャを採用する場合は、図 4の枠の中に
示した状態マシンを実装すれば良い。
minimal ||Sys1P1 = (Sys1P1Temp)
aP1 と bP1 をアーキテクチャ上の動作単位に割
り当てる場合は、全体動作モデルから P2 のみに
/{p2start / {m1s, m2s},
関係する動作イベント p2.act を内部動作として隠
p2end/{m1e,m2e},
蔽する(Sys1P1Temp)、さらに、二つあるインス
p1/{a.p1, b.p1}}.
タンスを同一視する抽象化をおこなうことで、ア
ーキテクチャ上の動作単位に実装すべき状態マシ
Sys1P1 を導出する際に ms および me は名前を
ン(Sys1P1)を得る。この過程を図 6に示す。
p2start および p2end に変更した。
P2 に対応する状態マシン(Sys1P2)も同様の手順
96
第四回システム検証の科学技術シンポジウム
で導出することができる。なお、導出した
である。この場合、デバイス毎の細かい制御が可
Sys1P2 は図 4の P2 状態マシンと同型になる。
能になる。また、制御用ではなく動作をモニタす
全体動作モデルからコンポーネントをアーキテ
るために使用することもできる。デバッグ時のみ
クチャにマップする際に、内部動作隠蔽をおこな
接続して動作をモニタしたり、半導体製造装置の
う。この処理をおこなわずに、全体動作モデルに
ように複雑な工程で例外が発生した場合の復旧計
対してインスタンス抽象化をおこなうことも可能
画を自動で立たりするようなアプリケーションが
である。この場合に得られる状態マシン
考えられる。
(Sys1Abs)は、システム全体を一つのアーキテク
実際の開発では、コンポーネントテンプレート
チャ上の実行単位にマップした場合の状態マシン
では対応できない場合がある。コンポーネント内
になる。
にタイムアウト機構が組込まれている場合や入力
に依存しない自律的な出力がある場合などで、内
p1
部動作隠蔽に失敗する場合がある。この様な場合
p1
p1
Sys1Abs
0
p2start
1
p2
2
には、コンポーネント分割やインスタンス抽象化
p1
3
4
5
p2
p2end
の過程でモデルから特定の遷移を削除したり、追
6
加したりする。あるいは制約条件を変換の途中で
p2start
p2end
追加することもある。また、抽象化の過程で非決
図 7 全体モデルを抽象化したもの
定性状態マシンが導出される場合もある。これら
の様な場合には、全体モデルで成立していた性質
この状態マシンは、各コンポーネント状態マシ
が保存されないことがある。実際の開発における
ン、Sys1P1 と Sys1P2、を合成することでも得る
これらの問題については今後の課題としたい。
ことが出来る。そして合成した物が Sys1Abs と一
致することで導出過程の正しさを検証することが
参考文献
できる。
[1]
Jeff Magee,Jeff Kramer,Concurrency, State Models &
Java Programs,Wiley,2006.
[2]
マイケル・ジャクソン, プロブレムフレーム, 翔泳社,
2006.
[3]
林純也、藤倉俊幸, モデル検査を利用したマルチコ
アでのタスク設計と検証の提案, ESS2007 論文集.
4. 考察
一般に、モデル検査ベースの手法を設計過程で
使用する場合、設計が詳細化するに従って状態数
が増えて、最後に状態数爆発が起こる。このため、
モデル検査手法を実開発に適用することを躊躇す
ることが多い。本手法では、状態数を減少させる
方向に開発が進むためその心配が無い。また、初
期に開発する全体動作モデルは、パイプライン全
体である必要は無く、境界条件に注意すれば部分
を切り出してモデル化することも可能である。さ
らに、パイプラインは繰り返し構造で構成される
ことが多いので、一度作成したコンポーネント動
作モデルは再利用しやすい。すなわち、幾つかの
多重化パターンをあらかじめ用意することが可能
である。
中間生成物であるインスタンス抽象化をおこな
う前の状態マシンを制御用に使用することも可能
97
第四回システム検証の科学技術シンポジウム
( 1 )
1
機能安全のためのソフトウェア認証制度普及
に向けた取り組みの紹介
長谷部 浩二
本稿では，ソフトウェア認証制度普及に向けて産総
研システム検証研究センターが行っている研究活動
を紹介する．特にここでは，機能安全のためのソフ
2 研究の背景と目的
具体的な研究内容に入る前に，まず「機能安全」と
トウェア認証に話題を限定して，研究の背景と目的，
はどのような概念なのかを，ここで簡単に説明して
これまでの活動内容，および今後の目標について述
おこう．例えば自動車の場合，衝突によるドライバー
べる．
の危険（リスク）を低減するために，エアバックや
ABS などの安全装置を装備したり，あるいは自動車
1 はじめに
を制御するオペレーティングシステムに時間保護や
今日，自動車や航空機などの大規模なシステムから
メモリ保護などの機能を付加することが考えられる．
家電などの身近な製品に至るまで，我々の身の回りの
このように，
「安全関連系（安全装置など）を用いて
さまざまなものがソフトウェアによって制御されてい
危険源を制御することにより得られる安全」を機能安
る．そのため，ソフトウェアの小さな不具合により，
全と呼ぶ．
人命や環境に甚大な被害をもたらす可能性が，近年
この機能安全の考え方によって，安全性の高いシ
非常に高まっている．こうしたソフトウェアの偏在化
ステムを構築するための国際規格として，IEC 61508
に伴う危険性を回避もしくは低減し，我々が安心して
[2] が発行されている．この規格は，システムの安全
安全な生活を営むための基盤技術を提供するために，
性を確保するための要求事項をシステムのライフサ
産総研システム検証研究センター（以下 CVS）では，
イクル全体にわたって規定したプロセス規格であり，
数理的技法を基にしたソフトウェア検証の理論的・実
システムを構成するソフトウェアについても本格的に
践的な研究を行うとともに，ソフトウェアの認証制度
要求事項を規定しているという点に特徴がある．ソ
普及に向けた研究活動を行っている．本稿では，後者
フトウェアの設計・開発に対する要求事項はこの規格
のソフトウェア認証に関する研究活動について紹介
の第 3 部にまとめられており，開発プロセスの各工
する．CVS ではソフトウェア認証に関していくつか
程において使用すべき技法や手法が規定されている．
の研究を行っているが，その中でも特に機能安全のた
この IEC 61508 は，近年，産業界において大きな注
めのソフトウェア認証に話題を限定して紹介する．な
目を集めており，種々の分野別規格が発行されるとと
お，紙幅の関係から詳しく紹介しきれなかった内容に
もに，海外ではこの規格の認証制度が普及してきて
ついては， [1] を参照されたい．
いる．しかしながら，この規格が欧州主導で策定され
たという経緯もあり，国内の特にソフトウェア分野に
Koji Hasebe, 産業技術総合研究所システム検証研究セ
ンター, Research Center for Verfication and Semantics, AIST
おいて，この規格の普及の遅れが問題となっている．
その原因の一つとして，IEC 61508 の第 3 部で規定
98
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
2
( 2 )
された技法や手法の具体的な適用事例が少なく，認証
ジェクトが，戦略的基盤技術高度化支援事業「機能安
基準が不明確であるということが挙げられる．その
全対応自動車制御用プラットフォームの開発」であ
ため，国内で IEC 61508 の認証制度の普及が遅れる
る．これは，IEC 61508 に適合した車載用リアルタ
と，近い将来，国内で生産された認証を取得していな
イム OS 及び通信ミドルウェアの開発を目標とするプ
いソフトウェアが海外において使われなくなるという
ロジェクトであり，CVS は，ソフトウェア安全性分
懸念が高まっている．
析や，数理的技法による検証，また認証を実証的に進
こうした問題を背景に，CVS では，IEC 61508 を
める役割を担っている．以下では，このプロジェクト
はじめとする機能安全規格に対してその認証基準を
の初年度で，CVS がプロジェクト参加メンバーと共
明確化し，国内での IEC 61508 の認証制度を普及さ
同で進めてきたソフトウェア安全性分析手法の開発に
せるための研究活動を行っている．これにより，我々
ついて，その概要を紹介する．
は，先に述べたような懸念を払拭し，国内のソフト
ソフトウェア安全性分析とはどのようなものである
ウェア産業の国際競争力を高める効果を期待すると
のかを，ここで簡単に説明しておく．IEC 61508 で
ともに，以下のような効果も期待している．まず，製
は，システムの安全を達成するために必要となる要求
品の消費者（もしくは利用者）にとっては，安心し
仕様のうち，ソフトウェアに対する部分をソフトウェ
て製品を購入もしくは利用できるという利点がある．
ア安全要求仕様と呼んでいる．そしてソフトウェア
一方で生産者にとっては，規格に準拠した方法によっ
開発プロセスの最初のフェーズにおいて，ソフトウェ
て安全な製品を開発することができると考えられる．
ア安全要求仕様を決定しなければならないと定めて
また近年，ソフトウェアコンポーネントをアウトソー
いる．そのための作業のことを総称して，ソフトウェ
シングすることが行われており，それに伴って海外で
ア安全性分析と呼ぶ．ソフトウェア安全性分析では，
は，コンポーネントに対する認証取得が（RTOS な
ハザード分析およびリスク評価が中心となる．ハザー
どにおいて）実際に行われている．こうした場面にお
ド分析とは，予見可能な全てのハザード（潜在危険）
いてコンポーネントに対する認証制度が普及すると，
を列挙する作業である．またリスク評価とは，ハザー
安全性の観点から複数のコンポーネントを比較する
ド分析の結果を踏まえて，リスクが許容レベル以下で
上での明確な基準を与えることができ，国内において
あるか否かを判断する作業である．ハザード分析およ
も（特に安全に関わるシステムを構築する際の）ソフ
びリスク評価の結果，リスクが許容レベルを上回ると
トウェア開発の効率化に繋がると考えられる．
判断された場合，それを軽減するための機能を実現
するためにソフトウェアに対して要求される事柄が，
3 模擬認証の試み
ソフトウェア安全要求仕様となる．
IEC 61508 の具体的な認証基準を明確化するため
しかしながら，このプロジェクトにおいて対象とす
に，CVS が最も効果的と考えている研究の方法が模
るようなソフトウェアコンポーネント単体での認証
擬認証である．模擬認証とは，CVS が民間企業など
を得るためには，ソフトウェアのコンポーネントのみ
のソフトウェア開発者と協力し，IEC 61508 で規定
を対象とした安全性分析が必要である．先に述べた
されている手法や技法を実際のソフトウェア開発プ
ように，IEC 61508 のフレームワークでは，ソフト
ロセスに導入し，さらにその導入事例に対して CVS
ウェアの安全要求仕様を獲得するためには，それを含
が仮想的な認証機関となって規格の適合性を評価す
んだ何らかのシステム全体の安全性分析が必要であ
るというものである．特に，事例が乏しい数理的技法
る．ところが，ソフトウェア単体での認証取得を行う
（formal mehtods）やソフトウェアの安全性分析手法
場合には，通常，そのソフトウェアが使われるシステ
などを中心に，我々はこの模擬認証を通じて認証基準
ムが具体的に定まっていない．そのため，ソフトウェ
を明らかにしたいと考えている．
アの安全要求仕様は，いわば先回りして，我々の側で
模擬認証を行う場として CVS の参加しているプロ
安全機能と呼べるソフトウェアの機能をあらかじめ
99
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
1983
3
決めておき，その機能に不具合が生じたときにどの
様化に伴い，ソフトウェア安全性の概念も（例えばセ
ようにそれを回避もしくは低減するのかを分析する
キュリティの問題などと密接に関連することにより）
必要がある．以上のようなソフトウェア安全性分析
複雑になってきており，こうした視点を盛り込むこと
手法については，実際にどのように実施するのかに
も重要である．さらに，先の模擬認証の成果や，ソ
ついての具体的な事例報告が乏しく，そのため，我々
フトウェア安全性概念の議論をもとに，我々は IEC
はプロジェクトのメンバーと共同で，このソフトウェ
61508 認証基準の策定を行い，将来的には国内でのソ
ア安全性分析手法の開発を実証的に進めている．
フトウェア認証制度の確立を目指したいと考えてい
る．これは，現行規格の改訂や規格に対する技術文書
4 今後の目標
認証制度普及に向けた今後の研究活動としては，短
（ガイドライン）を提案するのみならず，政府や産業
界との連携による社会的な活動も必要である．
期的には前節で紹介したプロジェクトにおいて模擬認
以上で述べた目標は，息の長い継続的な研究活動が
証の活動を継続して行うことを計画している．特に
不可欠であるが，CVS では模擬認証を出発点に，今
今後は，数理的技法による仕様記述や検証に関して，
後もソフトウェア認証制度普及に向けて活動を行う予
先のソフトウェア安全性分析と同様に模擬認証を行う
定である．
予定である．
また長期的な課題としては，まずソフトウェア安全
性の概念を整理・明確化することが挙げられる．そも
そも「安全なソフトウェア」とはどのようなものであ
るのかについて，かなり以前から議論がなされている
ものの，共通理解を得た明確な定義がなされていると
は言いがたい．加えて近年のソフトウェアの用途の多
参考文献
[ 1 ] 水口大知，長谷部浩二．ソフトウェアの安全性をめ
ぐる課題について．日本信頼性学会誌 Vol. 29，No. 5
（特集号「人に触れる機械の課題」），pp. 310-318，2007
年 8 月．
[ 2 ] IEC．IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety Related Systems，1998-2000．
100
第四回システム検証の科学技術シンポジウム
( 1 )
1
研修コース研究開発
西原 秀明
を目に見えるように制度化することを企画して
1 背景
以前に較べて数理的技法の認知度は上昇し，産業界
での適用事例も散見されるほどになりました．しか
います．
この講演では，特に現在集中して進めているモデル
検査研修コースの開発についてお話しします．
し社会全体で見るとまだ数理的技法は広く認知され
ている技術とは言えません．その一つの理由として，
2 目的
数理的技法の教育体系が確立されておらず，数理的技
教育環境を整えるという観点からは，前述の活動
法の実体を学ぶ機会が殆どないということがあると
内容のうちで研修コースの開発が最も中心的なもの
思われます．
になります．その元となるカリキュラム「CVS 教程」
システム検証研究センター (以下 CVS/AIST) で
を定めた際，コース作成に関して幾つかの指針を設定
は，2004 年度から「研修コース班」を立ち上げ，広
しました．それらをまとめると，
「技術者向けに汎用
い視点から数理的技法教育環境の整備を行っていま
的な知識を教える．理論にも適用対象にも偏らず両方
す．それは具体的には三つの内容に分けられます．
をバランスよく教える」ということになります．
• 一つ目は学習カリキュラムを策定し，研修内容
数理的技法は数学・論理と関係が深く，抽象概念が
や程度を明確にすることです．2005 年度に我々
各所に現れたり数学特有の表現が現れたりします．そ
はモデル検査と対話型証明についてカリキュラム
れらは諸概念を手短に曖昧さなく記述するという大
を作成し，
「CVS 教程」と名づけました．それぞ
きな効果をもたらすわけですが，学習の際の障壁の一
れ初級編・中級編・上級編の三つのコースを設定
つとなっています．よってつくられる教材は抽象概念
し，レベルに合った研修が可能です．
の扱いや論理に慣れていない人でも習熟度に応じて
• 二つ目はカリキュラムにそって各種研修コース
を開発することです．2005 年度末にモデル検査
研修内容を全て理解できるように作られている必要
があります．
研修コース初級編が完成し，現在はモデル検査研
また，とりあえずツールが動いて結果が出るからと
修コース中級編と上級編を中心に開発を進めて
いって検査メカニズムや理論を軽視したり，逆に理論
います．
の細部に拘って「検査するための技法である」ことを
• 三つ目は数理的技法技術者の技術を評価し社会
忘れてしまっては本質を見失ってしまいます．多様な
的な価値を高める仕組みをつくることです．現在
実例の抽象としての理論と，抽象概念や理論に実体を
は企画調査段階ですが，技術者資格などでスキル
与える例を偏りなく扱い，両者が相補うものである
Hideaki Nishihara, 産業技術総合研究所システム検証研
究センター (CVS/AIST)
ことを理解できるように教材を作成する必要があり
ます．
101
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
2
( 2 )
使わないわけではなく，具体例や演習を通して理解で
3 方法
きるように教材を作成しています．特に，技術や理論
2005 年度までに作成した「モデル検査研修コース
の修得においては，実際に手を動かして操作をなぞっ
初級編」は「モデル検査の概要を知る」ことを目標と
てみたり，少しずつ異なる複数の例を考えてみたりす
し，内容はモデル検査の概要と作業手順，使用例の紹
ることが有効であるので，研修では各演習に十分な時
介にとどまっていました．
間を割いて進めるようにしています．
現在開発中の中級編では，初級編修了者が「モデル
研修コースの開発ということで，コーステキスト
検査の典型的な技術を学ぶ」という目的を設定し，典
以外のマテリアルも整備開発しています．コースを開
型的な技術としてモデルの合成，抽象化，計算木論理
催するためのマテリアルとして，研修の時間配分例，
(CTL) の三つの題材を扱います．
講師が研修を進める際のヒント集，よくある質問など
モデルの合成は基本的な技術ですが，その意味する
ものはツールや問題の文脈によって幾つかの流儀が
をまとめました．これらは四度にわたる試行開催の経
験から実際に得られたデータをもとにしています．
あります．中級編では四種類の合成を紹介し，合成の
仕方や応用例を紹介します．抽象化はモデル検査を適
4 成果物
用する際によく使われる重要な技術です．少し一般的
「モデル検査研修コース初級編」の教材その他のマ
に，写像で与えられる抽象化と，保たれる性質につい
テリアルをパッケージ化しました．現在技術移転ベン
て説明した後，抽象化の例であるデータ抽象化と述
チャー企業がそれを使用して研修コースを開催してい
語抽象化を時間をかけて説明します．CTL は検査式
ます．また受講者用のテキストを改めて書籍としてま
を記述する論理体系としてよく使われるものですが，
とめ，出版しました [1]．
本コースの初級編では LTL のみを使って検査項目を
「モデル検査研修コース中級編」も同様の展開を目
記述していました．CTL と LTL という主要な二つ
指しています．現在は教材その他のマテリアルのパッ
の論理体系を知ることで，より適切な検査式をつくる
ケージ化が終わった段階にあり，コーステキストを出
能力を身につけます．
版公開するべく準備を進めています．
モデルの合成，モデルの抽象化，CTL はどれも抽
象理論としての扱いが可能なテーマですが，コース作
成の指針に沿って，過度に抽象化・一般化して記述す
ることは避けています．ただし抽象概念や理論を全く
参考文献
[1] 産業技術総合研究所システム検証研究センター:『4 日
で学ぶモデル検査 (初級編)』 NTS, 2006.
102
第四回システム検証の科学技術シンポジウム
( 1 )
1
MLAT
田辺 良則
抽象構造作成ツール MLAT は，ポインタを扱うプ
への遷移は，プログラム上では，ある実行文の列 cs
ログラムの性質の検証をするために，述語抽象化の手
と対応しています．そこで，A ∧ wp(cs, B) という論
法によって抽象構造を作成するツールです．この発表
理式を作り，この充足可能性を判定します．ここで，
では，ツール MLAT の現状を報告します．
wp は，最弱事前条件を表します．それが真の場合，
すなわち，充足可能である場合には，遷移があると判
1 ツール MLAT 概要
定します．そうでない場合には，遷移がないと判定し
MLAT は，Modal Logic Abstraction Tool の略で，
ます．
ポインタを操作するプログラムの検証のための，抽
この抽象遷移作成部分が，MLAT の中心部分をな
象構造を作成するツールです．抽象遷移系を自動作成
しています．この機能を取り出して単体ツールを作成
し，その遷移系に対してモデル検査を行う，という検
しました．そのツールを，pfvalid と呼んでいます．
証手続きを支援することを目的とします．
MLAT には，次のような特徴があります．
3 ツール構築およびその評価
• 述語抽象化の枠組みを採用している．
いままでに述べました原理をもとに，ツール MLAT
• ポインタによって構築されるデータ構造の性質
を検証できる．
• 抽象化に，様相論理を使用する．ポインタが指
すという関係を様相ととらえる．
の version 1 を構築し [2]，いくつかのプログラムの検
証を行いました．その際，様相論理として「ノミナル
付き 2 方向 CTL」というものを採用しました．結果
として，次のようなことがわかりました．
• 簡単なプログラムとその性質は検証可能である．
2 MLAT が行う抽象化の原理
• 複雑なプログラムやその性質の検証を行おうと
すると計算量が大きくなり，実用的な時間内に結
MLAT は，述語抽象化によって抽象構造を作成し
果が得られないことが多い．
ます．抽象構造を作成するときには，遷移可能性を判
定する必要があります．その判定は，最弱事前条件と
• 検証対象によっては，より強力な性質記述力が
必要となる場合がある．
充足可能性判定を組み合わせて行います．
例えば，抽象状態 A から B への遷移が可能かどう
かを判定する際には，次のようにします．A から B
これらを受け，次のような取組みを行っています．
まず，複雑なプログラムや性質で計算量が大きくなる
点については，アルゴリズムの改良および統合検証環
Yoshinori Tanabe, 産業技術総合研究所 システム検証
研究センター, Research Center for Verification and
Semantics (CVS), National Institure of Advanced
Industrial Science and Technology (AIST)
境での問題分割を試行しています．後者の統合検証環
境のアプローチは，自動検証の枠組みにとらわれず，
利用者が対話的に行う検証行為をサポートするとい
103
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
2
う方向を目指しています．
性質記述力の強化は，論理の拡張で対応します．こ
( 2 )
操作するプログラムを記述することができる．
• 検証する性質を記述するための，性質記述論理．
の拡張には，2 つの方向が考えられます．1 つは，充
線形時間論理 LTL をベースとする．
足可能性判定が決定的である範囲での拡張です．この
• 証明に用いられる Hoare 論理．
方向では，様相 µ 計算の導入を行いましたので，後
以上の枠組みに基づいたプロトタイプを作成し，
述します．もう 1 つの方向としては，充足可能性問題
いくつかのプログラムと性質の検証を行いました．
が決定可能でない範囲にまで論理を拡張することが
MLAT 単体での検証に比較し，問題を分割した効果
考えられます．たとえ理論的には決定不可能であって
が確認されました．
も，実用的な問題を解くには十分な決定手続きが見い
だせる可能性はあるからです．これは，今後の検討課
5 Deutsch-Schorr-Waite マーキングアル
ゴリズムの検証
題です．
上述の MLAT version 1 に対して，以下の改善を
4 Agda-MLAT 連携
対話型証明支援系 Agda [3] を利用して，統合検証
行いました．
• 状態記述言語を CTL ベースのものからμ計算
ベースのものに拡張し，記述力を向上させた．
環境での問題分割というテーマにとりくんでいます．
このアプローチでは，利用者が対話的に，プログラム
• MLAT の充足可能性判定器の性能を改善した．
これにより自動証明の能力が向上した．
が正しいことの証明を構築します．証明は Hoare 論
理に基づいて行われます．システムはこの作業を支
• Agda 上のライブラリにも簡単な自動推論機能
を備えた．
援します．利用者にとってのインタフェースは Agda
であり，プログラムと検証する性質を Agda 上で参照
しながら，証明を構築することになります．
MLAT は，agda の裏側で動作します．実際に使用
この改良の結果，ポインタ解析のベンチマークとし
て知られる，Deutsch-Schorr-Waite マーキングアル
ゴリズムの安全性の検証が可能となりました [1]．
されるのは，前述した pfvalid です．pfvalid は，agda
の plug-in 機構を用いて，利用者が呼び出すことにな
ります．
利用者が，問題を定理の形で記述したり，証明を
構築したりする際に，agda のライブラリ群が必要
になりますので，これを作成し，PML-Hoare Logic
Library と名付けました．ライブラリ群が扱う範囲に
は，以下のものが含まれます．
• PML と呼ばれる，プログラム言語．ポインタを
参考文献
[ 1 ] 湯浅 能史，田辺 良則，関澤 俊弦，高橋 孝一: AgdaMLAT 連携による Schorr-Waite マーキングアルゴリ
ズムの検証, 日本ソフトウェア科学会第 24 回大会, 2007
年 9 月 13 日
[ 2 ] 田辺 良則, 関澤 俊弦, 湯浅 能史, 高橋 孝一: 様相論
理を使用したヒープ検証方式 . 第 3 回ディペンダブルソ
フトウェアワークショップ (DSW’06), pp.39-50, 2006
[ 3 ] Agda Official Web Site
”http://agda.sourceforge.net/”
104
第四回システム検証の科学技術シンポジウム
( 1 )
1
Agda-IVE の実用問題への適用
加藤 紀夫
Agda-IVE は Martin-Löf 型理論に基づく対話型
る、という検証スタイルを支援するものである。
証明支援系 Agda の上に構成された統合検証環境で
Agda-IVE の中核は、Agda から外部の自動検証器
ある。本研究では、Agda-IVE を MPI 通信ライブラ
を呼び出すプラグインの一般機構である。Agda と自
リ YAMPII における検証という実用問題に適用し、
動検証器は
その適用可能性を確かめることに成功した。とくに、
1. 自動検証器が支援する論理の Agda 上の実装と
while 文のポインタ構造に関する不変式を対話的に発
2. Agda からの自動検証器への呼び出しを自動化
見するために非常に有用であったことを報告する。
するプラグイン機構
によって接続される。このプラグイン機構を用いて
1 背景
SMV や FOL（Gandalf）、それに後述する MLAT な
システム検証研究センター（CVS）定理証明研究グ
どのシステムを Agda から呼び出せるようにし、対話
ループは、さまざまな検証方式を適材適所に適用し結
型検証と自動検証を局面に応じて使い分けることを
果を統合するための統合検証環境 Agda-IVE（Agda
可能にしている [2]。
Integrated Verification Environment）の研究開発を
行った。統合検証環境では、さまざまな検証問題の記
1.2 Martin-Löf 型理論に基づく証明支援系
述、小問題への論理的分解、各種自動検証ツールの
Martin-Löf 型理論は、論理とプログラミングを統
呼び出し等を、共通の記述言語とユーザーインター
一する基礎理論である。論理式に対する証明の構成と、
フェースによって行うことができる。統合検証環境は
プログラム仕様（型）に対するプログラムの構成とは
これらの過程を整合性が保証される形で半自動化する
同一の原理で基礎付けられるという、Curry-Howard
ため、各種ツールを手動で組み合わせるのに比べて、
同型の考えに基づく。型理論は、証明をプログラムと
より確実で、より便利である。
して書ける汎用プログラミング言語の理論と言える。
論理としては直観主義高階論理を含む。システム検証
1.1 Agda-IVE
の基盤として型理論が優れているのは、システムのモ
Agda-IVE は、Martin-Löf 型理論に基づく対話型
デルとなるプログラム、検証したい性質を表す論理
証明支援系 Agda [1] の上に統合検証環境を構成した
式、モデルが性質を満たすことの証明をひとつの体系
ものであり、外部の検証ツールを Agda から呼び出
で扱えるためである。
し、検証の結果を再び Agda に取り込んで検証を続け
構成的型理論や高階論理などに基づく証明支援系
の研究は 1980 年代に始まり、現在では Agda をふく
Norio KATO, 産業技術総合研究所 システム検証研究セ
ンター, AIST, CVS
めて多数の実験システムが構築され、一部は、銀行オ
ンラインシステムの検証などの実用に供されている。
105
第四回システム検証の科学技術シンポジウム
2
コンピュータソフトウェア
しかしながら、証明支援系を他のシステムの作業台
（workbench）として用いる発想は、一部に萌芽がみ
( 2 )
よって発行され、実際の通信は REQUEST 層での
ポーリングのタイミングで行われる。
られたものの、CVS が Agda-IVE によって初めてこ
の発想を明確にし、実装してみせた。
3.2 検証項目の策定
YAMPII のような巨大なシステムを限られた期間
1.3 MLAT プラグイン
とマンパワーで検証する場合には、システム全体の
CVS の自動検証研究グループは、彼らの研究開
完全な検証は不可能であるから、検証項目に優先順
発する MLAT システム [3] の一部である Hoare 三
位をつける必要がある。優先順位は、いろいろな価値
つ組の自動検証器を Agda-IVE から呼べるように
観で決定されうる。今回は、開発者にとって、もっと
した。これにより、MLAT の入力言語である PML
もバグが出やすそうに思われるのはシステムのどの
（Pointer Manipulation Language）の基本命令列に
部分のどんな性質に関してか、ということを調査し、
関する Hoare 式の自動証明が Agda-IVE で行えるよ
検証項目を決定した。調査では、過去の開発過程で実
うになり、同時に、while 文を含む一般の PML プロ
際に発生したバグについて聞き取り、検証項目を決定
グラムの対話的な検証が Agda-IVE で行えるように
する材料とした。その結果、YAMPII が通信要求を
なった。MLAT プラグインを使うと、ポインタ代入
管理するときに使う待ち行列が正しく実装され、かつ
文を実行する前後でのポインタ構造に関する性質を、
正しく使われていることの検証を行うことにした。こ
簡潔に記述し検証することができる [4]。
の部分はポインタ操作が関係するため、バグが入る可
能性が他の部分よりも大きそうであったからである。
2 目的
そこで、図 1 に記すようなプログラムに関して、
本研究では、Agda-IVE の適用可能性を確かめるた
Agda-IVE による検証を行った。そしてこのプログラ
めに、Agda-IVE を実用問題に適用することを試みた。
ムに関して、「q ではじまる二重リストが良形（well-
具体的には、実用問題として MPI（Message Passing
formed）である」が while 文の不変条件（invariant）
Interface）の石川裕らによる実装である YAMPII [5]
になっているということを検証すべき項目として設定
の検証をとりあげることにした。このシステムを取り
した。不変条件の論理式は、命題論理の表現力に限界
上げた理由は、MLAT プラグインを用いて検証する
があるために、非常に長くなった（20 以上のリテラ
のに向いたポインタ処理が含まれていそうなことな
ルの連言）が、2 名で 3.5 か月程度かけて発見し記述
どもさることながら、開発者のグループが検証実験に
することができた。
極めて協力的であったことも影響が大きい。
この検証項目は、Agda-IVE を用いて 5 名で約 1
か月かけて検証することができた。検証そのものより
3 方法
も、その前段階である、検証すべき部分をうまく切り
我々は、YAMPII のなかからポインタ操作に問題
出して適当な検証項目を設定する作業に、より多くの
が起こり得る部分を抽出し、その部分の正当性を
手間がかかっていることに注意すべきである。また、
Agda-IVE を用いて検査するという作業を行った。以
この検証項目設定の段階では、二重リストが良形で
下ではその方法を順番に説明する。
あることを含意するような不変条件の論理式を発見
するために試行錯誤するが、この作業を行うために、
3.1 YAMPII の構成の概観
Agda-IVE の対話環境と MLAT の最弱事前条件計算
YAMPII は、通常の通信システムと同じく、いく
器が極めて有効に機能した。これらの結果は、実際の
つかの層に分けてメッセージを処理する。その中の
検証作業において Agda-IVE のような対話的な環境
REQUEST 層が待ち行列を使って通信要求を管理し
による支援が有用であることを示している。
ている。通信要求は上位層である SENDRECV 層に
106
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
issued.val := FALSE
insert(sQ,req)
req.val := SENDING
while (req.val != DONE)
if (*) if (issued.val == FALSE)
issued.val := TRUE
req.val := CANCEL
if (*) if (e1 <- sQ.top)
remove(sQ,e1)
if (e1.val == CANCEL)
insert(cQ,e1)
e1.val := WAIT
else e1.val := DONE
if (*) if (e2 <- choose(cQ))
remove(cQ,e2) e2.val := DONE
1983
3
度か行い、改良をすすめることによって、大規模シス
テムに対して、妥当な形で形式的検証法を適用するこ
とが可能になることが予想される。
Agda-IVE は、記述調整の支援を Agda によって行
なう道を拓くものである。その結果、自動検証システ
ムの利用範囲を拡大し、情報処理システムの信頼性向
上に寄与することができる。
CVS では、Agda-IVE の普及のため、手引などの
ドキュメントを整備する一方で、Agda の公式ホーム
ページ http://unit.aist.go.jp/cvs/Agda/ を新
設し、one-click installer などを提供して配布体制を
強化している。
• insert/remove/choose は別途定義された関数
• if (*) B は B の非決定的実行
• sQ (sendQueue): 送信要求の待ち行列
• cQ (cancelQueue): キャンセル応答の待ち行列
図1
検証対象の PML プログラム
4 結論・成果物
本研究によって、統合検証環境 Agda-IVE を用い
た検証手法が確立し、その適用可能性を確かめること
ができた。今後、Agda-IVE の適用実験をさらに何
参考文献
[ 1 ] Agda. http://unit.aist.go.jp/cvs/Agda/
[ 2 ] 池上大介. 対話型証明支援系 Agda のプラグイン
機構. 日本ソフトウェア科学会第 22 回大会, 東北大学.
2005.
[ 3 ] 田辺良則, 湯浅能史, 関澤俊弦, 高橋孝一. 様相論理
を使用したヒープ検証方式. 第 3 回ディペンダブルソフ
トウェアワークショップ（DSW’06）. 2006.
[ 4 ] 湯浅能史, 高橋孝一, 田辺良則, 関澤俊弦, 武山誠. 自
動証明系と定理証明支援系の連携によるポインタ操作プ
ログラムの検証について. 日本ソフトウェア科学会第 23
回大会, 東京大学本郷キャンパス. 2006.
[ 5 ] 石川 裕. YAMPII もう一つの MPI 実装. 情報処理
学会, SWoPP’04, 2004.
107
第四回システム検証の科学技術シンポジウム
( 1 )
1
図示記法
吉田聡
小池憲史
竹内泉
大崎人士
いることが明らかになりました. その主な理由は, 時
1 背景
相論理の習得はソフトウェア開発現場の技術者にとっ
モデル検査法は, システムに潜む発見困難な不具合
て心理的ハードルが高く, 検査項目の時相論理式によ
の検出や, 再現性の極めて難しい不具合の原因を究明
る表現を自在に行うことが困難であることにありま
する技術として期待されるものです. 矢崎総業株式会
した.
社と産業技術総合研究所システム検証研究センター
例えば, 図 1 は C ソースコードに対するモデル検査
は, これまでモデル検査法を効果的に車載ソフトウェ
による検証プロセスを表しています. ここでは, ソー
ア開発現場に導入するための研究を共同で行ってきま
スコードからモデルすなわち遷移系を作成し, プログ
した. その中で, 仕様から得られる検査項目を時相論
ラムの要求仕様から検査項目を与え, それを時相論理
理式として表現するという検査式の作成作業は, 検査
式に表現した検査式を与えています. そして, それぞ
期間においてモデル作成に並んで大きな工数を占めて
れをモデル検査器に入力し検査を行いますが, 状態爆
発などにより検査が完了しない場合やモデルや検査
式に間違いがある場合は, モデルや検査式を修正 · 変
1. ⢛᥊
C䉸䊷䉴䉮䊷䊄
if (a<0) {
䊶䊶䊶
}
x++;
ㆫ⒖♽
更して再び検査器に入力します. これを繰り返すこと
᛽⽎ൻ
ᄌ឵
㐿⊒⃻႐䈮䈍䈇䈩ᔃℂ⊛
䈭䊊 䊄䊦䈏ૐ䈇
䈭䊊䊷䊄䊦䈏ૐ䈇
⁁ᘒ῜⊒
䊝䊂䊦
䊂䊦
ᬌᩏེ
෻଀⸃ᨆ
䇸Yes䇹䉁䈢䈲
䇸No + ෻଀䇹
ᬌᩏᑼ
ⷐ᳞઀᭽
⠡⸶
⁁ᘒ῜⊒
Ᏹ x<5 䈎䋿
Ᏹ䈮
䈎
[] (x < 5)
෻଀⸃ᨆ
ᄌᦝ
によって検査式がモデルにおいて成立するか否かを判
定します.
このプロセスの中で, 本質的に難しいところはモデ
ル作成の作業における抽象化の部分です. しかしなが
ら, 例えば, モデル検査器 SPIN を用いる場合, その
ᢙℂ⺰ℂቇ䈱⍮⼂䉕ᔅⷐ䈫䈜
䉎䈢䉄⃻႐䈱ᛛⴚ⠪䈮䈫䈦䈩ᔃ
ℂ⊛䈭䊊䊷䊄䊦䈏㜞䈇
モデル記述言語である Promela は C 言語に類似した
言語であることから, そのモデル作成は通常のプログ
ラミングとして行うことができます. さらに, C ソー
図1
背景
Satoru Yoshida, 産業技術総合研究所システム検証研究
センター
Satoshi Koike, 矢崎総業株式会社技術研究所
Izumi Takeuti, 産業技術総合研究所システム検証研究セ
ンター
Hitoshi Ohsaki 産業技術総合研究所システム検証研究セ
ンター
スコードに忠実なモデルの作成を行うとき, 我々はそ
れを機械的な行うことができます. つまり, 抽象化の
部分を除けば, ソフトウェア開発現場の技術者にとっ
てモデルの作成作業は比較的着手し易い部分という
ことができます. 一方, 検査式の作成について, 時相
論理に馴染んでいない現場の技術者にとって時相論理
108
第四回システム検証の科学技術シンポジウム
2
( 2 )
コンピュータソフトウェア
式によって検査項目を表現することは敷居が高く, こ
図 3 では, 次の 4 つの LTL 論理式 ˜P （ボックス
のことがモデル検査技術を現場導入する際の大きな
P ）, ♦Q（ダイヤ Q）, ˜(P → Q)（ボックス (P な
阻害要因になっています.
らば Q)）, ˜(P → ♦Q)（ボックス (P ならばダイヤ
本研究では, その阻害要因となる検査式の作成に注
Q)）に対する図示記法による図を与えています. そ
目し, 検査式と検査項目の直観的理解の間を繋ぐ時相
れぞれの論理式に対応する図において点線矢印は状
表現として「図示記法」を考案しました。
態遷移系における実行列（時間軸）を表わしており,
黒点は一つの状態（時点）, そして, 黒点から上に縦
2 目的
に伸びている線分の上に原始命題がある場合, その黒
ソフトウェア開発現場の技術者にとって受け入れや
点の状態においてその原始命題が成り立つことを表
すい時相表現は, 図 2 で挙げた 3 つの特徴を備えてい
します.
ると考えられます. すなわち, 一つは特別な知識を前
図 3 における (a) について, これによってその実行
提としない時相表現であり, 二つめは誰もが受け入れ
列上の任意の状態において P が成り立つことを表し
られる直観的表現, そして, 三つめは行いたい検査内
ています.
容を表現できる表現力です. 本研究では, これら 3 つ
(b) について, 視点が与えられていて, その視点の
を備えたものが図による表現であると考えました. そ
ある状態から先にある状態（未来の時点）において P
して, その記法を確立することによって, 検査式の作
が成り立っていることを表します. そして, (init) は
成と理解を助け, さらに他の人に検査の内容を伝える
初期状態を表します. つまり, この (b) は初期状態か
手段として用いることで, 検査式作成の難易度を押し
ら見て先にある状態で P が成り立つことを表します.
(c) について, 前件の P は下側に伸ばした線分の先
下げると考えました.
さて, その図による表現の記法として本研究におい
て提案した図示記法を次節において紹介します.
に置きます. そして, P → Q が成り立つ状態を表す
黒点は, (a) と同様にその実行列の任意の状態を表す
ように置かれています.
3 方法
(d) について, (c) における点線矢印の上側の部分に
本 研 究 で は, 特 に LTL(Linear-time Temporal
(b) をはめ込んだものになっています. つまり, 任意
Logic, 線形時相論理) モデル検査法を念頭に置き,
の状態において P が成り立っていたら, その状態より
LTL 論理式として与えられる検査式を図的に表現す
も先に Q が成り立つ状態があることを表しています.
るものとして図示記法を考案しました.
ところで, 図示記法は LTL 論理式のすべてを表現
3. ᣇᴺ
2 ⋡⊛
2.
࿑␜⸥ᴺ
LTLᑼ䉕࿑⊛䈮⴫⃻䈜䉎ᣇᴺ
࿑␜⸥ᴺ䈱଀
࿑␜⸥ᴺ䈱଀䋺
䊶․೎䈭⍮⼂䉕೨ឭ䈫䈚䈭䈇᭽⋧⴫⃻
․೎䈭⍮⼂䉕೨ឭ䈫 䈭 ᭽⋧⴫⃻
䊶⺕䉅䈏ฃ䈔౉䉏䉌䉏䉎⋥ᗵ⊛䈭⴫⃻
⺕䉅䈏ฃ䈔౉䉏䉌䉏䉎⋥ᗵ⊛䈭⴫⃻
䊶ⴕ䈭䈇䈢䈇ᬌᩏౝኈ䉕⴫⃻䈪䈐䉎⴫⃻ജ
((a)) 䂔䌐
((b)) 䂺Q
䌐
ⷞὐ
Q
(init)
ታⴕ೉
Q
P
(d) 䂔(Pĺ 䂺Q)
㪨
ᬌᩏ㗄⋡䈱࿑⊛䈭⴫⃻
P Q䈲ේᆎ๮㗴
P,
図2
(c) 䂔(䌐ĺ Q)
㪧
図3
目的
109
方法
第四回システム検証の科学技術シンポジウム
( 3 )
Vol. 0 No. 0
1983
3
できるわけではなく, その記法では表現できない LTL
論理式も存在します. しかし、現在までに得られてい
4 ᚑᨐ
4.
る図示記法ならば, 車載ソフトウェアに対するモデル
࿑␜⸥ᴺ䈱⃻႐೑↪ᣇᴺ䈱⏕┙
ᴺ
႐
ᴺ
- ᬌᩏᑼ䈱䊂䊋䉾䉫
- ࿑␜⸥ᴺ䈮䉋䉎࿑䉕⷗಴䈚䈫䈚䈢
䉴䊕䉾䉪䊌䉺䊷䊮㓸
検査における一般的な検査内容を表現するに足りる
表現力を持つと我々は考えています。
ਥ䈭⊒⴫䋺
ዊᳰᙗผ䇮ศ↰⡡䇮ᄢፒੱ჻,
ዊᳰᙗผ
ศ↰⡡ ᄢፒੱ჻
LTL䊝䊂䊦ᬌᩏ䈱ὑ䈱࿑␜⸥ᴺ,
╙14࿁䉸䊐䊃䉡䉢䉝Ꮏቇ䈱ၮ␆䊪䊷䉪䉲䊢䉾䊒
䋨FOSE2007) (full paper), ਅ㑐, 2007ᐕ11᦬.
4 成果
本研究では, 図示記法と呼ぶ LTL 論理式を図的に
表現する記法を与えました. さらに, 検査式作成の難
易度を下げるため, 図 4 において挙げた 2 つの図示記
法の利用方法を考案しました. すなわち, そのうちの
1 つは検査式のデバッグであり, 2 つめは図示記法に
よる図を見出しとしたスペックパターン集です. 検査
式のデバッグへの利用とは, 検査式作成の際に自身が
検査式の意味を確認したり, また, 検査式の意味を他
の人に伝えるために用いることです. そして, スペッ
クパターン集とは過去に使用した検査式を収集分類し
た用例集のことであり, これについての利用とは, そ
の作成の際, 検査式を検索するための見出しとして図
示記法による図を用いるというものです.
これら２つの利用法について, 検査式のデバッグで
は, 検査したい内容を予め図示記法による図で表現し,
図を確認しながら検査式を求めていくという形で, 組
織的に検査式を得ることができます. 特に, 図示記法
による図を見出しとしたスペックパターン集では, す
でに描いた図もしくは頭の中でイメージした図をも
とに, スペックパターン集の中から必要な検査式を直
図4
成果
ちに得ることができます.
なお, 本研究における図示記法を中心とする成果の
一部は研究会などにおいて発表されています [1], [2].
最後に, 今後の研究について, LTL 論理式と図示記
法による図の自動変換や, 与えられた LTL 論理式の
図示可能性の判定などの研究を行っていきます.
謝辞
本研究は, 矢崎総業株式会社と独立行政法人産業技
術総合研究所システム検証研究センターによる共同研
究「車載ソフトウェア開発プロセスへのモデル検査技
術の現場導入のための研究」（2005 年 4 月から 2008
年 3 月まで）に実施されました. 共同研究に携わった
各位に感謝致します.
参考文献
[ 1 ] 小池憲史, 吉田聡, 図示記法：現場技術者のための時相
表現, JAIST/TRUST - AIST/CVS joint workshop
on verification technology (3rd VERITE), 2006 年
11 月.
[ 2 ] 小池憲史, 吉田聡, 大崎人士, LTL モデル検査のた
めの図示記法, 第 14 回ソフトウェア工学の基礎ワーク
ショップ (FOSE2007), 2007 年 11 月発表予定.
110
第四回システム検証の科学技術シンポジウム
( 1 )
1
業務システム開発検証ツール
高木 理
Aist Workflow Verifier（以下 AWV）は産業技術
総合研究所（以下 AIST）のシステム検証研究セン
ター（以下 CVS）と情報技術研究部門（以下 ITRI）
との共同の研究班（以下，共同研究班†1 ）により開発
された，業務フロー図の検証ツールである．本論文で
は，AWV の開発にいたるまでの共同研究班の取り組
みと AWV について説明する．
1 AWV の開発にいたるまでの取り組み
AIST は 2006 年に所内の情報システムの再開発に
着手した．この再開発を手がける次期情報システム研
究開発推進室は，固有の開発ベンダーに依存しない，
図1
業務フロー図の例
利用者主導のシステム開発・運用を可能にし，自治体
などにも適用できる包括的なフレームワークの研究
AIST の情報システム再開発プロジェクトの中で，
開発を行ってきた．このフレームワークにおける要求
共同研究班は情報システムの要求定義，特に業務フ
定義の中心的役割を果たすものが “AIST-EAI2 業務
ロー図の検証のための研究調査を行ってきた．その取
フロー図”（以下，業務フロー図）である．
り組みの中で，現実の業務フロー図はシンタックスが
業務フロー図は業務を構成する一連の作業の流れ
完全に統一されておらず，そのために曖昧あるいは矛
を表すダイアグラムである．例えば，図 1 は「研究計
盾した記述が複数の箇所で発見された．そのため，業
画」という業務を表す業務フロー図である．このダイ
務フロー図のシンタックスの明確化と，そのシンタッ
アグラムの中の長方形（例えば「研究計画書の作成」）
クスを業務フロー図の設計者に統一的に使用させる
は各作業を表し，その横にある「計画書」は作業に用
ためのツールの必要性が明らかになった．
いられる書類（エビデンス）を表す．
（業務フロー図や
エビデンスについては [1] または [2] を参照されたい．
）
Osamu Takaki, 産業技術総合研究所, National Institute of Advanced Industrial Science and Technology
(AIST)
†1 共同研究班の実行メンバー：高橋孝一（CVS），和泉
憲明（ITRI），竹内泉（CVS），清野貴博（ITRI），
高木理（CVS）．
さらに，共同研究班は，業務フロー図が表している
業務の主な部分がエビデンスおよびデータベース上
のデータの加工であることに注目し，各エビデンスの
ライフサイクルの整合性，つまり，各エビデンスが作
成されてから保管または破棄されるまでのエビデン
スの状態の変化に矛盾が無いかどうかが，業務フロー
図に対する最も重要な検証項目の 1 つであると考え
111
第四回システム検証の科学技術シンポジウム
コンピュータソフトウェア
2
( 2 )
た．そこで，AIST の情報システム再開発プロジェク
トにおいて実際に作られた約 460 の業務フロー図を
調査したところ，次のような結果が得られた．
• 業務フロー図の中には，エビデンスに関して曖
昧あるいは整合的でない記述が多く見られ，その
中には手作業では見つけにくいものも存在する．
• エビデンスの記述に関する不備の原因は以下の
3 種類に分類できる．
1. エビデンスの記述に関する単純なミス
2. 業務フロー図の構造の複雑さ
3. 業務フロー図の構造自体の不整合
• 上記の 2 や 3 を原因とするエビデンスの記述の
図2
Aist Workflow Verifier の構成
不備を見直すことにより，業務フロー図全体の欠
陥を修正することが出来る．
そこで共同研究班は，業務フロー図のシンタックス
およびエビデンスのライフサイクルの整合性を自動的
に検証する機能を持つ AWV の研究開発に着手した．
2 Aist Workflow Verifier
ここで AWV について簡単に説明したい．
AWV の構成は図 2 の通りである．シンタックス
に関する検証の殆どを図 2 のデータ入力用インター
フェースモジュールが行い，エビデンスのライフサイ
図3
クルの整合性の検証は図 2 のエビデンス検査器が行
R
R
Microsoft‚
Visio‚
を用いた AWV
う．インターフェースモジュールを調整することによ
の後続ツールの研究開発が進められ，現在，いくつか
り，業務フロー図の作成ツールを取り替えることが出
R
R
来る．図 3 は Microsoft°
Visio°
を業務フロー図
の大規模情報システムの開発現場への導入が行われ
ている．
作成ツールとして用いたときの AWV による業務フ
ロー図の作成・検証作業の様子を表している．
エビデンス検査器は XML ファイルにより記述され
た業務フロー図を入力データに持ち，エビデンスのラ
イフサイクルに関する不具合のリストを出力データ
とするプログラムである．エビデンス検査器について
は [1], [2], [3] および [4] を参照されたい．
共同研究班は，情報システムの再開発プロジェクト
において作られた業務フロー図を用いて AWV の適
用実験を行い，実際の開発現場における AWV の有
用性を確かめることが出来た（適用実験の詳細につい
ては [1] あるいは [2] を参照されたい）．さらに，共同
研究班のメンバーである和泉と清野を中心に，AWV
参考文献
[ 1 ] Osamu Takaki, Takahiro Seino, Izumi Takeuti,
Noriaki Izumi, and Koichi Takahashi, “Verification Algorithm of Evidence Life Cycles in Extended
UML Activity Diagrams”, The 2nd International
Conference on Software Engineering Advances (ICSEA 2007). IEEE Computer Society Press, ISBN13: 978-0-7695-2937-0, ISBN-10: 0-7695-2937-2.
[ 2 ] 高木理，清野貴博，竹内泉，和泉憲明，高橋孝一，
“ UML アクティビティ図に対する事象部分グラフ抽出
および事象独立性検証アルゴリズム ”，ソフトウェアエ
ンジニアリング最前線 2007，近代科学社. pp.153-164．
2007．
[ 3 ] 高木理，清野貴博，竹内泉，和泉憲明，高橋孝一，
“ 検証システム ”，特願 2007-170616．
[ 4 ] 高木理，清野貴博，竹内泉，和泉憲明，高橋孝一，
“ 検証システム ”，特願 2007-218850．
112
第四回システム検証の科学技術シンポジウム 講演論文集（算譜科学研究速報）
発行日
2008年1月28日
発 行 独立行政法人産業技術総合研究所関西センター
編 集 独立行政法人産業技術総合研究所システム検証研究センター
〒560-0083 大阪府豊中市新千里西町1-2-14 三井住友海上千里ビル５F
電話 06-4863-5022 FAX 06-4863-5052
期日 2007年11月5日−7日 会場 名古屋大学 野依記念学術交流館
本掲載記事の無断転載を禁じます。
AIST01-J00022-75
独立行政法人
産業技術総合研究所
システム検証研究センター
AIST01-J00022-75
Research Center for
Verification and Semantics