論文 / 著書情報
Article / Book Information
題目(和文)

ペトリネットと時相論理を用いたリアクティブ並行システムの開発環
境の研究

Title(English)

A programming environment for reactive and concurrent systems using
petri nets and temporal logic

著者(和文)

内平直志

Author(English)

Naoshi Uchihira

出典(和文)

学位:博士(工学),学位授与機関:東京工業大学,
報告番号:乙第3125号,
授与年月日:1997年12月31日,
学位の種別:論文博士,
審査員:佐伯 元司Citation(English)

Degree:Doctor (Engineering),
Conferring organization: Tokyo Institute of Technology,
Report number:乙第3125号,
Conferred date:1997/12/31,
Degree Type:Thesis doctor,
Examiner:

学位種別(和文)

博士論文

Type(English)

Doctoral Thesis

Powered by T2R2 (Tokyo Institute Research Repository)A Programming Environmentfor Reactive and Concurrent Systems
Using Petri Nets and Temporal Logic
ZHjMCHH~j@}rQ$?
j"/F#VBT79F`N+/D-N&f
Naoshi Uchihirab? >VGraduate School of Information Science and Engineering
Tokyo Institute of Technologyl~)HgX ps})X&fJ W;)Xl6
A thesis submitted to Tokyo Institute of Technology
in partial ful llment of the requirement forthe degree of Doctor of Engineering

December, 1997

N. Uchihira: A Programming Environment for Reactive and Concurrent Systems

ABSTRACT

1

There has been a rapid trend towards parallel, distributed, and interactive/reactive computing overthe past decade. Generally speaking, it is not so easy for ordinary programmers to produce correctand ecient programs for these systems as compared with sequential programming. Therefore, somekind of computer-aided concurrent programming environment is necessary to achieve high productivity
and high reliability. The purpose of this thesis is to present theories, methods and tools (programming
environments) for reactive and concurrent systems using Petri nets and temporal logic.
Both Petri nets and temporal logic have been investigated as formal speci cation languages for reactive
and concurrent systems. While temporal logic is appropriate for specifying the properties and constraintsof programs but inappropriate for specifying the behavioral structures of programs, Petri nets can specify
the behavioral structures but not the properties and constraints. In this thesis, the fusion of Petri nets andtemporal logic is proposed as a speci cation language for reactive and concurrent systems. Then, practicaland ecient veri cation and synthesis methods using Petri nets and temporal logic and Petri-net-based
design methodology are described. Finally, a programming environment embedding these methods is
introduced. This thesis attempts in illustrating a typical programming paradigm and its environment
using Petri nets and temporal logic.
The main outcomes of this thesis are as follows.
(1) Speci cation by fusion of Petri nets and temporal logic
The fusion of Petri nets and temporal logic is proposed as a speci cation language, and its
applications to veri cation and synthesis are considered. The remarkable point is that the proposed methods are for unbounded Petri nets, while former veri cation and synthesis methods
were mainly for bounded (i.e., nite) ones.
(2) Compositional veri cation
An ecient and practical veri cation method using transition systems (bounded Petri nets)
and temporal logic is proposed. Generally, the computation costs for veri cation increase exponentially as the scale of the programs increases. To overcome this problem, a reduction techniqueof the target program has been investigated using bisimulation equivalence. However, bisimulation equivalence cannot deal with \divergence" explicitly. Therefore, a new process equivalence
relation (!-bisimulation equivalence) is proposed. A Process Query Language (PQL) which isan extended temporal logic and semantics of which is based on !-bisimulation equivalence isde ned. Then, a compositional veri cation method using PQL is proposed.
(3) Compositional program adjustment
A new synthesis method using transition systems (bounded Petri nets) and temporal logic is
proposed. Since conventional program generation from a temporal logic speci cation is impractical, this thesis proposes a new approach, \program adjustment". In program adjustment, a target
program written by programmers which may be functionally correct but may be imperfect in its
timing is automatically adjusted (tuned up) to satisfy given temporal logic constraints.
(4) Petri-net-based software design methodology
A Petri-net-based software design method is proposed. In this method, a causality matrix is
introduced for an earlier design phase when the system structure is obscure and it is dicult towrite Petri nets directly. A designer can construct Petri nets systematically from an ambiguous
requirement using the causality matrices according to the design method.
(5) MENDELS ZONE
A programming environment, MENDELS ZONE, based on the above techniques has beendeveloped. MENDEL net which is a high-level Petri net for reactive and concurrent systems
is used as the programming language. The designer constructs a program (MENDEL net) andveri es it using temporal logic. If there are any bugs, the program can be adjusted. Finally, theconstructed program is executed on a parallel computer.

N. Uchihira: A Programming Environment for Reactive and Concurrent Systems

2

5W
W;!79F`NBs=$,6=$$s?i/F#V/j"/F#V=K<$$BTWm0i_s0N{WO^9^9g-/JjDD"k%7+7J,i$BTWm0i`N+/O$`!Wm0i`N+/Kf
YFJJKq7$%5iK$)f79F`JINj"/F#V79F`NBTWm0i`KOb$.j,Wa5lk3H,?$%3Nh&J=UH&'"Nb8:-*hSb.j-rN]9k?aKO$=U
H&'"+/NW;!YgOTDgG"k%\&fN\*O$ZHjMCHH~j@}rQ$?j"/F#
V&BT79F`N=UH&'"+/Yg;QrN)9k3HG"k%ZHjMCHH~j@}OHbKBT79F`NA0*JEM-R!H7F&f5lF-?%7+7$~j@}O)s-RKO,7F$k,=$-RKOT,G"j$UKZHjMCHO=$-RKO,7F$k,)s-RKOT,G"C?%=3G$\&fGO~j@}HZHjMCHN;gKhkj"/F#V&
BT79F`NEM-R!rNQ9k%5iK$ZHjMCHH~j@}rQ$?BQ*J!Z&g.j!
JINWG;Qr+/7$=lirH_~s@Wm0i`N+/D-Nnn*hS=UH&'"_W}!
@Ns(rTJ&%\&fKhj$ZHjMCHH~j@}rQ$?lDNqN*J=UH&'"+/Yg
NOrN)9k3H,G-?%\&fNgJqN*.LH7FO$J<N`\,"k%(1) ZHjMCHH~j@}N;gKhkEM-R!NsF$~j@}HZHjMCHN;g!r(7$ZHjMCH,~j@}r~?9+]+r!Z9k"k4j:`r(7?%>h$-&JZHjMCHKP9k~j@}Khk!Z!ONilF$?
,$=lr-&GJ$lLNZHjMCHN!ZKH%7?%(2) Q_EM0!Z!N&f+\79F` (-BZHjMCH) H~j@}rQ$?g,OWm0i`KP9kz(*J!Z!r(7?%>h$~j@}NbGk!:!GO!ZKW9k39HNz/*}g,dj"j$3
lrsr9k?aKM9J}!,sF5l$=N1DK!ZP]NLsj!,"k%7+7$>hN}0GO$V bt+\Khk5Bk<WWNh}KX7Fdj,"C?%\&fGO$=Ndj@
rX&9kHHbK$=lr'59k77$Mj@} PQL rsF7$PQL rQ$?Q_EM!Z!r(7?%(3) Wm0i`40!N&f+\79F` (-BZHjMCH) H~j@}KhkBTWm0i`N77$g.!r(7?%>hN~j@}+iNWm0i`g.!O$BQ,ONWm0i`K,Q9kKOEM-R=O*
hSW;LN@Gs=B*G"C?%=3G$Wm0i`4NN+0g.GOJ/$MV,n.7?T04JWm0i` (+\79F`) r~j@}0G-R5l?EMr~?9h&Kt,*K+0$57$\*NWm0i`r8.9kVWm0i`40!WrsF7?%(4) MCHX~=UH&'"_W!NsF
ZHjMCHO1Jk-RjJG"j$"$^$JEM+iZHjMCHr3P9k?aN,$Ii$s (_W!) ,,WG"k%\&fGO$"$^$JEMrZHjMCHKqN=9kjJ
H7FxLX8^HjC/9r3~7?j"/F#V&BT79F`N=UH&'"_W!rsF
7?%(5) Wm0i_s0D- MENDELS ZONE N+/
e-NWG;Qr}g7?Wm0is_s0D-rBsW;!eKnn7?%33G$Wm0i`Obe`ZHjMCHG"k MENDEL MCHG-R9k%_WTOMCHX~_W!Khj
Wm0i` (MENDEL MCH) rn.7$Wm0i`!ZGWm0i`r!Z7$b7dj@,"
klgOWm0i`40KhjWm0i`r~19k%5iK$8.5l?Wm0i`rB]KB
s^7seGBTG-k%

N. Uchihira: A Programming Environment for Reactive and Concurrent Systems

3

Acknowledgments
This thesis was supervised by Prof. Motoshi Saeki. I am grateful for his kind and helpful guidanceand continuous encouragement which lead me to accomplishing my thesis. Also, this thesis was advised
by Prof. Takuya Katayama, Prof. Naoki Yonezaki, Prof. Takehiro Tokuda, Prof. Tomohiro Yoneda, andProf. Takashi Imaizumi. I am very thankful for their advice.
The greater part of my research has been carried out as a part of MENDELS ZONE project at Toshiba
Corporation. My special thanks go to Dr. Shinichi Honiden who was a project leader. At the beginningof the project, he provided me chance to study temporal logic and Petri nets from a software engineering
viewpoint. Throughout the project, he has properly supported, guided, and encouraged my research
activities.
Hideji Kawata is my research partner who made considerable contribution on the implementation andimprovement of our tools, MENDELS ZONE and SAVE/SFC. I wish to express my gratitude for his
generous collaboration.
I also have many thanks to the all other members of the MENDELS ZONE project and SAVE/SFC
project, especially to Akihiko Ohsuga, Kazunori Matsumoto, Mikako Arami, Toshiaki Kasuya, Toru
Uraoka, Akiko Uraoka, and Toshibumi Seki. When PQL was applied to a practical machine control
program, the discussion with Satoshi Sumida was very helpful. I would like to thank him.
When joining Toshiba in 1982, I was a novice in software engineering. A lot of senior researchers of
our laboratory educate, train, and promote me through the wide range of software engineering activities.
These valuable experiences lie at the foundation of this thesis. I would like to thank them, especially
Kazuo Matsumura, Hideo Nakamura, Yutaka Ofude, and Shoichi Kojima.
I am also grateful to successive directors and senior managers of the Systems & Software Engineering
Laboratory, Seiichi Nishijima, Sadakazu Watanabe, Mutsuhiro Arinobu, Masahiko Arai, Takeshi Kohno,
Shinsuke Tamura, Junichiro Tsuda, and Kazuo Mikame. Without their continuous support and encouragement, I could not continue the research about temporal logic and Petri nets during a long term (morethan 10 years).
This research has been a ected by both Petri net and software engineering communities. Many people
gave me fruitful suggestions and critical comments in the related conferences. I would like to tender mythanks to them, especially Prof. Mikio Aoyama and Prof. Kunihiko Hiraishi. The MENDELS ZONE
project has been supported by ICOT. I am also indebted to members of ICOT.
Finally, I reserve a special gratitude to my wife, Mari, for mental and physical support. I dedicate
this thesis to Mari and our baby girl, Akari.

Contents
1 Introduction1
2

3

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Formal Speci cation for Reactive and Concurrent Systems . . . . . . . . . . . . . .
2.2 Veri cation for Reactive and Concurrent Systems . . . . . . . . . . . . . . . . . . .
2.3 Synthesis for Reactive and Concurrent Systems . . . . . . . . . . . . . . . . . . . .
2.4 Design Methodology for Reactive and Concurrent Systems . . . . . . . . . . . . . .
2.5 Programming Environments for Reactive and Concurrent Systems . . . . . . . . .
Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Preliminaries: Models and Logics for Reactive and Concurrent Systems
123

Models for Reactive and Concurrent Systems . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Transition System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Buchi Sequential Automata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Finite State Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Transition System with Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Models for Real-Time Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8 Comparison of Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logics for Reactive and Concurrent Systems . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Propositional Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Linear Time Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Branching Time Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Process Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Propositional Modal -calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Logics for Real-Time Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Comparison of Logics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Related Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Software Development Process for Reactive and Concurrent Systems
1

2
3
4

Reactive and Concurrent Systems (RCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 What is RCS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Characteristics of RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Software Architecture of RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Application Software and System Software . . . . . . . . . . . . . . . . .
1.3.2 Concurrent Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Synchronization Part and Functional Part . . . . . . . . . . . . . . . . . .
Software Development Process for RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Software Development Process for TFS . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Software Development Process for RCS . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Diculties in Developing RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programming Environment for RCS Using Petri Nets and Temporal Logic . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4

10

10
11
11
14
14
15
15
16

19

19
19
19
20
21
22
23
24
24
24
24
25
26
27
28
28
28
29

30

30
30
31
32
32
32
33
33
35
35
36
36
39

N. Uchihira: A Programming Environment for Reactive and Concurrent Systems

5

4 Speci cation, Veri cation, and Synthesis Using Petri Nets and Temporal Logic

40

1

2
3

4
5

Petri Nets and Temporal Logic as Speci cation Language . . . . . . . . . . . . . . . . . .
1.1 How to Fuse Petri Nets and Temporal Logic . . . . . . . . . . . . . . . . . . . . . .
1.2 Example of Speci cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Theoretical Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concurrent Program Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concurrent Program Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Composition of Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Petri Net Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Concurrent Program Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Temporal Logic Speci cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Controller Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Agent Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Compositional Veri cation Using Modal Logic
1

2
3
4

5
6
7

Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Overview of Main Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Organization of the Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Representation of Concurrent Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Equivalence of Transition Systems for Compositional Veri cation . . . . . . . . . .
2.2 Composition of Transition Systems . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 SPQL (Strong Process Query Logic) . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 PQL (Process Query Language) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compositional Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Veri cation Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Veri cation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Reduction Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 The Jobshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 The Manufacturing Machine Control Software . . . . . . . . . . . . . . .
Toward Practical Veri cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Translation Target Program to Transition Systems . . . . . . . . . . . . . . . . . .
5.2 Chemical Plant Control Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Veri cation Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Compositional Veri cation Methods . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Comparison with Partial Order Approach . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Compositional Program Adjustment
1

2
3
4

40
41
42
42
44
46
48
49
50
52
52
52
54
55

56

56
56
57
58
59
59
59
61
62
62
65
67
67
67
69
69
69
72
75
75
75
81
82
82
83
85

90

Motivation and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
1.2 Overview of Main Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
1.3 Organization of the Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Finite State Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.1 Equivalence of Finite State Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.2 Operators on Finite State Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Program Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.1 Temporal Logic Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.2 Basic Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.3 Compositional Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Example and Experimental Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

N. Uchihira: A Programming Environment for Reactive and Concurrent Systems

56
7

4.1 Example: The Machine Control Program . . . . . . . . . . . . . . . . . . . . . . . 100
4.2 Experimental Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Program Adjustment in Standard Programming Languages . . . . . . . . . . . . . . . . . 104
Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7 MENDEL Net: High-Level Petri Net for Reactive and Concurrent Systems
1
2

3

4
5
6

6
7

4
5
6
7

127

Petri-Net-Oriented Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Software Architecture of Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Causality Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Design Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Example: Lift Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.2 Observation of actual design process . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.3 Qualitative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

9 MENDELS ZONE: Petri-Net-Based Programming Environment
1
2
3

107

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Petri Nets as Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2.1 Programming Language for Reactive and Concurrent Systems . . . . . . . . . . . . 107
2.2 Extension of Petri Nets as Programming Language . . . . . . . . . . . . . . . . . . 108
2.3 Petri-Net-Based Programming Languages . . . . . . . . . . . . . . . . . . . . . . . 109
2.4 High-Level Petri Net as Programming Language . . . . . . . . . . . . . . . . . . . 110
MENDEL Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.1 Place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.2 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.3 I/O Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.4 Process-Oriented Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.4.2 Graphical Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.4.3 Textual Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.5 Process Scheduling Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.5.1 Base-Level MENDEL Net . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.5.2 Meta-Level MENDEL Net . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.6 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.7 Macro Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Simple Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Related Works: Petri Nets and Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8 Petri-Net-Oriented Design Methodology
1
2
3
4
5

6

141

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Requirements for Programming Environment . . . . . . . . . . . . . . . . . . . . . . . . . 141
MENDELS ZONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3.1 Graphical MENDEL Net Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.2 Causality Matrix Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.3 Software Reuse Support Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.4 Veri cation and Adjustment Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.5 Program Execution on Multi-PSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Software Development Process in MENDELS ZONE . . . . . . . . . . . . . . . . . . . . . 147
Example: Power Plant Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.1 Comparison with STATEMATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.2 Comparison with Other Petri Net Tools . . . . . . . . . . . . . . . . . . . . . . . . 153
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

N. Uchihira: A Programming Environment for Reactive and Concurrent Systems

10 Conclusion
1
2
3

7

155

Review of Developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

List of Practical Examples of Reactive and Concurrent Systems
The following middle-scale examples are relatively practical and used to show that the techniques proposedin this thesis can be applicable to actual systems.
1. Manufacturing machine control systemcompositional veri cation (Chapter 5)transition system + temporal logic (PQL)
2. Chemical plant control systemcompositional veri cation (Chapter 5)
Petri net (SFC) + temporal logic (PQL)
3. Lift control system
Petri-net-oriented design methodology (Chapter 8)
Petri net (MENDEL net) + temporal logic (PLTL)
4. Power plant control system
MENDELS ZONE (Chapter 9)
Petri net (MENDEL net) + temporal logic (PLTL)

Glossary
Notation

?








"
X
X!
X1
X
X1 nX2
T
A
Act
S



TS = (S; P; A; ; ; s0 )N = (P; T; w; m0 )m1 [> m2
()
LN = (N; )
P = (S; A; L; ; ; s0; F )L=A
L(LN )
L! (LN )L! (LN )Lfair
! (LN )TS1 j TS2s"
TS1 ! TS2
f
2f
}f
f
f1 U f2
TS j= fa f
 a + f[[a]] f[[a]]+ f

Meaningtransition function (transition system)
disabledtransition function (automaton)
unobservable internal action
action/transition sequence (run)label sequence (word)
deadlock
empty sequencea set of nite sequences over X
a set of in nite sequences over X
X1 = X [ X!
a complementary set of X
X1 nX2 = X1 \ X2
a set of transitions
a set of actions
Act = A [ f g
a set of statesalphabet
state attribute assignment function
transition system
Petri net
m1 is reachable from m2 by a transition sequence 
di erential vector
labeling function
Labeled Petri net
nite state process (FSP)
sequences of L where all elements except A are deleted
Petri net language
Petri net in nite language
Petri net in nite language with deadlock
Petri net fair in nite language with deadlock
process composition
divergence!-bisimulation equivalence
formulaf is always true.
f will be eventually true.
f will be true at the next time.
f1 continues to be true until f2 becomes true.
TS is a model of f
f will be sometime true after a is occurred (minimum xed point)
f will be sometime true after a is occurred (maximum xed point)
f will be always true after a is occurred (minimum xed point)
f will be always true after a is occurred (maximum xed point)8

N. Uchihira: A Programming Environment for Reactive and Concurrent Systems

apat fapet fepat fepet f

f is true at all time in all paths
f is true at some time in all paths
f is true at all time in some path
f is true at some time in some path9

Chapter 1

Introduction
1 Motivation
Computer systems have been moving rapidly toward parallel, distributed, and reactive computing during
the past decade. There is an increasing demand for programmers who can design concurrent programsfor these systems. However, generally speaking, compared with sequential programming it is not so easy
to produce correct and ecient concurrent programs. In particular, the cost of testing and debugging
becomes a heavy burden. Moreover, most reactive systems (e.g. embedded control systems, process control systems) require high reliability. Therefore, some kind of computer-aided concurrent programming
environments are necessary to enable ordinary programmers to develop concurrent programs while achieving high productivity and high reliability. The programming environment means tools for veri cation,
debugging, performance evaluation, and methods to synthesize correct and ecient programs.
To achieve both high productivity and high reliability, a formal method is the most promising approachin the long run. In the formal method, speci cations and programs (implementation) are described using
some formal language, the semantics of which is formally de ned. Then, the formal method provides
veri cation and synthesis methods for these speci cations and programs. Many formal methods havebeen proposed for concurrent systems. For example, they include models of programs (e.g., transition
system, Petri net, automaton), logics of programs (e.g., Hoare logic, temporal logic, dynamic logic,
process logic), and algebras of programs (e.g., CCS, CSP, ACP). Temporal logic is a especially usefulformal framework for speci cation, veri cation, and synthesis for concurrent programs. Therefore, theapplication of temporal logic to computer science has been actively investigated by many researchers allover the world from the late 1970's to the present.
This thesis concentrates on reactive and concurrent systems. The purpose of this thesis is to establish theories, methods and tools (programming environment) for these systems using temporal logic.
Especially, much consideration is given to practical techniques in order to apply temporal logic to actual
reactive and concurrent systems.
To apply temporal logic to the actual development of reactive and concurrent systems, the following
issues should be considered.
1. Actual systems cannot be fully described by temporal logic
Standard temporal logic is too inconvenient to describe actual reactive and concurrent systems.
Therefore, a syntactical extension of temporal logic for practical use or combination with othercomplementary formal languages is required.
2. Cost of veri cation and synthesis is beyond practical computing power
Generally speaking, computing cost of veri cation and synthesis based on formal methods becomesvery huge due to \state explosion problem". Consequently these methods are often applicable only
to \toy programs". Techniques to avoid state explosion and reduce computing cost are required.
3. Formal methods do not support the whole development process
The formal method is not an all-around player. It can support a few parts of the whole development
process. Remaining parts of the process are done by traditional and informal methods. There is an
obvious gap between formal methods and traditional and informal methods. Therefore, a design
10Chapter 1: Introduction

11

methodology (guidelines) is required to specify how to utilize formal methods and informal methods complementarily in the development of reactive and concurrent programs. Furthermore, theprogramming environment is required to mechanically support the design methodology throughout
the entire development process.
This thesis proposes the following solutions for above problems.
1. Fusion of Petri nets and temporal logic
Temporal logic is appropriate for specifying the properties and constraints of programs, but inappropriate for explicitly specifying the behavioral structures of programs. In other words, temporal
logic is declarative and not operational. On the other hand, Petri nets can specify the behavioral
structures operationally. In this thesis, a fusion of Petri nets and temporal logic is proposed as a
speci cation language for reactive and concurrent systems.
2. Compositional veri cation and adjustment
A temporal logic model-checking method is actually useful to verify reactive and concurrent systems.
However, as the scale of the programs increases, the computation costs for veri cation increase
exponentially. To reduce the computation costs, this thesis introduces a compositional approach
into model-checking, and proposes a new modal logic, PQL, and a compositional veri cation method
based on PQL.
Since it seems that the conventional program generation approach from temporal logic speci cation
is impractical, a new approach \program adjustment" is proposed, in which a target program madeby programmers is automatically adjusted (tuned up) to satisfy given temporal logic constraints.
Since this also causes the state explosion problem, compositional program adjustment is proposedin this thesis.
3. Petri-net-based design methodology and its programming environment
As a software design methodology for reactive and concurrent systems, several methods have been
proposed which include OOAD and RTSAD. However, few are based on Petri nets. Since Petri nets
are used as a speci cation language in our approach, a Petri-net-based design method is proposed
which gives guidelines for deriving detailed Petri nets from ambiguous requirements, and thenverifying and adjusting programs using Petri nets and temporal logic.
MENDELS ZONE is a programming environment for reactive and concurrent systems, which supports the software development process from rst to last, including veri cation, adjustment, andPetri-net-based design method.

2 BackgroundTo providing the background for this thesis, this section presents a brief survey of software development
techniques for reactive and concurrent systems. Especially, focusing on formal techniques including
speci cation, veri cation, synthesis, and design methodology (Fig. 1).

2.1 Formal Speci cation for Reactive and Concurrent Systems

Specifying systems formally is an e ective way to recognize and clarify ambiguous parts of the system
requirement/speci cation, and is necessary to verify the speci cation and synthesize programs from thespeci cations. A lot of speci cation languages for reactive and concurrent systems have been proposed.
Roughly speaking, they can be classi ed into operational approaches and declarative approaches.

 Operational Approach

In an operational approach, reactive and concurrent systems are modeled with speci cation models/languages which are executable on the abstract machine. The operational (i.e., executable)
speci cation models for reactive and concurrent systems include transition systems, state machines,
automata, Statechart and Petri nets. These models will be described in detail in Chapter 2. However, these models are too primitive to describe practical systems. Therefore, several practical speci cation languages which are based on some primitive model and extended from a practical point ofChapter 1: Introduction

12

Design
Methodology
RTSAD, OOADDARTS, NOD

Specification
Synthesis

Temporal Logic
Dynamic Logic
Process Logic-CalculusÌ

Tableaux Construction

Figure 1.

CCS
CSP
ACP

Transition System
Petri Net

Verification

Logical Reasoning
Model-checking

Software Development Techniques for Reactive and Concurrent Systems

view. These speci cation languages include PAIZLey [Zave 82, Zave 91], SDL, and Coloured PetriNet [Jensen 92, Jensen 95].

 Declarative Approach

In a declarative approach, systems are modeled by logical formulas or algebraic terms, and thenaxioms of the logics or algebras give the semantics of the systems. For concurrent systems, a lot of
declarative formalisms have been proposed, which include modal/program logic (Dynamic Logic,
Temporal Logic, Process Logic, Modal -calculus, UNITY logic, etc.) and process algebra (CCS,
CSP, ACP, -calculus, etc.).

In this thesis, we focus on Temporal Logic. Temporal logic is a kind of modal logic in which modal
operators represent the topology of time. While the truth-values of propositions are constant in classicallogic, the truth-values of propositions can be changed with time in temporal logic. For example, astatement \if a proposition p is true now, p will have to be false at the next time" can be represented
by a temporal logic formula,p  :p;where is a temporal operator representing the next time. This cannot be done directly by the classicallogic.
From a historical point of view (see [Rescher 71]), temporal logic was initially investigated by philosophers and logicians since Prior constructed the rst tense logic in the 1950s. Then, since the 1970s,
temporal logic has been applied to computer science, especially, arti cial intelligence1 and software
engineering2 . Temporal logic is an especially useful formal framework for speci cation, veri cation, andsynthesis for reactive and concurrent systems. The application of temporal logic to these systems has
been actively investigated by many researchers all over the world from the late 1970's to the present. The
historical background of temporal logic was well surveyed by Galton [Galton 81].
1 For example, McDermott's Temporal Logic, and Allen's Theory of Time.
2 Pnueli initially systematized temporal logic [Pnueli 77] in software engineering.

Chapter 1: Introduction

13

In this thesis, we adopt temporal logic as a formal speci cation language for reactive and concurrent
systems for the following reasons.
 The modality of temporal logic is intuitive and easy for software designers to understand.
 A temporal logic formula can be translated into an equivalent !-automaton which is compatible
with a state transition system and can be easily manipulated in veri cation and synthesis.
 Most reactive and concurrent systems can be basically modeled by state transition systems.
Temporal logic has been applied to speci cation, veri cation, and synthesis for reactive and concurrent
systems. First, the research background on speci cation by temporal logic is brie y surveyed.
There are several variants of temporal logic. The variant initially presented by Pnueli is linear
time temporal logic , which has been investigated chie y by Pnueli, Manna, and their group [Pnueli 77,
Pnueli 81, Manna 81a, Manna 81b, Pnueli 86, Manna 92] for speci cation and veri cation of concurrent
programs. A second common version of temporal logic is branching time temporal logic [Ben-Ari 83,
Emerson 85a]. Each logic assumes a di erent underlying nature of time, as follows [Emerson 90a].
 Linear time temporal logic: The course of time is linear; at each moment there is only one
possible future moment.
 Branching time temporal logic: Time has a branching, tree-like nature; at each moment, time
may split into alternate courses representing di erent possible futures.
Linear time temporal logic is suitable for speci cation for program synthesis, while branching time temporal logic is suited to describe queries for veri cation. Besides these two popular version, there are several
versions of temporal logic for concurrent programs (e.g., Partial Order Temporal Logic [Pinter 84], Interval Temporal Logic (ITL) [Moszkowski 86]).
These logics are sucient to consider the essential features of reactive and concurrent systems, but not
expressive enough to describe an entire system speci cation. There are two approaches to make temporal
logic suitable for practical speci cations; extension of temporal logic and combination of temporal logic
with other formalisms (called dual-language approach in [Felder 94]).
With regard to the rst approach, temporal logic can be extended by introducing the following features
for practical speci cations.
 regular expression [Wolper 83b]
 more than operator [Yoshimura 93]
 unbounded message bu ers [Sistla 84, Koymans 87]
 modularity, compositionality and abstractness [Barringer 84, Josko 87, Yonezaki 91]
 nonmonotonicity for avoiding frame problem [Saeki 87]
 real-time [Alur 89, Ostro 90]
Furthermore, several executable speci cation languages based on temporal logic have been proposed,in uenced by logic programming (e.g. Tempula [Moszkowski 86]), in which operational semantics canbe given to extended temporal logic formulas. These executable speci cation languages are useful for
prototyping of reactive and concurrent systems [Hale 87]. However, in spite of these extensions, it is stilldicult to describe an entire practical system by temporal logic. Moreover, these extensions often makeautomatic veri cation and synthesis dicult, and increase computing costs.
With regard to the second approach, temporal logic is combined with another formalism as a specication language. Since temporal logic is declarative, a combination of temporal logic and other formal
language having operational semantics, like transition system and Petri net is e ective. A combination of
temporal logic and Petri net has been investigated recently by our group and others. These works will besurveyed in Chapter 4. The second approach appears promising and realistic for practical speci cation.

Chapter 1: Introduction

14

2.2 Veri cation for Reactive and Concurrent Systems

The background on the research on veri cation by temporal logic is brie y surveyed. There are two
approaches in veri cation for reactive and concurrent systems; logical reasoning and model-checking.

 Logical Reasoning Approach:

Both speci cation and implementation (program) are speci ed by temporal logic formulas. If thespeci cation is represented by a formula fs and the implementation is represented by a formula fi ,then the implementation is correct i fi  fs is valid. Manna and Pnueli [Manna 81b, Pnueli 81]
presented methods for proving fi  fs inductively using axioms and inference rules. Furthermore,
Manna and Wolper [Manna 84] presented an automatic veri cation method based on refutation,
where it is shown that :(fi  fs ) is not satis able using tableaux construction.

 Model Checking Approach:In a model-checking approach, the speci cation is represented by a temporal logic formula f , andthe implementation is represented as a model M of temporal logic. The implementation is correcti M is a model of f (i.e., M j= f ). Transition systems are usually used to represent models(i.e, implementations). Clarke, Emerson, and Sistla [Clarke 86] initially proposed an automaticveri cation method of nite-state concurrent systems based on model-checking. They dealt with abranching time temporal logic called CTL (Computation Tree Logic).

Since the model-checking approach can provide a practical and widely applicable veri cation method
as compared with the logical reasoning approach, much work based on model-checking has been done
over the last decades. The early researches in this area are well surveyed in [Clarke 87]. The latest trends
can be caught by watching the Annual Conference on Computer-Aided Veri cation (CAV). These works
can be classi ed into two types;
 Extension of expressive ability of temporal logics and models (e.g., Fairness [Emerson 85b])
 Local model-checking for Petri nets [Brad eld 92]
 Proposal of ecient model-checking algorithms
Since model-checking can be regarded as a type of state space analysis method, the state explosion
problem is usually the limiting factor in applying these algorithms to realistic systems. Therefore, an ecient model-checking algorithm is required. These ecient algorithms can be classi ed into the following
three approaches.
 Symbolic Model Checking [Burch 90, McMillan 93]
 Partial Order Approach [Valmari 90, Godefroid 91a, Godefroid 96]
 Compositional Approach [Clarke 89]
This thesis will focus on the compositional approach, and propose a new compositional veri cation
method.

2.3 Synthesis for Reactive and Concurrent Systems

The rst attempts to synthesize reactive and concurrent systems from temporal logic speci cations weredeveloped in [Manna 84] and [Emerson 82]. Propositional versions of linear time temporal logic andbranching time temporal logic are used as the speci cation language in [Manna 84] and [Emerson 82],
respectively. Both synthesis methods are based on tableaux construction representing models of the given
temporal logic formula. The target nite-state program is generated from this tableaux.
These pioneering synthesis method can be applied to the synthesis of closed reactive systems. The
closed reactive system means a system in which all actions are observable and controllable. In contrast,
open reactive systems has unobservable and uncontrollable actions. For example, a plant control system
consists of a controller and controlled objects in which some actions and states are unobservable anduncontrollable from the controller. Pnueli and Rosner proposed a synthesis method for these open
reactive systems [Pnueli 89a, Pnueli 89b, Pnueli 90].

Chapter 1: Introduction

15

These works made worthy contributions from the theoretical view point. However, from the practicalpoint of view, they were suggestive but hard to apply to actual systems. The main reason is that it is
too dicult and too expensive to describe a whole speci cation by temporal logic and then synthesize awhole program from it. Therefore, a more practical approach is proposed, \program adjustment", whichmodi es (adjusts) a given target program to satisfy a temporal logic speci cation instead of generating
a whole program from it.

2.4 Design Methodology for Reactive and Concurrent Systems

Software design methodology plays important part so that formal methods are utilized during the softwaredevelopment process. As a software design methodology for reactive and concurrent systems, several
methods have been proposed; Real-Time Structured Analysis and Design (RTSAD), Object-Oriented
Analysis and Design (OOAD), and Design Approach for Real-Time Systems (DARTS).

 Real-Time Structured Analysis and Design (RTSAD)

Real-Time Structured Analysis and Design (RTSAD) is an extension of Structured Analysis andDesign for real-time systems. There are two popular variations which have been developed by
Ward [Ward 85, Ward 86] and Hatley [Hatley 87], respectively. In RTSAD, functional requirements
for the target system are hierarchically decomposed into several functions, which are describedby data/control ow diagrams. In addition to the data/control ow diagrams, behavioral
requirements are represented by state transition diagrams. Since the data ow diagram isfamiliar to designers and easy to understand, RTSAD has been used on a wide variety of projects
and there is much experience in applying RTSAD. However, RTSAD is weak in its provision of task
structuring guidelines which address how to structure the system into concurrent tasks.

 DARTSIn the reactive and concurrent system design, task structuring is given considerable weight. DARTS(Design Approach for Real-Time Systems), which was proposed by Gomaa [Gomaa 93], is a design
method based on RTSAD and emphasizes the decomposition of a real-time system into concurrent
tasks. DARTS provides a set of task structuring criteria for structuring a real-time system into
concurrent tasks, as well as guidelines for for de ning the interfaces between tasks.

 Object-Oriented Analysis and Design (OOAD)

Object-Oriented Analysis and Design (OOAD) [Booch 94, Rumbaugh 91] is a design method basedon object-oriented paradigm. In OOAD, classes and objects are rst identi ed by analyzing the
problem domain, then object diagrams and class diagrams are developed to describe the relationships between classes and objects. After de ning the object structure, behavior for each object
is described by the state transition diagram. Finally, objects are classi ed into tasks (active
objects) and packages (passive objects) of the concurrent programming language.

Generally speaking, each design method consists of several charts which represent functional, behavioral, and module structures of systems and guidelines (criteria) for deriving these charts. Data/control
ow diagrams, state transition diagrams, and class/object diagrams are used as the design charts in theabove methods.
Although a Petri net can be a promising design chart for reactive and concurrent systems, there arefew design methods which use Petri nets as the design chart and give guidelines for manipulating them.
Reisig [Reisig 92] proposed a design method based on Petri nets. It is very suggestive but not suciently
mature. This thesis considers a Petri-net-oriented design method, which is called Net-Oriented Design
method (NOD) [Honiden 92].

2.5 Programming Environments for Reactive and Concurrent Systems

A lot of tools have been proposed which support formal methods for reactive and concurrent systems.
Recently, these tools have become sophisticated and are of practical use3 . The more well-known tools
include the following.
3 Some of them can be easily obtained by INTERNET.

Chapter 1: Introduction

16

 Tools based on state transition systems (state machine, automata):

STATEMATE4 [Harel 90] and SPIN [Holzmann 91],
 Tools based on process algebra5 :Concurrency Workbench (CWB) [Cleaveland 93] and AUTO/AUTOGRAPH [Boudol 89],
 Tools based on Petri nets:
DESIGN/CPN [Jensen 92] and Cabernet [Ghezzi 93].
However, none of them is a comprehensive programming environment covering the overall development
process which includes veri cation, synthesis, and a design methodology based on Petri nets and temporal
logic.

3 Synopsis
The organization of this thesis is as follows (Fig. 2).
Chapter 2 starts by providing de nitions, models, and logics for reactive and concurrent systems asa preliminary section.
Chapter 3 considers a software development process for reactive and concurrent systems. In thischapter, a de nition and the characteristics of reactive and concurrent systems and a development process
for them are discussed. Finally, a software development process using Petri nets and temporal logic
is conceptually proposed. According to this conceptual development process, detailed techniques aredescribed in the following chapters.
In Chapter 4, a fusion of Petri nets and temporal logic is proposed as a speci cation language forreactive and concurrent systems. Its expressive power and theoretical results are also considered. In
succession, veri cation and synthesis methods are shown as an application of speci cation by Petri nets
and temporal logic. Examples are provided to show the e ectiveness of the veri cation and synthesis.
The remarkable point is that proposed methods are for unbounded Petri nets, while former veri cationand synthesis methods were mainly for bounded (safe) Petri nets.
Chapter 5 considers an ecient and practical veri cation method, temporal logic model-checking, fornite-state (i.e. bounded) systems. The model-checking method is actually useful to verify reactive andconcurrent systems. However, as the scale of the programs increases, the computation costs for veri cation
increase exponentially due to the state explosion. To ease the state explosion, a compositional approach tomodel-checking seems promising and is adopted here. The point of compositional veri cation is to reduce(localize, minimize) the target program, leaving only essential information for each veri cation query. The
reduction of the target program is formalized by process equivalence theory. This chapter introduces a
new process equivalence relation (!-bisimulation equivalence) for compositional veri cation. This new
relation is required because conventional bisimulation equivalence, which was used in other compositionalveri cation, cannot deal with \divergence" explicitly. An explanation of why conventional bisimulationequivalence does not work well with divergence is given, and then !-bisimulation is de ned. After
this, Process Query Language (PQL) is proposed. PQL is a modal logic which is union of temporal
logic and process logic, and the semantics of which is based on !-bisimulation equivalence. Then, thischapter proposes the compositional veri cation method using PQL with consideration of the divergence.
Its e ectiveness is demonstrated by means of some experimental results.
In Chapter 6, program synthesis using temporal logic is discussed. From the standpoint that theconventional program generation approach from temporal logic speci cation, which was initially proposedby Manna and Wolper [Manna 84], is impractical, this chapter proposes a new approach, \programadjustment". In program adjustment, a target program made by programmers, which may be functionallycorrect but may be imperfect in its timing, is automatically adjusted (tuned up) to satisfy given temporal
logic constraints. To put it concretely, program adjustment is realized by adding an arbiter process which
is synchronized with and restricts the behavior of the target program. It is more feasible for ordinary
programmers to adopt the program adjustment approach compared to conventional program generation
approach for the following reasons.
4 STATEMATE is a trademark of i-Logix
5 These tools are also applicable for state transition systems which are equivalent to the process algebra.

Chapter 1: Introduction17 It is not very dicult for ordinary programmers to produce a target program, which satis es atleast the functional requirements. A more dicult task is to design and debug the timing of suchprograms.
 It is easy for ordinary programmers to specify timing constraints, such as deadlock-free and starvationfree constraints, as compared with implementing them.
 Computation cost of program adjustment is generally smaller than program generation.
Furthermore, when a target program becomes large, the arbiter synthesis may cause a computing cost
explosion. Therefore, we propose compositional adjustment.
Chapter 7 considers Petri nets as a programming language instead of a speci cation language. First,
it is discussed what properties are required for a programming language for reactive and concurrent systems, and what extensions are required to use Petri nets as a programming language. Then, a MENDEL
net is introduced, which is a high-level Petri net for reactive and concurrent systems. A MENDEL net
can be used not only for speci cation but also for programming (detail prototyping) owing to several extensions, an I/O interface with the environment, concurrent tasks, and a mechanism for their scheduling.
Chapter 8 proposes a software design methodology based on MENDEL nets and temporal logic,
which is called Net-Oriented Design method (NOD). In this method, a causality matrix is introduced at
an earlier design phase when the system structure is obscure and it is dicult to write MENDEL nets
directly. According to the design method utilizing causality matrices, a designer can construct MENDEL
nets systematically from an ambiguous requirement, then verify and adjust the MENDEL nets by methods
based on temporal logic mentioned in earlier chapters.
Chapter 9 shows an overview of a programming environment for reactive and concurrent systems,
called MENDELS ZONE. MENDELS ZONE provides analysis tools based on formal methods (e.g.,veri cation and adjustment tools) and a design support tool based on the informal design method (e.g.,causality matrix editor) in addition to the usual programming tools such as graphical MENDEL net editor,
simulator, and compiler. MENDELS ZONE has been implemented on the parallel machine, Multi-PSI.
Finally, Chapter 10 concludes this thesis, summarizing the research contributions, and presenting
intentions for further work.
Related our publications are summarized as follows.

Chapter 4: [Uchihira 90b]
Chapter 5: [Uchihira 92a]
Chapter 6: [Uchihira 92c, Uchihira 95a]
Chapter 7: [Uchihira 96b]
Chapter 8: [Uchihira 92b]
Chapter 9: [Uchihira 87, Uchihira 88, Uchihira 90a, Uchihira 92b, Uchihira 95a]

Chapter 1: Introduction

18

Chap. 2Preliminaries

Chap. 3Development Process

Chap. 4
Specification, Verification, and Synthesis(Petri Nets and Temporal Logic)

Chap. 5Compositional
Verification(Transition Systems
and PQL)

Chap. 6Compositional
Adjustment(Transition Systems
and Temporal Logic)

Chap. 7
Programming Language(MENDEL Net)

Chap. 8Design Methodology(Net-Orineted Design Method)

Chap. 9Programming Environment(MENDELS ZONE)

Figure 2.

Organization of The Thesis

Chapter 2

Preliminaries: Models and Logics for
Reactive and Concurrent Systems
This chapter introduces several notations and de nitions of models and logics for reactive and concurrent
systems.

1 Models for Reactive and Concurrent Systems
Many models have been proposed for reactive and concurrent systems. Most of them are based on statetransition systems which may be extended about concurrency and liveness. Among them, this section
shows Transition System, Buchi Sequential Automaton, Finite State Process, and Petri Net.

1.1 Sequence

To begin with, we introduce several notations about sequences. In the context of this thesis, a sequenceis used to represent the time series of actions which a reactive and concurrent system takes, and states
which it stays in.
Let X be a set. The set of all nite sequences over X , including the empty sequence ", is denoted
by X . If there is no empty sequence ", the set is denoted by X +. The set of all in nite sequences
over X is denoted by X ! ; ! means \in nitely many". X 1 is de ned by X 1 = X  [ X ! . X means acomplementary set of X . X1 nX2 = X1 \ X2
For a sequence  2 X 1, [i] means the i-th element in ; (k) means the pre x subsequence[1][2]:::[k] of , and j  j the length of .
For A  X and L  X 1, L=A is de ned as L=A def= f0 j 9 2 L:8i:(0 [i] = [i] if [i] 20A; otherwise  [i] = ")g. \/" is a label restriction operator. Intuitively, L=A consists of sequences of
L in which all elements except A are deleted.

1.2 Transition System

De nition 1 (Transition System)
TS = (S; P; A; ; ; s0 )S : A set of states
P : A set of state attributes
A : A set of actions
Act = A [ f g
 : an unobservable internal transition : S ! 2P A boolean function
 : S  Act ! 2S A nondeterministic transition function
s0 : An initial state
For TS = (S; P; A; ; ; s0 ) and s; s0 2 S and a 2 A, p 2 (s) means that a state attribute p is true ins, and s0 2 (s; a) means that the system which stays in s can move to the state s0 after an action a.
19

Chapter 2: Preliminaries

20

a s0 $s(!
 ) !
a (!
 ) s0 is
According to Milner's notation [Milner 89], (s; a) 3 s0 is expressed as s !
a0expressed as s ) s . Also, a^ expresses a when a 6=  , and a^ expresses " when a =  . Here, " means an^ s0 = s )" s0 = s(!
 ) s0 %We show a simple example of a transition system in
empty string, that is, s )Figure 3.

Example 1 (Transition System) T = (fs0 ; s1 ; s2 ; s3 g; fp1; p2 g; fa; bg; ; ; s0) wheres0 !a s1 ; s0 !b s2 ; s1 !b s3 ; s2 !a s3 ; s3 ! s0 ; and (s0 ) = fp1 ; p2 g; (s1 ) = fp1g; (s2 ) = fp2g; (s3 ) = ;.
s0
a

s1

p1

p1,p2

b

Ó

p2

b

s2

a
s3

Figure 3.

Example of a transition system

De nition 2 (Finite Branching Condition)

A nite branching condition in TS = (S; P; A; ; ; s0 ) is:(s; a) is a nite set for 8s 2 S and 8a 2 A.
This nite branching condition is necessary for the fully automatic veri cation and synthesis fortransition systems. When S , P , and A are nite, the nite branching condition is satis ed. We assume
S , P , and A in TS are nite whenever we do not mention it explicitly.

1.3 Buchi Sequential Automata

A transition system can model all possible (safe) behaviors of systems, but cannot model desirable
behaviors. A nite automaton can express desirable (acceptable) behaviors explicitly using terminal
states.

De nition 3 (Finite Automaton) A nite automaton is a tuple A = (; S; ; s0 ; F ), where  is an alphabet, S is a set of states,  : S   ! 2s is a nondeterministic transition function,
 s0 2 S is an initial state, and F  S is a set of terminal states.

A run of a nite automaton A over a nite word  = t1 t2 :::tn 2  is a state sequence s0 ; s1 ; :::; sn ,where si 2 (si 1 ; ti ) for all i  1. A run s0 ; s1 ; :::; sn is accepting if sn 2 F . A nite word  is acceptedby A if there is an accepting run of A over . The set of all words, accepted by A, is denoted L(A).
A nite automaton treats only nite sequences (words). Since reactive and concurrent systems often
takes in nite ongoing computation, a nite automaton on in nite sequences is necessary to model them.

De nition 4 (Buchi Sequential Automaton ) Buchi sequential automaton is a tuple A = (; S; ; s0 ; F ),where

Chapter 2: Preliminaries21  is an alphabet, S is a set of states,  : S   ! 2s is a nondeterministic transition function,
 s0 2 S is an initial state, and F  S is a set of designated states.

A run of a Buchi sequential automaton A over an in nite word  = t1 t2 ::: 2 ! is a sequence s0 ; s1 ; :::,
where si 2 (si 1 ti ) for all i  1. A run s0 ; s1 ; ::: is accepting if for some s 2 F there are in nitely many
i's such that si = s. An in nite word  is accepted by A if there is an accepting run of A over . The setof all words, accepted by A, is denoted L(A).

1.4 Finite State Process

A nite state process [Kanellakis 90] is de ned as a general model which includes both a transition
system and an automaton. Therefore a nite state process can specify a transition system with livenessconditions as its acceptance condition.

De nition 5 (Finite State Process) A Finite State Process (FSP) is a seventuple P = (S; A; L; ; ; s0; F ),where:

 S is a nite set of states,
 A is a nite set of actions, L is a nite set of synchronization labels,  : S  A ! S [ f?g is a deterministic transition function ((s; t) = ? means the action t 2 A is
disabled in the state s 2 S ),  : A ! (L [ f g) is a labeling function, ( is an invisible internal action),
 s0 2 S is an initial state, and F  S is a set of designated states.
Example 2 (Finite State Process) P = (fs0 ; s1 ; s2 ; s3 g; ft1; t2 ; t3 g; fa; bg; ; ; s0; fs3g) is a nite stateprocess where (s0 ; t1 ) = s1 ; (s0 ; t2 ) = s2 ; (s1 ; t2 ) = s3 ; (s2 ; t1 ) = s3 ; (s3 ; t3 ) = s0 ; (t1 ) = a; (t2 ) =b; (t3 ) = : (Fig.4)

initial state
t1/a

s0

t2/b

Ó

s1

t3/
t2/b

s3

s2

t1/a

Figure 4.

action/label
designated state

Finite State Process

Let P = (S; A; L; ; ; s0; F ) be an FSP. A transition function can be extended such that  : S  A !
S [ f?g, i.e., (s; a) def= ((s; ); a). Note, (s; ") = s. Since a transition function is deterministic,a current state can be uniquely determined from an initial state and an action sequence. We call anChapter 2: Preliminaries

22

action sequence a behavior. Similarly, we can extend a labeling function such that  : A ! (L [ f g) ,i.e., () = ([1])([2]):::([j  j]). In addition, ^() is de ned as the sequence gained by deleting all
occurrences of  from (). The set of reachable states from a state s in P is de ned as RP (s) def= fs0 2
S j 9 2 A :s0 = (s; )g and RP+(s) def= fs0 2 S j 9 2 A+ :s0 = (s; )g. Also, the set of all possible
action sequences of P is de ned as L(P ) def= f 2 A j (s0 ; ) 6= ?g, and the set of all possible label
def ^sequences is de ned as L (P ) = f() 2 L j  2 L(P )g. Since interest is in the in nite behavior of an
FSP, we introduce a set of in nite action sequences L! (P )  A! and L! (P )  (A! [ A fg! ) where means deadlock:

L! (P ) def= f 2 A! j 1  8k:(s0; (k)) 6= ?g

8f 2 A! j 1  8k:(8s0; (k)) 6= ?g[
>
>
9
<
def
i  k:(s0 ; (i)) 6= ? and =<L! = > f 2 A fg! j 9k:( 18a28A:(s0 ; (k)); a) = ? and ;)g:: [j ] =  (for8j > kL! (P ) is an extension of L(P ) into a set of in nite action sequences where if  2 L(P ) is a deadlock
sequence (i.e., an inevitably nite sequence), then  is represented as ! 2 L! (P ).
def
fair
Lfair
! (P )  L! (P ) is de ned as L! (P ) = f j  2 L! (P ) under the fairness conditiong where
the fairness condition means whenever a behavior  in nitely often passes through some state s, every
action a enabled at s must appear in nitely often on  (i.e., if s = (s0 ; (i)) for in nitely many i and(s; a) =6 ?, then s = (s0 ; (j )) and [j + 1] = a for in nitely many j ).

An FSP is a transition system with liveness conditions. In an FSP, liveness conditions are represented
by designated nodes that indicate satis able behavior of an FSP as follows.

De nition 6 (Satis able Behavior) Let P = (S; A; L; ; ; s0; F ) be an FSP.  2 A! is a satis able
behavior, if (s0 ; (k)) 2 F for in nitely many k  1. Lb (P )  A! is de ned as a set of all satis able
behaviors on P .
Note that a satis able behavior corresponds to an accepting run of Buchi automaton.

De nition 7 (Completeness of FSP)Let P = (S; A; L; ; ; s0 ; F ) be an FSP. P is complete if 8s 2 RP (s0 ):9s0 2 RP+ (s) and s0 2 F . 2
A state s 2 RP (s0 ), having no path to designated nodes from s, is called an unsatis able state. If P iscomplete, P has no unsatis able states. A behavior reaching an unsatis able state is called an inevitably
unsatis able behavior.

Lemma 1 If an FSP P is complete, then Lfair
! (P )  Lsat (P ). 2
This lemma means that if P is complete, then a random transition over P leads to a satis able
behavior. Consequently, if P is complete, P is deadlock-free.

1.5 Transition System with Concurrency

Transition systems ( nite state processes, automata) have no ability to express concurrency explicitly
by themselves. Reactive and concurrent systems are constructed from some number of processes. Each
local process can be modeled as a transition system. When processes are modeled by transition systems
TS1; TS2 ; :::; TSn, concurrency among processes can be expressed as process composition TS1 j TS2 j ::: j
TSn using composition operators `j'. TS1 j TS2 means a concurrent system in which TS1 and TS2 runconcurrently and communicate with each other. It is called communicating transition systems.
Furthermore, transition systems are also used to de ne semantics of process composition. Global
behaviors of communicating transition systems can be expressed by one global transition system basedon interleaving semantics. In the interleaving semantics, concurrent structures of systems is expanded
into a set of nondeterministic global behaviors.
Process composition and interleaving semantics will be explained in detail in Chapter 5 for transition
systems and in Chapter 6 for nite state processes.

Chapter 2: Preliminaries

23

I/O automata and Statechart can be classi ed into a kind of communicating transition systems. I/O
automata is communicating transition systems featuring reactive properties. In I/O automata [Lynch 86,
Lynch 88], each process is modeled by an automaton with input and output actions. Due to reactive
properties, input actions cannot be controlled by the automaton, while output actions can be. Statecharts[Harel 87a] are extended transition systems in order to design large and complex reactive and concurrent
systems. Statecharts have several extended features including hierarchy, concurrency, and their visual
formalisms. For example, a system which consists of three processes TS1; TS2; TS3 can be expressed inFig. 5. Since Statechart can express concurrency graphically, it is often used in design methodologies and
CASE tools.
TS1

TS2
s10

s21

a21

a22

a11

a12

a23

s11

s22

TS3

s20

a24

a31
s31

s30
a32

Figure 5.

Concurrency in Statechart

1.6 Petri Net

A Petri net is another approach to express concurrency explicitly in addition to state transition models.

De nition 8 (Petri Net) A Petri net is a 4-tuple N = (P; T; w; m0 ) where: P = fp1 ; p2 ; :::; pn g is a nite set of places, T = ft1; t2 ; :::tm g is a nite set of transitions, w : (P  T ) [ (T  P ) ! f0; 1; 2; 3; :::g is a weight function, w(p; t) is the weight of the arc from p
to t and w(t; p) is the weight of the arc from t to p, especially w(p; t) = 0 (w(t; p) = 0) means there
exists no arc between p and t,
 m0 : P ! f0; 1; 2; :::g is the initial marking.
 P \ T = ; and P [ T 6= ;A marking in a Petri net is changed according to the following ring rules:

 A transition is said to be enabled, if each input place p of t is marked with at least w(p; t) tokens.
 Only one of the enabled transitions can re at a time.
 Firing of an enabled transition t removes w(p; t) tokens from each input place p of t, and adds

w(t; p) tokens to each output place p of t.
Let t be a transition and P = fp1 ; p2 ; ::; pn g be a set of places. An n-dimensional di erential vector
is de ned as (t) = (w(t; p1 ) w(p1 ; t); :::; w(t; pn ) w(pn ; t)). Furthermore, (t1 t2 :::tm ) = (t1 ) +(t2 ) + ::: + (tm ) for a transition sequence t1 t2 :::tm .
When t 2 T is enabled at a marking m, we denote m[t >. After ring t, if m0 is a new marking, we
denote m[t> m0 . In the case that m1 [t1 > m2 ; m2 [t2 > m3 ; :::; mk 1 [tk 1 > mk for a transition sequence = t1 :::tk 1 , we denote m1 [ > mk . A set of reachable markings R(N ) of Petri net N is de ned as
R(N ) = fm j 9 2 T  :m0 [> mg.

Chapter 2: Preliminaries

24

De nition 9 (Labeled Petri net) A labeled Petri net is a 2-tuple, LN = (N; ), where N = (P; T; w; m0 )is a Petri net and  : T ! (alphabet) [ f"(empty sequence)g is a labeling function.
The labeling function  : T !  [ f"g is extended to  : T 1 ! 1 by ()[i] = ([i]) for all  2 T
and 1  i j  j. A sequence of transitions ( 2 T  ) is called a legal ring sequence on the Petri net N
if the ring sequence  is allowed by the ring rules; an in nite sequence of the transitions ( 2 T ! ) isa legal ring sequence if every pre x is a legal ring sequence. The set of all nite (in nite) legal ring
sequences of N is denoted by F (N ) (F! (N )).

De nition 10 (Petri net language) L(N; ) is a nite Petri net language generated from a labeled Petrinet (N; ) if L(N; ) = f() 2  j  2 F (N )g. Similarly, L! (N; ) = f() 2 ! j  2 F! (N )g is anin nite Petri net language, and L! (N; ) = f() 2 ! j  2 F! (N )g [ f() 2  j  2 F (N ) and 8t 2
T:t 62 F (N )g is a -in nite Petri net language. Here, \-in nite" means \in nite including ! ".
Remark: L! (N; ) may include nite words such as s! (s 2  ), while L! (LN ) includes onlyin nite words.
We introduce a label manipulation operator. When L  , we de ne a label restriction operator \/"for a labeling function as =L : T ! L [ f"g such that =L(t) = (t) if (t) 2 L and =L(t) = " if(t) 62 L. This means h(t) 2 L is visible and h(t) 2 nL is invisible. An identity function e : T ! T isde ned as e(t) = t for all t 2 T . We use an abbreviation =L def= e=L().

1.7 Models for Real-Time Systems

Several models for real-time systems are proposed as extension of transition systems, automata, andPetri nets, which include timed automata (timed graphs ) [Alur 90, Alur 91], timed transition systems[Henzinger 91], generalized stochastic Petri nets [Marsan 86, Marsan 95], time Petri nets [Berthomieu 91],
and time basic nets [Bellettini 93]. In this thesis, we do not mention them in detail.

1.8 Comparison of Models

Table 1 shows comparison of models which we mentioned, with regard to concurrency and liveness.
Table 1.

Comparison of Models

ModelsConcurrency LivenessTransition System
Transition System with composition operators
Buchi Sequential Automaton
Finite State Process with composition operators
Statechart
Petri Net

2 Logics for Reactive and Concurrent Systems
This section introduces several temporal and modal logics: Linear Time Temporal Logic, Branching
Time Temporal Logic, Process Logic, and Propositional Modal -calculus. These logics can provide
useful formalisms for specifying and verifying reactive and concurrent systems.

2.1 Propositional Logic

A logical language is given by an alphabet of symbols and the de nition of a set of strings over language,
called formulas. The simplest kind of a logical language is called propositional logic which can be given
as follows.

Chapter 2: Preliminaries

25

Syntax

Propositional logic formulas are built from: A set of all atomic propositions: Prop = fp1 ; p2 ; p3 ; :::; pn g, Boolean connectives: ^ and :, Parentheses: \(" and \)".
The formation rules are:
 An atomic proposition p 2 Prop is a formula, If f1 and f2 are formulas, so are f1 ^ f2 , :f1 , If f is a formula, so are (f ).

Abbreviation

Further logical operators and constants can be introduced to abbreviate particular formulas.

Abbreviated Formula = Original Formula= :(:f1 ^ :f2 )= :f1 _ :f2= f _ :f
= :true

f1 _ f2
f1  f2true
false

2.2 Linear Time Temporal Logic

Temporal logic is a special type of modal logic, where its modalities concern with time. There two possible
views regarding the underlying nature of time. One is that the course of time is linear. The other is thattime has branching, tree-like nature. First, we show Propositional Linear time Temporal Logic (PLTL)
based on the former view. Then, Propositional Branching time Temporal Logic based on the latter view
will be shown.

Syntax PLTL formulas are built from: A set of all atomic propositions: Prop = fp1 ; p2 ; p3 ; :::; pn g Boolean connectives: ^, _
 Temporal operators: (\next"), U(\until")
The formation rules are:
 An atomic proposition p 2 Prop is a formula.
 If f1 and f2 are formulas, so are f1 ^ f2 , :f1 , f1 , f1 Uf2 .

Semantics The operators intuitively have the following meanings: 2f (read next f): f is true for the

next state, f1 Uf2 (read f1 until f2 ): f1 is true until f2 becomes true and f2 will eventually become true.
The precise semantics are given as the Kripke structure [Manna 84].
We use }f (\eventually f") as an abbreviation for (true U f) and 2f (\always f") as an abbreviation
for :F :f . Also, f1 _ f2 and f1  f2 represent :(:f1 ^ :f2 ) and :f1 _ f2 , respectively.

Lemma 2 Given an PLTL formula f, one can build a Buchi sequential automaton Af = (; S; ; s0 ; F ),where  = 2Prop, such that L(Af ) is exactly the set of sequences satisfying formula f .

Chapter 2: Preliminaries

26

Proof Ref. [Wolper 83a].
Here, an accepted word  = P1 P2 P3 :::Pi ::: (Pi  P ) means that all p 2 Pi are true and all p 62 Pi arefalse at time i (0 < i).

De nition 11 (Single Event Condition) A single event condition is de ned as follows,_^
fSEC = 2((pi ) ^ (pi ^ pj ))1in

1i<jnwhere p1 ; ::; pn are all atomic propositions. 2
This single event condition provides that only just one atomic proposition is true at any moment[Manna 84]. When we build a Buchi sequential automaton A0f = (; S; ; s0 ; F ) where f' is f with thesingle event condition, we can make  = Prop in place of  = 2Prop, because only one atomic propositionis true at each time.

Example 3 (A0f ) The following Af (Fig.6) is built from PLTL formula f with the single event condition(i.e. f 0 = f ^ fSEC ).
0

f = 2(t1  (:t1 Ut2 )) ^ 2(t2  (:t2 Ut1 ))Af = (ft1 ; t2 g; fs0; s1 ; s2 ; s3 g; ; s0; fs0 ; s3 g) where  = ffs1g = (s0 ; t1 ); fs2 g = (s0 ; t2 ); fs3 g =(s1 ; t2 )); fs3 g = (s2 ; t1 ); fs1 g = (s3 ; t1 ); fs2 g = (s3 ; t2 )g.
0

s0
t2

t1

s1

t2

Figure 6.

t1

t2

s2

t1

s3

Buchi Automaton Af built from PLTL formula f0

De nition 12 Ls (f ) is an in nite language generated from an PLTL formula f under the single event
condition, i Ls (f ) = L(Af ) where f 0 = f ^ fSEC , and a set of atomic propositions Prop becomes analphabet of Af .
00

Lemma 3 Given an PLTL formula f , Ls (f ) = Ls (:f ), where Ls (f ) = Prop! nLs(f ).
Proof. The paper [Wolper 83a] proved that L(Af1 ) = L(Af2 ), where f2 = :f1 and no single event
condition is assumed there. This lemma is a special case of that theorem.2

2.3 Branching Time Temporal Logic

We will consider a simple version of propositional branching time temporal logic: CTL (Computation Tree
Logic).

Chapter 2: Preliminaries

27

Syntax CTL formulas are built from: A set of all atomic propositions: Prop = fp1 ; p2 ; p3 ; :::; pn g Boolean connectives: ^, _, Temporal operators: , U , Path operators: 8, 9,
The formation rules are:State Formulas An atomic proposition p 2 Prop is a state formula.
 If f1 and f2 are state formulas, so are f1 ^ f2 , :f1 .
 If g is a path formula, then 8g and 9g are state formulas.
Path Formulas
 If g1 and g2 are state formulas, then g1 , and g1Ug2 are path formulas.
CTL Formulas
 If f is a state formula, then f is a CTL formula.

Semantics The operators intuitively have the following meanings: 8 f = \f becomes true at thenext time for all paths", 8f1Uf2 = \f2 becomes eventually true and f1 is true subsequently until then for
all paths",9 f = \f becomes true at the next time for some path", 9f1 Uf2 = \f2 becomes eventuallytrue and f1 is true subsequently until then for some path".
The precise semantics of CTL formulas are de ned with a tree-like structure M and a state s. A
model of a CTL formula f is an in nite tree over M starting at s (we denote (M; s) j= f ). It is known
that if a given CTL formula f is satis able (i.e., it has at least one model), there exist a nite transition
system TS = (S; P; A; ; ; s0 ) such that A = ; (i.e., without actions) and a model of f can be obtainedby unwinding TS (Small Model Theorem). Therefore we can regard transition systems without actions
as models of CTL formulas.
In CTL, the formulas appearing in the scope of path quanti ers are restricted to be a single temporal
operators. Therefore some PLTL formulas cannot be expressed in CTL. CTL* is extension of CTL, inwhich arbitrary PLTL formulas can appear in the scope of path quanti ers. An arbitrary PLTL formula
f is expressed by 8f in CTL*.

2.4 Process Logic

A process logic is a kind of modal logics in which its modalities concern with actions.

Syntax Propositional process logic (PPL) formulas are built from: A set of actions: A Boolean connectives: ^, _
 Modal operators: hai for a 2 A
 A constant: true
The formation rules are:
 A constant true is a formula.
 If f1 and f2 are formulas, so are f1 ^ f2 .
 If f is a formula and a is an action (a 2 A), the haif is a formula.

Chapter 2: Preliminaries

28

Semantics The operators intuitively have the following meanings: haif = \it is possible to execute an
action a and terminate in the state satisfying f ".
Formally, PPL formulas are also interpreted with a tree-like structure M and a state s. A model ofa PPL formula f is an in nite tree over M starting at s (we denote (M; s) j= f ). It is known that if agiven PPL formula f is satis able (i.e., it has at least one model), there exist a nite transition system
TS = (S; P; A; ; ; s0 ) such that P = ; (i.e., without state attributes) and a model of f can be obtainedby unwinding TS (Small Model Theorem). Therefore we can regard transition systems without state
attributes as models of PPL formulas.

2.5 Propositional Modal -calculus

-calculus is a variation of process logic extended with a least xed point operator . Since the xed
point operator is very powerful, -calculus can express both temporal logic and process logic uniformly.
We show the de nition of propositional modal -calculus.

Syntax The propositional modal -calculus has formulas built from: A set of actions: A
 A set of variables: V ar
 Boolean connectives: ^, _
 Modal operators: hai for a 2 A
 A xed-point operator: The formation rules are:
 A variable Z is a formula.
 If f1 and f2 are formulas, so are f1 ^ f2 .
 If f is a formula and a is an action (a 2 A), the haif is a formula.
 If f is a formula and Z is a variable (Z 2 V ar), the Z:f is a formula.
Z:f means \every Z appearing in f are replaced with f ". The semantics of -calculus is de ned in
the same way as PPL.

2.6 Logics for Real-Time Systems

There are two main approaches in introducing real-time into temporal logics.
 introduction of a global clock (Explicit Clock Temporal Logic)
ex. a ^ t = T  }(b ^ t  T + 10), where t is a global clock.
 introduction of time bounds (Metric Temporal Logic)
ex. 2<5 f:
RTTL [Ostro 90] is an extended PLTL with a global clock variable. TCTL (Timed CTL) [Alur 90]
is an extension of CTL for specifying real-time systems. Models of TCTL formula correspond to timed
graphs (timed automata). In this thesis, we do not mention them in detail.

2.7 Comparison of Logics

Table 2 shows comparison of logics which we mentioned, with regard to relations between logics andmodels.

Chapter 2: Preliminaries

29
Table 2.

Comparison of Logics

LogicsModelsEquivalent Models
PLTL
in nite sequences accepted sequences of Buchi Sequential AutomatonCTL
in nite trees
Transition System without actions
PPL
in nite trees
Transition System without state attributes
-calculus
in nite trees
Transition System with actions and state attributes

3 Other Related Approaches
There are a lot of other approaches for modeling and specifying reactive and concurrent systems, which
include process algebra (CCS, CSP, ACP, -calculus, chemical abstract machine), data ow model (Kahn's model), object-oriented model (Actor Model), and concurrent logic programming (Concurrent Prolog, PARLOG, GHC).
Since these models are out of scope of this thesis, we do not mention them in detail.

Chapter 3

Software Development Process for
Reactive and Concurrent Systems
This chapter proposes a conceptual software development process for reactive and concurrent systems
using Petri nets and temporal logic.

1 Reactive and Concurrent Systems (RCS)

1.1 What is RCS?

A reactive system was rst de ned by Pnueli [Pnueli 86] and Harel [Harel 87b]. They classi ed computerized systems into two basically di erent types: Transformational Systems and Reactive Systems.
Transformational systems and reactive systems are de ned in the book by Manna and Pnueli[Manna 92]
as follows.

 Transformational Systems (TFS): \A transformational program is the more conventional typeof program, whose role is to produce a nal result at the end of a terminating computation. " Reactive Systems: \A reactive program is a program whose role is to maintain an ongoinginteraction with its environment rather than to compute some nal value on termination."

We remark that reactive systems include real-time systems, that is to say, a real-time system is a
speci c reactive system which has real-time constraints.
Examples of reactive systems are as follows: Embedded control systems

ex. Home electric appliances, car electric appliances, and communication equipment (telephone
and facsimile).
 Process control systems
ex. Control systems for chemical plants, electric power plants, steel mill plant, and sewage
plants.
 Computer and network operating systems
ex. Operating systems, switching systems, and computer network control software.
 User interface management systems
ex. Window systems for workstations and personal computers.
Most reactive systems necessarily have concurrency which is often represented as concurrent tasks(multitasking) since the framework of the concurrent tasks is t to model and implement reactive systems
having several kinds of interactions which should be handled concurrently. Therefore we focus on reactive
and concurrent systems (RCS) in this thesis, especially embedded and process control systems.
30

Chapter 3: Software Development Process

31

1.2 Characteristics of RCS

We summarize the characteristics of reactive and concurrent systems as follows.

 Reactivity'

RCS maintain an ongoing interaction with their environments. In the case of plant control systems,
the environment is controlled objects of the plant, and the controller interacts with the controlled
objects through input devices (sensors) and output devices (commands) as shown in Fig. 7.
LAN

SensorControlled
ObjectController
Control
ProgramCommandSensorControlled
ObjectController
Control
ProgramCommand
Plant

Figure 7.

Plant Control System Nondeterminism'

Behaviors of TFS are deterministic, that is, an output O can be de ned as a functional relation
O = f (I ) for a given input I in TFS. On the contrary, behaviors of RCS are nondeterministic
since the environment of RCS has uncontrollable and unobservable elements. For example, timing
and order of some sensory events (temperature and pressure changes) in chemical plants may
be nondeterministic. These timing and order of events have an in uence on the result. The
nondeterministic behaviors of RCS make it dicult to test and debug the programs compared withTFS.

 Real-time Properties'

Most practical RCS have real-time properties to a greater or less extent%Real-time properties
include the followings.
{ Deadline adherence: The system should process tasks in accordance with their real-time
deadlines.
{ Periodic processing: The tasks are activated periodically by timer events.
The real-time systems can be classi ed in terms of deadline adherence.
{ Hard real-time systems: If the system cannot keep deadline, it may bring about a catastrophic result.
{ Soft real-time systems: Even if the system cannot keep deadline, it is possible to recoverit by a backup method (e.g. an exception handler).

 Concurrent Tasks'

The concurrent tasks are t to model and implement RCS having several kinds of interactions whichshould be handled concurrently. In particular concurrent tasks are essential for real-time systems.
For example, arrival of the interrupt results in a currently executing task being suspended, its
contents (a program counter, stacks, etc.) being saved, and an interrupt handler to process theinterrupt being invoked. After the interrupt has been serviced, the interrupted task's content isrestored so that it can resume execution. It may be possible to manage these interrupts without
concurrent tasks. However, a design without concurrent tasks is unnatural and makes the programChapter 3: Software Development Process32

dicult to debug, maintain and reuse. Moreover RCS in distributed environments (e.g. RCS which
consist of several controllers connected by networks) inevitably require concurrent tasks.
In this thesis, a task and a process have the same meaning. However, we often use \task" in thecontext of the software design methodology and \process" in the theoretical context.
These properties (reactivity, nondeterminism, real-time property, concurrent tasks) are called \timing
features of RCS" or \synchronization features of RCS", and the other features, which are in common
with TFS, are called \functional features of RCS".

1.3 Software Architecture of RCS

We will consider software architectures required to construct reactive and concurrent systems.

1.3.1 Application Software and System Software

Software of a reactive and concurrent system consists of application software and system software (i.e., an
operating system). The system software provides abstract manipulations of computer hardware including
system resources, I/O devices, network devices, and timers (Fig. 8), and also provides concurrent tasking
mechanisms including task generation, task scheduling, and task communication and synchronization.
Application software is constructed on the system software by using system calls and run-time libraryprovided by the system software.
SoftwareApplication Software

System Software
Resource

I/O

Network

Timer

HardwareFigure 8.

Application Software and System Software

In reactive and concurrent systems, real-time operating systems and network operating systems areoften used as system software.

1.3.2 Concurrent Tasks

Application software of reactive and concurrent systems usually consists of several concurrent tasks.
Gomaa classi ed them into the following tasks [Gomaa 93].

 I/O Tasks{ Asynchronous Device I/O Tasks{ Periodic I/O Tasks{ Resource Monitor Task
 Internal Tasks{ Periodic Task

Chapter 3: Software Development Process

33{ Asynchronous Task
{ Control Task
{ User Role Task
Concurrent tasks can be classi ed into I/O tasks , which correspond to I/O devices and hardware
resources and manage them, and internal tasks , which supervise these I/O tasks. From another viewpoint,tasks can be classi ed into periodic tasks which are invoked periodically (e.g., every 100 milliseconds)
and aperiodic tasks .

1.3.3 Synchronization Part and Functional Part

In most application software of RCS, a process (task) can easily be separated into two parts: a synchronization part and a functional part [Manna 84].
 Synchronization (Timing) Part: A part which enforces the necessary constraints on the relative
timing of the execution of the di erent processes.
 Functional Part: A part which manipulates the data and performs the computation required ofthe program.
A functional part of RCS can be regarded as TFS. We focus on a design matter of synchronization
parts; how to design and verify synchronization parts and how to adjust synchronization parts, consideringfunctional parts.
A synchronization part design is classi ed into a centralized one and a decentralized one (Figure 9). A
centralized synchronization part is easier to design and verify, but more dicult to implement eciently,
especially in a distributed environment. Conversely, a decentralized synchronization part is harder todesign and verify, but can achieve run-time eciency.

Synchronization Part

Functional
Part

Functional
Part

Functional
Part

Centralized Synchronization
Supervisor

Figure 9.

Process

Process

Process

Synchronization
Part

Synchronization
Part

Synchronization
PartFunctional
Part

Functional
Part

FunctionalPart

Decentralized Synchronization
Supervisor

Synchronization Part

A hierarchical synchronization supervisor is a compromised structure between a centralized one anda decentralized one (Figure 10). It can be constructed hierarchically where each level can be constructed
as a centralized one, that is, easy to design and verify. As a whole, it looks like a decentralized one.
For example, small embedded control systems such as home electric appliances adopt a structure
having the hierarchical synchronization supervisor (Figure 11).
In the next section we will consider a software development process for RCS which have these characteristics and structures.

2 Software Development Process for RCS
This section takes a general view of the software development process for transformational systems (TFS)
and reactive and concurrent systems (RCS), and considers a distinctive feature of RCS as compared withTFS.

Chapter 3: Software Development Process

34

Process
FP (=Functional Part)

SP (=Synchronization Part)

SP

FP

SP

ProcessFP

SP

Process

Figure 10.

FP

Process

Hierarchical Synchronization Supervisor

Controller

SP (Main Controller)

SP

FP
Device Controller

Device

SP

FP

FP

SP

Device Controller

DeviceFP
Device Controller

DeviceEnvironment (Controlled Object)

Figure 11.

Hierarchical Synchronization Supervisor for Control Systems

Chapter 3: Software Development Process

35

2.1 Software Development Process for TFS

According to the software life-cycle model, the software development process can be divided into several
phases. The most widely used software life-cycle model is often referred to as the \Waterfall" Model[Boehm 76]. Although the Waterfall Model has several limitations and alternative models are proposed
to overcome them (Prototyping and Spiral Model), it is used here because it is sucient to consider
distinctive features of the proposed software development process for RCS.
Figure 12 shows the software development process which consists of the following phases.
Validation

Design
ReviewInformalSpecification

Analysis/Design

Figure 12.

DesignDocument

Testing

Implementation

Program

Software Development Process Analysis/Design Phase: This phase includes requirement analysis and architectural design.

The goal of the requirement analysis is to provide a complete description of what the system's
external behavior is. During the architectural design, the system's architecture is de ned by design
documents which describe how the system works internally. We intentionally do not divide thisphase into two phases (analysis and design) clearly because analysis and design are intertwined and
it is dicult to completely separate them in the actual software development.
 Implementation Phase: This phase includes detailed design where the algorithmic details ofeach component are de ned and coding in a programming language.
 Validation Phase: This phase includes design review for design documents and testing for programs. Testing consists of unit testing, integration testing, and system testing.

2.2 Software Development Process for RCS

The software development process for RCS requires consideration of RCS characteristics(which is mentioned in the section 1.2) in addition to those of TFS.

 Input/Output Consideration

Input/output considerations are important for RCS which interact with their environment throughI/O devices. In the analysis/design phase, an interface between a system and its environment
should be de ned and designed. This includes a software design of I/O driver.
! Reactivity

 Concurrent Task Structuring

Concurrent task structuring is one of the most important issues in RCS design. Concurrent task
structuring includes the designer's tradeo between introducing tasks to simplify the design and
not introducing too many tasks which increase intertask communication overhead. Concurrent
task structuring criteria are needed to help the designer make the tradeo and show him how todecompose a software system into tasks systematically.
! Concurrent Tasks

 Task Communication and Synchronization

Chapter 3: Software Development Process36

After task structuring, the task interface is de ned. The task interface consists of communicationand synchronization between tasks. The most popular method of task communication design isa data ow diagram (DFD) which shows communication relationships between tasks, including
input data, output data, and data stores. On the other hand, task synchronization design includes
deadlock prevention, mutual exclusion, and other timing issues. In the design phase, communicationand synchronization are designed using message communication, event synchronization, and datastores, which are implemented later using run-time support services (mail boxes, semaphore, event
ag, etc.)! Concurrent Tasks and Nondeterminism Performance Design

Performance design is necessary for RCS to satisfy given real-time constraints. Performance design
includes performance analysis using simulation models and scheduling. A real-time operating systemprovides several mechanisms such as timer (set timer, get timer), task management (start task,
terminate task, suspend task), and priority control (change priority). These mechanisms are used
for the scheduling design to satisfy given real-time constraints.
! Real-time Property and Nondeterminism

2.3 Diculties in Developing RCSGenerally speaking the development (especially testing and debugging) of RCS is more dicult than thatof TFS. The safety and reliability of RCS are very important as they are used in crucial systems such as
power plants, chemical plants, and various computer embedded systems. As RCS become increasingly
complex and distributed over computer networks complete testing of the safety of these programs becomes
more dicult and the cost of testing and debugging becomes a heavy burden. The diculty in testingand debugging RCS can be summarized as follows.

 Concurrent thinking: The concurrent model is t to design static structures of systems. However,

it is dicult to trace their dynamic behaviors concurrently because human thinking is essentiallysequential. Concurrent thinking which is required for designing, testing and debugging RCS is verydicult for designers to achieve.
 Data and timing variations: In testing TFS, the designer has to consider only data variations.
However, timing variations in addition to data variations have to be considered in testing RCS.
Combination of data and timing variations makes testing very complicated.
 Environment modeling: Since a program of the reactive system cannot function without its
environment, testing on the development machine requires an environment model and its simulator.
The designer can test RCS with environment simulators, which are very useful in reducing testing
costs. However, simulator construction requires additional programming costs, and it is ine ective
to construct a handmade environment simulator for each RCS.
 Lack of bug reappearance: Unlike in TFS, bugs do not necessarily reappear in RCS. For example
bugs which appear in the usual execution often disappear when using the debugging tool (it is called
the probe e ect). It makes debugging of RCS very dicult.
 Task structuring: As compared with module structuring in TFS, task structuring is more difcult because physical constraints (real-time constraints and constraints due to devices) must be
considered in addition to logical module structuring.

3 Programming Environment for RCS Using Petri Nets andTemporal Logic
This section shows a basic concept and organization of the proposed software development process andits programming environment in this thesis. Then it is shown how the above diculty is eased by them.

Chapter 3: Software Development Process37

Formal Speci cation for RCS
In the proposed software development process, the formal speci cation takes up a position as asoftware design document (SDD) which is produced through the analysis and design phase. The formal
speci cation is used for the formal veri cation and adjustment later.
Many formal speci cation languages are proposed. Some are declarative, and some are operational.
However, speci cation of practical systems requires both a declarative one and an operational one. For
example, it is impossible to describe all of the practical systems by temporal logic (declarative one).
Conversely, it is impossible to describe liveness properties such as deadlock-free by Petri nets (operationalone). An operational speci cation language is suitable for describing static and dynamic structures ofthe system. On the other hand, a declarative one is suitable for describing constraints of the system.
We adopt both Petri net and temporal logic as a formal speci cation language for RCS because they
can complement each other

Design Document Reuse
The development process promotes and supports reuse of software design documents written by Petrinets and temporal logic. Reusable components are stored in the reusable component library. Since Petrinets provide a graphical representation of reusable components in the library, the designer can easily grasp
these components. Temporal logic provides a formal framework to check whether reusable components
work just as the designer designed.

Veri cation and Adjustment for RCS
The software design document can be veri ed by the formal method, that is, it is possible to verify
whether the given Petri net satis es the given temporal logic constraints.
Moreover, when the Petri net does not satisfy the temporal logic constraints, the Petri net can be
automatically adjusted to satisfy them.
In particular, software reuse involves risk of bugs because the designer may not have an accurate
understanding of reused components. So, veri cation and adjustment can complement software reuse.

Programming Language for RCS
The veri ed and adjusted software design documents are coded with the programming language in
the implementation phase. The proposed development process also adopts Petri net as a programming
language. In this case, implementation is expected to be smoother because both design document language
and programming language are based on the same framework. However, since pure Petri net is insucient
as a practical programming language for RCS, it should be extended.

Design Methodology for RCS
Software design documents written by using Petri nets and temporal logic are very formal and strict.
Therefore, it is very dicult to describe these documents directly from ambiguous and informal requirements in analysis and design phase. There are many design methods such as RSA/RSD and OOA/OOD.
However, they do not use Petri nets as their design documents (charts). A Petri-net-oriented design
method for RCS is required in the development process.

Software Development Process (Basic Concept)
Based on the above consideration, the proposed software development process is summarized as follows(Fig. 13).
1. Analyze and design a target system from informal speci cation according to the Petri-net-based
design methodology.
2. Construct a software design document written by using Petri nets and temporal logic. When re ning
Petri nets, reusable components are available.

Chapter 3: Software Development Process

InformalSpecification

Reusable
Components

Petri-net Basd
Design

Reuse

38

Petri
Nets

Adjustment

Temporal
Logic

Verification

Test

Petri
Nets

Inplementation

Petri
Nets

Validation

Figure 13.

Proposed Software Development Process for RCS

3. Verify and adjust the design document.
4. Implement the design document and code it by using a Petri-net-based programming language.
5. Test the generated program.

Programming Environment for RCS
The programming environment supports the proposed software development process continuously. It
includes Graphic editor for Petri nets
 Support tool for design and software reuse Veri cation and adjustment tool Compiler/Interpreter of Petri-net-based programming language Testing and debugging tools including program and environment simulators

How to Ease Diculties in Developing RCS
The proposed software development process and its programming environment utilizing Petri nets
and temporal logic can ease some diculties of software development of reactive and concurrent systems
as follows.

 Petri Nets: Petri nets provide a user-friendly graphical representation of reactive and concurrent
systems and also their environments. Petri nets are adopted from rst to last (i.e., from design toimplementation) in the proposed software development process.
! ease diculties due to concurrent thinking, and environment modeling.
 Temporal Logic: Temporal logic provides formal methods of speci cation, veri cation, and adjustment about timing constraints of reactive and concurrent systems.
! ease diculties due to timing variations and lack of bug reappearance.

Chapter 3: Software Development Process39 Methodology: Design methodology featuring Petri nets and temporal logic provides support sothat the designer can easily use these formal methods and design continuously from ambiguous
requirement to program implementation.
! ease diculties in task structuring.

4 SummaryThis chapter has shown a conceptual overview of the software development process for reactive andconcurrent systems using Petri nets and temporal logic. In the following chapters, we explain the detailtechniques required to realize this software development process.

Chapter 4

Speci cation, Veri cation, andSynthesis Using Petri Nets andTemporal Logic
Both Petri nets and temporal logic have been widely used to specify concurrent programs [Shatz 93]. Petrinets are appropriate to specify the behavioral structures of programs explicitly, while temporal logic isappropriate to specify the properties and constraints of programs. Since one can complement the other,using a combination of Petri nets and temporal logic is a highly promising approach to analyze, verify andsynthesize concurrent programs. This fusion of Petri nets and temporal logic as speci cation language
belongs to dual-language approach. For the purpose of automatic program veri cation and synthesis,
the emptiness problem (i.e. whether a legal ring transition sequence satisfying a given temporal logic
formula on a given Petri net exists) must be decidable. This chapter rst reports a class to combine
Petri nets and temporal logic as an in nite language and whose emptiness problem is decidable. Then,
we apply these results to veri cation and synthesis of concurrent programs. Our veri cation method
allows verifying several properties which cannot be covered by the traditional Petri net analysis, suchas analysis of mutual exclusion and partial ordering of events. Our synthesis method can be used tomodify an original concurrent program that is represented by a Petri net, to satisfy a given temporal
speci cation.

1 Petri Nets and Temporal Logic as Speci cation Language
As mentioned at Chapter 1 (Section 2: Background), a speci cation of reactive and concurrent systems
can be classi ed into declarative approach and operational approach. Petri net and temporal logic are
typical speci cation languages based on operational approach and declarative approach, respectively.
The Petri net [Peterson 81, Murata 89] is widely accepted as a graphic and formal modeling tool, applicable to reactive and concurrent systems, and it is suited for modeling behavioral structures [Shatz 93].
However, Petri nets are de cient in their ability to describe declarative constraints of programs, which
is a strong point of logic. On the other hand, temporal logic is successfully applied as a tool for theveri cation [Pnueli 77] and synthesis [Manna 84] of concurrent programs, and suited for specifying theconstraints (declarative properties) of reactive and concurrent systems. Manna and Pnueli [Manna 92]
classi es these properties into two disjoint classes.
 Safety Properties:
A safety property claims that \something bad" does not happen.
 Liveness Properties:
A liveness property claims that \something good" eventually happens.
Temporal logic can specify both safety property and liveness property. For example, prohibiting constraints, such as \once an error event occurs, a start event must not be activated" can be described
explicitly by temporal logic, but it can only be described implicitly by Petri nets.
40

Chapter 4: Speci cation, Veri cation, and Synthesis

41

Petri net and temporal logic can complement each other as shown in Table 3. Therefore, it is useful tocombine Petri nets and temporal logic as a speci cation language for analyzing, verifying and synthesizing
concurrent programs. One can design concurrent programs operationally by Petri nets, while one canspecify them declaratively by temporal logic. We consider fusion of temporal logic and Petri nets, whichis called dual-language approach in [Felder 94].
Table 3.

Comparison of Petri Nets and Temporal Logic

Petri Net
Temporal Logic
Operational(Executable)
Declarative(Unexecutable)
Suitable for Structure Description Suitable for Constraint Description
Visual and Textual Representation
Textual Representation

Since a bounded Petri net has only nite states, expressive power of Petri nets combined with temporal
logic is equivalent to one of nite state transition systems combined with temporal logic. Veri cation andadjustment using transition systems and temporal logic will be described in the subsequent chapters. We
focus on unbounded Petri nets in this chapter.
Several classes [Cherkasova 87, Howell 88, Suzuki 89] have already been proposed in which unbounded
Petri nets are combined with temporal logic. However, these classes are inadequate for automatic veri cation and synthesis because some are undecidable in regard to the emptiness problem (i.e. whether
or not there exists a legal ring transition sequence satisfying a given temporal logic formula on a given
Petri net), and some are decidable but their complexity is as enormous as the reachability problem. The
decidability of the emptiness problem is inevitable for automatic veri cation and synthesis. In this chapter, we select a class combining Petri nets and propositional linear time temporal logic (PLTL), such thatits expressive power is less than classes mentioned above, but its emptiness problem is decidable, and its
complexity is the same as the coverability problem. In this class, a transition ring sequence corresponds
to a model of the temporal logic formula, and it is possible to combine Petri nets and temporal logic as anin nite Petri net language. In nite Petri net languages were well investigated by Valk [Valk 83, Valk 85].
The following results will be shown in this chapter using in nite Petri net language techniques:
1. It is decidable whether or not a Petri net satis es a propositional temporal logic speci cation.
2. For a given Petri net N and propositional temporal logic speci cation f , the new Petri net N 0 can
be constructed by modifying N , such that N 0 satis es f .
These results are applied to veri cation and synthesis for concurrent programs in Sections 2 and 3,
respectively.

1.1 How to Fuse Petri Nets and Temporal Logic

There are several ways to combine a Petri net with temporal logic. The key point in combining iswhat the atomic proposition in temporal logic corresponds to in Petri nets. There are some possible
correspondences between atomic propositions in PLTL and Petri net properties as follows.

(a) an atomic proposition mk(p) is true i place p has at least one token.
(b) an atomic proposition ge(p; c) is true i place p has at least c tokens. 6(c) an atomic proposition en(t) is true i a transition t is enabled.
(d) an atomic proposition fi(t) is true i a transition t just res. 7
For these correspondences, several research results are presented as shown in Table 4. It can be seenthat the emptiness problem becomes undecidable in some Petri nets combined with temporal logic. Someare decidable, but are limited to bounded Petri nets or restricted PLTL. Here, the emptiness problem isroughly de ned as to decide whether, for a given Petri net N and a given temporal logic speci cation
6 (a) is a special case of (b), i.e. mk(p) = ge(p; 1).
7 Note that fi(t)  en(t) always holds.

Chapter 4: Speci cation, Veri cation, and Synthesis

42

f , there exists a legal ring transition sequence on N satisfying f . Our purpose is to select an general
Petri net class combined with general PLTL in which the emptiness problem is decidable. The reason
is that decidability is necessary for automatic program veri cation and synthesis, and unboundedness ofthe general Petri net is necessary for modeling asynchronous communication in concurrent programs.
Table 4.

Several Combinations of Petri Nets and Temporal Logic

Paper[Katai 82][Cherkasova 87][Howell 88][Suzuki 89]

Type
a
b,c,d
a,c,d
b,c,d

[Uchihira 90a]dPetri netsafe
generalgeneralgeneralEmptiness Problem
decidable
undecidable
undecidable
undecidable
decidable for restricted PLTL
bounded decidable

Here, we adopt only d-type correspondence and combine the Petri net N and PLTL formula f asa formal language. A labeling function h : T ! Prop [ f"g is used to map transitions t 2 T of N toatomic propositions fi(t) 2 Prop (i.e., h(t) = fi(t)). In addition, all transitions of N do not necessarily
correspond to atomic propositions. Some transitions may be invisible to a user who describes temporal
logic speci cations (i.e. h(t) = " for a invisible transition t). We are now going to generally de ne a newformal language from N , f , and h.

De nition 13 (L(N; f; h)) N = (P; T; w; m0 ) is a Petri net, and f is a PLTL formula which consistsof atomic propositions Prop, and h is a labeling function such that h : T ! Prop [ f"g. We de neL(N; f; h) def= L! (N; h) \ Ls (f ), where L! (N; h) is an in nite language generated from a labeled
Petri net (N; h), and Ls (f ) is an in nite language generated from f under the single event condition 8 .
L(N; L; h) 6= ; means that there exists a legal ring transition sequence satisfying f on N .

1.2 Example of Speci cation

A typical example of reactive and concurrent systems, mutual exclusion, is considered. In this example,
a behavioral structure of the system is given by Petri net N shown in Fig. 14, and declarative constraints
are given by the following temporal logic formula.
 d-typef = 2}fi(t11)^2}fi(t21 )^2(fi(t11 )  (:fi(t21 ) U fi(t12)))^2(fi(t21 )  (:(fi(t11 )) U fi(t22)))

 a-typef = 2}mk(CS1 ) ^ 2}mk(CS2 ) ^ 2:(mk(CS1 ) ^ mk(CS2 ))Here, CS and NCS mean \critical section" and \non-critical section", respectively. Both formulas meanthat this Petri net is deadlock-free and the mutual exclusion of critical sections CS1 and CS2 is preserved.

1.3 Theoretical Results

Theorem 1 (Decidability of Emptiness Problem of L(N; f; h)) The emptiness problem of L(N; f; h) (i.e.
L(N; f; h) is empty or not) is decidable for given N , f , h.

Proof. It is sucient to prove that the emptiness problem of L! (N; h) \ Ls(f ) is decidable. To begin
with, the following procedures are provided which constructs an extended coverability graph G from N ,h, and Ls (f ).
8 L! (N; h) and Ls (f ) are de ned in Chapter 2.

Chapter 4: Speci cation, Veri cation, and Synthesis

43

free
t11

t21

NCS1

NCS2
CS1

busy
t12

Figure 14.

CS2

t22

Petri Net N Representing Mutual Exclusion

Main Procedure
1. A Buchi sequential automaton Af = (Prop; S; ; s0 ; F ) accepting Ls (f ) is constructed.
2. Then, construct an extended coverability graph G from N = (P; T; w; m0 ), h and Af . G is alabeled directed graph. Each node x of G is represented as a k+2-tuple x = (x1 ; :::; xk ; s; f ) wherejP j = k; xi 2 f0; 1; :::g [ f!g(1  i  k), s 2 S , f 2 f0(normal node); 1(designated node)g. Eachedge e = (x; x0 ) is labeled with an element of T . A transition t 2 T is called to be enabled in x if
t is enabled at a marking (x1 ; :::; xk ) and (s; h(t)) 6= ;, and t is called to be local enabled if t isenabled in the marking and h(t) = ". G is constructed as follows:(a) Start with a graph G containing only an initial node xinit = (x01 ; :::; x0k ; s0 ; f ) where m0 =(x01 ; :::; x0k ), s0 is an initial state of Af , and f = 1 if s0 2 F , otherwise f = 0. Let xinit be
an unapplied node.
(b) Repeatedly apply the following Graph Addition Procedure to the new (unapplied) nodes of G
until all nodes of G have been applied.

Graph Addition Procedure

1. Let x be a given node with x = (x1 ; ::; xk ; s; f ). Create new node candidates x0 = (x01 ; :::; x0k ; s0 ; f 0)
from x according to the following (a)-(d) for all enabled transitions t at x and all s0 2 (s; h(t)).
Also create new node candidates x0 = (x01 ; :::; x0k ; s; 0) according to (a)-(c) for all local enabledtransitions t:(a) x0i = ! if xi = ! (1  i  k).
(b) If there is a node y = (y1; :::; yk ; s0 ; fy ) on some path from xinit to x (that is an ancestor of x)such that yj  xj w(pj ; t) + w(t; pj ) for all j (1  j  k) and yi < xi w(pi ; t) + w(t; pi ) forsome i, then x0i = !.
(c) For the other i, x0i = xi w(pi ; t) + w(t; pi ).
(d) f = 1 if s0 2 F , otherwise f = 0.
2. If x0 is new in G, that is, G doesn't have the same node, then add a new node x0 and a new edgee = (x; x0 ) labeled with t. Otherwise add only a new edge e = (x; x0 ) labeled with t.
The above procedure always terminates because G is nite in the same way of the normal coverability
graph of a Petri net. Next, we prove the following claim.

Claim: L! (N; h) \ Ls (f ) 6= ; i there exists a cycle c = n0n1 :::nk n0 on G such that n0 is a designatednode (i.e. f = 1) and ()  0 where  = t1 :::tk+1 is a transition sequence over c (i.e. ti is a label ofe(ni 1 ; ni )).

Chapter 4: Speci cation, Veri cation, and Synthesis

44

Note that  is not necessary to be legal. The above claim follows directly from the result (Theorem
3.11) of Valk and Jantzen [Valk 85]. Furthermore, it is decidable whether or not there exists such a cycle
as follows: For each designated node n0 , a set of all transition sequences  forming cycles on G passing
through n0 , can be represented by a regular expression R (e.g. R = (t1 t2 ) + (t1 (t3 + t4 ) t5 ) ). We want
to decide if there are some  2 R such that ()  0. For this purpose, we can regard R as commutative.
Therefore, R can be expressed as a nite sum of terms of the shape 0 1 2 :::n such that i 2 T (0 
i  n), using the decomposition rules (AB = BA, A B  = (AB ) (A + B  ), (A + B ) = A B  ,(A B ) = " + A B  B ), which are described in the Conway's book [Conway 71]. For each 0 1 2 :::n ,we can e ectively decide whether (0 1 1 2 2 :::n n ) = (0 ) + 1 (1 ) + 2 (2 ) + ::: n (n )  0 forsome 1 ; 2 ; :::; n  0, by using linear programming.
While Valk and Jantzen [Valk 85] showed that it is decidable whether there is a legal ring sequence
on a Petri net satisfying various fairness constraints, this theorem shows that it is decidable whether
there is a legal ring sequence on a Petri net satisfying temporal logic constraints. It is also possible toprove this theorem by showing Petri net + temporal logic constraints to be equivalent to Petri net +some fairness constraints.
When L(N; f; h) is nonempty, it is very important to nd a concrete sequence accepted by L(N; f; h)for the sake of program synthesis.

Theorem 2 (Construction of Legal Firing Sequence) If L(N; f; h) is nonempty, we can construct a
deterministic legal ring sequence 0 c! on N such that h(0 c! ) 2 L(N; f; h).

Proof sketch. First, we rede ne a weight function  as (e) = (transition of edge e) for edges of G.
If L(N; f; h) is nonempty, there exists a cycle c = e0 e2 :::ek on G where e0 = (x0 ; x1 ); :::; ek = (xk 1 ; x0 ),(c)  0, and x0 is a designated node from Theorem 1. Remark that c might not be legal. We willshow cycle c can be constructed, and we can also construct a path p from the initial node xinit to thedesignated node x0 , whose transition sequence is legal and a marking in x0 (let it mx0 ) is so large that c
becomes legal.

 Construction of cycle c

In the same way as the proof of Theorem 1, we can compute 1 ; 2 ; :::; n  0, such that (c) =(e00 ) + 1 (e01 ) + 2 (e02 ) + ::: n (e0n )  0 where e0i may not be adjacent to e0i+1 . Each i means
how many times the edge e0i appears in c. Therefore, the construction of c can be reduced to theconstruction of Euler cycle c such that each edge e0i appears i times in c.

 Construction of path p

We can form the path into p = p0 c1 1 p1 c2 2 :::cnn pn where ci means a cycle in which some place's
marking changes into ! on G (we call it i-th ! place). We would like to compute 1 ; 2 ; :::; n  0such that (p0 c1 1 p1 c2 2 :::cnn pn )  mx0 . Here, the problem is not so easy because p must be legal.
The following recurrent formulas must be solved:(0) M0 = m0 + (p0 ), and a path p0 from marking m0 must be legal,(i) Mi = Mi 1 + i (ci ) + (pi ), and a path ci i pi from marking Mi 1 must be legal,(n) Mn  mx0 .
We point out that these formulas can be solved backward from the n-th formula, that is, we cancompute i backward independently from 1 ; 2 ; :::; i 1 , because we can ignore j-th ! place forall j < i.
After all, a deterministic legal transition sequence 0 c! such that h(0 c! ) 2 L(N; f; h) is directly
produced from pc! .

2 Concurrent Program Veri cation
Consider concurrent program veri cation focusing on behavioral properties. After retracting the basic
behavioral structures represented by Petri nets from concurrent programs, it is possible to analyze thebehavioral properties of programs. This veri cation means to check whether or not a given Petri net

Chapter 4: Speci cation, Veri cation, and Synthesis

45

satis es a given speci cation. Temporal logic is adopted as a speci cation language where atomic propositions correspond to transition ring as described in the previous chapter. Only the in nite Petri net
language L! (N; h) is considered there, which does not care for nite behaviors of N including deadlocks.
Therefore, Petri net N is extended to Petri net N! which is made deadlock-free by adding a visible
dummy transition nop (no operation) in Fig. 15.

nop

Figure 15.

nop (no operation)

It will be shown how to verify whether a given concurrent program (N! ) meets a given speci cation(f ). We assume that all transition are visible and atomic propositions of f are identi ed with transitions.
In this case, a labeling function to map transition to atomic propositions is an identity function e. To
verify that the program meets the speci cations, it suces to check Ls (f )  L! (N! ; e), which means
each of all possible computations in Petri net N! is a model of PLTL formula f .
De nition 14 A deadlock-free Petri net N! satis es the temporal logic speci cation f with the single
event condition i Ls (f )  L! (N! ; e). Deciding whether N! satis es f is called a veri cation problem.
Theorem 3 The veri cation problem is decidable.

Proof. From Chapter 2 Lemma 2, the veri cation problem (Ls(f )  L! (N! ; e)) can be reduced to theemptiness problem (Ls (:f ) \ L! (N! ; e) = L(N! ; :f; e) = ;). Therefore, it is decidable from Theorem.

It will now be made clear what the inputs and outputs of this veri cation are:
INPUT: Concurrent program structure (represented by Petri net N! ).
INPUT: Speci cation (represented by temporal logic f ),OUTPUT: Yes / No,
where "yes" means that the program satis es the speci cations, and "no" means it does not.
It is signi cant to analyze what is possible and what is not in this veri cation method as follows:

What is possible to verify
 Mutual exclusion

ex. Intervals [t1 ; t2 ] and [t3 ; t4 ] between two transitions do not overlap each other:2(t1  (:(t3 _ t1 ) U t2 )) ^ 2(t3  (:(t1 _ t3 ) U t4 ))

Note: Though we cannot directly specify tokens of places, in the case of Fig. 16(a) an interval [t1 ; t2 ]can specify that place p has a token in the interval.
 Partial ordering among transition ringex. Transitions t1 and t2 re in turn: Firing prohibition

2(t1  (:t1 U t2 )) ^ 2(t2  (:t2 U t1 ))ex. Once t1 res, t2 will never re.

2(t1  2:t2 )Chapter 4: Speci cation, Veri cation, and Synthesis46

 Deadlock inevitability

ex. Transition t will eventually fall into deadlock.

}2:t Boundedness and safeness property It can be veri ed by introducing dummy transitions. ex. }2:d
to verify whether place p is bounded in Petri net with a dummy transition d (Fig. 16(b))
p
t1

p

t2

d
(a) Existence of a token

Figure 16.

(b) Verification of boundedness

What is Possible to Verify

What is impossible to verify
 Number of tokens

It is impossible to generally verify the number of tokens in places, which could be used to specify
reachability property.
 Possibility of deadlock (liveness property)
This arises from the introduction of nop.
Consideration for complexity gives a clear interpretation to these possibility and impossibility ofveri cation. When PLTL formula is small enough compared with Petri net (in fact all example formulas
mentioned above are small), complexity of our veri cation method has the almost same order as thecoverability problem. Therefore, our method cannot verify in itself the reachability problem and livenessproperty, of which complexity is far larger than the coverability problem.

Veri cation Example As a simple example, verifying a concurrent program, let's consider a mutual

exclusion problem containing unbounded bu ers. A target Petri net N! is illustrated in Fig. 17, whereplaces p4 and p5 are unbounded bu ers (this Petri net is deadlock free itself, therefore we ignore nop
for a simple explanation). Speci cation f is given such that intervals [t1 ; t2 ] and [t3 ; t4 ] satisfy a mutual
exclusion condition, as follows:f def= 2(t1  (:t3 U t2 )) ^ 2(t3  (:t1 U t4 ))Buchi sequential automaton A:f = (ft1 ; t2 ; t3 ; t4 g; fs0; s1 ; s2 ; s3 g; ; s0 ; fs3g) is shown in Fig. 18. The
extended coverability graph G can be generated from A:f and N! (Fig. 19). In G, no designated node
exists. That means L(N! ; :f; e) = ; from Theorem 1. We conclude N! satis es f .

3 Concurrent Program Synthesis
It is not easy for an ordinary programmer to realize a correct synchronization in concurrent programs,
and it requires tremendous debugging e orts. This section provides a method to synthesize a concurrent
program automatically with reusable components by program tuning. The goal programs are synthesized
to satisfy the given speci cation by tuning up reused programs that are represented by Petri nets. We
also emphasize that our method adopts a compositional way to synthesize. It is necessary for two reasons:Chapter 4: Speci cation, Veri cation, and Synthesis

47

p1
t3

t1

p3

p6
p2

t2

t4
t5
p5

p4

Figure 17.

N! : Mutual Exclusion with an unbounded bu er

t1,t2,t3,t4
t3

s1
t1

s1
t1

t2,t3

s2

t3

s3

t4,t1

t1,t2,t3,t4

A:f

Figure 18.

t1

100000 s0 0011000 s2 0

t1011000 s0 0t2

Ø00 s2 0 t1

Ø00 s0 0

011

100

t1

Ø00 s0 0

011

t5

t5

ØØ0 s0 0

t2

t5

t1

ØØ0 s0 0

t1

t4
1 s0 0

t3

100

011

t2

t3
010

t5

ØØ

ØØ0 s2 0t5011

ØØ0 s1 0010

t5

Figure 19.

G: Extended Coverability Graph

Chapter 4: Speci cation, Veri cation, and Synthesis48

 Reusable software itself is composed compositionally in ordinary software, and global synthesis of a large-scale program requires huge, and therefore impractical, computing power.
The model building techniques in Theorem 2 are used in this synthesis method.

3.1 Composition of Petri Nets

We also introduce a composition operator "jL" which plays an important role in the synthesis method.

De nition 15 (Composition of labeled Petri nets) For given labeled Petri nets LN1 = (N1 ; h1 ), LN2 =(N2 ; h2 ), and a given label set L   where N1 = (P1 ; T1 ; w1 ; m01 ), N2 = (P2 ; T2 ; w2 ; m02 ), P1 \ P2 = ;,and T1 \ T2 = ;, a labeled Petri net (N; h) = LN1 jL LN2, which is called a composition of LN1 and
LN2 with L, is de ned as follows.
N = (P; T; w; m0 ), where P = P1 [ P2 ,
 T = T10 [ T20 [ T 0 such that
{ T10 = ft 2 T1jh1(t) 62 Lg,{ T20 = ft 2 T2jh2(t) 62 Lg,{ T 0 = ftij j h1(ti ) = h2(tj ) 2 Lg, w(p; t) =8
< w1 (p; t) for t 2 T10t) for t 2 T20: ww21 ((p;p; ti ) + w2 (p; tj ) for t = tij 2 T 0
w(t; p) is also de ned similarly,
 m0 (p) = m01 (p) + m02 (p) for all p 2 P .
Example 4 We show an example of a composition (N1 ; h1 ) jL (N2 ; h2 ) in Fig. 20. In this example,
h1 (t1 ) = b; h2(t4 ) = c; h1 (t2 ) = h2 (t3 ) = a, and L = fag.

b
t1

a
t2

(N1,h1)

a
t3

c
t4

(N2,h2)

Figure 20.

b

a

t1

t23

(N1,h1)ct4

L (N2,h2)Composition of Petri Nets

Lemma 4 Let LN , LN1 ,LN2 be labeled Petri nets and L   be a set of labels. When LN = LN1 jL
LN2 , L(LN )=L = L(LN1)=L \ L(LN2 )=L, L! (LN )=L = L! (LN1)=L \ L! (LN2 )=L, and L! (LN )=L 
L! (LN1 )=L \ L! (LN2)=L. Here, L(LN ) represents L(N; h) such that LN = (N; h).

Proof. L(LN )=L = L(LN1)=L \ L(LN2)=L and L! (LN )=L = L! (LN1)=L \ L! (LN2 )=L are clear.
We prove L! (LN )=L  L! (LN1)=L \ L! (LN2 )=L by showing a example  2 L! (LN )=L and 62 L! (LN1 )=L \ L! (LN2 )=L (Fig.21). In LN = LN1 jfc1 ;c2g LN2, a ring sequence  = t1 t5 falls
into deadlock. Therefore, h() = ! 2 L! (LN )=L, but h() 62 L! (LN1 )=L \ L! (LN2)=L.

Chapter 4: Speci cation, Veri cation, and Synthesis

49

LN1

LN2

a1

a2

c1

b1

c2

b2

c1

c2

{c1,c2}

LN
t1/a1

t2/a2

t3/c1

Figure 21.

t5/b2

t4/b1

t6/c2

Counter Example of L! (LN )=L = L! (LN1 )=L \ L! (LN2 )=L

3.2 Petri Net Synthesis

De nition 16 Lfair
! (N; h)  L! (N; h) is de ned as
def
!
 !
Lfair
! (N; h) = fh() 2  [   j  2 F! (N ) under the visibility-fairness conditiong

where the visibility-fairness condition means whenever some visible transitions are in nitely enabled, thenone of them will eventually re. Here, L! (N; h)  Lfair
! (N; h)De nition 17 A Petri net N = (P; T; w; m0 ) is deadlock-free i there is at least one enabled transition forevery reachable marking. A labeled Petri net (N; h) is visibility-starvation-free i Lfair
! (N; h) = L! (N; h),that is, there is no in nite loop of invisible transitions (which looks like deadlock for the outside) underthe visibility-fairness condition.
Now, we will show how to synthesize a new Petri net which satis es temporal logic speci cations
and is deadlock-free and visibility-starvation-free, by tuning up the original net (i.e. adding some places,transitions, and arcs to the original net).

Theorem 4 (Petri Net Synthesis) If 0 c! 2 L! (N; h), a labeled Petri net (N 0 ; h0 ) can be constructedby adding some places, transitions, and arcs to N such that N 0 is deadlock-free, (N 0 ; h0 ) is visibilitystarvation-free, and L! (N 0 ; h0 ) = 0 c! .

Proof. It is easy to construct a labeled Petri net (Ns ; e) such that L(Ns; e) = fs0 sc g. Then, make acomposed Petri net (Nc ; hc) = (N; h) j (Ns ; e). Here, L! (Nc ; hc ) = L! (N; h) \ L! (Ns ; e) = fs0 s!c g from

Lemma 4. Finally, we can construct (N 0 ; h0 ) by tuning up (Nc ; hc ) according to the Valk and Jantzen's
tuning method [Valk 85] (cf. Appendix I) such that N 0 is deadlock-free, and Lfair
! (N 0 ; h0 ) = L! (N 0 ; h0 ) =!
s0 sc .

Corollary 1 Let (N; h) be a labeled Petri net and f be a PLTL formula. If L(N; f; h) 6= ;, a labeled
Petri net (N 0 ; h) can be constructed by adding some places, transitions, and arcs to N such that N 0 isdeadlock free, (N 0 ; h0 ) is visibility-starvation-free, and Lfair
! (N 0 ; h0 )  L(N; f; h)  Ls (f ).
From now on, we abbreviate fi(t) to just t for simplicity. In this case, a labeling function h of d-type
forms h = e=L where L is a set of visible transitions (i.e. atomic propositions).

Chapter 4: Speci cation, Veri cation, and Synthesis

50

Example 5 (Petri Net Synthesis) A Petri net N is given in Fig. 22(a), and h = e=ft0; t1 ; t2 g is a labeling
function of N . And 0 c! 2 L! (N; h) is given where 0 = t0 and c = t1 t2 . First, N is constructed(Fig. 22(b)) such that L(N ; e) = f0 c g. Then, (Nc ; h) = (N; h) j (N; e) is composed (Fig. 22(c)).
00!
0Finally, N 0 is constructed as shown in Fig. 22(d). Here, Lfair
! (N ; h) = L! (N ; h) = f0 c g, and N is
tuned up to be deadlock-free while Nc is not.

È

(b) N

(a) N

t0

t2

t3

t0

t1

t1

(c) Nc

t2

(d)N’

t2

t1

t3

t1
2
t3

t0

Figure 22.

t2

t0

Example of Petri Net Synthesis

3.3 Concurrent Program Structure

It is assumed that a target program consists of one controller (main controller) and several agents (device
controller) which control devices locally. While the controller controls each agent sequentially, the agent is
independent from other agents and they can run concurrently with each other. This structure (hierarchicalsynchronization supervisor, ref. Chapter 3) is very natural in some domains, such as robot control systems
and plant control systems. An example (Example 6) is shown in Fig. 23.
The controller and the agent i communicate with each other by a set of synchronous communication
channels Ci , like CCS [Milner 89]. It is assumed that a raw controller and raw agents have already been
constructed from reusable software components up to this step. Here, the raw controller is represented
by Petri net Nc = (Pc ; Tc; wc ; mc0 ), and the raw agent i is represent by Nai = (Pai ; Tai ; wai ; mai0 ).
Communication channels Ci between Nc and Nai are de ned as Ci = fhi (t) 2 Tc j t 2 Tai g wherehi : Tai ! Tc [ f"g is a labeling function (called "channel function") to connect Nai 's transitions with
Nc 's transitions. If t 2 Tai and hi (t) = ", t is a internal and invisible transition which is not connectedwith Tc. In case of Example 6, a controller and an agent may be represented as shown in Fig. 24, andchannel functions are de ned as hi (start) = starti , hi (end) = endi , hi (overflow) = " for each i.

Chapter 4: Speci cation, Veri cation, and Synthesis

51

Controller
start1start2
end1

end2

Agent

Agent

devicedeviceFigure 23.

start1

Concurrent Program Structure

start2start
2
3
overflow

end1

end2

Controller

Figure 24.

end
Agent

Original Controller and Agents

Chapter 4: Speci cation, Veri cation, and Synthesis

52

3.4 Temporal Logic Speci cation

The user speci es several constraints by a PLTL formula f with a set of atomic propositions Prop  Tc
so that the controller satis es f cooperating with all agents.

Example 6 Prop = Tc = fstart1 ; end1 ; start2 ; end2 g
 f = 2(start1  (:start2 U end1 )) ^ 2(start2  (:start1 U end2 ))The formula f above means that once Agent 1 starts, Agent 2 never starts until Agent 1 ends. Also

when Agent 2 starts, Agent 1 never starts until Agent 2 ends.
Here, a concurrent program synthesis means to tune up reusable components to satisfy this speci cation (constraint). To start with, it is made clear what the inputs and outputs are:

INPUT: Speci cation f (written by PLTL)INPUT: Reused Programs

One raw Controller and several raw Agents and Channels (represented by Petri nets Nc ; Na1 ; Na2 ; :::; Nak ,and channel functions h1 ; h2 ; :::; hk )OUTPUT: Synthesized Programs
One Controller and several Agents and Channels (represented by Petri nets Nc0 ; Na0 1 ; Na0 2 ; :::; Na0 k ,and channel functions h01 ; h02 ; :::; h0k )The proposed program synthesis method consists of two procedures. First, we show the controller
synthesis procedure and then the agent synthesis procedure.

3.5 Controller Synthesis

This controller synthesis procedure consists of the following four steps:
Step 1: Each Petri net Nai of agent i is reduced as far as possible [Lee 85] into Nari such that L! (Nai ; h1) =L! (Nari ; h1 ).
Step 2: Make a composed Petri net (N; h) = (Nc; e) jC1 (Nar1 ; h1) jC2 ::: jCk (Nark ; hk ) . We abbreviate this composition to Sync(Nc; Nar1 ; Nar2 ; :::; Nark ; h1; h2 ; :::; hk ), since it means synchronization ofProcesses with channels.
Step 3: Construct an in nite ring sequence  = 0 c! on N such that h=Prop(0 c! ) 2 L(N; f; h=Prop)
from Theorem 2.
Step 4: Construct a deterministic Petri net Nc0 such that L(Nc0 ; e) = f0c =Tcg.
Nc0 is a Petri net of the synthesized controller, that is a deterministic sequential program. In caseof Example 6, Nc0 is synthesized from a transition sequence  = (start1 end1 start2 end2 )! which satis es
speci cation f , as shown in Fig. 25.

3.6 Agent Synthesis

For each agent, we can construct a tuned agent Petri net Na0 i = (Pa0 i ; Ta0 i ; wa0 i ; m0ai 0 ) and a labeling
function h0i : Ta0 i ! Ci from Nari , and 0 c! such that Na0 i is deadlock-free, (Na0 i ; h0i ) is visibility-starvationfree, and L! (Na0 i ; h0i ) = f0 c! =Ci g, using Theorem 4. Fig. 26 shows a composition (Nari ; hi ) jci (N ; e)where L! (N ; e) = f(starti endi ) g, and a synthesized agent in Example 6.
Note that the synthesized controller is a deterministic sequential program while the tuned agentscan be nondeterministic concurrent programs. Here, we must assume the visibility-fairness condition foreach agent. After all, the controller Nc0 and the agents Na0 i can run concurrently with synchronous communication by channels, of which structure is represented by Sync(Nc0 ; Na0 1 ; Na0 2 ; :::; Na0 k ; h01 ; h02 ; :::; h0k ).
The following theory assures that this composed concurrent program satis es a given temporal logic
speci cation.

Chapter 4: Speci cation, Veri cation, and Synthesis

53

start1start2

end1

end2

Figure 25.

Synthesized Controller Nc0

start
2

start
overflow2

3
3

overflow4

end
overflow
Composition

end
Synthesized Agent

Figure 26.

Composition (Nari ; hi ) jci (N ; e) and Synthesized Agents Na0 i

Chapter 4: Speci cation, Veri cation, and Synthesis

54

Theorem 5 If labeled Petri nets (Nc0 ; e); (Na0 1 ; h01 ); (Na0 2 ; h02 ); :::; (Na0 k ; h0k ) are synthesized from Petri nets
Nc ; Na1 ; Na2 ; :::; Nak , channel functions h1 ; h2 ; :::; hk , and a PLTL formula f with a set of atomic propo-

sitions Prop, according to the above synthesis method, then
 a composed labeled Petri net (N 0 ; h0 ) = Sync(Nc0 ; Na0 1 ; Na0 2 ; :::; Na0 k ; h01 ; h02 ; :::; h0k ) is deadlock free, (N 0 ; h0 ) is visibility-starvation-free, and L! (N 0 ; h0 =Prop)  L(N; f; h=Prop)  Ls (f ), under the visibility-fairness condition
where (N; h) = Sync(Nc0 ; Na0 1 ; Na0 2 ; :::; Na0 k ; h01 ; h02 ; :::; h0k ).

Proof. It is followed from our method utilizing previous theorems.
The main drawback in this synthesis is that a synthesized controller is deterministic. The controller
is serialized by a deterministic ring sequence, while agents are non-deterministic and run concurrently
with each other. However, when expanding a deterministic one to nondeterministic one that looks morenatural, it is indispensable to consider invisible transition of each agent, which requires other information
besides given communication channels. Therefore, non-deterministic controller synthesis has danger ofdecreasing concurrency of a synthesized program.

4 Related Works
We compare our veri cation and synthesis methods with related works.

Veri cation: One of common goals of other works [Cherkasova 87, Howell 88, Suzuki 89] is to uniformly

specify most Petri net properties with temporal logic. Therefore its decision procedure inevitably falls
into undecidable or costs more than the reachability problem. Complexity more than the reachability
problem is out of the practical veri cation. Our method's complexity is almost equal to the coverability
problem because of abandoning some veri cation properties, such as deadlock possibility. However, ourmethod still provides more special properties, such as analysis of partial ordering among transition ringand mutual exclusion, which can not be covered by the traditional analysis. These abilities are e ective
for the concurrent program veri cation. Our method is not all-around but can complement the traditional
analysis.
On the other hand, if we would restrict the Petri net into a bounded one, the veri cation becomes simpler [Uchihira 90a, Katai 82]. However, an unbounded bu er is sometimes necessary to specify ordinary
concurrent programs. It might be possible to assume a large enough bounded bu er in real programs.
A bounded Petri net with a large bounded bu er usually produces a larger coverability graph than onesof unbounded Petri nets. Recently, several ecient veri cation methods based on temporal logic model
checking for bounded Petri nets have been proposed. They can be classi ed into two types; symbolicmodel checking [Hiraishi 95] and partial order method [Yoneda 93]. In particular, Yoneda et. al. proposed an ecient model checking method based on partial order for one-safe time Petri nets [Yoneda 93].
It would be a future promising approach to apply techniques of symbolic model checking and partial
order method to unbounded Petri nets.

Synthesis: We think the software-reuse-based program synthesis is highly practical. Our method di ers
from other synthesis methods [Manna 84, Clarke 82] that also use temporal logic speci cations, in regard
to the point of utilizing software reuse. Another signi cant feature is to relax the automatic synthesis
for only nite-state programs [Manna 84, Clarke 82] to in nite-state programs, such as a Petri net. Our
method has the same approach as that of Valk and Jantzen [Valk 85] in point of tuning up existing
programs (reusable software) satisfying the given speci cations. However, our method has the following
characteristic features:
 the speci cation is described with temporal logic, and the program synthesis method consists of two phases; controller synthesis and agent synthesis.

Chapter 4: Speci cation, Veri cation, and Synthesis

55

5 SummaryThis chapter considers the fusion of unbounded Petri nets and temporal logic as a speci cation language
for reactive and concurrent systems. We propose a version of the fusion and prove that the emptinessproblem is decidable in this version. Then, veri cation and synthesis for reactive and concurrent systems
are discussed based on these results. In this chapter,(1) we de ne the class combining Petri nets and temporal logic which is decidable,(2) the decision procedure for this class is applied to concurrent program veri cation, and(3) a two phase synthesis method is provided which modi es reusable components to satisfy a specication.
This research was carried out to establish veri cation and synthesis for unbounded Petri nets andtemporal logic. Ecient veri cation and synthesis for bounded Petri nets (i.e., transition systems) andtemporal logic will be described in the subsequent chapters.

Appendix I
Results of Valk and Jantzen's method are brie y summarized. See the original paper [Valk 85] for proofs.

De nition 18
 N = (P; T; w; m0 ) is a Petri net.

 A marking m is T'-continual for some subset T' of T, i there is an in nite legal ring sequence
from m which contains all t 2 T 0 in nitely often.
 CONTINUAL(T 0) def= fm j m is T'-continualg.
 N is a set of non negative integers. Let K  N k , then the residue set of K , written res(K ), is asmallest subset of K which satis es res(K ) + N k = K + N k .

Theorem 6
 res(CONTINUAL(T 0)) is nite and can be e ectively constructed.
 Using res(CONTINUAL(T 0)), we can construct a new Petri net N 0 whose all reachable markings
are lying in CONTINUAL(T 0) with the same number of places of N , but possibly additionaltransitions and arcs.

Chapter 5

Compositional Veri cation Using
Modal Logic
This chapter proposes PQL (Process Query Language) and the compositional veri cation method ofreactive and concurrent systems using PQL. Our compositional approach is e ective to ease the state
explosion problem in the veri cation.

1 Background and Motivation
Temporal logic model-checking method [Clarke 86] is very useful for veri cation of reactive and concurrent
systems. However, a major drawback to using this method is that as the scale of the programs increase,the computation costs for veri cation increase exponentially. An e ective solution for this problem iscompositional veri cation.
This chapter focuses on the compositional veri cation for nite state transition systems instead ofPetri nets because of the following reasons.
 In general a compositional veri cation for in nite systems [Winskel 90] is restricted and dicult toapply to practical systems.
 Many practical reactive and concurrent systems can be modeled as nite state transition systems(with approximation).
Compositional veri cation for transition systems is formalized as process reduction in which the bisimulation equivalence of concurrent programs is used to extract from each system component (subprocess)only these abstract information necessary to verify each given query, thereby avoiding an explosion incost.
In this chapter, PQL (Process Query Language) is proposed as an improved method in the solutionof this problem. PQL is based on modal logic which is the union of temporal logic and process logic.
Then, this chapter proposed the compositional veri cation method by using PQL with consideration of
the divergence by internal transitions.We have applied this method to program veri cation of sequencecontrol systems.

1.1 Background

Since the framework of reactive and concurrent systems often can be expressed with transition systems,veri cation methods based on temporal logic, process logic, CCS, ACP are well investigated [CAV 89,
Beaten 90]. For example we have developed an automatic veri cation system (PTSV: Practical Temporal
Speci cation and Veri cation tool) [Uchihira 89a] which is based on model-checking of CTL (Computation
Tree Logic) [Clarke 86], and apply it to manufacturing systems.
The veri cation method based on model-checking can be summarized as follows. First, a at andglobal nite-sate graph is generated, which expresses all possible behaviors of the target program. For
example, when the target program consists of several processes, a at and global nite-sate graph is
generated by process composition based on interleaving semantics. Next, veri cation of whether given
56

Chapter 5: Compositional Veri cation57

temporal logic queries are satis ed is performed by tracing all the states of the graph. However, thisveri cation method has the following problems.
(1) State explosion problem
A generated global nite-state graph often becomes excessively large.
(2) Lack of expression ability about \actions"
CTL can express only queries about \states" and \state attributes".
One of the promising approaches for the problem (1) is compositional veri cation [Mishra 85, Clarke 89,
Stirling 89b]%Compositional veri cation is de ned as follows in this thesis 9 .
Compositional veri cation is a method for generating a local and minimum nite-state graphcompositionally for each veri cation query and verifying it, instead of generating and verifying
a global and huge graph.

Here, a local and minimum nite-state graph means a graph in which only necessary information to
verify a given query is kept and the rest is reduced. Because this compositional veri cation method does
not generate the global graph directly, the state explosion problem can be e ectively eased.
Based on this idea, Mishra and Clarke applied the hierarchical veri cation method by CTL for verifying asynchronous circuits [Mishra 85]. However, this method has some limits for expressive power ofveri cation queries and is not a sophisticated and general method. Also, Clarke, Long and MacMillan
proposed a compositional veri cation method which introduced the compositional framework of CCS[Milner 89] (i.e., process composition and observation equivalence) for CTL model-checking. While CTL
is a logic concerning \states" (state attributes), CCS is a calculus concerning \actions". Therefore, thepoint is how to handle \states" and \actions" in the same frame. This is also the solution for the problem(2). However, Clarke's veri cation method [Clarke 89] could not express \states" and \actions" freely
mixed with each other. On the other hand, researches have been undertaken to characterize CCS expressions by process logic (ex. Hennessy-Milner Logic : HML) [Hennessy 85a, Hennessy 85b]. Furthermore,
new logics, which combine temporal logic and process logic, have been investigated. These logics can
express \states" and \actions" freely mixed with each other, and yet cope with compositional framework.
They, therefore, are promising as query language for compositional veri cation. An example is Stirling's
General Temporal Logic (GTL) [Stirling 89a, Stirling 89b]. GTL is a general logic which combines temporal logics (linear-time temporal logic and branching-time temporal logic) and process logic (HML). And
further, Stirling and Walker proposed the compositional veri cation method by GTL [Stirling 89b].

1.2 Motivation

The point of compositional veri cation is to reduce (localize, minimize) the global state graph, leaving only essential information for each veri cation query. In the compositional veri cation by GTL,
this information is formalized by observation equivalence [Milner 89] . Whenever the reduced graph isobservation-equivalent to the original graph, it is assured that the reduction has no in uence on theveri cation results, that is, it preserves the same results for every veri cation query.
However, the compositional veri cation method based on observation equivalence has one problem.
In observation equivalence, any divergence is ignored. The divergence [Milner 81, Walker 90] means anin nite cycle (loop) of internal and unobservable transitions (i.e.,  -actions) which cannot be observed
and then looks like deadlock for an observer (we call it an external deadlock). This occurs due to thefact that a certain fairness is assumed for internal and unobservable transitions (i.e., if there is at least
one observable and executable action, there will not be an external deadlock by divergence). In the caseof compositional veri cation, to make the transition observable or not will be decided by whether it isnecessary for a given veri cation query or not. Therefore, if a di erence in fairness exists depending upon
the given veri cation query, a problem arises.
For instance, in the transition system Ta shown in Fig. 27, the answer will be NO for a query: \Doesthe system eventually reach the end state for all paths" because there exists a path with an in nite loop ofb which never reaches the end state. On the other hand, the answer will be Y ES if b is unobservable. The
reason is that Ta is recognized to be equivalent to Tb of Fig. 27 according to observation equivalence if b isunobservable (i.e.,  -action). However, it is a problem from the standpoint of compositional veri cation.
9 The formal de nition and survey of compositional veri cation are described in detail in Section 6.1.

Chapter 5: Compositional Veri cation

58

start

start
b

a

c

start
a

a

a

c

c
end

end

Ta

Tb

Figure 27.

b

b

end
Tc

Transition systems with/without divergence

The existence of a path, which has an in nite loop of b and never reaches the end state, must be recognized
regardless of observability of the action b.
In order to introduce expressive power of recognizing divergence into logics, Intuitionistic HML(IHML) [Stirling 87] has been proposed. Furthermore, Stirling suggested (but not with any concrete
proposal) the possibility of adding the IHML feature to GTL and expanding it (GTL + IHML). But even
if this \GTL + IHML" can be realized, there still remains the same problem. That is, the equivalence
theory (equivalence based on partial bisimulation preorder) [Stirling 87], which IHML is based on, maysometimes produce recognition (abstraction from the observer's point of view) which does not agree withintuition, depending upon which action will be made observable.
In the case of Ta and Tc in Fig. 27, if b is not observable, divergence occurs in both transition systems,
and Ta and Tc are equivalent from the equivalence theory of IHML. This equivalence is derived fromthe observation that both transition systems cannot take action c after action a in some path. However,a problem arises for the query: \Is there a state in which the system cannot take action c in all paths
after action a." Intuitively, the answer should be NO for Ta and Y ES for Tc, regardless of whether b
is observable or not. It is natural to be able to di erentiate between these two cases. The equivalence
theory of IHML, which considers both Ta and Tc to be equivalent, will cause a loss of the necessary
information to verify the query. In other words, the compositional veri cation of GTL + IHML reduces
Tc into Ta according to its equivalence theory, thereby creating stronger abstraction than necessary.
From these points of argument, it can be concluded that the usual equivalence theories (observationequivalence, equivalence by partial bisimulation preorder) which the usual modal logics (HML$GTL$
GTL + IHML, etc.) based on, is aimed at equivalence relation from the viewpoint of the external
processes as observers and therefore, it is not appropriate to apply directly these equivalence relations
for compositional veri cation because of creating stronger abstraction than necessary. In compositionalveri cation, \not observed" simply means \not paid attention" instead of \not synchronized". Therefore,
even if a certain action is made unobservable, its existence must be preserved.

1.3 Overview of Main Results

In this chapter, we propose Process Query Language (PQL) for compositional veri cation in order tosolve the problem described above. PQL can clearly express and easily handle the cycles of unobservableactions, taking a di erent approach from GTL + HML. The unique feature of PQL is the followings.

 PQL is be able to uniformly express both temporal logic properties and the existence of cycles ofunobservable actions using the maximum/minimum xed point operators.
 Constraints about state attributes and actions can be expressed in the uniformed and exible way.
 PQL provides several useful macros including the regular expression.
 PQL model-checking is decidable and has the ecient decision procedure. Furthermore, PQL has a
new process equivalence relation (!-bisimulation equivalence) which is used for the compositionalveri cation. That is, if two transition systems (original one and reduced one) are equivalent, it isassured that every PQL query has the same answer.

Chapter 5: Compositional Veri cation

59

1.4 Organization of the Chapter

The remainder of this chapter is organized as follows. Section 2 de nes concurrent programs usingtransition systems and their equivalence relation (extended bisimulation equivalence). In Section 3, PQL
is de ned and it is shown that the discrimination ability of PQL is the same as the extended bisimulationequivalence. This means that even if the given concurrent program is reduced to a smaller equivalent
program, veri cation results of PQL will be preserved. A compositional veri cation method using theresult obtained in Section 3 is proposed and its e ectiveness is demonstrated by means of experimental
results in Section 4. In Section 5, we consider how to apply this method to actual reactive and concurrent
systems. We introduce an application to chemical plant control systems by example. Section 6 mentions
related works in which other compositional veri cation methods and a partial order method are surveyed
and compared with our method.

2 Representation of Concurrent Programs
Concurrent programs are constructed from some number of processes. The program and each process
are as transition systems T = (S; P; A; ; ; s0 ) [Arnold 92], which have been de ned in Chapter 2.
Here, we assume that S , P , and A are nite sets for the automatic veri cation. In this case, the nitebranching condition holds.

2.1 Equivalence of Transition Systems for Compositional Veri cation

We introduce a new bisimulation equivalence of transition systems (!-bisimulation equivalence), which
is an extension of Milner's weak bisimulation equivalence [Park 81, Milner 89] in order to recognize  cycles. First, (weak) bisimulation used in CCS is de ned for (S; Act; ).

De nition 19 (bisimulation)
For (S; Act; ), a binary relation R  S  S is (weak) bisimulation if 8(s; t) 2 R implies

 8a 2 Act:8s0 2 S:(if s !a s0 then 9t0 2 S:t )a^ t0 ^ s0 Rt0 ) 8a 2 Act:8t0 2 S:(if t !a t0 then 9s0 2 S:s )a^ s0 ^ s0 Rt0 )The  -cycles cannot be recognized in bisimulation. Therefore, we introduce !-bisimulation which
can do.

De nition 20 (!-divergence)
For (S; Act; ) and s 2 S , )n s0
s " def= 8n > 0:9s0 2 S:s(!

De nition 21 (!-bisimulation)
For (S; Act; ), a binary relation R  S  S is !-bisimulation if 8(s; t) 2 R implies
 8a 2 Act:8s0 2 S:(if s !a s0 then 9t0 2 S:t )a^ t0 ^ s0 Rt0 ) 8a 2 Act:8t0 2 S:(if t !a t0 then 9s0 2 S:s )a^ s0 ^ s0 Rt0 ) s" i t"

Furthermore, !-bisimulation is introduced for (S; Act; ; P; ) where state attributes P and aboolean function  is added to (S; Act; ) in order to take the equivalence of state attributes into consideration.

De nition 22 (!-bisimulation)
For (S; Act; ), a binary relation R  S  S is !-bisimulation if 8(s; t) 2 R implies (s) = (t)

 8a 2 Act:8s0 2 S:(if s !a s0 then 9t0 2 S:t )a^ t0 ^ s0 Rt0 )Chapter 5: Compositional Veri cation60

 8a 2 Act:8t0 2 S:(if t !a t0 then 9s0 2 S:s )a^ s0 ^ s0 Rt0 ) s" i t"
De nition 23 (;  ! ;  ! )In (S; Act; ; P; ), for s1 ; s2 2 S $if there exists bisimulation such that (s1 ; s2 ) 2 R, then we denotes1  s2 . s1 ! s2 and s1 ! s2 are de ned in the same manner.
Theorem 7 (Relation between ;  ! ;  ! )For every s1 ; s2 2 S in (S; Act; ; P; ), if s1 ! s2 , then s1 ! s2 , and if s1 ! s2 , then s1  s2 .
Proof. This is clear from the de nition. 2
Since s1  s2 is called bisimulation equivalence, s1 ! s2 is to be called \!-equivalence"%

De nition 24 (!-equivalence for Transition Systems)
For T1 = (S1 ; P; A; 1 ; 1 ; s01 ) and T2 = (S2 ; P; A; 2 ; 2 ; s02 ) (S1 \ S2 = ; is assumed), T1 and T2 is!-equivalence (denoted by T1 ! T2) if s01 ! s02 in (S1 [ S2 ; Act; 1 [ 2 ; P; 1 [ 2 )!-equivalence is the extended bisimulation equivalence which can handles !-divergence and state

attributes, and it has higher discrimination ability than the bisimulation equivalence.
For divergence, there are several researches by Milner[Milner 81], Stirling[Stirling 87], Walker[Walker 90].
However, their equivalence (T1 p T2 def= T1 v T2 ^ T2 v T1) based on partial bisimulation preorder (v)is weaker than !-equivalence. For example (shown in Fig. 27), when b is unobservable (i.e.  action),Ta  Tb and Ta 6! Tb , where  -cycle can be discriminated. Also, as Ta p Tc and Ta 6! Tc, theproblem pointed out in section 1 is solved.
Figure 28 shows the diagram of proper inclusions among several well-known equivalence relations and!-bisimulation equivalence. The arrow (!) means proper inclusion. For example, \!-bisimulationequivalence ! bisimulation equivalence" means \for every T1; T2 if T1 ! T2 then T1  T2 ". The detailde nitions of equivalence relations referred in this gure are shown in Appendix II.

' $&' $'% $' $& %& %' $
$
&
%
&% '
& %
PartialBisimulation Eq.
by Local Divergencep

Failure Eq.

f

PartialBisimulation Eq.
by Global Divergencegp

Trace Eq.

1

CO

kQ !-Bisimulation Eq.
!

XXXXX
y
XX

XXXX Bisimulation Eq.
Figure 28.

Comparison of equivalence relations

Chapter 5: Compositional Veri cation

61

2.2 Composition of Transition Systems

A concurrent program is composed of processes (transition systems) which run concurrently and communicate with each other by the handshaking-type synchronization mechanism. Here, operators (composition,relabeling) concerning the composition of transition systems is to be introduced. Also, it will be
proved that these operators preserve the !-equivalence.

Composition: T1 j T2

The transition system T = T1 j T2 , which is composed of T1 = (S1 ; P1 ; A1 ; 1 ; 1 ; s01 ) and T2 =(S2 ; P2 ; A2 ; 2 ; 2 ; s02 ) such that P1 \ P2 = ;, is de ned based on the interleaving semantics as follows:

T = (S1  S2 ; P1 [ P2 ; A1 [ A2 ; ; ; (s01 ; s02 ))where  : S1  S2 ! 2P1 [P2 is de ned as(s1 ; s2 ) = 1 (s1 ) [ 2 (s2 ) for all s1 2 S1 ; s2 2 S2 $
 : S1  S2  (A1 [ A2 [ f g) ! 2S1S2 is de ned as$

8 0f(s1 ; s2 ) j s01 2 1 (s1 ; a)g
if a 2 A1 ^ a 62 A2
>
>
>
0
0
>
f
(
s
;
s
)
j
s
2

(
s
;
a
)
g
if a 62 A1 ^ a 2 A2
< 1 2 2 2 2((s1 ; s2 ); a) = > f(s01 ; s02 ) j s01 2 1 (s1 ; a); s02 2 2 (s2 ; a)g if a 2 A1 ^ a 2 A2
0 0
0
0
>
>
>
: f(s1 ; s2 ) j (s1 (2s0 21 (s12 ;(s2);; s2); =s0 s=2 )_s1 )g if a = 
2
1.

Intuitively, T1 j T2 means a concurrent program in which T1 and T2 run concurrently and takesynchronous actions with the same labels, while T1 j T2 is formally de ned as the above transition system
T . In other words, T1 j T2 is equivalent to T based on the interleaving semantics.

relabeling: T [f ]For T = (S; P; A; ; ; s0 ) and a relabeling function f = (fA ; fP )suchthatfA : A [ f g ! 2A [f g(here, fA ( ) = f g), and fP : P ! P 0 [ ftrueg (here, fP (p) = true means it makes the state attribute p0

unobservable), the relabel-led transition system T 0 = T [f ] is de ned as follows:
T 0 = (S; P 0 ; A0 ; 0 ; 0 ; s0 )where 0 : S  (A0 [ f g) ! 2S is de ned as 0 (s; a0 ) = fs0 j s0 2 (s; a); a0 2 fA (a)g, and0 : S ! 2P [ftrueg is de ned as 0 (s) = fP ((s)).
0Intuitively, fA (a) = fa0 g and fP (p) = p0 means simply relabeling a to a0 and p to p0 , respectively.
fA (a) = fa1 ; a2 g means relabeling the original a to a1 and its replica to a2 after adding one more sametransition with the label a.
Now, the actions and state attributes of the transition system T can be changed by the relabeling
function f . This relabeling function is used to avoid overlapping of names of actions and state attributes
in the case that the program consists of several same processes (i.e. T 0 = T [f1] j T [f2]). Also, therelabeling function is used to make actions and state attributes of T unobservable (i.e. fA (a) = f g,
fP (p) = true)%
For convenience, this relabeling function fA can be denoted as follows:
0 ; :::l0 g=l1; :::; fl0 ; :::l0 g=ln]
[fl11
1k1
n1 nknThis denotes a function fA such that fA (li ) = fli01 ; :::lik0 i g for all i 2 f1; :::; ng. This applies to fP , too.

Theorem 8 (Preservation of !-equivalence)
If T11 ! T12 ; T21 ! T22 , then T11 j T21 ! T12 j T22 ; T11 [f ] ! T12[f ]Proof' This is obvious for relabeling. As for composition, as mentioned in Proposition 7.2 of [Milner 89],
it is easily shown that the following relation R is !-bisimulation:
R = f((s11 ; s21 ); (s12 ; s22 )) j s11 ! s12 ; s21 ! s22 ; s11 2 S11 ; s12 2 S12 ; s21 2 S21 ; s22 2 S22 g2

Chapter 5: Compositional Veri cation

62

3 Process Query Language
Process Query Language (PQL) is introduced which is used to describe queries in the compositionalveri cation for transition systems.
The unique features of PQL is: Constraints about state attributes and actions can be expressed in the uniformed exible way.
 Divergence by  -cycles can be explicitly expressed using the maximum/minimum xed point operators.
 Strong expression ability including the regular expression.

First, a modal logic SPQL (Strong Process Query Logic) is de ned, where  actions are observable,
and then PQL is de ned as a macro-language of SPQL where  actions are unobservable.

3.1 SPQL (Strong Process Query Logic)

SPQL is a modal logic which uni es temporal logic and process logic with xed point operators.

De nition 25 (SPQL formula)[Syntax]

P : a set of state attributes
A : a set of actions

SPQL formulas are recursively de ned as follows. Here, a free state variable is a state logical variablewhich is not bound by any xed point operator (-operator).

State Formula  A state logical variable Z is a state formula.
 p 2 P and true are state formulas.
 If f1 and f2 are state formulas, then f1 ^ f2 and :f1 are state formulas.
 If f is a state formula, and Z is a free state logical variable appearing in f , and negation

nesting of Z in f is even, then Z:f is a state formula.
 If g is a path formula, 9g is a state formula.
Path Formula  a 2 A is a path formula.
 If g1 and g2 are path formulas, then g1 ^ g2 and :g1 are path formulas.
 If f is a state formula, then Xf and Tf are path formula.
SPQL Formula  If a state formula f include no free state logical variables, then f is a SPQL
formula.

[Semantics]

A state satisfying an SPQL formula f is called a model of f . V [ f ] , a set of models of SPQL formula
f for a transition system T = (S; P; A; ; ; s0 ), will be de ned. Here, we assume the following notations.
 f : a state formula.
 g : a path formula.
 SF : a set of state formulas.
 PF : a set of path formulas.
 V [ f ]  S : a set of states satisfying f .
 R[ g]  S  S : a set of paths, whose length is 1 (i.e., edges), satisfying g.
 (Z:f1 )f2 : a state formula in which a free state logical variable Z in f1 is replaced with f2 .
 [ S 0 ] 1 : a virtual state formula f such that V [ f ] = S 0 (for example, [ ;] 1 = false; [ S ] 1 = true).

Chapter 5: Compositional Veri cation

63

V : SF ! 2S for a state formula f , which includes no free state logical variables, is de ned as follows:V [ p] = fs 2 S j p 2 (s)g
V [ 9g] = fs 2 S j 9(s; s0 ) 2 R[ g] )gV [ :f ] = S V [ f ]V [ f1 ^ f2 ] =TV [ f1 ] \ V [ f2 ]V [ Z:f ] = fS 0  S j V [ (Z:f )[[S 0 ] 1 ]  S 0 g
R : PF ! 2SS is de ned as follows:
R[ a] = f(s; s0)js !a s0 g
R[ :g] = (S  S ) R[ g]R[ g1 ^ g2]] = R[ g1 ] \ R[ g2 ]R[ Xf ] =f(s; s0 )j9a:(s !a s0 ^ a 6=  ^ s0 2 V [ f ] )g
R[ Tf ] =f(s; s0 )j9a:(s !a s0 ^ a =  ^ s0 2 V [ f ] )g
Also, the following convenient constants and operators are introduced.
 false def= :true f1 _ f2 def= :(:f1 ^ :f2 ) Z:f def= :Z 0 ::(Z:f )(:Z 0 )The intuitive meaning of each operator is shown as follows.

 ^(AND),_(OR); :(NOT).
 Xf : f will be true immediately after any action except  occurs.
 Tf : f will be true immediately after a  action occurs.
 9g : g is true on some path.
 Z:f :  is the minimum xed point operator.

Z:f : expresses the minimum xed point where a free state logical variable Z in f is recursively
bound with f itself.
For instance, Z:(f _ 9XZ ) means \on some paths, f will be eventually satis ed".
 Z:f :  is the maximum xed point operator.
For instance, Z:(f _ 9XZ ) means \on some paths, f will be eventually satis ed, or there
exists an in nite path (it cannot be decided by a nite path)".

The important properties of the minimum and maximum xed point operators of SPQL are statedin the following lemmas. Here, it is de ned that for x:y, (x:y)1 z def= (x:y)z and (x:y)k+1 z def=(x:y)(x:y)k z (k > 1).

Lemma 5 (Monotonicity)
S1  S2 ) V [ (Z:f )[[S1 ] 1 ]  V [ (Z:f )[[S2 ] 1 ]Proof:As the number of the negation nesting on Z in f is even, the monotonic property is clear by the de nitionof SPQL. 2

Chapter 5: Compositional Veri cation

64

Lemma 6 (Properties of minimum/maximum xed point operators)(1)V [ Z:f ] = klim
(S 0 :V [ (Z:f )[[S 0 ] 1 ] )k ;!1
= klim
V [ (Z:f )k false]!1
V [ Z:f ] = klim
(S 0 :V [ (Z:f )[[S 0 ] 1 ] )k S
!1
= klim
V [ (Z:f )k true]!1(2)
s 2 V [ Z:f ] () 9k:8h  k:s 2 V [ (Z:f )h false](3) If S is nite, for any f including  operators, there exists a formula f  of nite length f  including
no  operators such that V [ f ] = V [ f  ] .

Proof:(1) Let S k = (S 0 :V [ (Z:f )[[S 0 ] 1 ] )k ; = V [ (Z:f )k false] and S ! = limk!1 S k . According to themonotonicity,
8S 0  S:(V [ (Z:f )[[S 0 ] 1 ]  S 0 ) S !  S 0 ):Also, it is clear that
therefore,V [ (Z:f )[[S ! ] 1 ]  S ! ;\V [ Z:f ] = fS 0  S j V [ (Z:f )[[S 0 ] 1 ]  S 0 g = S ! :Same for V [ Z:f ] .
(2) Since ;  S 1  S 2     S ! ,s 2 S ! () 9k:8h  k:s 2 S h () 9k:8h  k:s 2 V [ (Z:f )h false] :(3) When S is nite, from (2)9k:(V [ Z:f ] = V [ (Z:f )k false] ):Therefore, there exists a formula f 0 , in which the most outer -type subformula Z:fsub of f issubstituted with (Z:fsub )k false, such that V [ f ] = V [ f 0 ] . By repeating this substitution operation
until there is not any more -type subformula, we can construct a formula f  including no 
operators such that V [ f ] = V [ f  ] .

2
De nition 26 (Model)
If s 2 S and s 2 V [ f ] , s is called a model of an SPQL formula f , and is denoted as s j= f . Similarly, if
s0 2 V [ f ] for a transition system T = (S; P; A; ; ; s0 ), T is a model of an SPQL formula f , and denoted
as T j= f .
Theorem 9 (Decidability of SPQL model checking)For any transition system T = (S; P; A; ; ; s0 ) and any SPQL formula f , if S is nite, there exists analgorithm which automatically decides whether T j= f .

Proof:

It is enough to show the algorithm which computes V [ Z:f ] and V [ Z:f ] . From lemma 6(1),[ Z:f ] = klim
(S 0 :V [ (Z:f )[[S 0 ] 1 ] )k ;:!1

Therefore, if S is nite, it is decidable since (S 0 :V [ (Z:f )[[S 0 ] 1 ] )k ; converges in a nite number k.
Same for V [ Z:f ] . 2
The ecient model checking algorithm for SPQL can be implemented by extending those for CTL[Clarke 86].

Chapter 5: Compositional Veri cation

65

3.2 PQL (Process Query Language)

PQL is de ned based on SPQL. In SPQL, the  action is assumed to be observable and it has to be
explicitly expressed in an SPQL formula like Tf . PQL is a language in which the  action is unobservable,
and therefore it is not necessary to express the  action explicitly in the formulas.

De nition 27 (PQL formula)[Syntax]

P : a set of state attributes.
A : a set of actions.

 A state logical variable Z is a state formula.
 p 2 P and true are state formulas.
 If f1 and f2 are state formulas, then f1 ^ f2 and :f1 are state formulas.
 If f is a state formula and a 2 A,  a + f;  a  f;  : + f;  :  f; + f;  fare state formulas.
 If f is a state formula, and Z is a free state logical variable appearing in f , and negation nesting of
Z in f is even, then Z:f is a state formula.
 If a state formula f include no free state logical variables, then f is a PQL formula.
The set of entire PQL formulas is denoted as LPQL.

[Semantics]

The PQL formula can be translated into an equivalent SPQL formula with the following rules. Therefore the semantics of a PQL formula is given as one of the translated SPQL formula.

 a f ,
Z1 :(9((a ^ X (Z2:(f _ 9TZ2))) _ TZ1))
  a + f ,Z1 :(9((a ^ X (Z2 :(f _ 9TZ2))) _ TZ1))
 : f ,
Z1 :(9(X (Z2 :(f _ 9TZ2)) _ TZ1))
  : + f ,Z1 :(9(X (Z2 :(f _ 9TZ2)) _ TZ1))  f , Z:(f _ 9TZ ) + f , Z:(f _ 9TZ ) Other PQL formulas are also SPQL formulas.

The intuitive meaning of each operator is shown as follows.
  a  f : After an action a, it is possible to become a state in which f is satis ed.
  a + f : After an action a, it is possible to become a state in which f is satis ed, or there is adivergence of the  -cycle.
When there exists a divergence of the  -cycle and it is impossible to become a state in which f issatis ed after an action a,  a  f is interpreted as false and  a + f is interpreted as true. In thelatter, the formula interpreted as true because the system never reaches a state in which f is unsatis ed
when it falls into the divergence.
For other PQL formulas,  :  f means 9a 2 A:  a  f ,  f means  "  f .
PQL has a stronger expression ability than one of CTL, that is, PQL can express anything which
CTL can. PQL can express various kinds of veri cation queries about actions and state attributes ofconcurrent programs from the temporal point of view. However, it cannot be said that PQL's readability
is excellent enough for practical use, so the following macro-operators are introduced for convenience.
Here, apat, apet, epat, and epet means 82, 8}, 92, and 9} of CTL temporal operators, respectively.
That is, a = \8(for all)", p =\path", e = \9 (exists)" , and t = \time".

Chapter 5: Compositional Veri cation66

 f1 _ f2 def= :(:f1 ^ :f2 ) (Z:f1 )f2 ( notation is allowed to be appear explicitly in PQL formulas) Z:f def= :Z 0 ::(Z:f )(:Z 0 ) [[a]]+ f def= :  a  :f [[a]] f def= :  a + :f
 [[:]]+ f def= :  :  :f [[:]] f def= :  : + :f
 [[ ]]+ f def= :  :f [[ ]] f def= : + :f
 apat f def= [[]]+ Z:(f ^ [[:]]+ Z )(f can always be true in all paths)
 apet f def= [[]]+ Z:(f _ ( :  true ^ [[:]]+ Z ))(f can eventually be true in all paths)
 epat f def=   Z:(f ^ ([[:]]+ false_  :  Z ))(f can always be true in some paths)

 epet f def=   Z:(f _  :  Z )(f can eventually be true in some paths)
 external deadlock def= [[:]]+ false(It looks deadlock from the observer, although the divergence may occur.)=  + false
 internal divergence def(The divergence exists which cannot be observed.)= [[:]]+ false ^ :  + false
 internal deadlock def(It is complete deadlock without divergence)

We show several examples of PQL formulas. We remark that PQL can express temporal properties
equivalent to th regular expression.

Example 7 Examples of veri cation queries by PQL(1) apat(epet  a  true)
Meaning: an action a is deadlock-free.
(2) Z1 :([[b]]+ false ^ [[c]]+ false ^ [[a]]+ (Z2 :([[a]]+ false ^ [[b]]+ Z2 ^ [[c]]+ Z1 )))Meaning: The sequence of actions a,b, and c are equivalent to th regular expression(ab c) ).
As one of the most important properties of PQL, it is proved that the discrimination ability of PQL
for transition systems is equal to that of !-equivalence. That is, the transition systems which are!-equivalent have the same results for any PQL veri cation queries. This property is necessary for thecompositional veri cation.

De nition 28 (P QL )T1 PQL T2 def= 8f 2 LPQL :(T1 j= f i T2 j= f )Chapter 5: Compositional Veri cation

67

Theorem 10 (Relationship between PQL and !-equivalence)

For any transition systems T1 and T2 ,Proof: Appendix 2

T1 ! T2 , T1 PQL T2

Example 8 Simple veri cation example by PQL

For three transition systems in Figure 27, when an action b is assumed to be unobservable (i.e. tau
action), veri cation (model checking) results for three PQL formulas are shown in th Table 5. In thistable, YES means the transition system is a model of the PQL formula, and NO means it is not. These
results show that there exist PQL formulas which can discriminate these three transition systems. It
supports that Ta 6! Tb , Ta 6! Tc , and Tb 6! Tc.
Table 5.

Simple Example of Veri cation Using PQL

PQL Formula

Ta

Tb

Tc

 a   c  true
YES YES YES[[a]]  c  true
NO YES NO
 a  :  c  true NO NO YES

4 Compositional Veri cation
The compositional veri cation method for concurrent programs, based on the result of Theorem 10, isshown here. First, the veri cation scope is introduced which is necessary for compositional veri cation,then the veri cation procedure is proposed.

4.1 Veri cation Scope

Generally, each of veri cation queries often may concern only a local properties of the target systems.
Therefore, we introduce a veri cation scope in order to explicitly state what potion of the program is
exclusively veri ed.
To be more speci c, the veri cation scope V S of a transition system T = (S; P; A; ; ; s0 ) is expressed
as V S = (P 0 ; A0 ), where P 0  P and A0  A are watched state attributes and actions in the veri cation.
Then a veri cation query is expressed as a pair of a veri cation scope V S and a PQL formula f , (V S; f ).
We remark that state attributes Pf and actions Af appearing in f must be included in the veri cation
scope V S = (A0 ; P 0 ) (i.e., Pf  P 0 ; Af  A0 ). In the veri cation procedure, all the state attributes andactions which are not on the veri cation scope V S are considered unobservable, and relabeled with  andtrue. This relabeling function derived from V S is denoted as lV S .
Accordingly, T j= (V S; f ), a macro-expression for describing veri cation queries easily, is de ned as
T [lV S ] j= f . It is more natural for veri er to describe T j= (V S; f ) in which V S is part of the veri cation
query instead of T [lV S ] j= f . For instance, for a query f = :  true, there may be some observableactions which do not appear in f explicitly, which can be expressed as observable using a veri cation
scope.

4.2 Veri cation Procedure

A basic idea of the compositional veri cation is to achieve the global veri cation as the composition of
local veri cations. In this case, instead of verifying globally

T j= (V S1 ; f1 ) ^ (V S2 ; f2 ) ^ ::: ^ (V Sn ; fn );we verify compositionallyT1 j= f1 ^ T2 j= f2 ^ ::: ^ Tn j= fn :Chapter 5: Compositional Veri cation

68

Here, Ti is the projection of T onto the veri cation scope V Si of fi . This means that state attributes
and actions of T which are not appeared in V Si are interpreted as unobservable and T is reduced to Ti
as much as possible such that T [lV Si ] PQL Ti using the reduction function described later. Ti is called
the projection transition system of T to V Si . The more local the scope V Si is, the smaller the projection
transition system Ti is. These smaller projection transition systems can ease the state explosion problem
which the naive construction of T often causes.
It is shown how to construct the projection transition system as follows (Fig. 29). We only show thecase that the concurrent program T = T1 j T2 consists of two processes (transition systems), T1 and T2 .
When the program consists of n processes, it can be treated as an extension of one of 2 processes (i.e.,
T = (:::((T1 j T2 ) j T3 )::: j Tn)). The veri cation query is expressed as (V S; f ).

T1

T2

reduction

reduction

red(T1[l1])red(T2[l2])composition

red(T1[l1]) | red(T2[l2])reduction
Tf

Figure 29.

Construction of projection transition systems

If T is composed directly from T1 and T2 , the size of T is of the multiplication order of T1 and T2 ,which is the cause of its state explosion. The following procedure to compose the projection transition
system Tf can ease the state explosion problem using a reduction function.
Tf = red((red(T1 [l1 ]) j red(T2 [l2 ]))[lV S ])Here, l1 and l2 are relabeling functions that make attributes and actions unobservable which do notappear in the veri cation scope of f and do not related to the composition (i.e., synchronization) of T1
and T2. That is, these attributes and actions are relabeled as true and  . Also, red is a reduction function
and T 0 = red(T ) is a reduced transition system such that T ! T 0 and j T jj T 0 j. The concrete
reduction function will be mentioned in the following section.
Based on Theorem 9, the model checking can be done for the projection transition system Tf instead of
T [lV S ]. As T [lV S ] ! Tf , it is guaranteed that they have the same veri cation result (i.e., T [lV S ] PQL
Tf ) by Theorem 10. Since this compositional veri cation method can control the maximum number ofstates of the temporary transition systems which are created during repeating composition and reduction,
it is possible to verify large-scale concurrent programs.
The following is the input and output of an automatic veri cation tool using this method (Fig. 4.2)'

INPUT:(1) Concurrent Program(expressed in terms of a composition of transition systems, including necessary relabeling functions).
(2) Veri cation Queries(each query is expressed as a pair of veri cation scope and PQL formula)Chapter 5: Compositional Veri cation

69

OUTPUT:(1) Answers to Each Veri cation Queries(YES/NO)
Concurrent Program- Composition ofTransition Syatems

Verification Queries- Scope- PQL formula

Automatic Verification Tool

Answer (YES/NO)

Figure 30.

Input and output for the automatic veri cation tool

From above input information, the veri cation tool can perform automatically relabeling, reduction,
composition, and model checking, then output answers.

4.3 Reduction Function

Reduction means generating the smaller transition system T 0 = red(T ) from a given transition system Tsuch that T 0 is !-equivalent to T . Two reduction functions are introduced here.
(1) Reduction by !-bisimulation
Let R be the maximum !-bisimulation in T . The transition system, where all related(i.e., equivalent) nodes in R are reduced into one node, is called red(T ). Then T 0 = red(T ) is
the transition system with minimum states which satis es T 0 ! T . The ecient algorithm
to compute !-bisimulation R is acquired by modi cation of an algorithm for bisimulation[Kanellakis 90].
(2) Reduction by rewriting rules
Although the reduction by !-bisimulation can obtain the the transition system with minimum states, its computation cost might swell in case when T is large. So, ve heuristic rules(shown in Fig. 4.3) that rewrite a transition system focused on the tau actions are applied toreduce the transition system as much as possible. Since rewriting by these heuristic rules preserves the !-equivalence, the reduced transition system T 0 = red(T ) satis es T 0 = red(T ) O
T 0 ! T . If compared with original reduction by !-bisimulation, the reduction rate may
be smaller, but it possesses the capability of speedy reduction for large scale transition systems.
Furthermore, the combination of two reduction methods is e ective in which heuristic rewriting
rules are applied rst before reduction by !-bisimulation.

4.4 Experiments
4.4.1 The Jobshop

Using the simple example presented in \Communication and Concurrency" by Robin Milner [Milner 89],
we con rm e ectiveness of the compositional veri cation. The target program, jobshop, which we wantto verify, is given as the following composition of four process (jobber  2; hammer; mallet).
jobshop = (((jobber[lj1 ] j hammer[lh ]) j mallet[lm]) j jobber[lj2 ])[ljs ]The transition systems of these processes are shown in Fig. 32, and labeling functions are de ned asfollows.

Chapter 5: Compositional Veri cation

70

rule 1

rule 2

s1

s1

Ó

s2

a

s1
a

s2

a

s2

s2

Ð(s1)=Ð(s2)rule 3Ó

s1
a1 ...

ana1 ...
s3

Ó

s1
s2
an
s3

...

s2
a1 ...

...

s4

s4

rule 4
s1
a

a
s2

Ó

s1

s2

Ó

s0

sn

s2

Ó

Ó

s3

Ó

s1

Ó

a

s3

rule 5s0

ÓÐ(s0)=Ð(s1)=Ð(s2)=...=Ð(sn)Figure 31.

Heuristic reduction rulesanChapter 5: Compositional Veri cation71

 lj1 = ([=easy; =hard; =normal; =do; in1=in; out1=out;geth1=geth; puth1=puth; getm1=getm; putm1=putm]; [ ]): lj2 = ([=easy; =hard; =normal; =do; in2=in; out2=out;geth2=geth; puth2=puth; getm2=getm; putm2=putm]; [ ]): lh = ([=error; fgeth1; geth2g=geth; fputh1; puth2g=puth]; [h off=off ]): lm = ([=error; fgetm1; getm2g=getm; fputm1; putm2g=putm]; [m off=off ]): ljs = ([=geth1; =geth2; =puth1; =puth2; =getm1;
=getm2; =putm1; =putm2; in=in1; in=in2; out=out1; out=out2]; []):

jobbermallethammerinnormal

easy
hard

getm

geth

putm

getm

geth

geth

out

puth

error

error
do

off

do

do

off

puth

putm

Figure 32.

Example: The Jobshop

The following veri cation queries are given to the target program.
(1) Can the deadlock occur? (([ ]; [ ]); epet external deadlock)(2) Is there any internal divergence which cannot be observed? (([ ]; [ ]); epet internal divergence)(3) Is there a pattern of the action sequence \in; in; out; out"?
(([in; out]; [ ]);  in   in   out   out  true)(4) Even if mallet is not available, if hammer is available, deadlock will never occur. Is it true?
(([ ]; [m off; h off ]); apat((m off ^ :   h off )  :external deadlock) K
How the veri cation system works for above queries is shown in the following two steps.

(Step1) Composition and Reduction: The projection transition system is composed for each queryin which unrelated actions and state attributes for the query are reduced as much as possible. For
instance, for query (3), the projection transition system (jobshopf3 ) is composed in the following way.
We remark that this composition procedure is automatically made of the original composition structureof jobshop and the veri cation scope.
jobshopf3 = red(red((red((red((red(jobber[lj1 ]) j red(hammer[lh ]))[lj1h ])j red(mallet[lm ]))[lj1hm ]) j red(jobber[lj2 ]))[lj1hmj2 ])[ljs ]);
0

0

where
 lh = ([=error; fgeth1; geth2g=geth; fputh1; puth2g=puth]; [true=off ]):00Chapter 5: Compositional Veri cation72

 lm = ([=error; fgetm1; getm2g=getm; fputm1; putm2g=putm]; [true=off ]): lj1h = [=geth1; =puth1]
 lj1hm = [=getm1; =putm1]
 lj1hmj2 = [=geth2; =puth2; =getm2; =putm2]
 ljs = [in=in1; in=in2; out=out1; out=out2]
 lj1 and lj2 are not changed%
00Table 6 shows the nal state numbers of jobshop (original one) and jobshopf3 (reduced one), andmaximum numbers of states in two cases which are temporally created during composition and reduction
procedure. The two previously mentioned reduction functions are used here. This table shows that our
reduction method could reduce the nal size of states to one-tenth of the original one.
Table 6.

E ect of Reduction (The Jobshop)

Transition System
Final Size Maximum Temporary SizejobshopJ original K
164
164
jobshopf3J reduction function (1) K
1772
jobshopf3J reduction function (2) K
90110(Step2) Veri cation: For each query f and its projection transition system jobshopf , the decision(YES/NO) on jobshopf j= f is made. The results of these decisions are shown in Table 7.
Table 7.

Result of Veri cation (The Jobshop)

Veri cation Query Result
(1)
YES
(2)
YES
(3)
YES
(4)
YES

4.4.2 The Manufacturing Machine Control Software

Our compositional veri cation method was applied to a middle-scale manufacturing machine control
software (Fig. 33). This machine consists of 5 arms, 4 chambers, and other equipment. An etching
chamber, a transfer chamber, an electrode, a pusher, and 2 inner arms constitute an etching unit. Two
etching units are identical. The outer arm repeatedly transports material wafers from a loading cassette
to one of two pushers in front of chambers (vacant one) via a wafer liner and from the pusher to an
unloading cassette. The wafer liner puts a wafer in order. One inner arm transports material wafers froma pusher to an electrode in an etching chamber, and the other inner arm does in the opposite directory,
that is, from an electrode to a pusher. In etching chamber, materials should be etched in a vacuum.
The two gates are controlled to keep the etching chamber in a vacuum. Since these 5 arms can moveconcurrently, the control software becomes considerably complicated.
This machine control software is controlled by a concurrent (multi-task) program which consists of
16 element processes (tasks). Each process is a local controller of a corresponding controlled object (i.e.,arm, chamber, electrode, etc.). This control software is modeled by a set of communicating transition
systems shown in Fig. 34 where transition systems are represented by safe Petri nets and synchronization
between transitions is represented by a dotted line. Table 8 shows the sizes of element processes. The state
numbers of each element process may seem to be small. It attributes to the fact that only synchronization
parts of systems are modeled by transition systems.
The following veri cation queries are given for the software.

Chapter 5: Compositional Veri cation73

etching_chamber1

etching_chamber2
electrode2

electrode1

transfer_chamber1

inner_gate1

inner_gate2

arm11

arm21

arm12

outer_gate1

arm22

transfer_chamber2

outer_gate2

pusher1

pusher2outer_arm

loading_cassette

wafer_liner

Figure 33.

Table 8.

unloading_cassette

Manufacturing Machine

Machine Control Software

Element Process  The number of it State Number of Transition System(p1) Outer Arm  1
6(p2) Wafer Liner  13(p3) Loading Cassette  15(p4) Electrode  23(p5) Unloading Cassette  15(p6) Setting Arm (armi1 )  26(p7) Extracting Arm (armi2 )  26(p8) Transfer Chamber  22(p9) Etching Chamber  24(p10)Pusher  2
3

Chapter 5: Compositional Veri cation74

load_cassette
unload_cassetteinwafer_liner

set_wafer
reset_wafer
set_wafer

finished

reset_wafer

set_waferadjust_wafer

empty

reset_wafer

waiting

set_wafer

set_wafer

reset_wafer

reset_wafer

outrelease_wafer_at_liner

outer_arm

movingcatch_wafer_at_cassettecatch_wafer_at_pusher1

catch_wafer_at_pusher1

movingmovingrelease_wafer_at_cassetterelease_wafer_at_cassette
empty

catch_wafer_at_liner

catch_wafer_at_liner

movingmovingrelease_wafer_at_pusher1

release_wafer_at_pusher1

pusher1
reset_
wafer

pusher2
wait_
etching

arm11

set_
wafer

set_
wafer

empty

wait_
take_out

reset_
wafer

reset_
wafer

arm12

transfer_chamber1(tc1)outer_gate_open

outer_gate_open

wait_
etching

set_
wafer

arm21

gate_open
inner_
gate_closeouter_
gate_close

release_wafer

inner_gate_open

electrode1

reset_
wafer

arm22
outer_gate_open

low_vaccumgate_close

gate_open

middle_vaccuminner_gate_
open

gate_close

gate_open

inner_gate_close

finishedvaccumdischarge

high_vaccumwaiting

wait_
take_outtransfer_chamber1(tc2)outer_gate_open

low_vaccumcatch_
wafer

set_
wafer

empty

release_wafer

inner_
gate_close

catch_
wafer

inner_
gate_closeouter_
gate_close

catch_
wafer

outer_
gate_close

release_wafer

inner_gate_open

etching_
chamber1(ec1)

inner_gate_
open

gate_close

gate_open

inner_gate_close

finishedvaccumdischarge

high_vaccuminner_gate_open

waiting

set_wafer

etching

empty

finished

reset_wafer

Figure 34.

gate_close

middle_vaccumelectrode2

set_wafer

etching

empty

finished

reset_wafer

Machine Control Software (Transition Systems)

release_wafer

inner_
gate_closeouter_
gate_close

catch_
wafer

inner_gate_open

etching_
chamber1(ec2)

Chapter 5: Compositional Veri cation75

1. The complete deadlock never occurs.
(([]; []); :(epet internal deadlock))
2. Whenever an action in occurs, an action out eventually occurs. The action in means a material isput in a loading cassette (cassette1), and the action out means a material is got out of an unloading
cassette (cassette2).
(([in; out]; []); apat([[in]] (apat(epet  out  ))))
3. An inner gate and an outer never become open at the same time to keep vacuum condition betterin an etching chamber.
(([]; [tc1(outer gate open); ec1(inner gate open)]); apat:(tc1(outer gate open)^ec1(inner gate open)))(([]; [tc2(outer gate open); ec2(inner gate open)]); apat:(tc2(outer gate open)^ec2(inner gate open)))Figure 9 shows the e ectiveness of reduction in the rst veri cation query (\the complete deadlock
never occurs").
Table 9.

Machine Control Software (E ect of Reduction)

Transition System
machineJ original K
machinered(reduction function (1) K
machineredJ reduction function (2) K

Final Size Maximum Temporary Size
16741
16741
4
1276
1425
4218

In this example, only synchronization parts of the system are modeled by transition systems. Actually,
they have a lot of non-synchronization (functional) parts which are unrelated to veri cation queries.
Therefore, the reduction will be more e ective.

5 Toward Practical Veri cation

5.1 Translation Target Program to Transition Systems

How does the designer model the target systems with transition systems in the practical software development? Since a transition system is a very simple model, it is impractical to describe the systems
using naive transition systems. In fast most reactive and concurrent systems can be modeled as extended
nite state transition systems, such as Petri net, Statechart, HMS machine [Gabrielian 91], and SFC(Sequential Function Chart) [IEC 1131-3]. Generally speaking, it is possible to translate them to naivetransition systems with some approximation.
This section presents an example of applying our compositional veri cation method to actual chemical plant control systems, in which control programs written by SFC are automatically translated intotransition systems. SFC is a kind of safe Petri net which has shared memories. In the latter chapter,
we will also provide high-level Petri nets (MENDEL nets) to describe the target reactive and concurrent
systems, from which transition systems can be retracted as skeletons of them.

5.2 Chemical Plant Control SoftwareThis section shows how our veri cation method can be applied to practical chemical plant control systems.
The point of this application is how to translate a practical plant control system to a set of transition
systems. We brie y illustrate the translation and validation process using an example of a simple chemicalplant shown in Fig. 35.
A requirement for a control software of this plant is described as follows. Two raw materials are
poured into a reactor via pipe1 and pipe2. When the level sensor of the reactor indicates high, valve1
and valve2 are closed. Then, valve4 opens and hot steam is poured into the reactor via pipe4 untilChapter 5: Compositional Veri cation76

valve1valve2
pipe1

temperature

pipe2
agitatorlevel(high)pipe4
valve4
reactor

pipe5

Figure 35.

level(low)pipe3valve3

Example of Chemical Plant

the temperature of the reactor becomes high. At high temperature, chemical reaction is caused by anagitator. Finally, produced materials are extracted from the reactor via pipe3 by valve3.
In this example, the control software consists of two processes; the main control process (task1 )and the temperature control process (task2 ) 10 . These tasks are described by SFC which is a populargraphical programming language for sequence control systems (Fig. 36 and Fig. 37).
When applying the compositional veri cation method to the plant control software, the target systemshould be translated to a set of transition systems. The target system consists of the control software andcontrolled objects (plant equipment), both of which should be translated to transition systems because
the control software can not function without connecting it with controlled objects. We brie y show
procedures of the translation.

 SFC Tasks ! Transition Systems

In translation from a SFC task to transition system, two issues have to be considered; concurrency
within a task and access to shared memories.

{ Concurrency within a task

Each SFC task is translated to a transition system. Since SFC is based on Petri nets, SFC may
have concurrency in a task. For example, v1_open and v2_open are concurrently processed
in Fig. 36. If a SFC task has no concurrency, then a generated transition system almost
corresponds to a SFC task by one to one. If a SFC task has concurrency, then a global transition
system is produced which is equivalent to the original SFC by interleaving concurrent actions.
Note that this interleaving within a task has possibility to cause state explosion, but it usually
does not because most state explosions are caused by interleaving among concurrent tasks andnot by interleaving within a task.
{ Access to shared memories
In plant control systems, communication among tasks and communication between tasks andplant are done by way of shared memories. It means asynchronous communication. As atransition system supposes only synchronous communication, access to shared memories haveto be translated into synchronous communication. In our method, possible access patterns ofa shared memory are modeled as actions, and each access is interpreted as synchronizationof the same actions. For example, gure 39 illustrates how to translate accesses to sharedmemories for communication among task1 and valve1.
Figure 38 shows a generated transition system of task1.

 Plant Modeling with Transition Systems

10 Here, \task" and \process" are identical. Since \task" is conventionally used in plant control systems, we use \task" inthe following explanation.

Chapter 5: Compositional Veri cation

77
START

level_low

N v1_op

N v2_op

v1_openv2_open
S timer1

v1_opatimer1_up

S timer2v2_opatimer2_up

timer1_up

timer2_up

waiting

S timer1

level_hightimer1_up

timer1_up

N v1_clN V2_cl

v1_closev2_close
S timer1

v1_clatimer1_up

S tmer2v2_clatimer2_up

timer1_up

timer2_up

waiting
temper_high

S timer1

ag start

S agitator

timer1_up

ag stop

R agitator

N v3_op
v3_open
S timer3v3_opatimer3_up
timer3_up
waiting

S timer1

level_low
timer1_up

timer1_up
N v3_cl

v3_close
S timer3
timer3_up
v3_clatimer3_up

error
handling

N v1_clN v2_clN v3_clS switch

stop_or_continueswitchswitchstop

Figure 36.

Plant Control Software (task1)

Chapter 5: Compositional Veri cation

78

START
temper_low
level_high
N v4_op
v4_open
S timer4v4_opatimer4_up
timer4_up
waiting

temper_high

N v4_cl
v4_close
S timer4
v4_clatimer4_up
timer4_up
stop_or_continueswitchswitchSTOP

Figure 37.

waiting

Plant Control Software (task2)

Chapter 5: Compositional Veri cation

79

Controlled objects should be directly modeled by the designer with transition systems. This may be
a tedious job. Focusing on chemical plants, we have proposed a method to generate automaticallytransition systems (plant simulator) by reusing and connecting model fragments corresponding toplant equipment from plant con guration data (e.g., process ow diagram) [Kawata 95, ?].

level(low)timer1(up)v1(opa)v1(op),
timer1(set)timer2(up)v2(op),
timer2(set)timer1(up) timer2(up)v2(op),
timer2(set)v1(opa)v2(op),
timer2(set)v2(opa)v2(opa)timer2(up)v2(opa)v1(op),
timer1(set)v1(op),
timer1(set)v1(opa)timer1(up)timer1(set)level(high)timer1(up)v1(cla)v2(cl),
timer2(set)timer2(up)v1(cl),
timer1(set)timer1(up)timer2(up)v2(cl),
timer2(set)timer1(up) timer2(up)v2(cl),
timer2(set)v1(cla)v2(cla)v1(cl),
timer1(set)v2(cla)v2(cla)v1(cl),
timer1(set)v1(cla)timer1(up)temper(high)ag(start),timer1(set)ag(end),timer1(up)timer3(up)timer1(up)v3(op),timer3(set)v1(cl),v2(cl),v3(cl)

v3(opa)timer1(set)switch(off)v3(cl),
timer3(set)level(low)switch(set)v3(cla)switch(on)timer3(up)Figure 38.

Transition System (task1)

Figure 40 shows a nal structure of the plant control system components of which are modeled bytransition systems.
Veri cation queries for this plant control software are listed as follows.
 There exists no complete deadlock except normal termination (task1(stop) ^ task2(stop2)).
(([]; [task1(stop); task2(stop2)]); apat(internal deadlock  (task1(stop) ^ task2(stop2)))) The normal termination state is reachable from every state which is reachable from an initial state.
(([]; [task1(stop); task2(stop2)]); apat(epet (task1(stop) ^ task2(stop2)))) There are no abnormal states such that material pouring and extracting are simultaneously carriedout in the reactor.
(([]; [valve1(open); valve2(open); valve3(open)]); apat :((valve1(open)_valve2(open))^valve3(open))) There are no dangerous states such that a reactor is heated up although material is not lled up
enough.
(([]; [valve4(open); level(high)]); apat valve4(open)  level(high))

Chapter 5: Compositional Veri cation

80

op

Control
Softwareop

SharedMemoryopa

Controlled
Object

opa

cl

cl

task1

valve1valve1cla

cla

task1:cla

close
valve1:clvalve1:cla

task1:op

task1:op

task1:cltask1:opa
task1:cltask1:clvalve1:opa

open

valve1:op

task1:op

Figure 39.

Modeling of Shared Memory

switchtask1

valve1ag

timer1valve2

timer2

reactorFigure 40.

task2

valve3timer3valve4level

tempersteam

Structure of the Plant Control System

Chapter 5: Compositional Veri cation

81

In fact, This SFC program has a lot of bugs, most of which can be detected as complete deadlock
except normal termination. To put it concretely, there exist the following bugs.
 When a termination switch is turned on in certain timing, it is possible that one of tasks is terminated and the other is hung up.
 Since task2 can not completely cope with error handling of task1, task2 is possibly hung up.
 When it takes long time to close valve1 and valve2, heating process of task2 may be nished. Onthat occasion, task1 may be hung up by waiting forever the temperature becomes high.
The e ectiveness of computing cost in compositional veri cation in the case of deadlock detection isshown in Table 10.
Table 10.

State Space Generation (Chemical Plant Control System)

MethodStates Transitions
Compositional Method
528
4064
Naive State Space Generation 283439 2174168

5.3 Veri cation Tool

We initially implemented primitive operations used in the compositional veri cation including composition, relabeling, reduction, and PQL model checker. However, when the veri cation method is actuallyapplied, the following problems still remain.
 It is not necessarily easy for ordinary designers to describe in PQL queries.
 The exact location of bugs cannot be spotted even if the existence of bugs can be detected.
 Process composition and relabeling operations are laborious.
Therefore, we have developed a took kit named \VERASQUES" (VERi cAtion Systems for temporal logic
QUErieS) which is of general purpose and includes the following facilities to solve the above problems.
 Primitive operation commands
 PQL query generation interface
 Debugger which supports to identify the location of bugs
 PCL (Process Composition Language) which is a command language to describe operation procedures.
When focusing on certain domains such as chemical plants, the more speci c veri cation tool can beavailable. SAVE/SFC [Uchihira 93a, Kawata 96] is a Simulation And Veri cation Environment for SFC
programs which we have been now developing (Fig. 41). SAVE/SFC has a simulation facility in addition
to the veri cation facility. Moreover, veri cation is tightly tuned up by merging compositional method
and partial order method [Uchihira 95b]and introducing a lot of heuristics.
We have applied SAVE/SFC to a real chemical plant control software, where the plant consists of 28
valves, 4 pumps, 5 measurements, and 1 reactor, and the program consists of 5 tasks. Many trivial bugs
can be found by typical and varied simulation using the heuristic selection. Some complicated bugs thatare dicult to nd by typical simulation have been detected by exhaustive simulation using the logicalselection. The veri cation generated the reduced state space which has 2800 states, and takes about 3
hours.

Chapter 5: Compositional Veri cation

82

Figure 41.

SAVE/SFC

6 Related Works

6.1 Compositional Veri cation Methods

Many compositional veri cation methods have been proposed for a system which has compositional
structure like CCS, CSP, and Modular Petri nets. Generally speaking, compositional veri cation can bede ned as
 verifying properties of the components of a system, and then deducing global properties from these local properties.
This compositional approach can reduce veri cation cost drastically. Compositional veri cation should
be compositional in the structure of processes and work purely on the syntactical level without inspecting
components. An ideal method of compositional veri cation can be formalized as follows.
(op(T1 ; T2; :::; Ti ; :::; Tn ) j= f ) ()opf ((T1 j= op1 1 (f )); (T2 j= op2 1 (f )); :::; (Ti j= opi 1 (f )); :::; (Tn j= opn 1 (f )))where T1 ; T2; :::; Ti ; :::; Tn are component processes of the system and op(T1 ; T2; :::; Ti ; :::; Tn) is a composite
process using an operator op over the components, f is a formula representing veri cation queries, T j= fmeans a process T satis es f , opi 1 (f ) is a formula which is derived from f and op for i-th argument ofop, opf is a logical operator corresponding to op. Here, opi 1 (f ) is a projection of f onto i-th argumentof op. Note that opi 1 (f ) is derived without inspecting components T1; T2 ; :::; Tn . This function opi 1
plays an important role in the compositional veri cation, that is, if Ti j= opi 1 (f ) can be locally veri ed
for every component Ti , then opf ((T1 j= op1 1 (f )); (T2 j= op2 1 (f )); :::; (Tn j= opn 1 (f ))) can be computed
instead of globally verifying op(T1 ; T2 ; :::; Ti ; :::; Tn ) j= f .
For example, a summation operator \+" of CCS is good-natured for the compositional veri cation.
The compositional veri cation with regard to \+" can be formalized as follows.
(T1 + T2 ) j= haif () (T1 j= haif ) _ (T2 j= haif );where op = +, opi 1 (haif ) = haif and ophaif = _. In this case, it is sucient to prove local properties(T1 j= haif ) and (T2 j= haif ) instead of proving a global property (T1 + T2 ) j= haif .
Unfortunately, it is proved that it is impossible to nd opi 1 (f ) for every operator op of CCS[Fantechi 91]. In particular, a composition operator is inadequate for the ideal compositional veri cation.
Therefore, several non-ideal compositional veri cation methods have been proposed with avoiding thisessential limitation.

Chapter 5: Compositional Veri cation

83

1. Restriction of veri cation queries
For example, Winskel [Winskel 90] showed a compositional veri cation for restricted assertions, inwhich an assertion over process composition (product) T1  T2 should be described as product ofassertions A1  A2 .
2. Introduction of component's information to opi 1 (f )If we are allowed to inspect components T1 ; :::; Tn and use an extended projection opi 1 (f; T1 ; :::; Tn)
instead of opi 1 (f ), pseudo-compositional veri cation is available. Since the projection opi 1 does
not require entire information of T1 ; :::; Tn, it is possible to derive a relatively simple and equivalent
formula red(opi 1 (f; T1 ; :::; Tn)) by apply reduction rules to the original opi 1 (f; T1 ; :::; Tn ). Andersen
and Winskel [Andersen 92] propose a compositional veri cation method based on this framework.
The latter approach is essentially equivalent to our and Clarke's compositional veri cation methods.
The di erence between them is concerned with the place on which information derived by inspecting
components is re ected. In our and Clarke's methods, Ti+ j= opi 1 (f ) is used instead of Ti j= opi 1 (f )+in verifying local properties, where
T + = op(T1 ; :::; Ti ; :::; Tn)i

op 1 (f )+ = op 1 (f; T1 ; :::; Tn):ii

In other word, the information (+ ) is re ected on a transition system Ti in our and Clarke's methods,
while it is re ected on a formula opi 1 (f ) in Andersen and Winskel's method. Note that both methods
make good use of reduction techniques. More speci cally, we can show the following correspondence forthe formulation of our compositional veri cation method described in Section 4.2.
(T1 j T2 j= f1 ^ f2) ()((Tf1 j= f1 ) ^ (Tf2 j= f2 ))where Tf1 = T1+ = red((red(T1 [l11 ]) j red(T2 [l12 ]))[lV S1 ]) and Tf2 = T2+ = red((red(T1 [l21 ]) j
red(T2 [l22 ]))[lV S2 ])Although Andersen and Winskel's approach is essentially equivalent to our and Clarke's methods, ourapproach is more appropriate for transition systems which can utilize (extended) bisimulation for process
reduction.

6.2 Comparison with Partial Order Approach

Another approach to avoid the state explosion is partial order approach [Valmari 90, Godefroid 91a,
Godefroid 91b, Wolper 93, Godefroid 96]. When there are many redundant interleaving simulation paths
over the state space, we can leave one representative path and delete the others by the partial ordermethod. Figure 42 illustrates an essential idea of the partial order method. A naive state space of P1 j P2
has 18 states and 20 paths by transition interleaving (i.e., total ordering). Here, P1 and P2 synchronize
only about actions a and b. However, if P1 and P2 are independent regarding actions t11 ; :::; t23 , this naivestate space is redundant in order to detect deadlock. It is sucient to analyze only one representative
path a ! t11 ! t12 ! t13 ! t21 ! t22 ! t23 ! b which consists of 9 states.
To compare the partial order method with the compositional method, we show Fig. 43 where t11 ; t13 ; t21 ; t23
are internal ( ) actions and processes P1 and P2 are rst reduced and then composed. This method can
reduce 18 states of a naive state space to 7 states.
These two approaches can be characterized as follows.

 Partial Order Method{ Compatibility with conventional testing and simulation

Partial order method is well-suited to actual execution of target programs because a selection
mechanism of a representative path can be implemented as a smart scheduler. Veri cation
is modeled as a smart exhaustive simulation and harmonized with conventional testing andsimulation. In other words, conventional testing and simulation are interpreted as a special
case of a smart exhaustive simulation based on the partial order method.

Chapter 5: Compositional Veri cation

P1

84

P2
a

P1 | P2

a

a
t11

t11

t21

t12

t21

t21

t22
t11

t13
t12

t12
t21
t13

t22
t21

t13

t23
t22

t22
t13

t12
t13

t23
b

b

b

Figure 42.

P1

t11

t12
t23

t22

t32

t11
t23

Partial Order Method

P2
a

t11

t12

a
red(P1)red(P2)

a

a

t21

t22

t13

t32

b

b

t12

b

Figure 43.

red(P1) | red(P2)

a
t12

t22

t22

t12

t22

b

Compositional MethodbChapter 5: Compositional Veri cation

85{ Applicability to ill-structured systems

It is not so dicult to implement a smart scheduler which requires only information aboutdata and control dependency between processes. Therefore, it is applicable to ill-structured
systems.
{ Flat and global analysis
Since the partial order method is a smart version of global state apace analysis, it can not
make good use of hierarchical and compositional structures of the target systems.

 Compositional Method{ E ectiveness for well-structured systems

The compositional method is e ective for well-structured systems which consist of many but
uniform and mostly independent subprocesses because process reduction works well for them.
{ Hierarchical and compositional analysis
The compositional method is e ective for large but hierarchical systems because veri cation
is done compositionally where subprocesses are abstracted by process reduction.

Since compositional methods and partial order methods are orthogonal, it is practical solution toutilize both methods complementarily (hybrid method). For example, we illustrate a typical hybrid
method for the target system which consists of two large processes P1 and P2 (Fig. 44). First P1 andP2 is reduced to simple interface processes which produces only behaviors related to given queries andsynchronization by the compositional method, then a smart state space generation is done by the partial
order method. Finally, the state space is analyzed by PQL model checker. In fact we adopted this hybrid
approach in SAVE/SFC [Uchihira 93a, Uchihira 95b] which is mentioned in the previous section.
Target Program

P1

red(P1)
P2

red(P2)

Reduction by
Compositional
MethodPQL Queries
State Space
Model Checking

Figure 44.

State Space
Generation byPartial Order
MethodHybrid Approach of Compositional and Partial Order Methods

7 Summary
Process Query Language of concurrent program veri cation based on state logic and the compositionalveri cation method were proposed and its e ectiveness con rmed by using the examples.
This chapter focuses on the compositional veri cation for transition systems, which have only nitestates, in place of Petri nets, which may have in nite states. A model-checking method for Petri nets was
proposed by [Brad eld 92], which is very powerful but not compositional (he showed some remarks oncompositionality at page 82 of [Brad eld 92]). In general the compositional veri cation for Petri nets isdicult and impractical. Therefore, developing a compositional veri cation method for Petri nets, which
may be restricted to some degree but practical enough, is one of the further works.

Chapter 5: Compositional Veri cation

86

Appendix I : Proof of Theorem 10
To proof theorem 10, several de nitions and lemmas are introduced.

De nition 29 (k ! )In (S; Act; ; P; ), for 8s; t 2 S; 8k  0,s 0! t def= (s) = (t)
 s" i t"+1 t defs k!
= (s) = (t)

 8a:8s0:(if s !a s0 then 9t0 :t )a^ t0 ^ s0 k! t0 )
 8a:8t0:(if t !a t0 then 9s0 :s )a^ s0 ^ s0 k! t0 )
 s" i t"

Lemma 7 (Relation of  ! and k ! )s ! t ,

(1)
(2)

s 6! t ,

1
_
k=1

1
^

(s k! t)

k=1

(s 6k! t) , 9k:(s 6k! t)

Proof. It is obvious from the de nition.2
Lemma 8 (Semantics of   f;  + f;  a  f;  a + f )s j= 

f () 9t =   :9s0 :(s !t s0 ^ s0 j= f )s j= + f () 9t =   :9s0 :(s !t s0 ^ s0 j= f ) _9t =  ! :(s !t )s j= a f () 9t =   a  :9s0 :(s !t s0 ^ s0 j= f )s j= a + f () 9t =   a  :9s0 :(s !t s0 ^ s0 j= f ) _9t =   a ! :(s !t ) _9t =  ! :(s !t )Here 9t =   a  means 9t 2 f i a j j i; j  0g.

(1)
(2)
(3)
(4)

Chapter 5: Compositional Veri cation

87

Proof.
(1) From lemma 6, s 2 V [   f ] = [ Z:(f _ 9TZ )]] () 9k:s 2 V [ (Z:(f _ 9TZ ))k false] =V [ (9T )k 1 f ] () 9t =   :(s !t s0 ^ s0 2 V [ f ] ):+(2) From lemma(f _ 9TZ )]] = limk!1 V [ Z:(f _ 9TZ )k true] =Sk 6,1 V [  i f ] = V [ Z:
limk!1 i=0 V [ (9T ) f ] [ V [ (9T )k true] : Therefore, s 2 V [  + f ] () 9i:(s 2 V [ (9T )i f ] ) _s 2 V [ (9T )! true] () 9t =   :(s !t s0 ^ s0 2 V [ f ] ) _ t =  ! :(s !t ):(3) In the same way as (1), s 2 V [  a  f ] = V [ Z1 :(9(a ^ X (Z2 :(f _ 9TZ2))) _ TZ1)]] ()9i; j:s 2 V [ (9T )i 9(a ^ X (9T )j f )]]: Therefore, s 2 V [  a  f ] () 9t =   a  :(s !t s0 ^ s0 2
V [ f ] ):(4) In the same way as (2), V [ Z:(f _ 9TZ )]] = limk!1 (Ski=01 V [ (9T )i f ] [ V [ (9T )k true] ): Therefore,s 2 V [  a + f ] = V [ Z1 :(9(a ^ X (Z2 :(f _ 9TZ2))) _ TZ1)]]() 9i; j:(s 2 V [ (9T )i 9(a ^ X (9T )j f )]])_9i:(s 2 V [ (9T )i 9(a ^ X (9T )! true)]])_s 2 V [ (9T )! true] :Then, s 2 V [  a + f ] () 9t =  i a j :(s !t s0 ^s0 2 V [ f ] )_9t =  i a ! :(s !t )_9t =  ! :(s !t ):2

Proof of Theorem 10[Proof of T1 ! T2 ( T1 PQL T2 ]If T1 6! T2 , it is sucient to prove 9f:(T1 j= f ^ T2 6j= f ). As 9k:(s01 6k! s02 ) from lemma 7, theinduction about k can be applied as follows. In the case of s 6k! t, f such that s j= f ^ t 6j= f can beconstructed for the following 4 cases.
Case 1 (s) 6= (t) ) f = p s:t: p 2 (s); p 62 (t):Case 2 s " ^:(t ") ) f = + false:J from Lemma 8)
Case 3 s !a s0 ^ :9t0 :(t )a^ t0) ) f = a  true: (from de nitions)
Case 4 s !a s0 ^ 8t0i:(t )a^ t0 ) s0 6k!1 t0i ) )By the induction,^
8t0i :9fi :(s0 j= fi ^ t0i 6j= fi ). Then, f = a  fi .
i

[Proof of T1 ! T2 ) T1 PQL T2 ]8f:(T1 ! T2 ^ T1 j= f ) T 2 j= f ) is shown here. From Lemma 6(3), only nite length PQL formulaswith no  operators should be considered. When PQL formulas which do not contain  operators, it
can be proved by the structural induction of PQL formulas as follows. Here the cases of f = a +
f 0 ; f = a  f 0 are proved. As for other formulas, the proof can be provided in the same manner.
 f = a  f 0'
t1 s0 ^ s0 j= f ) from Lemma 8, also
When s1 ! s2 and s1 j= a  f 0 , 9t1 =   a  :(s1 !
1 1t
9t2 =   a  :(s2 !2 s02 ^ s01 ! s02 ) from s1 ! s2 . By the structural induction, s02 j= f 0 , thens2 j= a  f 0 .
 f = a + f 0'
When s1 ! s2 and s1 j= a + f 0, from Lemma 8,(1) 9t =   a  :(s1 !t s01 ^ s01 j= f ), or(2) 9t =  ! :(s !t ), or(3) 9t =   a ! :(s !t )%In the case of (1), it can be proved in the same manner as f = a  f 0 . In the case of (2), sincet1s1 " and s1 ! s2 , s2 ". Therefore s2 j= a + f 0 . In the case of (3), since 9t1 =   a  :(s1 !
t2 s0 ^ s0 "). Therefore, s j= a + f 0 2
s01 ^ s01 ") and s1 ! s2 , 9t2 =   a  :(s2 !
2
2 2Chapter 5: Compositional Veri cation

88

Appendix II : Well-known Equivalence Relations and DivergenceThis section shows detail de nitions of well-known equivalence relations (trace equivalence, failure equivalence, partial bisimulation equivalence) referred in Fig. 28. Their relations are summarized from theviewpoint of \divergence".

De nition 30 (trace equivalence)
Let S be a set of states, A be a set of actions (Act = A [f g), and  : S  Act ! 2S be a nondeterministictransition function. For (S; Act; ) and s; t 2 S , s and t are trace equivalent, written s 1 t, if 8 2^^
Act :s ) i t )De nition 31 (failure)
For (S; Act; ) and s 2 S ,^ s0 and s0 !
failures(s) def= f(; L) j  2 Act ; L  A such that 9s0 2 S:(s )6  and 8a 2 L:s0 !
6 a )gDe nition 32 (failure equivalence)
For (S; Act; ) and s1 ; s2 2 S , failure equivalence (f ) is de ned as follows.
s1 f s2 () failure(s1) = failure(s2)De nition 33 (partial bisimulation preorder by global divergence)
For (S; Act; ), a partial bisimulation preorder with global divergence vg ( S  S ) is de ned as thelargest relation such that
if 8s; t 2 S; s vg t implies

 8a 2 Act:8s0 2 S:(if s !a s0 then 9t0 2 S:t )a^ t0 ^ s0 vg t0 )
 if :(s ") then
{ :(t ")
{ 8a 2 Act:8t0 2 S:(if t !a t0 then 9s0 2 S:s )a^ s0 ^ s0 vg t0 )De nition 34 (partial bisimulation equivalence by global divergence)
For (S; Act; ) and s; t 2 S ,s gp t () s vg t ^ t vg s:

gp is called partial bisimulation equivalence by global divergence.
De nition 35 (parameterized !-divergence)
For (S; Act; ) and s 2 S; a 2 Act,a^ s0 ^ s0 ")s " a def
= s " or 9s0 :(s )De nition 36 (partial bisimulation preorder by local divergence)
For (S; Act; ), a partial bisimulation preorder by local divergence v ( S  S ) is de ned as the largest

relation such that
if 8s; t 2 S; s v t implies

 8a 2 Act:8s0 2 S:(if s !a s0 then 9t0 2 S:t )a^ t0 ^ s0 v t0 )
 8a 2 Act: if :(s " a) then
{ :(t " a){ 8t0 2 S:(if t !a t0 then 9s0 2 S:s )a^ t0 ^ s0 v t0 )De nition 37 (partial bisimulation equivalence by local divergence)
For (S; Act; ) and s; t 2 S ,s p t () s v t ^ t v s:

p is called partial bisimulation equivalence by local divergence.

Chapter 5: Compositional Veri cation

89

Partial bisimulation equivalence by local divergence is sometimes simply called \partial bisimulationequivalence". The discrimination ability of partial bisimulation equivalence by local divergence is thesame as Intuitionistic Hennessy-Milner Logic (IHML) [Stirling 87].

Theorem 11 (Imvolvement Relation among Equivalence Relations)

The imvolvement relation among equivalence relations is shown as follows.

 ! gp
 gp p
 gp f
 f 1 p 1
Here, \R1  R2 " means \8s; t 2 S: if sR1 t then sR2 t".

Proof. It is obvious from the de nition.2
Figure 45 shows a counter example which shows there is no imvolvement relation bwtween f andp . In this example, T1 p T2 but T1 6f T2 . On the other hand, T3 6p T4 but T3 f T4.

a

a

tau

a

b

a

a

a

T1

a

b

c

d

T3

Figure 45.

b

T2

a

b

tau

a

b

b

c

d

T4

Example which shows there is no imvolvement relation bwtween f and pChapter 6

Compositional Program Adjustment
In this chapter, we examine \program adjustment", a formal and practical approach to developing correct
concurrent programs, by automatically adjusting an imperfect program to satisfy given constraints. A
concurrent program is modeled by a nite state process, and program adjustment to satisfy temporal
logic constraints is formalized as the synthesis of an arbiter process which partially serializes target (i.e.
imperfect) processes to remove harmful nondeterministic behaviors. Compositional adjustment is also
proposed for large-scale compound target processes, using process equivalence theory.

1 Motivation and Overview
1.1 Motivation

The diculty of concurrent program debugging is mainly due to its nondeterministic behavior. We
classify nondeterminism into the following 3 types.
 Intended nondeterminism: Nondeterministic behaviors which the programmer intends to implement.
 Harmful nondeterminism: Nondeterministic behaviors which the programmer does not intend
to implement and does not expect.
 Persistent nondeterminism: Nondeterministic behaviors which have no e ect on the results.
For example, Fig. 46 shows a simple Ada-like concurrent program \Seat Booking", where two processes read/write a shared memory \seat" to reserve one seat. This program has the 3 types of nondeterministic behaviors.

Intended nondeterminism The following nondeterministic behaviors 1 and 2 derive di erent results: P1 can book the seat (status1 = OK ) in 1 , but cannot (status1 = NG) in 2 . However both arecorrect (intended behaviors).
 1 = l1 ! l2 ! l3 ! l4 ! l5 ! m1 ! m2 ! m5
Result: status1 = OK; seat = OCCUPIED; status2 = NG.
 2 = m1 ! m2 ! m3 ! m4 ! m5 ! l1 ! l2 ! l5
Result: status1 = NG; seat = OCCUPIED; status2 = OK .

Harmful nondeterminism The following nondeterministic behavior 3 derives an incorrect result(double booking). So, this program has harmful nondeterminism.
 3 = l1 ! m1 ! l2 ! m2 ! l3 ! m3 ! l4 ! m4 ! l5 ! m5

Result: status1 = OK; seat = OCCUPIED; status2 = OK .

90

Chapter 6: Compositional Program Adjustment

91

Persistent nondeterminism The following two nondeterministic behaviors have the same result be-cause l1 (write in status1) and m1 (write in status2) are independent actions of each other. We call sucha situation persistent.
 4 = l1 ! m1 ! l2 ! l3 ! l4 ! l5 ! m2 ! m5
Result: status1 = OK; seat = OCCUPIED; status2 = NG.
 5 = m1 ! l1 ! l2 ! l3 ! l4 ! l5 ! m2 ! m5
Result: status1 = OK; seat = OCCUPIED; status2 = NG.

P1

P2

l1: status1 := NG ;l2: if seat.read = FREE thenl3: seat.write(OCCUPIED) ;l4: status1 := OK ;end if ;l5: terminate ;write

status1

read

m1: status2 := NG ;m2: if seat.read = FREE thenm3: seat.write(OCCUPIED) ;m4: status2 := OK ;end if ;m5: terminate ;
write

seat
(Initially, seat := FREE)
Figure 46.

status2

An example of a concurrent program

In our observation of concurrent program development, a programmer rst tries to design and implement processes so as to maximize concurrency, which may include 3 types of nondeterminism. He thenoften nds harmful nondeterministic behaviors in testing and debugs them by partially serializing thecritical sections which interfere each other using synchronization mechanisms (e.g. semaphores). Bugs
due to harmful nondeterministic behaviors often account for a considerable part of all timing bugs.
We will show that the debugging processes for harmful nondeterministic behaviors can be mechanicallysupported using formal methods. It can be also regarded as a practical application of program synthesis
techniques to program modi cation in debugging.

1.2 Overview of Main Results

We propose \program adjustment" which automatically adjusts (debugs) an imperfect program to satisfy
given constraints. Here, we consider only timing constraints for concurrent programs that can be speci edby temporal logic. In this context, \an imperfect program" is regarded as a program which is functionallycorrect but may be imperfect in its timing. We call such a program an FCTI program (FunctionallyCorrect Temporally-Imperfect program).
A concurrent program is modeled with the nite state process [Kanellakis 90] , which can specify thenite state transition system with liveness conditions. It can not only represent the transition systems
in CCS [Milner 89], but also Buchi automata [Buchi 62]. A target FCTI program is compositionallyconstructed from several nite state processes with the composition operator \j"(ex. P = (P11 j P12 ) j(P21 j P22 ) in Fig.47(a)).

Basic Adjustment Program adjustment (basic adjustment) means to adjust an FCTI program tosatisfy given constraints by adding an arbiter process which is synchronized with and restricts the behaviorof the FCTI program (Fig.47(b)). The arbiter partially serializes the FCTI program to remove harmful
nondeterministic alternatives which do not satisfy given constraints. We will show an algorithm tosynthesize an arbiter process Cf automatically.

Chapter 6: Compositional Program Adjustment(a)Process
Composition

(b)
Basic
Adjustment

P1
P

P11

P2
P12

P21

P22

arbiter

CfP’(c)
Compositional
P’
Adjustment

Figure 47.

92

P1

P2
P12

P11

P21

C0

P1

P2
C1

P11

P22

C2
P12

P21

P22

Process Composition (a), Basic (b), and Compositional (c) Adjustment

Input: An FTCI program P .
Input: Temporal logic constraints f .
Output: An arbiter process Cf such that P j Cf satis es f .
Compositional Adjustment When a target program becomes large, the arbiter synthesis may cause
computing cost explosion. Therefore, we propose compositional adjustment, in which local arbiters aresynthesized in each composition step. For example, an adjusted program with local arbiters C0 , C1 , andC2 is shown as follows (Fig.47(c)).
P 0 = (P11 j P12 j C1 ) j (P21 j P22 j C2 ) j C0

In each composition step, the reduction of the nite state process, based on process equivalence theory,
can ease computing cost explosion. We introduce a new process equivalence relation (!-bisimulation)
to manipulate liveness properties because the traditional weak bisimulation equivalence used in CCS
cannot. !-bisimulation is used to reduce a nite state process to a smaller and equivalent one in thecompositional adjustment.
It is more feasible for ordinary programmers to adopt the program adjustment approach comparedto other methods which synthesize complete programs from (temporal logic) speci cations [Manna 84,
Emerson 82, Pnueli 90]. The reasons are as follows.

 It is not very dicult for ordinary programmers to produce an FCTI concurrent program, which

satis es at least the functional requirements. A more dicult task is to design and debug the timingof such programs.
 Many bugs are derived from harmful nondeterministic alternatives.
 It is easy for ordinary programmers to specify timing constraints, such as deadlock-free and starvationfree constraints, as compared with implementing them.

Chapter 6: Compositional Program Adjustment93

1.3 Organization of the Chapter

The remainder of this chapter is organized as follows. Section 2 de nes Finite State Processes (FSP)
and their equivalence relation and composition operator. Basic and compositional adjustment of FSP
is described in Section 3. Section 4 shows a simple and nontrivial example and an experimental result of compositional program adjustment. Finally, Section 5 takes program adjustment in standard
programming languages into consideration, followed by related works and summary in Section 6 and 7.

2 Finite State Processes
The basic model for concurrent programs is the nite state process (FSP) de ned in Chapter 2, which
can specify the nite state transition system with liveness conditions. First, we introduce an equivalence relation for FSPs. Then, several operators (composition, relabeling, and reduction) on FSPs are
introduced and their properties are shown.

2.1 Equivalence of Finite State Processes

We now introduce !-bisimulation equivalence for FSP which was originally de ned for compositionalveri cation in Chapter 5. In this chapter, it is used to reduce an FSP to a smaller and equivalent one incompositional adjustment. !-bisimulation equivalence is rede ned for FSPs as follows.

De nition 38 (!-divergence)
Let P = (S; A; L; ; ; s0; F ) be an FSP. s 2 S is !-divergent (s ") if 8n > 0:9s0 2 S:9 2 A :(j  j=n; ^ () = " and s0 = (s; )). 2
De nition 39 (!-bisimulation Equivalence)
Let P1 = (S1 ; A1 ; L1 ; 1 ; 1 ; s01 ; F1 ) and P2 = (S2 ; A2 ; L2 ; 2 ; 2 ; s02 ; F2 ) be FSPs. P1 and P2 are !bisimulation equivalent (P1 ! P2 ), if there is a binary relation R  S1  S2 , such that (s01 ; s02 ) 2 R,
and 8s1 2 S1 :8s2 2 S2 :(s1 ; s2 ) 2 R ()
 s1 2 F1 i s2 2 F2 , s1 " i s2 ", 8t1 2 A1 :8s01 2 S1 :( if s01 = 1 (s1 ; t1 ) then9 2 A2 :9s02 2 S2 :^1 (t1 ) = ^2 (); s02 = 2 (s2 ; ); and (s01 ; s02 ) 2 R), 8t2 2 A2 :8s02 2 S2 :( if s02 = 2 (s2 ; t2 ) then9 2 A1 :9s01 2 S1 :^2 (t2 ) = ^1 (); s01 = 1 (s1 ; ); and (s01 ; s02 ) 2 R):2!-bisimulation is extended so that it can discriminate designated states and divergence, whichcannot be discriminated by weak bisimulation (the weak bisimulation ignores divergences, i.e.,  -loops
and  -circles). The following lemma is derived from these discrimination abilities.
Lemma 9 If P1 is complete and P1 ! P2 , then P2 is also complete. 2
De nition 40 (Reduction) For a given FSP P = (S; A; L; ; ; s0 ; F ), a reduction of P , red(P ) =(Sr ; Ar ; Lr ; r ; r ; sr 0 ; Fr ), is an FSP such that P ! red(P ) and j Sr jj S j. 2
The smallest red(P ) is constructed e ectively by the relational coarsest partitioning algorithm [Paige 87,
Kanellakis 90] such that all states of P that are !-bisimilar to each other are brought together into asingle state of red(P ).

Chapter 6: Compositional Program Adjustment94

2.2 Operators on Finite State Processes

Concurrent programs are constructed as a composition of several FSPs that are synchronized with eachother. The composition and relabeling operators for FSPs are introduced and their important properties(substitutivity and re ectivity) are shown.

De nition 41 (Composition Operator)
For P1 = (S1 ; A1 ; L1 ; 1 ; 1 ; s10 ; F1 ) and P2 = (S2 ; A2 ; L2; 2 ; 2 ; s20 ; F2 ), a composition P = P1 j P2 isde ned as follows.
P = (S1  S2  f0; 1g2; (A1 [ fidleg)  (A2 [ fidleg); L1 [ L2; ; ; (s10 ; s20 ; 0; 0); F ), where  : (S1  S2  f0; 1g2)  (A1 [ fidleg)  (A2 [ fidleg) ! (S1  S2  f0; 1g2) [ f?g such that
((s1 ; s2 ; f1; f2 ); (a1 ; a2 )) =8
(1 (s1 ; a1 ); 2 (s2 ; a2 ); f10 ; f20 ); when1 (a1 ) = 2 (a2 ) 6= ; and f1 = f2 = 1;>>>0 1 if i (si ; ai ) 2 Fi ;>>>where ffi0 =( for each i = 1; 2)>>;
i = 0 otherwise>>>(1 (s1 ; a1 ); 2 (s2 ; a2 ); f10 ; f20 ); when 1 (a1 ) =2 (a2 ) 6= ; and (f1 = 0 _ f2 = 0);>>>0 1 if i (si ; ai ) 2 Fi _ fi = 1;>>>
where ffi0 =( for each i = 1; 2)>>
i = 00 otherwise ;>>>(1 (s1 ; a1 ); s2 ; f1 ; 0); when 1 (a1 ) 2= (L1 \ L2 ); a2 = idle; and f1 = f2 = 1;>>>>
f10 = 1 if 1 (s1 ; a1 ) 2 F1 ;
>
>
where
>
f10 = 0 otherwise ;<(1 (s1 ; a1 ); s2 ; f10 ; f2 ); when 1 (a1 ) 2= (L1 \ L2); a2 = idle; and (f1 = 0 _ f2 = 0);>>
f10 = 1 if 1 (s1 ; a1 ) 2 F1 _ f1 = 1;
>
where
>
>
f10 = 0 otherwise ;>>>>(s1 ; 2 (s2 ; a2 ); 0; f20 ); when 2 (a2 ) 2= (L1 \ L2 ); a1 = idle; and f1 = f2 = 1;>>>>
f20 = 1 if 2 (s2 ; a2 ) 2 F2 ;
>
where
>
>
f20 = 0 otherwise ;>>>>(s1 ; 2 (s2 ; a2 ); f1 ; f20 ); when 2 (a2 ) 2= (L1 \ L2); a1 = idle; and (f1 = 0 _ f2 = 0);>>>
f20 = 1 if 2 (s2 ; a2 ) 2 F2 _ f2 = 1;
>
>
where
>
>
f20 = 0 otherwise ;>>: ?; otherwise;2  : (A1 [ fidleg  A2 [ fidleg) ! L1 [ L2 [ f g such that8< ((a1 ; a2 )) = 1 (a1 ) = 2 (a2 ) if a1 2 A1 and a2 2 A2 ;((a1 ; idle)) = 1 (a1 )if a1 2 A1 ;: ((
idle; a2 )) = 2 (a2 )if a2 2 A2 ;
 and F = f(s1 ; s2 ; f1 ; f2) j s1 2 S1 ; s2 2 S2 ; f1 = f2 = 1g.

We remark that processes are synchronized at actions with the same labels in the above processcomposition. This composition is similar to composition in CCS[Milner 89] except for its treatment ofdesignated nodes. The following relabeling operators are used to relabel actions so that actions which
are synchronized in composition have the same labels.
De nition 42 (Relabeling Operator) For P = (S; A; L; ; ; s0; F ) and a relabeling function f : L !
L0 [ f g, P 0 = P [f ] is de ned as follows.

 0f ((a)) if (a) 6= ;
P 0 = (S; A; L0 ; ; 0 ; s0 ; F ); where 0 ((aa)) ==
if (a) = :2
Example 9 (Composition and Relabeling) P1 = (fs0 ; s1 ; s2 g; ft1; t2 ; t3 ; t4 ; t5 g; fa1; b1 ; cg; 1; 1 ; s0 ; fs1 g) where1 (s0 ; t1 ) = s1 ; 1 (s0 ; t2 ) = s2 ; 1 (s1 ; t3 ) = s2 ; 1 (s2 ; t4 ) = s1 ; 1 (s1 ; t5 ) = s1 ; 1 (t1 ) = a1 ; 1 (t2 ) =b1 ; 1 (t3 ) = b1; 1 (t4 ) = a1 ; 1 (t5 ) = c.

Chapter 6: Compositional Program Adjustment95

 P2 = (fs0 ; s1 ; s2 g; ft1; t2 ; t3 ; t4 ; t5 g; fa2; b2 ; dg; 2; 2 ; s0 ; fs2g) where2 (s0 ; t1 ) = s1 ; 2 (s0 ; t2 ) = s2 ; 2 (s1 ; t3 ) = s2 ; 2 (s2 ; t4 ) = s1 ; 2 (s2 ; t5 ) = s2 ; 2 (t1 ) = a2 ; 2 (t2 ) =b2 ; 2 (t3 ) = b2; 2 (t4 ) = a2 ; 2 (t5 ) = d.
 relabeling functions: fi (ai ) = a; fi (bi ) = b, and fi (l) = l for other labels l 2 fc; dg (for each i=1,2).
 P1 [f1 ] j P2 [f2 ] = (fs0 ; s1 ; s2 ; s3 ; s4 g; f(t1; t1 ); (t2 ; t2 ); (t3 ; t3 ); (t4 ; t4 ); (t5 ; idle); (idle; t5)g;
fa; b; c; dg; ; ; s0; fs3; s4 g) where(s0 ; (t1 ; t1 )) = s1 ; (s0 ; (t2 ; t2 )) = s2 ; (s1 ; (t3 ; t3 )) = s3 ; (s1 ; (t5 ; idle)) = s1 ; (s2 ; (t4 ; t4 )) =s4 ; (s2 ; (idle; t5 )) = s2 ; (s3 ; (t4 ; t4 )) = s1 ; (s3 ; (idle; t5)) = s2 ; (s4 ; (t3 ; t3 )) = s2 ; (s4 ; (t5 ; idle)) =s1 ; ((t1 ; t1 )) = a; ((t2 ; t2 )) = b; ((t3 ; t3 )) = b; ((t4 ; t4 )) = a; ((t5 ; idle)) = c; ((idle; t5)) = d.
(Fig.48) 2
P1:

P2:
s0

t5/c

s0’

t1/a1
t3/b1

t2/b1

s1

s2

t1/a2

t2/b2
t3/b2

t5/d

s1’

t4/a1

s2’
t4/a2
action/label

P1[f1]|P2[f2]:(t5,idle)/c(t1,t1)/as1,s1’,
1,0

s0,s0’,
0,0(t4,t4)/a(t2,t2)/b(idle,t5)/ds2,s2’,
0,1(t3,t3)/b(t3,t3)/bs1,s1’,
1,1

s2,s2’,
1,1(idle,t5)/dFigure 48.

(t5,idle)/c

Composition and Relabeling

De nition 43 (Projection) Let P1 and P2 be FSPs. A left projection L(P1 j P2 ) # left is de ned as
L(P1 j P2 ) # left def= f1 =fidleg j 9 2 L(P1 j P2 ):[i] = (1 [i]; 2[i])g. Similarly, a right projection
L(P1 j P2 ) # right is de ned. In the same way, projections of L! , Lfair
! , and Lb are de ned. 2
Lemma 10 (Re ectivity) Let P1 and P2 be FSPs. If P = P1 j P2 , then Lb (P ) # left  Lb (P1 ) andLb (P ) # right  Lb(P2 ). 2
Lemma 11 (Substitutivity) !-bisimulation equivalence is preserved by composition and relabeling;that is, if P ! Q, then 8R:(P j R ! Q j R), and 8f:(P [f ] ! Q[f ]). 2
Re ectivity and substitutivity are used in the basic adjustment and the compositional adjustment,
respectively. These adjustments are described in the next section.

Chapter 6: Compositional Program Adjustment

96

3 Program Adjustment
This section proposes program adjustment of FSPs. First, we show that a temporal logic constraint f
can be transformed to an equivalent FSP Pf . For an FTCI process P and a temporal logic constraint f ,P j Pf is a composed process in which P 's behaviors against f are disabled by Pf (i.e., safety properties
are satis ed). However, P j Pf is not necessarily complete (i.e., liveness properties may not be satis ed).
Program adjustment means to make P j Pf complete by adding arbiter process C (i.e., the adjusted
program = P j Pf j C ).

3.1 Temporal Logic Constraints

The constraints for concurrent programs (safety properties and liveness properties) are speci ed by propositional liner time temporal logic (PLTL) 11 . Safety properties include admissible partial ordering ofactions (i.e., transition ring), and liveness properties include deadlock and starvation about actions.
Theorem 12 Given an PLTL formula f under a single event condition, one can build an FSP Pf =(S; A; L; ; ; s0 ; F ) such that L corresponds to a set of atomic propositions of f , and Lb (Pf ) is exactly
the set of behaviors whose label sequences satisfy the formula f . 2

Proof. This is a FSP version of Lemma 2.
We remark that a label sequence of a satis able behavior in Pf corresponds to a model of an PLTL
formula.

Example 10 (Temporal Logic Constraints) Let a label set be L = fa1; a2 g.
 (1) 2}(a1 _ a2 ): Either a1 or a2 must in nitely often occur.
 (2) 2(a1  2(:a2 )): Whenever a1 occurs, then a2 must never occur.
FSPs which are generated from (1) and (2) are shown in Fig.49.
(2)

(1)
a1/a1
a1/a1

Figure 49.

a2/a2
a2/a2

a2/a2
a1/a1
a1/a1

FSPs Pf of Temporal Logic Constraints

In the context of the following program adjustment, we restrict temporal logic formulas so that Pf isdeterministic with regard to synchronization labels. In this case, some formulas, such as }2a, which

are translated to nondeterministic one, become not available. These formulas are suitable for veri cation,
but not for adjustment (synthesis) because the arbiter cannot look ahead at future behaviors as indicatedby Pnueli and Rosner[Pnueli 89a, Pnueli 89b].

3.2 Basic Adjustment

When temporal logic constraints f can be translated to an FSP Pf , we have to show how to make an
FSP P = Pf j P0 complete for the target FCTI program P0 by adding an arbiter process C . In otherwords, basic adjustment is de ned as an arbiter synthesis for P = Pf j P0 (Fig. 50).
In the following explanation, we assume that the target FSP P has already composed with Pf (i.e.,
P = Pf j ::::), and do not mention Pf explicitly.

Problem 1 (Basic Adjustment)
11 Detail de nitions are shown in Chapter 2.

Chapter 6: Compositional Program Adjustment

97

targetP0
programPffcomposition

P= P0 | Pfadjustment = arbiter synthesis

C

Figure 50.

Arbiter

Basic Adjustment

Input: An FSP P = (S; A; L; ; ; s0; F ) (We assume P = Pf j :::).
Output: A maximally permissive FSP C = (Sc; Ac; Lc; c; c; s0c; Fc) such that P j C is complete.
\C is maximally permissive" means that for every C 0 if P j C 0 is complete then L(P j C 0 )  L(P j C ). 2
The arbiter, C , restrains the target FSP P from falling into unsatis able states by eliminating harmful
observable transitions.

Algorithm 1 (Single Arbiter Synthesis)(Step 0) P 0 := P .
(Step 1) Find a set of unsatis able states Su  S 0 in P 0 = (S 0 ; A0 ; L; 0 ; 0 ; s00 ; F 0 ). If there are no

unsatis able states, go to Step 4.
(Step 2) Construct a pseudo-arbiter C 0 from P 0 as follows. At rst,  closure C is de ned asC (s; a) def= fs0 j 9:(s0 = (s; ); ^ () = a)g for 8s 2 S 0 and 8a 2 L [ f"g,S
C (Ssub ; a) def= s2Ssub C (s; a) for 8Ssub  S 0 and 8a 2 L [ f"g,then
C 0 = (Sc0 ; A0c ; L; c0 ; c0 ; C (s00 ; "); Sc0 ), where Sc0 = 2S ; A0c = fta j a 2 Lg [ fts j s 2 S 0 g, and for
8a 2 L, 8s0 2 Sc0 , c0 (s0 ; ta ) = C (s0 ; a) 2 Sc0 if C (s0 ; a) \ Su = ;, c0 (s0 ; ta ) = ? if C (s0 ; a) \ Su 6= ;, c0 (s0 ; ts ) = s0 ,and c0 (ta ) = a and c0 (ts ) =  for 8a 2 L; 8s0 2 Sc0 .
We remark that \c0 (s0 ; ta ) = ? if C (s0 ; a) \ Su 6= ;" means elimination of all behaviors whichcannot be distinguished from inevitably unsatis able behaviors by a label observer.
(Step 3) P 0 := P 0 j C 0, and return to Step 1.
(Step 4) Let the nal pseudo-arbiter C 0 , which is generated after applying Step 1 - Step 3 repeatedly,
be the arbiter C .
If C is empty (i.e., all behaviors are eliminated), C is called unrealizable; otherwise, C is called
realizable.
000Chapter 6: Compositional Program Adjustment

98

Theorem 13 (Main Theorem) If an FSP C = (Sc ; Ac ; Lc ; c; c ; s0c ; Fc ) is realizable for a given FSP
P = (S; A; L; ; ; s0; F ) in the above algorithm, then P j C is complete and C is maximally permissive.
2

Sketch of proof. During Step 1 - Step 3, all inevitably unsatis able behaviors are eliminated in the
nal P 0 . Therefore, P 0 is complete. Since the transition function of C 0 is deterministic about its labels,
C 0 restrains no satis able behavior of P . Therefore P j C is complete and C is maximally permissive.
Corollary 2

2

Lfair
! (P j C ) # left  Lb (P j C ) # left  Lb (P )Proof. This proof is derived from Lemma 1 and Lemma 10 with Theorem 13.
This corollary assures that P , adjusted by C , satis es its liveness constraints, whenever its behaviors
are made by random transitions over states. We remark that an arbiter is e ective in case Lfair
! (P ) 
Lb (P ) does not hold (i.e., P has harmful nondeterministic behaviors).

Example 11 (A single arbiter synthesis) Fig.51 shows a simple single arbiter synthesis. In the target
process P , only  = t3 t6 t7 is an inevitably unsatis able behavior. Since ft3t6 t7 ; t3 t4 g is a set of behaviors
which cannot be distinguished from  (i.e. have the same label sequence \ab"), t4 and t7 are eliminated.
From the remainder, the arbiter C can be constructed.
P (Target Program):
s0

t1/a

t3/a

Ó

t9/

s2

s1

Ó

t2/

Ó

t4/b

s3

s5

Ó

s4

t6/

t7/b

t8/c

s6

t5/

inevitably unsatisfiablebehavior

unsatisfiable stateÓ

S0={s0}C (Arbiter):

tS0/

S0

S1={s1,s2,s4}

Ó

tS1/

ta/a
S1

Figure 51.

3.3 Compositional Adjustment

Ó S1={s6,s2,s4}

tS2/

tc/c

S2

tc/c

Single Arbiter Synthesis

When a target program that is composed hierarchically with many processes becomes very large, thearbiter synthesis may cause the following problems.
1. The synthesis results in a computing cost explosion,
2. A single arbiter is too restrictive to control the whole program precisely.

Chapter 6: Compositional Program Adjustment

99

Therefore, we propose compositional adjustment, in which local arbiters are synthesized in eachcomposition step. The reduction of an FSP can ease the computing cost explosion in each step.

Theorem 14 If P1 ! P2 , then C is an arbiter of P1 i C is an arbiter of P2 .
2

Proof. From Lemma 1 and Lemma 11, C j P1 is complete i C j P2 is complete.
Corollary 3 If C is an arbiter of red(P), then C is also an arbiter of P.
2
Algorithm 2 (Compositional Arbiter Synthesis) For simplicity, we explain compositional adjustment

for the following target program that is constructed by two-level composition (Fig.47(c)). This algorithm
can be extended easily to arbitrary target programs.
 Target Program:(P11 [h11 ] j P12 [h12 ])[h1 ] j (P21 [h21 ] j P22 [h22 ])[h2 ]where P11 ; P12 ; P21 , and P22 are FSPs, and h11 ; h12 ; h21 ; h22 ; h1 and h2 are relabeling functions.
 Temporal Logic Constraints:
f1 ,f2 ,f0 are temporal logic constraints for each composition level.
The compositional arbiter synthesis is done in a bottom-up way (Fig. 52).
(Step 1) Low level arbiters C1 and C2 are synthesized for subprocesses P11 [h11 ] j P12 [h12 ] j Pf1 andP21 [h21 ] j P22 [h22 ] j Pf2 , respectively. We denote P1 def= (C1 j P11 [h11 ] j P12 [h12 ] j Pf1 )[h1 ] anddef
P2 = (C2 j P21 [h21 ] j P22 [h22 ] j Pf2 )[h2 ].
(Step 2) Reduced subprocesses red(P1 ) and red(P2 ) are made from P1 and P2 .
(Step 3) A top level arbiter C0 is synthesized for a target process red(P1 ) j red(P2 ) j Pf0 .
f1

f2

Transform

Pf1

Arbiter Synthesis

P11

P12

Composition

Transform

C1

Pf2

f0

Arbiter Synthesis

P21

P22

C2

Composition

Transform
P1

P2
Pf0

Reduction

red(P1)Figure 52.

Arbiter Synthesis

Reduction

C0

red(P2)Compositional Arbiter Synthesis

Corollary 2 assures that reduction preserves all information necessary for each local arbiter synthesis.
The reduction in each step can cut down the synthesis cost. As the ratio of internal actions in the processChapter 6: Compositional Program Adjustment

100

increases, so does the e ectiveness of the reduction. Note that it is possible to synthesize directly asingle arbiter C 0 for the target programs. However, C 0 is too restrictive because it has less controllable
actions compared with local arbiters, and its synthesis cost is more expensive without reduction. Process
reduction by weak bisimulation equivalence has been already proposed and shown its e ectiveness incompositional veri cation by Clarke et. al. [Clarke 89]. However, the reduction preserving livenessproperties by !-bisimulation is our original work.

4 Example and Experimental Result

4.1 Example: The Machine Control Program

In this example we synthesize a single arbiter. The problem may be stated informally as follows. The
target program must be designed to control machines which cooperatively process (i.e., etch) printed
circuit boards (Fig.53). The coating machine applies resist to boards. The exposure machine exposesboards to the light. The development machine develops boards. The arm machine moves boards from one
machine to another. The target program is composed of 6 processes (Resist, Exposure, Development,
Arm, and Trans  2) which control corresponding machines. Trans represents board transportation.
Each process is displayed as a Petri net, shown in Fig.54. With no arbiter, this system is FCTI because
it falls into deadlock when an action label sequence of Arm \get r ! put e ! get r" occurs. We give thefollowing temporal logic constraints:
f = 2}(get r _ put e _ get e _ put d)which means Arm never falls into deadlock. An arbiter C is synthesized as follows: rst, FSPs representing
6 subprocesses are relabeled by relabeling functions fr ; fe ; fd; fa ; ft1, and ft2 , and are reduced, and FSP
Pf (Fig.55) representing temporal logic constraints f is generated. The target process P (Fig.56) iscomposed from these FSPs (including Pf ). Finally, the arbiter C shown in Fig.57 is synthesized from P ,according to Algorithm 1. We can see that the adjusted program \C j Pf j Resist[fr ] j Exposure[fe ] jDevelopment[fd] j Arm[fa ] j Trans[ft1 ] j Trans[ft2 ]" satis es the above constraints. Figure 58 shows
the adjusted program represented by extended Petri net. You can see the target Petri net in Fig. 54 isadjusted by introducing the arbiter C in Fig. 58.
ArmResistDevelopment
Exposure

Figure 53.

4.2 Experimental Result

Machine for Processing Printed Circuit Boards

We will show how well the compositional method works when it is applied to a middle-scale manufacturingmachine control software. This machine is controlled by a concurrent (multi-task) program which consistsof 16 element processes (tasks). Table 11 shows the sizes of element processes. The state numbers of eachelement process may sound small. It attributes to the fact that only synchronization parts of systems aremodeled by FSPs.
For this target processes, we give temporal logic constrains by f ; prohibition of illegal behaviors
of arms and deadlock-freedom for two symmetric process groups (P4 ; P6 ; P7 ; P8 ; P9 ; P10 ). Two arbitersChapter 6: Compositional Program Adjustment

101

ResistDevelopment

hand-shake

get_r

put_d

Arm
get_r

put_d

put_e

get_e

get_r

put_d

put_e

get_e

put_e

get_e

Trans

Trans

Exposure

Figure 54.

Extended Petri net

get_r,put_e,
get_e,put_d
get_r

put_d

Figure 55.

get_e

put_e

FSP Pf for PLTL formula fChapter 6: Compositional Program Adjustment

102

Ó

get_r

Ó
Ó

get_r

Ó

Ó
put_e

put_d

Ó

Ó

get_e

put_e

Ó

deadlock:
unsatisfiable
state

get_r

Ó
Figure 56.

Ó

put_d

get_r

get_e

Ó

get_r

Target Process P (displaying only labels)

Ó

tS0/
tget_r/get_r

s0

tput_d/put_ds1

Ó tput_e/put_e

tS1/

s2
s3

tget_e/get_e

Ó

tS3/

Figure 57.

Synthesized Arbiter C

Ó

tS2/

Chapter 6: Compositional Program Adjustment

103
Arbiter C

Resist

get_r

put_d

put_e

get_e

Development

get_r

put_d

Arm
get_r

put_d

put_e

get_e

get_r

put_d

put_e

get_e

put_e

get_e

Trans

Trans

Exposure

Figure 58.

Adjusted Program

were synthesized after the compositional adjustment procedure. Fig. 4.2 shows their whole structure(communication and synchronization among processes).
Table 11.

Middle-scale Machine Control Software

Element FSP(p1) Distribution Arm(p2) Testing Equipment(p3) 1st Manufacturing Equipment(p4) 2nd Manufacturing Equipment  2(p5) 3rd Manufacturing Equipment(p6) Set-up Arm  2(p7) Extracting Arm  2(p8) 1st door  2(p9) 2nd door  2(p10)Conveyer  2

Number of States
6
3
5
3
5
6
6
2
3
3

The compositional adjustment procedure to synthesize two arbiters Cf 1 and Cf 2 is shown as follows12 .
1. Pc1 = red(P4 j P6 j P7 j P8 j P9 j P10 ) (max size = 48 states)
2. Pc2 = red(P1 j P2 j P3 j P5 ) (max size = 85 states)
3. Pc3 = red(Pc1 j Pc2 ) (max size = 77 states)
4. The rst arbiter Cf 1 is synthesized from f and Pc3 (max size = 385 states)
12 Relabeling functions are omitted for simplicity.

Chapter 6: Compositional Program Adjustment

104
Communication and
Synchronization between
Processes

P2

P1

P3

arbiter
Cf1

P5

P10

P10

P9

P9

arbiter
Cf2

f

f
P6

Figure 59.

P7

P6

P7

P4

P4

P8

P8

Adjusted Middle-scale Machine Control Software

5. Pc4 = red(Pc3 j Cf 1 ) (max size = 88 states)
6. Pc5 = red(Pc4 j Pc1 ) (max size = 239 states)
7. The second arbiter Cf 2 is synthesized from f and Pc5 (max size = 112 states)
Here, the \max size" means the maximal number of states which are temporally created during process composition and reduction procedure at each step, and the worst case is max size = 385. Without
the compositional method (i.e, by the basic adjustment), the naive process composition of 16 processes
would generate far larger number of states since the max size is increasing monotonously without reduction. Table 12 shows the maximum number of states in two cases (basic adjustment and compositional
adjustment). It says that the compositional method can reduce the maximum size to about 1/150 of thebasic adjustment.
In this example, only synchronization parts of the system are modeled by FSPs. If they have a lot ofactions which are unrelated to synchronization, which are regarded as  actions, the process reduction
would be more e ective.
Table 12.

Middle-scale Machine Control Software (E ect of Process Reduction)

Adjustment TypeMaximum Temporary Size of States
Basic Adjustment
61096
Compositional Adjustment
385

5 Program Adjustment in Standard Programming Languages
This section considers brie y program adjustment in standard programming languages, instead of FSP.
Program adjustment is applicable to concurrent programming languages which have a synchronous (i.e.,
hand-shake) communication mechanism, like Ada and Occam. For example, Fig. 60 shows a programadjustment example for the Ada program used in the motivation section (Fig. 46). Two FSPs P1 andP2 are derived from the original program, then an arbiter is synthesized by the basic adjustment procedure, and nally an adjusted Ada program13 is derived from FSPs and the arbiter. As you can see in
13 Some trivial declarations are omitted.

Chapter 6: Compositional Program Adjustment

105

Fig. 60, the arbiter controls the target programs using a rendezvous mechanism of Ada to remove harmful
nondeterministic behaviors (i.e., 3 ) mentioned in Section 1.
When applying the program adjustment to Ada, we require the following two converters.
 Ada ! FSP converter: The Ada program code is divided into basic blocks. Each basic block is
assigned to one state of a generated FSP. Control ows between basic blocks are represented asedges between these states. Synchronous communication commands are also represented as edges
with synchronization labels. Furthermore, the user can put arbitrary labels on edges which are used
to specify temporal logic constraints.
 FSP ! Ada converter: A synthesized arbiter represented by a FSP is converted into an Ada task
which implements state transitions using loop and select constructs. Synchronization labels in thearbiter are converted into accept commands, and synchronization labels in the target processes areconverted into entry call commands.

P1

P2

l1

Arbiter

in1

in1

in2
N=0

m1
in2

Ó

N=1
l2

m2

N=2

N=3
out1

out2

out2
l3

m3
out1

out1

out2
l4

Ó

l5

m4

Ó

m5

task arbiter isentry in1 ;entry in2 ;entry out1 ;entry out2 ;end arbiter ;task body arbiter is
N:integer:= 0 ;
begin
loop
task body p2 istask body p1 isselectbegin
begin
when N=0 =>status := NG ;status := NG ;accept in1 do N:=1; end in1 ;arbiter.in2 ;arbiter.in1 ;when N=0 =>if seat.read=FREE thenif seat.read=FREE thenaccept in2 do N:=2; end in2 ;seat.write(OCCUPIED) ;seat.write(OCCUPIED) ;when N=1 =>arbiter.out2 ;arbiter.out1 ;accept out1 do N:=3; end out1 ;status := OK ;status := OK ;when N=2 =>
else
else
accept out2 do N:=3; end out2 ;arbiter.out2 ;arbiter.out1 ;end select ;end if ;end if ;end loop :terminate ;terminate ;end arbiter ;end p2 ;end p1 ;Figure 60.

Program Adjustment in Ada

6 Related Works
Our previous works [Uchihira 87, Uchihira 90a, Uchihira 90b] had proposed program synthesis methods
based on temporal logic. However, these methods generated a global state transition graph based on
the assumption that all process actions are visible (not internal) and controllable. This assumption isChapter 6: Compositional Program Adjustment

106

restrictive, and the state transition graph often becomes huge, and its generation is expensive since itcannot be done compositionally. In this chapter, we introduce a CCS-like compositional framework toachieve compositional adjustment utilizing process reduction. Abadi, Lamport, and Wolper [Abadi 89]
proposed a compositional program synthesis using the CCS-like compositional framework, where failure
equivalence is adopted instead of our !-bisimulation equivalence. However, their approach is a top-down
program re nement, which di ers from our bottom-up program adjustment approach. From another view,
arbiter synthesis can be regarded as a control problem of discrete event systems (supervisory control) which
are well surveyed by Ramadge and Wonham [Ramadge 89]. However, while these works mainly consider
safety properties, they showed no compositional synthesis methods satisfying liveness constraints. The
concurrency control of database transactions [Bernstein 81] is much related to the program adjustment.
Both are intended to remove harmful nondeterminism. The program adjustment can be regarded as theextended concurrency control applied to compositional (hierarchical) concurrent programs.

7 SummaryWe have introduced the concept of \program adjustment" into concurrent programming. Program adjustment consists of partially synthesizing programs to remove bugs that are due to harmful nondeterministic
behaviors. In the proposed framework, program adjustment is de ned as the synthesis of arbiter processes which control target processes with synchronization to satisfy their temporal logic constraints. For
compositional adjustment, we have also introduced a new composition and equivalence for nite stateprocesses which can preserve liveness properties, because the traditional CCS framework (compositionand equivalence) is not adequate for nite state processes. These techniques are essential to the basic
and compositional adjustment.
We also remark that our method is suited for reactive systems which have uncontrollable and unobservable elements in its environment since they can be modeled by  actions in FSP.

Chapter 7

MENDEL Net: High-Level Petri Net
for Reactive and Concurrent Systems
Up to this chapter, Petri net is used as a speci cation language for reactive and concurrent systems.
This chapter focuses on a high-level Petri net as a rather programming language, and proposes a new
high-level Petri net, called MENDEL net, which is suited for both specifying and implementing reactive
and concurrent systems.

1 Introduction
Although many high-level Petri nets have been proposed, they are not practical enough to describe reactive and concurrent systems in the detail design and implementation phases. They are mainly intended
to describe concurrent systems in the modeling phase and are lacking in several important features (e.g.
concurrent tasks, task communication/synchronization, I/O interface, task scheduling) for programming
reactive and concurrent systems. On the other hand, there are several programming languages based on
Petri nets. However, they are deeply depend on its execution environment and not sophisticated as amodeling and speci cation language.
We propose MENDEL net which is a high-level Petri net extended by incorporating task, task communication/synchronization, I/O interface, and task scheduling in a sophisticated manner. MENDEL nets
can bridge the gap between Petri net as speci cation language and Petri net as programming language.
The remainder of the chapter is organized as follows. First Petri nets as programming languages forreactive and concurrent systems are considered in Section 2. Section 3 introduces MENDEL nets in detailand an example of MENDEL nets is shown in Section 4, followed by related works and a conclusion in
Section 5 and Section 6. Finally, a syntax of MENDEL nets is shown in Appendix.

2 Petri Nets as Programming Language

2.1 Programming Language for Reactive and Concurrent Systems

A practical programming language for reactive and concurrent systems requires expressive power for thefollowing items.

 I/O Interface with Environment

I/O interface with an environment (controlled objects) is necessary to de ne and describe inputs(e.g. sensor information from devices) and output (e.g. control commands to devices) (Fig. 61).
Concerning inputs, there are two types, active and passive. An active input device generates aninterrupt when it has some input to be processed by an interrupt handler of the system (controller).
As a passive input device does not generate interrupt, the system (controller) should read some
sensor data by an input handler periodically or on demand. Outputs like control commands aresent to devices by an output handler. These handlers (input, output, interrupt) are called device
driver generally.
107

Chapter 7: MENDEL Net

108
Reactive and Concurrent System (RCS)
Input/Sensor

Interrupt Handler
Input Handler

Environment(Controlled Objects)

Program
Output Handler

Output/Command

Figure 61.

Device Driver

I/O Interface with Environment

 Concurrent Tasks and Task Communication/Synchronization

It is necessary to de ne concurrent tasks and describe communication and synchronization between
these tasks. There are the following mechanisms to realize communication and synchronization[Andrews 83].

{ communication/synchronization by shared memories
semaphore, event ag, etc.

{ communication/synchronization by message passing

mail box (asynchronous message passing), rendezvous (synchronous message passing) Real-Time Task Scheduling

Most reactive systems are implemented by multi-tasking on a single processor. They require areal-time task scheduling mechanism to decide which task should be processed by the processor ata given moment. To realize the real-time scheduling, the following mechanisms are necessary andare usually provided by real-time operating systems.
{ Task priority{ Task dispatching{ Interrupt handling{ Real-time management (timer, periodical sampling) Abstraction Mechanism

A module (subroutine) and data abstraction (information hiding) are typical abstraction mechanisms in most programming languages. Additionally, the following abstraction mechanisms aree ective for reactive and concurrent systems.
{ Abstraction and information hiding for communication and synchronization{ Abstraction and information hiding for I/O devices

2.2 Extension of Petri Nets as Programming Language

Since standard Petri nets cannot fully satisfy the above requirements for describing reactive and concurrent systems, it is necessary to extend a standard Petri net as follows.

 I/O Interface with Environment

It is necessary to introduce I/O interface with the environment into Petri net explicitly. Concretely,
special places and transitions which are linked to device drivers should be de ned. For example,
Petri net with external inputs and outputs (PNIO) [Ichikawa 85] shows a typical Petri net extension
which has I/O Interface.

 Interface with Other Programming Languages

Reactive and concurrent systems may have data and numerical processing parts. It is dicult toextend Petri net to manipulate directly these parts. Therefore, the practical solution is to introduce
interfaces with other programming languages for data and numerical processing.

Chapter 7: MENDEL Net

109

 Concurrent Tasks and Scheduling Mechanism

Although a Petri net has concurrency in itself, the granularity of its concurrency is too small, thatis, transition-level. A module-level concurrency (i.e., task, process) should be introduced into Petrinets. Moreover, a scheduling mechanism which controls these tasks should also be expressed within
the extended Petri nets.

 Real-Time Extension

To introduce real-time into Petri nets, there are several approaches.
{ Time delays are associated with transitions and/or places. These models include timed Petrinets and stochastic Petri nets [Marsan 86].
{ A global clock is introduced, and then, time stamps are attached to tokens, which are used todescribe transition conditions and actions [Bellettini 93].
{ Timers are prepared as built-in subnets, that is, interfaces with the timers are introduced into
Petri nets.

 Individual Tokens and Hierarchical Net Structure

By extending tokens to possess individual attributes and values (we call them individual tokens), it ispossible to express high-level enabling conditions and actions accompanying transitions. Moreover,
it is possible to fold several symmetric nets into a single net by means of individual tokens. On theother hand, hierarchical net structure (e.g., some subnets can be represented by one macro-placeor macro-transition) is necessary to design large-scale systems. These individual tokens and net
hierarchy are regarded as abstraction mechanisms. Several extended Petri nets have been proposedin which these mechanisms are available. Generally, they are called high-level Petri nets.

2.3 Petri-Net-Based Programming Languages

In the eld of sequential control, programming languages based on Petri nets are popular, and several
languages have been proposed. Some are widely used as languages for programmable logic controller(PLC) in the industry. Individual languages are introduced brie y below.

 SFC

Traditionally, ladder charts and function blocks are used as programming languages for PLC. However, these languages are structurally at, and dicult to maintain when the program becomeslarge. In order to overcome this problem, it is e ective to introduce a state-transition-based structure (e.g. Petri net) into ladder charts and function blocks. Sequential Function Chart (SFC)[IEC 1131-3] is a popular programming language for PLC, which is originally based on Petri nets.
SFC has interfaces with ladder charts and function blocks. These ladder charts and function blocks
are used to describe transition conditions, actions, and I/O interface. SFC has been standardized
by International Electrotechnical Commission (IEC).
 High-Level SFC
Since SFC standardized by IEC is very basic, several extensions have been done by each PLC
provider. For example, Instrument Flow Chart (IFC) [Kojima 91] is a high-level SFC for plant
control systems (i.e., chemical plants and waterworks and sewage treatment plants), which has thefollowing extensions.

{ Multi-tasking mechanism{ Domain-speci c macro notations MFG/PFS

MFG/PFS [Miyagi 88] is a Mark Flow Graph (MFG) based programming language for control
systems for discrete event production systems (DEPS). MFS is a Petri-net-based language which
has the following additional features.
{ Speci c Tokens: Tokens represent \items" (material, work pieces, etc.) of DEPS.

Chapter 7: MENDEL Net

110{ I/O interface: Input and interrupt handlers are represented by speci c transitions, and output

handlers are represented by speci c places.
{ Modularity: A subnet-oriented modularity called \activity" is introduced which means a single
production operation of DEPS.
Production Flow Schema (PFS) is a macro representation of MFG which can support stepwise
re nement in designing and programming.
 C-net/SCR
Control-net (C-net) is a visual programming language for sequential control which is based on asafe coloured Petri net. In C-net, some control program fragments including I/O interface with theenvironment can be described in each place, which are called place procedures. Hence, a net structureof C-net represents a transaction control program where each transaction consists of several place
procedures. Station Controller (SCR) [Murata 90] is a programming and executing environment
which includes a C-net editor, a C-net interpreter, and an execution monitor. The C-net interpreter
supports multi-task processing in which each task is described as a C-net.
 K-NET
K-NET [Nagao 92] is a programming environment for Flexible Manufacturing Systems (FMS). KNET adopts a hierarchical high-level Petri net in which enabling conditions of transition and place
procedures can be speci ed by the following user-de ned functions and logical I/O functions.
{ user-de ned function: The user can de ne functions with C language which are used inenabling conditions and place procedures.
{ logical I/O function: Logical I/O functions are also used in enabling conditions and place
procedures. In the logical functions, each atomic proposition (logical I/O name) is linked tosome physical device.
The K-NET programming environment consists of editor, simulator, C program generator, monitor,and document generator. Petri net descriptions in K-NET are translated into C programs by the
C program generator and compiled and executed by factory computers.

2.4 High-Level Petri Net as Programming Language

Several high-level Petri nets and tools have been proposed, which include Coloured Petri Nets (CPN) andits tool (DESIGN/CPN) [Jensen 92, Jensen 95], Predicate/Transition Nets [Genrich 81] , and Algebraic
Petri Nets [Reisig 91] . CPN (DESIGN/CPN) introduces hierarchy constructs into nets to enable a largescale system description. Although these high-level Petri nets provide sophisticated modeling ability, theycannot be used as a programming (implementation) language for reactive and concurrent systems as theyare. Principally, the following extension should be done according to Section 2.2.
 I/O Interface with Environment
 Concurrent Tasks and Scheduling
Since an introduction I/O interface is easy, introduction of concurrent tasks and scheduling mechanism
is essential. Hierarchy (module) constructs which these high-level Petri nets provide are subnet-oriented;
that is, a part of the net (subnet) is regarded as a hierarchical unit and reduced to one node. This subnetoriented hierarchy (module) is inadequate to represent concurrent tasks because it does not concern
module-level concurrency. Reactive and concurrent systems require task-oriented modules and module
composition mechanism as provided in the process theory (e.g., CCS, CSP, ACP). Furthermore, taskscheduling cannot be speci ed explicitly within the framework of these high-level Petri nets.
On the other hand, there are some programming languages (C-net, K-NET) based on high-level Petrinets as mentioned in the previous section. Since they deeply depend on execution environment, they are
not sophisticated as speci cation languages. For example, multi-tasking of SCR is speci ed as a systemcon guration outside C-net.
The gap between Petri net as a speci cation language and Petri net as a programming language isa serious problem in the Petri-net-based software development process. In the next section, we propose
MENDEL net to bridge this gap.

Chapter 7: MENDEL Net

111

3 MENDEL Net
A MENDEL net is a high-level Petri net for both specifying and implementing reactive and concurrent
systems. In particular, MENDEL net adopts process-oriented hierarchy and scheduling mechanism by
two-level nets, which allows the concurrent tasks, task composition, synchronous/asynchronous communication between them, and task scheduling to be explicitly represented in its model14 . By this feature,
MENDEL net is distinguished from other high-level Petri nets as a speci cation language (e.g., CPN)
and as a programming language (e.g., C-net).
A MENDEL net has the following properties in addition to the standard Petri net.

 four types of places (state element, slot, ag, and port), and port attributes,
 logic program description of transition conditions and actions, I/O interface, process-oriented net hierarchy,
 two types of communication mechanisms (synchronous and asynchronous) between processes,
 real-time scheduling mechanism by two-level nets, and several macro representations.
The above properties not only make MENDEL nets powerful enough to describe most reactive andconcurrent systems but also make it possible to automatically retract a skeleton of the MENDEL nets
to be used for a net analysis phase (veri cation and adjustment). MENDEL nets are designed to handle
detailed descriptions as well as skeleton-level analysis. The above properties are explained in detail in
the following subsections. MENDEL net has both graphical and textual representation. The graphicalform is intuitive, but not perfect (i.e., only skeletons are shown). In the following explanation, both
representations are used complementarily.

3.1 Place

The places and transitions of standard Petri nets are very general and can have a wide variety of meanings.
From the viewpoint of reactive and concurrent programs, places are classi ed into four types (stateelements, slots, ags, and ports) as shown in Fig. 62.
initialassignment:attribute:attributestateelement

slot

Figure 62.

flag

port

Four Types of Places state element: A place which represents the local state of a system. This type of place has at

most one token (i.e. it is safe). If the place has one token, it means that the system stays in thelocal state (called \the state element is active"). Otherwise, it means that the system does notstay in the local state (called \the state element is inactive"). The state elements are graphically
represented by circles. Initial assignment of active state elements is represented by arrows startingfrom bold dots.

14 MENDEL net uses a term process instead of task.

Chapter 7: MENDEL Net

112

 slot: A place that represents data and database on a static storage. This type of place has

constantly one token. The slots are graphically represented by horizontal bars similar to the datastores in Data Flow Diagram.
 ag: A place that represents a Boolean variable on a static storage. If the place has a token, theag is true, otherwise false. The ags are often used for process synchronization, that is, used as
event ags. The ag is graphically represented by combination of two horizontal bars and a circle.
 port: A place that represents an in nite bu er necessary for modeling data ow and asynchronous
communication. Furthermore, the port may have several attributes which are used as indexes oftokens. For example, a token pushed with an attribute :att can be popped with :att. Each index
organizes a FIFO queue. The ports are graphically represented by ellipses.
This classi cation produces informative structures utilized in Petri net design, analysis, understanding,and code generation. These four types of places are textually declared as follows.
states([<state_element_name>,...],[<initial_state_element_name>,...]) ;slots([<slot_name>(<initial_value>),...]) ;flags([<flag_name>(<initial_value>),...]) ;ports([<port_name>(<initial_buffer>),...]) ;Example 12 (Place Declaration)states([s1,s2,s3],[s1]) ;slots([slot1(10),slot2(ok)]) ;flags([f1(true),f2(false),f3(true)]) ;ports([p1([]),p2([1,1,2]),p3([])]) ;3.2 Transition

In MENDEL net, the transition is called a method for historical reasons. A method is graphically
represented by a rectangle. The method's ring conditions and actions are described in detail by the
inscription language based on a logic programming language LPL15 . Therefore, a MENDEL net is a kindof high-level Petri net, where the individual tokens are represented in logic program terms (atom, integer,
logical variable, and list), and the conditions and actions are described with guards and actions of LPL
clauses, respectively. The textual form of a method follows:
method(<method_name>, <exchange_term>,<input_list>,<output_list> ) :<guard> | <action> ;<guard> ::= <LPL predicate>, <LPL predicate>, ...
<action> ::= <LPL predicate>, <LPL predicate>, ...

The exchange term is used for synchronous communication which is described later. The input list
and the output list mean a list of input places and a list of output places of the method, respectively.
As the slot and port have individual tokens, they are described in the form: hslot namei(htermi) andhport namei(htermi). Regarding ports, attributes can be used to identify individual tokens in the form:
hport namei : hattributei(htermi). In MENDEL net, there is no weight function associated with arcs, andthus, during ring, just one individual token is taken from an input port and just one token is delivered
to an output port. The propagation of token information is done by uni cation of logic program termsof tokens in the same manner as in Prolog. In hguardi, only LPL predicates which have no side-e ect
are available.
A ring rule of the MENDEL net is de ned as follows.

Enabled Method Search: Search all enabled methods satisfying the following conditions.
 All input state elements of the method are active.

15 In MENDELS ZONE, the concurrent logic programming language KL1 [Ueda 90, Chikayama 92] is actually used as a
inscription language. However, we can regard the inscription language as Prolog because concurrency of KL1 does notplay an important role in MENDEL net. Here, we call it simply Logic Programming Language (LPL).

Chapter 7: MENDEL Net

113

 All input ags of the method coinside with Boolean value of ags. (flag $ true, -flag $false)
 Each term of the input slot is successfully uni ed with the term described in the method.
When the term of the method is variable, the value of the input slot term is assigned to thevariable, and then is referred in the guard and action part.
 Each input port has at least one token. When the port has attributes, there is one token withthe same attribute that the method speci es. Each term of the token is successfully uni ed
with the term described in the method. When the term of the method is variable, the valueof the input port term is assigned to the variable, and then is referred in the guard and action
part.
 The guard condition is true for the assigned variables.
Method Selection: When there are plural enabled methods, select the upper one in the program text.
Method Execution: A selected method is executed as follows.
 Evaluate an action part of the method.
 Make all input state elements inactive, and make all output state elements active.
 Make Boolean value of ags coinside with the output ags. (flag $ true, -flag $ false) Write values evaluated in the action part on each output slot.
 Pop up the uni ed token from every input port, then push one token with the value evaluatedin the action part into every output port.

A method will be brie y explained by the following example.

Example 13 (Method (Fig. 63))
method(move, _, [ready,x(N1),y(M1),type:job(ID)], [busy,x(N2),y(M2),ack(A)]) :N1>0, M1>0 | N2 := N1+1, M2 := M1+1, A=ok(ID) ;

ready
type
:job
move

x

y

ack
busy

Figure 63.

Example of Method

In this method example, the method move is enabled if the state element ready is active, there is
at least one token with an attribute job in the port type whose term can be uni ed with a variable ID,
the guard (N 1 > 0 and M 1 > 0) is satis ed where terms N 1 and M 1 are copied from the slots x andy. When the method move is executed ( red), the body (N 2 := N 1 + 1; M 2 := M 1 + 1; A = ok(ID))
is evaluated, the state element ready becomes inactive and the state element busy becomes active, theevaluated terms N 2 and M 2 are written in the slots x and y, and the token is removed from the port
type and a token whose value is ok(ID) is pushed into the port ack.

Chapter 7: MENDEL Net

114

3.3 I/O Interface

In MENDEL net, I/O interface with the environment is realized by assigning device drivers to distinguished ags, slots, and ports (called I/O ags, I/O slots, and I/O ports). Note that state elements
are not available for I/O interfaces. These distinguished places are graphically represented by doublelines of the original shapes as shown in Fig. 64. The driver assignment is done using logical addresses
io tag$hlogical addressi which indicate physical I/O addresses or program pointers of the driver programs. Actual device drivers are implemented as physical I/O addresses and driver programs which aredependent on the hardware. The ports of Fig. 64 are declared using io slots, io flags, and io ports
textually as follows. In this example, in and out mean I/O mode.

Example 14 (I/O port Example)

I/O slot and port in Fig. 64 are de ned textually as follows.
io_slots([hand1(io_tag$add1,out)]) ;io_ports([hand2(io_tag$add2,in)]) ;I/O slot (out)I/O port (in)
hand2

hand1

io_tag$add1

io_tag$add2

HardwareFigure 64.

Example of I/O Slot and Port

3.4 Process-Oriented Hierarchy
3.4.1 Overview

In order to enable large-scale system description, it is necessary to introduce module constructs into
Petri nets. Many practical high-level Petri nets provide module constructs. However, most of them areclassi ed into subnet-oriented hierarchy, that is, a part of net (subnet) is regarded as a hierarchical unit
and reduced to one node. This subnet-oriented module is inadequate to represent concurrent processes
and process composition of reactive and concurrent systems. Therefore, we propose process-oriented
hierarchy.
The hierarchical unit of MENDEL nets is a process (i.e., task). A process may consist of several
subprocesses hierarchically. While transitions of each process are executed sequentially, the process canrun concurrently according to the scheduling mechanism which will be mentioned in the following section.
The interaction between hierarchical units is de ned as synchronous and asynchronous communication
between processes. The process interface is a set of external ports and external methods. A process canpush/pop tokens to/from external ports of subprocesses. Since ports are in nite bu ers, this interaction
realizes asynchronous communication. On the other hand, a process can synchronize its own methods
with the external methods of subprocesses (i.e., re these methods simultaneously only if they are all
enabled). Since data exchange is available using the exchange term, this interaction realizes synchronous
communication. We emphasize that this process-oriented hierarchy can directly specify a compositional
structure of well-researched concurrent process theories, such as CCS, ACP, CSP, and LOTOS. Unlike
process theories, MENDEL net allows only xed composition, and therefore dynamic process creation isunavailable.

Chapter 7: MENDEL Net

115

Another characteristic feature is indirect communication between processes. In MENDEL net, processes can communicate directly only with their parent processes. Communication between processes atthe same level is realized indirectly by way of the parent process. This restriction is introduced to secure
the bene t of process reuse, since direct communication makes processes strongly interdependent.

3.4.2 Graphical Representation
plug

m01

process1

m01

p1

s01

p01

p01

p1

m1

plug
process1

s1

s01

s2

m02
m2

p2

m2

m02

p2

p02

s02

s02
m03

p02

Extensive Form

plug

Reduced Form

m03

Process-Oriented Hierarchy

Figure 65.

Figure 65 illustrates a simple example of a MENDEL net including a process-oriented hierarchy. The
external ports and external methods are represented by bold ellipses and bold rectangles, respectively.
These external ports and external methods are called plugs which mean interfaces with the parent process.
The communication between processes is represented by linking dotted lines between places/methods.
These dotted lines are semantically interpreted as transition fusion and place fusion (Fig. 66) introduced
in [Christensen 92]. In the transition fusion, fused transitions can exchange data with each other by using
hexchange termi. From the viewpoint of the parent process, a subprocess is graphically represented bya large circle.
a1

a4

port1

port2

a2

a3

a1

fusiona3

Figure 66.

a6

a5

port1+2a2a5

method2

a4

a1

a6

a4

method1
a2

a5

a4

a1
fusiona6

a3a5

method1+2
a2

a3

a6

Place and Transition Fusion

The various communication mechanisms can be realized by place and transition fusion as follows.

Chapter 7: MENDEL Net

116

 ag fusion: event ag, semaphore, port fusion: mail box,
 method fusion: rendezvous.
Since transition fusion (method fusion) realizes synchronous communication and place fusion ( ag andport fusion) realizes asynchronous communication, MENDEL net can provide two types of communication
mechanisms.

3.4.3 Textual Representation

A process textually consists of the following four parts.
 Declaration part (dec:f...g)declaration of places (state elements, slots, ags, ports)
 Body part (body:f...g)declaration of subprocesses (<process_name>(<id>,<method_list>,<place_list>)) Method part (meth:f...g)de nition of methods
 Junk part (junk:f...g)de nition of LPL clauses used in methods
A syntax of a process is de ned as follows.
process <process_name>( <external_method_list>,<external_place_list>):dec:{...} ;body:{...} ;meth:{...} ;junk:{...}}.

Place and transition fusion are speci ed by argument matching. The following MENDEL net is a
textual form of Fig. 65. In this example, ports p01 and p02 of the parent process \main" are fused withports p1 and p2 of the process \process1" respectively, because these arguments are matched in the bodypart. In the same manner, a method m02 of \main" is fused with a method m2 of \process1".
process main([],[]):{
dec:{
ports([p01([]),p02([])]) ;states([s1,s2],[s1]) ;} ;body:{
process1(pid1,[m02],[p01,p02]) ;} ;meth:{
method(m01,_,[],[p01(v1)]) ;method(m02,v2,[s01],[s02]) ;method(m03,_,[p02(X)],[]) ;};junk:{} ;}.
process process1([m2],[p1,p2]):dec:{
ports([p1(_),p2(_)]) ;states([s1,s2],[s1]) ;} ;meth:{
method(m1,_,[s1,p1(X)],[s2]) ;method(m2,X,[s2],[s1,p2(X)]) ;} ;junk:{} ;}.

Chapter 7: MENDEL Net

117

The above example shows communication between a parent process and a child process. Communication between processes at the same level ( rst cousin processes) is described as follows. In this example,
the method m1 play the role of communication channel. In the body part, each process is given di erent
process identi cation (e.g., pid1, pid2) which makes it possible to create plural instances of the sameprocess.
process main([],[]):{
dec:{
ports([p1([]),p2([])]) ;} ;body:{
process1(pid1,[],[p1]) ;process1(pid2,[],[p2]) ;} ;meth:{
method(m1,_,[p1(X)],[p2(X)]) ;};junk:{} ;}.

3.5 Process Scheduling Mechanism

In specifying and programming for actual reactive and concurrent systems, a scheduling mechanism plays
an important role. Without information about the scheduling mechanism, simulation and analysis of themodel may di er from the actual situation and become imperfect in the timing aspect, and usable only
for checking the functional aspect. To introduce the scheduling mechanism into the Petri net model,
there are three approaches.
 all-in-one type: Both an application and a scheduler are described in the same Petri net model.
 separation type: An application is described by Petri nets, and a scheduler is described byanother model. While the interface with the scheduler may be provided in Petri nets, the schedulingmechanism itself is out of the Petri net model. Most Petri-net-based programming languages (e.g.,
C-net/SCR) are of this type.
 two-level type: An application and a scheduler are described in two Petri nets of di erent levels;
base-level net and meta-level net. A base-level net describes an application and a meta-level net
describes a scheduler.
Since a Petri net is not only used to specify concurrent programs but also suitable for describing
schedulers [Vallejo 94], we adopt the two-level net approach for MENDEL net (Fig. 67). Merits of the
two-level net include model consistency as compared with the separation type and easiness of description
and maintenance as compared with the all-in-one type.
scheduling commands
through meta-places

Base-Level
MENDEL net(Application)

Meta-Level
MENDEL net(Scheduler)
process status information
shared by both levels

Figure 67.

Two-Level MENDEL Nets

To specify interaction between base-level net and meta-level net, we introduce the notions of metaplace and token sharing.
 meta-place: A base-level net has special places, called meta-places, which are shared with a metalevel net by place fusion, and used to communicate with a meta-level net. A token that is put intoa meta-place in the base-level net is taken out and used in a meta-level net. These tokens represent
scheduling commands in MENDEL nets.

Chapter 7: MENDEL Net

118 token sharing: Some tokens in a base-level net can be shared with a meta-level net. Concretely,a meta-level net can change information of shared tokens which are referred to in a based-level net.
Shared tokens are used to change and refer to the status of processes from both a base-level net
and a meta-level net.

In the following sections, the process scheduling mechanism using two-level nets, token sharing, andmeta-place is described in detail.

3.5.1 Base-Level MENDEL Net

Since a base-level MENDEL net has already been described in the previous sections (3.1 { 3.4), we explain
several scheduling commands (tokens) sent from the application (base-level net) to the scheduler (metalevel net) via meta-places. Primitive scheduling commands include sta_prc, ter_prc, and sus_prc
which are also used in the real-time operating system -ITRON [Fukuoka 91] are brie y explained asfollows.

 sta prc(Proc,Prio): start the process at a processor Proc with a priority Prio.
 ter prc: terminate the process.
 sus prc: suspend the process.
One meta-place is established corresponding to each process. In other words, each process has one
meta-place which accepts scheduling commands from other processes or from the process itself. We callthe meta-place process place. Graphically we use a large circle representing a process for its process place(Fig. 68).
process
place

m1
process2:sta_prc(1,2)

Figure 68.

process1:ter_prc

Process Place and Scheduling Commands

A process place is textually identi ed as hprocess idi. When sending commands to itself, self is usedinstead of hprocess idi. For example, a MENDEL net of Fig. 68 is textually described as follows. In thisexample, p1 represents hprocess idi.
process process1([],[]):{
dec:{}
body:{
process2(p1,[],[]) ;} ;meth:{
method(m1,_,[],[p1:sta_prc(1,2),self:ter_prc]) ;} ;junk:{}}.

3.5.2 Meta-Level MENDEL Net

A scheduler is described as a meta-level net. A meta-level net manipulates tokens representing process
status, called process status token, which are initially created by the sta prc command. When the sta prc
command is sent to a process place in the base-level net, all initial state elements of the correspondingChapter 7: MENDEL Net

119

process are marked with tokens which have a process status information PSI . At the same time, thecorresponding process place in the meta-level net has a process status token which has the same PSI .
It is token sharing; tokens in initial state elements in the base-level net and a token in a process placein the meta-level net share the same PSI . While usual individual tokens have values, these tokens havereferences to the shared PSI (Fig. 69).
usual token

shared token

reference

value

reference

value

Figure 69.

Shared Token

There are the following process statuses in PSI .
 PSI.meta: process status changed by a meta-level net
e.g., PSI:meta 2 factive; ready; wait; suspended; wait suspended; deadg
 PSI.base: process status changed by a base-level net
e.g., PSI:meta 2 fenabled; disabledg
A process scheduler (meta-level net) can change process status (PSI.meta), which indicates a placewith the corresponding process token. In the base-level net, only active tokens (i.e., tokens PSI of whichis active) are available at method ring. As dead tokens can never be changed to active unless the process
is restated again, they can be removed from the base-level net. On the other hand, a base-level net canchange process status, enabled and disabled. When there are enabled methods regardless of PSI.meta,
a process status becomes enabled, otherwise it becomes disabled. This status information (enabled or
disabled) is used for process dispatching in the scheduler.
For example, a simple scheduler is described in Fig. 70 which is based on subset of -ITRON for asingle processor. A place process if is an interface with a base-level net which forms place fusion withprocess places. Functional inscriptions of transitions are described by LPL as follows.
 t1 (dispatch): The scheduler selects a process which is in the ready place and has the highest
priority and moves it to the active place.
 t2 (preempt): When a process has just become in the ready place and has higher priority thanthe process in the active place, the scheduler exchanges status of these processes.
 t3 (wait): When the active process has no enabled transitions in the base-level net (i.e., PSI:base =disabled), it is moved from the active place to the wait place.
 t4 (ready): When the waiting condition of the wait process is satis ed in the base-level net (i.e.,
PSI:base = enabled), it is moved from the wait place to the ready place.
 t5 { t18: omitted.

3.6 Timer

Concerning real-time extension of Petri nets, we adopt timers prepared as a built-in subnet,
sys$timer(<tid>,[],[op,up]).

Here, a setting/resetting port (op(set),op(reset)) and a referring ag (up) mean the interface of thetimer.

Chapter 7: MENDEL Net

120
P

t1

P

ready

P1

p1

active
P1

p3

t2

P2

P2
t3
P

t5

t4

p2

P
wait

P
t12

t9
t13
P
t14

waitsuspended

t10

t15
t7
t16
t8

t11

suspended

t6

t17

P

P
dead

sta_prc(P)sus_prc(P)ter_prc(P)rsm_prc(P)Figure 70.

process_if

Simple Scheduler Example (-ITRON)

process process([],[]){
dec:{states([s1,s2],[s1]) ;ports([op([])]) ;flags([up]) ;};body:{
sys$timer(t1,[],[op,up]) ;} ;meth:{
method(m1,_,[s1],[s2,op(set)]) ;method(m2,_,[s2,up],[s1,op(reset)]) ;} ;junk:{}}.

3.7 Macro Notations

Generally speaking, actual descriptions by Petri nets are often troublesome. Macro notations are very
useful in practice. Here, one of the macro notations, array representation, is introduced.

Array Representation Occasionally, a reactive and concurrent system contains several subprocesses

having the same structure. For example, a lift system may have several request buttons corresponding toevery oor. It is tedious to individually write all button processes. To overcome this problem, coloured
Petri nets represent these subprocesses as separate coloured tokens on a single net structure. However,this approach is not suitable for the process-oriented hierarchy, because a process is a hierarchical unit
and tokens should not be a process. Therefore, a MENDEL net provides an alternative: an array toChapter 7: MENDEL Net

121

represent several subprocesses with the same structure, in the same manner as the CSP-based concurrent
programming language Occam. Each arrayed process can be explicitly treated as a separate computing
unit that can run on a separate CPU. Figure 71 shows a graphical array representation of N identicalprocesses, whose textual form follows.

processfI g(mfI g)(infI g)(outfI g)  I : f1::N g
on {I}

proc {I}m {I}out {I}
Figure 71.

Graphical Representation of Array

4 Simple Example
A simple example of a MENDEL net (base-level net) is shown in Fig. 72, which describes a part of acontrol program of a telephone terminal. This MENDEL net speci es how the phone terminal becomesconnected. The MENDEL net consists of ve processes (main, phone, calling, hook, and ring), where
process main activates other processes by sending sta prc commands to process places. In these processes
calling and hook, I/O ports call driver and up driver are de ned which detect input events from theenvironment, calling and taking up the receiver, respectively. After detecting calling, a process phonereceives a token from a port call of the process calling and makes a ag bell of a process ring active. In
succession, the process ring sets an output slot bell driver on and o to ring a bell intermittently using
a built-in subnet sys$timer. Finally, after detecting taking up the receiver, the process phone makes theag bell inactive, then the process ring stops ringing the bell.
/* main */process main([],[]):{
dec:{states([start],[start]) ;ports([call([]),up([])]) ;flags([bell(false)]) ;};body:{
phone(p1,[],[call,up,bell]) ;calling(p2,[],[call]) ;hook(p3,[],[up]) ;ring(p4,[],[bell]) ;};
meth:{
method(m1,[start],[p1:sta_prc(1,4),p2:sta_prc(1,2),p3:sta_prc(1,1),p4:sta_prc(1,3)) ;};junk:{};}.

/* phone */process phone([],[call,up,bell]):{dec:{

Chapter 7: MENDEL Net

122:sta_prcm1
start:sta_prc

sys$timertup

call_driver:sta_prcp4(ring)p2(calling):sta_prc

topt1

p1(phone)standby

call

call

s_off

call

p3(hook)
bell

t1

t1

t2

ringing
bell

up_driver
bell

s_on

up

t2

t1

t2
up

connnected

bell_driver

Figure 72.

Example (Telephone Terminal)upChapter 7: MENDEL Net

123

ports([call(_),up(_)]) ;flags([bell(_)]) ;states([standby,ringing,connected],[standby]) ;};body:{};
meth:{
method(t1,_,[standby,call(on)],[ringing,bell]) ;method(t2,_,[ringing,up(on)],[connected,-bell]) ;};junk:{};}.
/* calling */process calling([],[call]):{dec:{
io_ports([call_driver(io_tag$call,in)]) ;ports([call(_)]) ;};body:{};
meth:{
method(t1,_,[call_driver(_)],[call(on)]) ;};junk:{};}.
/* hook */process hook([],[up]):{dec:{
io_ports([up_driver(io_tag$up,in)]) ;ports([up(_)]) ;};body:{};
meth:{
method(t1,_,[up_driver(up)],[up(on)]) ;method(t2,_,[up_driver(_)],[]) ;};junk:{};}.
/* ring */process ring([],[bell]):{dec:{
io_ports([bell_driver(io_tag$bell,out)]) ;ports([top([])]) ;flags([bell(_),tup(false)]) ;states([s_off,s_on][s_off]) ;};body:{
sys$timer(tim,[],[top,tup]) ;};meth:{
method(t1,_,[s_off,bell],[s_on,top(set),bell_driver(on)]) ;method(t2,_,[s_on,up],[s_off,bell_driver(off),top(reset)]) ;};junk:{};}.

5 Related Works: Petri Nets and Hierarchy
Several hierarchies in Coloured Petri Net (CPN) were proposed in [Huber 90]. They introduced thenotion of pages (i.e., net modules), substitution transitions and substitution places, where a substitution
transition/place is a macro node and represents a subpage which contains the detail of how it actually
performs the activity. It means subnet-oriented net hierarchy. Only the substitution transition is adopted
in DESIGN/CPN and this version is usually called Hierarchical Coloured Petri Net (HCPN). Modular
Coloured Petri Net (MCPN) [Christensen 92] extends HCPN by incorporating both place and transition
fusion. A more exible form of transition fusion was also proposed by extending CPN with synchronization channels [Christensen 94]. MCPN and CPN with synchronization channels are intended to represent
a process-oriented net hierarchy, which is similar to the hierarchy of MENDEL nets although they have

Chapter 7: MENDEL Net

124

been proposed apart from MENDEL net. Furthermore, Object Petri Net (OPN) [Lakos 95] has not only aprocess-oriented and subnet-oriented net hierarchy but also a token-oriented net hierarchy, where tokens
are allowed to be subnets encapsulating their own activity 16 . Other approaches of process-oriented net
hierarchy include OBJSA net [Battiston 88] and Protob [Bruno 95]. OBJSA nets combine nets with algebraic speci cation techniques and support process composition by transition fusion. Process composition
by transition fusion is advantageous for compositional analysis techniques. OBJSA net is similar to LOTOS which combines CCS with algebraic speci cation techniques, where label synchronization of LOTOS
is the same as transition fusion, and G-LOTOS [Bolognesi 89, Lee 91] provides a graphical representation
with a process-oriented hierarchy of LOTOS. Protob is a high-level Petri net in which systems can be
structured according to the principles of object orientation. An object model is a system's component
and its behavior is given by a net. Objects are enabled to communicate with other objects by interface
places. The structure of objects in Protob is a tree; a compound object contains other objects. This
compositional structure is very similar to MENDEL net. However, Protob is, if anything, a speci cation
language and objects in Protob do not directly correspond to concurrent processes. Compared withthese high-level nets with process-oriented net hierarchy, MENDEL nets are strongly process-oriented
because process scheduling mechanism and I/O devices can be explicitly speci ed within the MENDEL
net framework. In other words, MENDEL nets are intended to be a programming language rather thana speci cation language.

6 SummaryThis chapter considered a Petri net as a programming language for reactive and concurrent systems.
Although several Petri-net-based programming languages for reactive and concurrent systems have been
proposed, they are short of abstraction mechanisms and there is a large gap between Petri net as a
speci cation language and Petri net as an implementation language. On the other hand, high-level Petrinets are lacking in several important features (e.g. concurrent tasks, task communication/synchronization,
I/O interface, and task scheduling) for programming reactive and concurrent systems. Therefore we
proposed a high-level Petri net, MENDEL net, for reactive and concurrent systems to bridge the gap
between a speci cation language and an implementation language.
A MENDEL net features the following properties in addition to standard Petri nets.
 I/O interface, process-oriented net hierarchy, and task scheduling mechanism modeled by two-level net approach.
MENDEL nets are used as a speci cation and programming language in the programming environment
MENDELS ZONE.

Syntax of MENDEL Net Textual Representation<program> ::= <process> | <program><process> ::='process' <process_name> '(' <external_method_list> ',' <external_place_list> ')'':' '{'<declaration_part> ';'<body_part> ';'<method_part> ';'<junk_part> ';''}' '.'

16 There have been several proposals for combining object-orientation with Petri nets. They are classi ed into object inside
nets and Petri nets inside objects; in the former tokens are objects (e.g., OPN), in the latter Petri nets are used forspecifying the behavior of individual objects (e.g., HOOD nets [Giovanni91]). In the latter approach, hierarchy is notnecessarily provided by Petri nets.

Chapter 7: MENDEL Net

125<declaration_part> ::='dec' ':' '{'<declaration_list>'}'<declaration_list> ::=<declaration> ';' | <declaration_list><declaration> ::=<state_declaration> |<slot_declaration> |<flag_declaration> |<port_declaration><state_declaration> ::='states' '(' <state_list> ',' <initial_state_list> ')'<state_list> ::='[' { <state_element_name> ',' }* <state_element_name> ']' | '[' ']'<initial_state_list> ::='[' { <state_element_name> ',' }* <state_element_name> ']' | '[' ']'<slot_declaration> ::='slots' '(' <slot_list> ')' |'io_slots' '(' <io_slot_list> ')'<slot_list> ::= '[' { <slot_name> '(' <initial_value> ')' ',' }*<slot_name> '(' <initial_value> ')' ']'| '[' ']'
<io_slot_list> ::= '[' {<io_slot> ',' }*<io_slot> ']' | '[' ']'<io_slot> ::= <slot_name> '(' 'io_tag' '$' <logical_address>, <io_mode> ')'<flag_declaration> ::='flags' '(' <flag_list> ')' |'io_flags' '(' <io_flag_list> ')'<flag_list> ::= '[' { <flag_name> '(' <initial_value> ')' ',' }*<flag_name> '(' <initial_value> ')' ']'| '[' ']'
<port_declaration> ::='ports' '(' <port_list> ')' |'io_ports' '(' <io_port_list> ')'<port_list> ::= '[' { <port_name> '(' <initial_value> ')' ',' }*<port_name> '(' <initial_value> ')' ']'| '[' ']'
<body_part> ::= 'body' ':' '{'{ <process_call> ; }*'}'<process_call> ::= <process_name> '('<process_id> ','<external_method_list> ','<external_place_list> ')'<method_part> ::= 'meth' ':' '{'{ <method> ; }*'}'<method> ::= 'method(' <method_name> ',' <exchange_term> ','<input_place_list> ',' <output_place_list> ')' ':-'
<guard> '|' <action><input_place_list> ::='[' { <place> ',' }* <place> ']' | '[' ']'<output_place_list> ::= '[' { <place> ',' }* <place> ']' | '[' ']'<place> ::= <state_element> | <flag> | <slot> | <port><state_element> ::= <state_element_name>Chapter 7: MENDEL Net

126<flag> ::= <flag_name><slot> ::= <slot_name> '(' <LPL_term> ')'<port> ::= <port_name> '(' { <LPL_term> | <attribute> ':' <LPL_term> } ')'<guard> ::= { <LPL_predicate> ',' }* <LPL_predicate><action> ::= { <LPL_predicate> ',' }* <LPL_predicate><junk_part> ::= 'junk' ':' '{'{ <LPL_clause> ; }*'}'Chapter 8

Petri-Net-Oriented Design
Methodology
This chapter proposes a design methodology for MENDEL nets. Although many Petri net tools have been
proposed, most tools support only drawing, simulation, and analysis of Petri nets; few tools support thedesign methodology for Petri nets. While Petri nets are good nal design documents easy to understand,analyzable, and executable, it is often dicult to write Petri nets directly in an earlier design phase when
the system structure is obscure. A proposed design method makes a designer to construct MENDEL nets
stepwise and systematically using causality matrices and temporal logic.

1 Petri-Net-Oriented Design Methodology
As mentioned in Chapter 1, Petri nets are often inadequate in an early design phase when some partsof the system structure may be obscure. Particularly, while the structures of local processes, called
elementary processes, are usually tangible and able to be easily designed, the structures of a process tocoordinate elementary processes, called coordinator process, are often obscure at rst in a reactive andconcurrent systems. Since a Petri net is a formal language and does not permit vagueness, it is dicult
to design systems from beginning to end using only Petri net.
We focus on control systems which are typical instances of reactive and concurrent systems, and thenpropose a design method for them utilizing MENDEL net and additional complementary formalisms(causality matrix and temporal logic). The causality matrix represents causality relations among systemelements. It allows vagueness (abstract level description), so a designer can stepwise re ne the causality
matrix from an abstract level to a concrete level. Furthermore, draft Petri nets which are synthesizedfrom the causality matrix are validated using temporal logic. By doing these stepwise re nements, thedesigner can construct a correct MENDEL net systematically.
The proposed design method consists of the following phases.
1. Initially elementary processes (i.e., tangible or concrete processes) which have interfaces with controlled objects (environment) and manipulate them are designed by MENDEL nets.
2. Coordinators (i.e., conceptual processes) are created to coordinate elementary processes and elementary processes are interconnected with them by communication channels.
3. Coordinators are designed by stepwise re nement using the causality matrix, and MENDEL nets
are nally produced which represent these coordinators.
4. A target system which consists of elementary processes and coordinators are described by MENDEL
nets and are validated by simulation, veri cation, and adjustment.
The remainder of this chapter is organized as follows. Section 2 shows a typical software architectureof control systems. The causality matrix is described in Section 3. A detail procedure of the proposed
design method is given in Section 4. Section 5 describes a MENDEL net design example for a lift system,
followed by related works and a summary in Section 6 and Section 7.
127

Chapter 8: Petri-Net-Oriented Design Methodology

128

2 Software Architecture of Control Systems
First we show a typical model of control software (Fig. 73). In this model, control software consists ofelementary processes and coordinator processes.

Elementary process: This process corresponds to some controlled object in the problem domain andmanages I/O devices to control them. For example, in a plant control system, valves pumps, andmotors are controlled objects.
Coordinator process: This process corresponds to a set of functions required for controlling controlled
objects. This process coordinates elementary processes to accomplish these functions. The coordinator may be consists of a set coordinator processes.
Controller

Controlled Objects
D

EP

Control
Software

D
D

EP

D
D

EP

Coordinator

D
D

EP

D
D

EP

D
EP = elementary process, D = I/O device

Figure 73.

Model of Control Software

3 Causality Matrix
The causality matrix, C=[cij ], is a type of an extended incidence matrix of a Petri net (Fig. 74), where
each entry, cij , represents a causality relation between an i-th operator (i.e., method) and a j -th operand(i.e., state element, ag, slot, port, or external method). One of unique features of the causality matrix is
its wide-spectrum property that the causality relation of each entry can range from an abstract level to a
concrete level (we call this a wide-spectrum causality relation). Table 13 shows wide-spectrum causality
relations. For example, c11 =\+" of Fig. 74 is an abstract level relation representing only existence ofrelation between the operator opr1 and the operand opd1; the details of the relation are not given at
this level. On the other hand, c23 =\pop:X" is a concrete level relation in which the operator opr2 popsa token from the operand opd3 and uni es the color of the token with X (i.e., X is assigned the colorof the token). A designer stepwise re nes operators, operands, and causality relations from an abstractlevel to a concrete level, which is regarded as a design process. The wide-spectrum causality matrix has
the following advantages compared with graphical Petri net representations.

 The binary relation in the matrix is more adequate for system element analysis in the earlier designphase. It is much easier for a designer to decide what is a local abstract relation between every twoelements than to directly draw a rigid Petri net.
 A spread-sheet editor for the matrix can provide powerful editing abilities. Copying, eliminating,decomposing, browsing, focusing, and checking can be implemented more easily than by a graphical one. Furthermore, graphical representations are dicult to perceive without good topologicalChapter 8: Petri-Net-Oriented Design Methodology

operand

opd1

opd2

state
operator

opd3

opd4

port

guard

body

external

opr1

+

push

opr2

in

pop:X

opr3

>

opr4

+

opr5

+

+

X>0

true

+
+

<

Figure 74.

Table 13.

LEVEL
Abstract level

129

pp

Causality Matrix

Wide-Spectrum Causality Relations

RELATION EXPLANATION+
some relation
blank no relation/unde ned
Intermediate level (1) <input/cause>
output/e ect
Intermediate level (2) sync
synchronizationrw
read or write from/to slot
pp
pop or push from/to port
transstate transition
Intermediate level (3) insync
synchronization with input data
outsync
synchronization with output datareadread from slot
write
write to slot
pop
pop from port
push
push to portinreference of statefromtransition from statetotransition to state
Concrete level
KL1
KL1 codeChapter 8: Petri-Net-Oriented Design Methodology

130

arrangement. Current automatic topological arrangements in Petri net tools are not yet goodenough.
 The wide-spectrum property makes backtracking easier. Backtracking is inevitable in a design
process. However, the wide-spectrum property enables the designer to manipulate only common andconsistent design documents (causality matrices) throughout the design process, which minimizes
the modi cation e orts in backtracking.
A concrete causality matrix can be transformed straightforward into a process of MENDEL nets. In
other words, a causality matrix is a matrix-based representation of MENDEL nets which allows vaguenessand informality. Figure 75 shows an example of straightforward transformation from a matrix to a processof MENDEL nets. Remark that each matrix corresponds to one process and does not have a hierarchicalstructure in itself, which should be represented by MENDEL nets.
operand

free

busy

data

input

output

state

state

slot

port

port

operator

external

get

from

to

write:X

put

to

from

read:X

guard

body

X>0

true

true

Y:=X+1

external

pop:X
push:Y

free
input

get

output

data

put

busy

Figure 75.

Transformation from a Causality Matrix to a Net

4 Design Method
The proposed design method consists of four phases; design of elementary processes (Phase 1), processinterconnection and coordinator creation (Phase 2), design of coordinators (Phase 3), and validation(Phase 4).
First, Phase 1 and Phase 2 are carried out using directly MENDEL net because elementary processes
are not so obscure. Then, the design of the coordinator whose structure may be obscure is done by
stepwise re nement using the wide-spectrum causality matrix. A procedure of the matrix re nement issummarized as follows.
step 1: method recognition
step 2: port and slot recognition
step 3: state recognition
step 4: functional re nement (writing LPL code)
Finally, MENDEL nets are veri ed and adjusted using PLTL, and executed visually. Figure 76 outlines
the ow chart of the following design methodology.

Chapter 8: Petri-Net-Oriented Design Methodology

131

start

P1-S1: Find elementary processes

Phase 1

P1-S2: Construct MENDEL nets

P2: Interconnect subprocesses
and create coordinator

Phase 2Phase 3P3-S1: Recognize methods

P3-R1: Backtrack

P3-S2: Recognize slots and ports
P3-S3: Recognize states
P3-S4: Describe LPL code
P3-S5: Generate MENDEL net

P4-S1: Simulate

P3-R2: Refine

P3-R3:
Decompose
coordinator

Phase 4P4-S2: Verify
P4-S3: Adjust

stop

Figure 76.

Design Method (Flow Chart)Chapter 8: Petri-Net-Oriented Design Methodology

132[Phase 1](Step 1) Find elementary processes:

Find all elementary processes whose structure is well de ned, and enumerate the methods, slots,
and ports for each process. Most hardware-constrained processes are elementary. For example, cageis one of the elementary processes in a lift system, and its methods include move up, move down,
open door, and close door.
(Step2) Construct a MENDEL net for each elementary process:Construct a MENDEL net for each elementary process by appending the state elements and arrows
to the methods, slots, and ports listed in step 1. Then, classify each port and method as external
one which becomes a plug and is accessed from other processes or internal one.

[Phase 2] Interconnect elementary processes and create a coordinator:

Create a new process (parent process) that consists of the elementary processes (subprocesses). Interconnect the plugs of these subprocesses with asynchronous communication and synchronous communication. Some plugs which cannot be directly connected may remain; in this case some process is required
to coordinate them. Create a new subprocess (the coordinator) and connect the remaining plugs to it.
Note that an initial coordinator has only external ports and methods that are connected to the remaining
plugs of the elementary processes.

[Phase 3](Step 1) Create an initial causality matrix and recognize methods:

Create an initial causality matrix of the coordinator, in which only external ports and methods,
listed in phase 1, are lled. Then, recognize all functions (method candidates) of the coordinatorand ll them in the matrix.
(Step 2) Recognize internal ports and slots:
Judge existence of the causality relation between external/internal methods and external ports, andll abstract level judgment (+ or blank) in the matrix. Stepwise re ne these causality relations
into a less abstract level. This stepwise re nement helps a designer to recognize additional internal
ports and slots which are necessary to re ne the causality relations.
(Step 3) Recognize state elements:
Find logical state elements of the coordinator (e.g., active, sleep, waiting, busy), and add themand ll causality relations in the matrix. In the causality relation, each method should be decided
whether it is enabled or not in each logical state. In addition, consider the partial ordering of
method ring, and introduce dummy control state elements to put method ring in order.
(Step 4) Describe method inscriptions:
Describe the detailed condition and action for each method by logic programming language. At
this point, the causality matrix reaches its most concrete level.
(Step 5) Generate MENDEL net processes:
Finally, generate MENDEL net processes of coordinators straightforward from the most concretelevel matrices.
In addition, the following design rules are applicable during Phase 3.
(Rule 1) Cause design backtracking:
When any design failures or unexpected functions that require structural rearrangements are detected, go back to any previous steps in Phase 3.
(Rule 2) Re ne methods, slots, and ports:
Decompose and modify methods, ports, and slots if they have compound functions or meanings.
(Rule 3) Decompose coordinators:
Decompose coordinators if the coordinator becomes too large or too complex.

Chapter 8: Petri-Net-Oriented Design Methodology

133[Phase 4] Validate constructed MENDEL nets:(Step 1) Simulation:

Execute MENDEL net by a simulator, and con rm that it works well (i.e., it satis es your requirements).
(Step 2) Veri cation:
Specify timing constrains for the target system using PLTL which are derived from the original
informal speci cation. Then, verify and analyze whether the constructed MENDEL net satis es
these PLTL constraints (e.g., deadlock-free, interlock).
(Step 3) Adjustment:
If the MENDEL net does not satisfy all the speci ed PLTL constraints, the designer must adjust
the MENDEL net to satisfy them, manually using a MENDEL net editor or automatically using
the program adjustment mechanism described in Chapter 6.

5 Example: Lift Control System
5.1 Problem

This problem is a revised version of the popular problem presented for the 4th International Workshop
on Software Speci cation and Design [IWSSD 87].

List Control System:

One lift is to be installed in a building with M oors. The problem concerns the logic to movecages between oors according to the following constraints:

 The cage has a set of buttons, one for each oor. These illuminate when pressed and cause thecage to visit the corresponding oor. The illumination is canceled when the corresponding
oor is visited by the cage, or when the button is pulled out (canceling the request).
 Each oor has two buttons, one to request an up-lift and another to request a down-lift.
These illuminate when pressed. The illumination is canceled when a cage visits the oor andis either moving in the desired direction, or has no outstanding requests. The illumination
may also be canceled by pulling the button out (canceling the request).

5.2 Observation of actual design process

The actual design process of the lift system will be traced using MENDELS ZONE. Here, \Pi -Sj :" means
Step j of Phase i; it is an index for the design methodology.
(1) P1-S1: This lift system has four elementary processes: cage, button, oor button panel, andcage button panel.
(2) P1-S2: The constructed MENDEL nets of these elementary processes are shown in Fig. 77.
oor button panel, and cage button panel are constructed as parent processes of buttons. However, since they are very physical and require no coordinators, they ware regarded as elementary
processes. Remark, c = cage, f = oor, req = request, can = cancel, vis = visit.
(3) P2: The top level lift system is constructed by interconnecting 3 subprocesses: cage, oor button panel
and cage button panel. Here are all plugs (open, up, down, c req, c can, c vis, f req, f can, f vis)
remain unconnected. Therefore we create a coordinator process, and connect remaining plugs toit (Fig. 78).
(4) P3-S1: The initial causality matrix is created. It has 6 external ports and 3 external methods
corresponding to the plugs initially connected in (3). We nd the following functions (method
candidates) of the coordinator and enter them in the matrix:
 open: open the door of the cage when the cage visits the requested oor.

Chapter 8: Petri-Net-Oriented Design Methodology

134

cage

vis!

button

open

up

on

off

close

down
req

can

req

f_vis

up_viscanc_vis

dn_visvis
buttonbuttonbutton[i]req

up_req

f_req

f_can

c_req

floor_button_panel

Figure 77.

c_can

cage_button_panel

Elementary Processes of Lift Control System

req

can

f_vis
f_can
floor_
button_
panel
[i]

up

down

f_req

coordi
nator

cage

c_vis

open
c_can

cage_
button_
panel

c_req

Figure 78.

canProcess Interconnection and Coordinator Creation

Chapter 8: Petri-Net-Oriented Design Methodology135 up: move up to the target oor.
 down: move down to the target oor.
 c req / f req: accept requests from the cage button panel / oor button panel.
 c can / f can : delete the canceled oor from the request queue.
 c vis / f vis : acknowledge the cage button panel / oor button panel when the cage arrives

at the requested oor.
(5) P3-S2: Causality relations are entered at the abstract level. We recognize 3 internal slot candidates (req que, current f, target f) and one additional method candidate (start), and add them tothe matrix (Fig. 79).

open
up
down
c req
c can
c vis
f req
f can
f vis
start

open
methodexternal
+

open
up
down
c req
c can
c vis
f req
f can
f vis
start

up
methodexternal
+

down
c req
methodport
external external
+

f vis
port
external+

req que
slot+++
Figure 79.

+
+
+

c can
port
external

+

c bis
f req
port
port
external external

+

+

f can
port
external+

current f target f
slot
slot
guard body
+

+

+

+
+

+
+

+
+

Causality Matrix (Abstract Level) req que: a request queue in which all requests are stored.
 current f: the number of the current oor that the cage is currently staying.
 target f: the number of the target oor to which the cage will go.
 start: select a target oor from the request queue.
(6) P3-R2&S3: While re ning the causality relations stepwise, we re ne the operators and operands,
and recognize new state elements. The following case shows a fragment of this re nement andstate recognition process. When re ning the operator c can (Fig. 80(a)), that is a local view ofthe matrix, we notice that there are two cases.
Case 1: The canceled request remains in req que.
Case 2: The canceled request has already been selected as target f.
Here, we divide c can into c can 1 (case 1) and c can 2 (case 2), and try to re ne each operator.
Then, we recognize that the states (active and sleep) are necessary to re ne c can 2, and introduce
them. Finally, the matrix shown in Fig. 80 (b) is derived.

Chapter 8: Petri-Net-Oriented Design Methodology

c can
port
c can

pop

136

(a) Original Matrix
req queslot

target f
slot

rw

read

guard body

@@

c can
port
c can 1 pop:Xc can 2 pop:X(b) Re ned Matrix

req queslot
read:Q1, write:Q2
Figure 80.

target f
slot

active
state

sleep
state

guard

body

read:Y
read:Y

in
from

to

Xn=Y
X=Y

cancel r (X,Q1,Q2)
true

Causality Matrix (Re nement Example)(7) P3-R1: We notice that we have missed the fact that the cage should stop and open the door at
the oor that is stored in the req que even if it is not a current target. Consequently, we must
backtrack and modify the design; we must modify the method open.
(8) P3-R3: The coordinator is divided into 2 coordinators (cage controller and request controller),because the matrix becomes somewhat complex; so it is natural to divide its functions into thecage controller and the request controller. During this dividing, the following interface plugs(external ports) are introduced.
 start: acknowledge that the cage has started.
 end: acknowledge that the cage has visited the target oor.
 exit: acknowledge that the request has been canceled.
 current: inform the current oor that the cage is staying.
 command: command that the cage opens the door or not.
Divide the matrix into new two matrices which corresponds to generated coordinator processes(cage controller and request controller).
(9) P3-S3 (for cage controller): After checking for any method con icts, we introduce 9 dummy
control state elements (active, sleep, etc.) to serialize the methods (current, command, open, pass,up, and down) to avoid the con icts.
(10) P3-S5: We implement inscriptions used in the methods (e.g., cancel r of Fig. 80) which completes the stepwise re nement of the matrix. The nal causality matrix of the cage controller isshown in Fig. 81. From this matrix, MENDEL nets of the lift system can be generated automatically. Fig. 82 shows the top level process (lift system), and Fig. 83 shows one of the subprocesses(cage controller). In (b), slots are hide in the display for simpli cation, and a triangle represents
OR-connection of synchronous communication.
(11) We can verify at its skeleton level whether or not this system satis es the following constraints.
 Deadlock freedom of a cage:
PLTL formula = 2}(open _ up _ down) Once a k-th oor is requested, the cage eventually visits the oor and opens the door unlessthe request is not canceled:
PLTL formula = 2(((c req(k) _ f req(k)) ^ 2(:c can(k) ^ :f can(k)))  }open(k))
In this case it is fortunately assured that this system satis es these constraints in the skeleton
level, so no adjustments are necessary.

Chapter 8: Petri-Net-Oriented Design Methodology

open
end
exit
start
check1check2current
pass
opencheck3check4
up
down

open
methodexternal
outsyncup
methodexternal

down
methodexternal

start
port
external
pop:X

exit
methodexternal
insync137

end
methodexternal

commandport
external

current
port
external

outsynctotofrompush:CF

pop:COM
pop:COM

outsync
outsync

open
end
exit
start
check1check2current
pass
opencheck3check4up
downtarget f wait op
slot
state

end
state

from

to
from

ch
state

wait com move
state
state

from

c oor
slot

to
from
from

to
to
from
from

guard

true
true
true
true
read:(X, )X=Y
read:(X, )Xn =Y
read:CFtrue
COM=pass
COM=openread:(X, )X<Y
read:(X, )X>Y
read:(X, ),write:(Y,up)
true
read:(X, ),write:(Y,down)
true
Figure 81.

up
port

down
port

pop:X

to

read:Y
read:Y

open
end
exit
start
check1check2current
pass
opencheck3check4
up
down

from
to
from
from

to
to

outsync

write:X
read:Y
read:Ysleep active
state state

to
from

body

true
true
true
true
true
true
true
true
true
true
true
Y:=X+1
Y:=X-1

Causality Matrix (Concrete Level)

to
from

Chapter 8: Petri-Net-Oriented Design Methodology

down

up

138

cage_
button_panel

c_vis c_can

cage

c_req

exit

f_req

open

cage_
controller

floor_
button_
panel

f_can

request_controller

f_vis
end
current
start

commandFigure 82.

Constructed MENDEL nets (lift system)

start

commandactivechsleep

currentpass

wait_com

end

open

move

open

current
open

Figure 83.

Constructed MENDEL nets (cage controller)

Chapter 8: Petri-Net-Oriented Design Methodology

139

5.3 Qualitative Evaluation

We brie y show our experiences of the lift system design. When we designed it using only a Petri net
editor and with no methodology, we abandoned the use of the editor and did paper works in the earlier
design phase because backtracking caused tedious editing and rearrangement. We used a Petri net editor
only for a fair copy of the paper works. On the other hand, when we use the causality matrix and the
MENDEL net editor according the proposed design method, we succeed to nish design of the lift system
without escaping paper works.

6 Related Works
We believe that existing competitors to the proposed design method are RTSAD [Ward 86], OOAD
[Booch 94], DARTS [Gomaa 93], PAISLey [Zave 91], STATEMATE [Harel 90], and G-LOTOS [Lee 91].
We have also proposed another design methodology using structured analysis [Honiden 90]. All support
data ow, state machine, and hierarchy. The most obvious di erence from our approach is that these are
not directly based on Petri nets. Each approach has similar abilities in general and distinct merits anddemerit in detail. Nevertheless, we favor the Petri-net-based approach from the following reasons.

 Petri net is a multi-paradigm model which can represent both ow model and state model uniformly,

while design charts have to be separated into ow model and state model in other design methods.
This property is e ective to have an accurate grasp of both static and dynamic structure of systems.
 This approach can take advantage of graphical representations and a variety of analysis methods
which have been and will be provided by many Petri net researchers.
Recently, several Petri-net-based design methods have been reported. There are two following types
in these methods.
 Compound Type: Petri net are used only to represent state models instead of other substitutive
charts (i.e., state transition diagram or Statechart), where ow models are represented by anotherchart.
 Pure Type (Net-Oriented Design Method): Petri net are used to represent causality relations
among system elements, which include both state models and ow models. We call this type ofdesign method Net-Oriented Design Method.
Pinci and Shapiro proposed a methodology in which CPN are integrated with SADT (Structured
Analysis and Design Technique) [Pinci 91]. SADT is a sophisticated and well-used methodology forrequirement analysis [Ross 77]. Bruno also proposed a design method by combination of high-level Petrinets (Protob nets) and structure diagrams (Quid) [Bruno 95] instead of SADT. However, SADT and Quidare based on data ow diagrams and lacks the state transition feature, while our causality matrix supports
both data ow and state transition features. Etessami's rule-based design methodology [Etessami 91] isanother Petri-net-based approach which uses Abstract Petri Net (APN). A unique feature of APN is the
combination of timed and colored Petri net. According to the rule-based design methodology, a designer
rst formalizes the speci cation by means of a set of rules and lists attributes representing the statusof a target system. Then, he retracts places from the attributes and transitions from the rules, andnally describes APN. Etessami's approach seems to be in the same research direction as our approach.
However, Etessami's methodology is less systematic (therefore, has no computer support) and is weakerin design backtracking. In addition, APN is not hierarchical.
The design method by Reisig [Reisig 92] is one of the purest Petri-net-based design method, where it
uses two types of Petri nets, Channel Agency net (C/A net) and Individual Token net (I/T net). C/A
net is used only to represent static structure of the target system, while I/T net is a simple high-level
Petri net and used to static and dynamic structure. Similar to our approach, a C/A net is used in an
earlier design phase, then it is re ned stepwise into an I/T net. This design method is very interestingand promising. However, it is rough and immature in detail and has plenty of room for improvement.
We are now trying to improve this method and combine it with our method [Uchihira 93b].

Chapter 8: Petri-Net-Oriented Design Methodology

140

7 SummaryThis chapter has proposed a Petri-net-based design method which utilizes causality matrices and temporal
logic. According to this design method, the designer can construct Petri nets by stepwise re nement froman abstract level at the earlier design phase to a concrete level at the nal phase. Our method can beclassi ed into net-oriented design methods, where Petri nets are used to represent various causality
including data ow, control ow, and state transition. Therefore our method can be distinguished fromother popular design methods such as OOAD and RTSAD.
However, net-oriented design methods are not yet mature enough to be used for practical software
design as compared with other design methods. We need further experiences and deep consideration
about net-oriented design methods.

Chapter 9

MENDELS ZONE: Petri-Net-Based
Programming Environment
This chapter describes MENDELS ZONE, a Petri-net-based programming environment, which is purposed being suitable for reactive and concurrent systems. MENDELS ZONE adopts MENDEL nets, andprovides several utilities including temporal logic veri cation and adjustment, and computer-aided design
method, which are mentioned in the previous chapters.

1 Introduction
Since it is often troublesome for ordinary programmers to produce reactive and concurrent programs
as compared with sequential programs, several kinds of CASE (Computer-Aided Software Engineering)
tools are inevitable. Requirements for CASE tools for reactive and concurrent systems include editors(graphical and textual), simulators (program simulator, I/O simulator, and environment simulator),
debugger, execution monitor, validation tools (veri cation and analysis), program generater (compiler,translator, and program synthesis), performance evaluation tool, software reuse support tool (program
component library), and documentation tool.
MENDELS ZONE [Uchihira 87, Honiden 90, Uchihira 90a] is a programming environment for reactive
and concurrent systems, which had been developed over 8 years by 3{7 persons as a part of the Fifth
Generation Computer System Project (FGCS) [Furukawa 92]. It facilitates the dicult task of concurrent
programming for reactive and concurrent systems. MENDELS ZONE adopts a high-level Petri net,
MENDEL net, as a kernel programming language. In addition to a MENDEL net editor and a compiler
to the concurrent programming language, MENDELS ZONE provides two appealing features described
below.
(1) Veri cation and adjustment using Petri nets and temporal logic(2) Computer-aided design method for high-level Petri nets
With regard to the latter feature, MENDELS ZONE is unique compared with other Petri net tools
because they so far support only the drawing (graphical editor), simulation, and analysis (reachability
and invariant analysis) of Petri nets [Feldbrugge90].
The remainder of this chapter is organized as follows. First requirements for CASE tools for reactive
and concurrent systems are considered in Section 2. Overview and structure of MENDELS ZONE aregiven in Section 3. Section 4 illustrates a software development process in MENDELS ZONE. Section 5
introduces a middle-scale example, followed by related works in Section 6.

2 Requirements for Programming Environment
A programming environment consists of several constituent tools. The following tools are useful fordeveloping reactive and concurrent systems using Petri nets.
141Chapter 9: MENDELS ZONE Graphical Editor

142

An editor is the most fundamental programming tool. In the Petri-net-based programming environment, a graphical editor is indispensable because the graphical representation of Petri net is oneof the most strong points. The recent remarkable progress of graphical user interface technology
makes it easier and less expensive to develop sophisticated graphical editors. There still remains
some room for consideration in regard to graphical manipulation of hierarchy (module) of Petrinets.
 Program Synthesizer
Program synthesis is de ned to generate an executable program from an unexecutable speci cationsuch as temporal logic and algebraic speci cation. It is not realistic to synthesize a whole program in actual software development. Partial program synthesis is a promising solution. Programadjustment is included in this approach.
 Program Generater (Compiler or Translator)
A machine-executable code should be automatically generated from graphical representation of the
program. In particular, the cross-compiler is required in case that the execution environment di ers
from the programming environment. Actually, most embedded systems require the cross-compiler.
 Simulator and Debugger
When the execution environment di ers from the programming environment, simulation and debugging in the programming environment are very useful. Simulation in the programming environment
requires not only a program execution simulator but also an I/O hardware simulator and an environment simulator.
 Validation Tool
Validation tools include a testing tool and a veri cation tool. Testing is easy to apply but dicult
to cover all possible cases. On the other hand, formal veri cation can check all possible casesby analyzing the program source code. Veri cation is very promising for safety-critical reactive
systems. However, veri cation is usually hard to apply ill-structured systems and very expensive.
From the practical point of view, complementary use of both testing and veri cation is e ective
and necessary [Uchihira 95b].
 Execution Monitor
After testing and debugging the program in the programming environment, it is also necessary
to execute and test the program in the actual execution environment as integration testing. In
this case, execution monitor is indispensable. Especially visual execution monitor is e ective for
concurrent systems. We emphasize that testing in the actual execution environment is not so easy
because it does not reproducible behavior. For example, errors which appear in the usual execution
often disappear when using the monitor (it is called probe e ect).
 Performance Evaluation and Real-Time Analysis Tool
Performance evaluation is important for some reactive and concurrent systems. Timed Petri net
are often used for this purpose. Real-time scheduling analysis (e.g., rate monotonic analysis) is also
useful for hard real-time systems using real-time operating systems [Stankovic 95].
 Software Reuse Support Tool
In general software reuse is very e ective to achieve high productivity. The recent programming
environment such as Visual Basic and Visual C++ provide powerful software reuse mechanisms.
However, there are some room for consideration in regard to software reuse for reactive and concurrent systems.
 Requirement Analysis and Design Methodology Support Tool
Support tools used analysis and design phases are called upper CASE tool, while editor, testing anddebugging tools are called lower CASE tool. There are many upper CASE tools supporting OOAD
and RTSAD. However, most of them are used only for analysis and design phases and are linked
to editing, testing and debugging tools. Recently programming environments which integrate both

Chapter 9: MENDELS ZONE

143

upper CASE tool and lower CASE tool are required and some have been proposed. Petri nets arepromising framework to achieve this integrated programming environment.
 Documentation Tool
Some documentation of the nal product is necessary for its maintenance. The documentation tool
produces documents from program information which can be retracted in the above tools (e.g.,graphical editor), or generates documents from the source code by reverse engineering.

3 MENDELS ZONEMENDELS ZONE is a CASE tool kit for concurrent programming. The kernel concurrent programming
language is MENDEL, which is a textual form of a MENDEL net 17 . MENDEL programs are compiled
into the concurrent logic programming language KL1 [Ueda 90, Chikayama 92] and executed on theparallel computer Multi-PSI [Taki 89] 18 . MENDEL is regarded as a user-friendly macro languageof KL1, whose purpose is similar to A'UM [Yoshida 88] and AYA [Suzaki 91]. However, MENDEL(MENDEL net) is more convenient for designers to use in designing state-transition-based reactive andconcurrent systems.
MENDELS ZONE provides the following facilities.
 Automatic generation of MENDEL elementary processes from algebraic speci cation [Honiden 91a],
 MENDEL-net-based programming environment backed up by design methodology [Uchihira 92b],
and Veri cation and adjustment tool using bounded MENDEL nets and temporal logic [Uchihira 95a].
(a) Component
SynthesisTool

Component Library(Subnet, Process)Editing & Visualizing Tools(c) Causality
Matrix
Editor(d) Software
Reuse

Performance
Evaluation

MEDEL Net(e) Analyzing
Tools(b) MENDEL Net
EditorVerification(f) Translater

Adjustment(g) Animater(Visual Monitor)
KL1 Program

Environment

Figure 84.

I/O

Temporal
Logic

Multi-PSIMENDELS ZONE (Block Diagram)

Figure 84 shows a block diagram of MENDELS ZONE. These tools are implemented on Multi-PSI
except for a causality matrix editor. We have also proposed a performance evaluation tool [Honiden 94]
for MENDEL programs. However, it was not yet implemented in MENDELS ZONE. Table 14 shows how
MENDELS ZONE satis es requirements of CASE tools enumerated in the previous section.
Figure 85 shows the graphical user interface of MENDELS ZONE, which consists of several subwindows. The designer basically constructs MENDEL nets and execute them through this interface. The
following sections describe constituent tools of MENDELS ZONE in detail.
17 MENDELS ZONE supports an only subset of MENDEL net, because Multi-PSI is a symbol manipulation machine, nota real-time control machine. For example, MENDELS ZONE omits scheduling facilities of MENDEL net.
18 MENDEL programs can also be translated into the C language and be executed on a distributed personal computer
system [Uchihira 89b].

Chapter 9: MENDELS ZONE

144

Table 14.

Requirements for CASE tools and MENDELS ZONE

Requirements
MENDELS ZONE
Graphical Editor(b)Program Synthesizer(a),(e)Program Generator(f)
Simulator/Debugger|
Validation Tool(e)
Execution Monitor(g)
Performance Evaluation|
Reuse Support(d)Design Methodology(c)Documentation|(a) | (g) indicate functions of MENDELS ZONE which are shown in the block diagram (Fig. 84).

MENDELS ZONE(b)
I/O Definition
Editor(c)

Process
Library(d)Temporal
Logic
Specification
EditorFigure 85.

(a)

MENDEL Net
Graphical Editor & Visual Monitor(e)Message Window

MENDELS ZONE (Graphical User Interface)Chapter 9: MENDELS ZONE

145

3.1 Graphical MENDEL Net Editor
 MENDEL Net Editor

The designer constructs each process of MENDEL nets using a graphic editor (Fig. 85(a)) which
provides the creation, deletion, and placement functions for ports, state elements, ags, slots,
methods, arrows, and tokens. This editor also supports the hierarchical expansion and reduction ofnets, and the transition over the process-oriented hierarchy (i.e., from process to subprocess, andvice versa).
 Method Editor
The method editor provides several editing functions speci c to a high-level Petri net. Using themethod editor, the designer describes methods (their conditions and actions) in detail with KL1.
Furthermore, the editor checks syntax and consistency of edited methods. This method editor isactivated by clicking the target method in the MENDEL net editor.
 I/O De nition Editor
This I/O de nition editor (Fig. 85(b)) is used to assign I/O devices to I/O places. MENDELSZONE provides the following I/O devices.

{ Files: The program reads/writes character streams from/to designated les.
{ Windows: The program reads/writes character streams from/to standard input/output win-dows.
{ Lists: The program reads character streams represented as lists (e.g., [a; b; c; d; :::]).

3.2 Causality Matrix Editor

This spread-sheet editor supports stepwise re nement of the causality matrix. It provides the following
functions: creation, deletion, and renaming of methods, ports, slots, and state elements,
 dividing methods, ports, slots, and state elements into detailed ones,
 checking whether re ned relations are legal, and localizing and focusing the view of relations of designer's interest.
The causality matrix editor is implemented on a UNIX workstation and consists of 3 parts; a general
purpose spread-sheet editor (Oleo), a consistency checker, and a translator.
 Oleo: a free software for spread-sheet editing.
 Checker checks whether the matrix data edited by Oleo are consistent.
 Translator translates the matrix data into MENDEL nets.

3.3 Software Reuse Support Tool

Reusable processes are stored in the process library (Fig. 85(c)). This library tool supports browsing andsearching. In MENDELS ZONE, processes can be not only retrieved and but also interconnected in two
main ways; manually and automatically.

Manual Interconnection

The designer selects an process from an process library and interconnects these processes with arrows
manually. These operations are carried out graphically using the MENDEL net editor.

Chapter 9: MENDELS ZONE

146

Automatic Interconnection

The designer gives program speci cations as a set of input/output attributes which are a kind of
I/O data type. Appropriate processes are then selected from an process library and interconnected
automatically by pattern matching of these I/O attributes. Automatic retrieval and interconnection are
carried out, according to the following principles [Uchihira 87, Honiden 94].
(1) A pair of plugs having the same attributes can be interconnected.
(2) All required output attributes must be reachable from given input attributes through connected
processes and arrows.
These automatic retrieval and interconnection can be formalized as a simple and classical planningproblem in Arti cial Intelligence. For example, when the following attributes are given, process B, C,
and D are retrieved and interconnected as shown in Fig. 86.
 Input attribute a, b ; Output attribute e ;input attribute

input attributeabInterconnectionbdProcess
B

ad
Process
C

Process
D

c

c

c
e

Process
Ekg

Retrieval

ProcessHeoutput attribute

Figure 86.

b

Process
Fca
ProcessAek

Process Library

Automatic Process Retrieval and InterconnectionMore Flexible Automatic Interconnection

This automatic retrieval and interconnection (i.e., automatic binding) seems to be not powerfulenough. The binding mechanism depends on the simple pattern matching between output and input
attribute names. In some cases, it might nd no candidate to t the given I/O attributes, or a lot ofcandidates in other cases. More information must be needed to select the most adequate candidate. To
overcome this problem, we adopt a kind of semantic network (called attribute network) which represents
the attribute structure and de ne a metric to order the candidates on the semantic network. Detailtechniques are described in [Uchihira 87].

3.4 Veri cation and Adjustment Tool

In the previous chapters, compositional veri cation and adjustment was investigated for transition systems. When MENDEL nets are supposed to be bounded, veri cation and adjustment can be also applied
to MENDEL nets, because bounded MENDEL nets are equivalent to transition systems. Therefore, only
skeletons of MENDEL net structures are automatically retracted (detailed KL1 codes of methods are ignored) in MENDELS ZONE. Furthermore, every asynchronous communication should be approximatedby bounded bu ers.

Chapter 9: MENDELS ZONE

147

Then the veri cation tool checks whether a MENDEL net satis es the given PLTL constraints enteredby the designer using the PLTL editor (Fig. 85(d)). If the net fails to satisfy the constraints, theadjustment tool can automatically adjust (tune up) the net to satisfy the PLTL constraints by adding
an arbiter process [Uchihira 90a, Uchihira 95a].
We note that PQL is not used and PLTL is used as a speci cation language in MENDELS ZONE.
The reason is that the same speci cation language must be used for both veri cation and adjustment.
Unfortunately, we do not provide compositional adjustment method for PQL. To be exact, we do not try
to provide it because we think branching time temporal logic including PQL is ill-suited for synthesis
and adjustment. Veri cation method for bounded Petri nets and temporal logic is a special case of our
method proposed in Chapter 4. Moreover, we can also use other ecient veri cation methods for PLTL
after bounded Petri nets are translated to transition systems. For example, a model checking method for
PLTL [Vardi 86] is one of the most ecient one.
The veri cation and adjustment are based on the theorem proving method (i.e., tableau construction)of PLTL that is eciently executed on Multi-PSI. The basic idea of parallel graph generation algorithm
which is used in generating nite state processes from PLTL is shown in [Patent KOUKAI H4-259071].

3.5 Program Execution on Multi-PSI

The adjusted MENDEL net is translated into its textual form (MENDEL program). The MENDEL
program is compiled into a KL1 program by the MENDEL translator. The generated KL1 program
can be executed on Multi-PSI. Each Process of the MENDEL program may run on the di erent CPU.
Several compilation techniques (e.g., separate compilation) are introduced here to deal with large-scale
programs. During execution, ring methods blink on the visual monitor (Fig. 85(a)), and the values(colors) of the tokens are displayed on the message window (Fig. 85(d)). The designer can visually checkthat the program behaves satisfactorily.

4 Software Development Process in MENDELS ZONE
Fig. 87 (Data Flow Diagram) and Fig. 88 (Flow Chart) show a typical software development process in
MENDELS ZONE. The designer should construct a target program according to the following steps.
InformalSpecification

Reusable
Components
Validation

Petri-net Basd
DesignReuse

MENDEL
Nets

Adjustment

Temporal
Logic

Verification

VisualExecution

Figure 87.

MENDEL
Nets

Inplementation

MENDEL
Nets

Software Development Process in MENDELS ZONE (Data Flow Diagram)(Step 1): MENDEL Net Construction

A designer constructs a MENDEL net using the MENDEL net editor and the process library as
follows.

 (Step 1-1) Construct elementary MENDEL processes basically by software reuse, where
MENDELS ZONE provides a process library and a process retrieval tool. If the library has noChapter 9: MENDELS ZONE

148

suitable reusable MENDEL processes, MENDELS ZONE can synthesize it from a given algebraic speci cation. It is also possible for the designer to construct the elementary MENDEL
process by himself using the MENDEL net editor.
 (Step 1-2) Interconnect MENDEL processes by communication links using the graphic editor
to make a new compound MENDEL process. A large-scale program can be constructed in thiscompositional way. The designer can also make use of an automatic process interconnection
mechanism provided in MENDELS ZONE.
Constructed programs are functionally-correct temporally-imperfect (FTCI) because a designer
reuses programs whose possible behaviors he may not fully understand; so communication links
may be incomplete.
(Step 2): MENDEL Net Veri cation and Adjustment
The compositional adjustment is used in cooperation with the veri cation. In MENDELS ZONE,
the designer rst nds existing bugs by the veri cation step, then adjusts the program to remove
the bugs by the adjustment step.
Start(Step 1) MENDEL Net Construction(1-1) Construct Elementary Processes(1-2) Interconnect Processes(2-1) PLTL Specification(2-2) Verification

satisfiable

unsatisfiable(2-3) Adjustment(Step 3) Translation(Step 4) Execution and Test

Stop

Figure 88.

bug

Software Development Process in MENDELS ZONE (Flow Chart)

After constructing an FCTI MENDEL net, the designer speci es safety and liveness properties thatmust be satis ed by MENDEL net. These properties are speci ed by temporal logic.
The veri cation and adjustment procedure in MENDELS ZONE is as follows.

 (Step 2-1) The designer gives a PLTL formula for a MENDEL net of each elementary orcompound process.
 (Step 2-2) MENDELS ZONE checks whether a MENDEL net satis es a given PLTL formula.
 (Step 2-3) When it does not satisfy the PLTL formula, the adjustment method is invoked.

(Step 3) and (Step 4): Concurrent Program Generation and Execution

The adjusted MENDEL program is compiled into a KL1 program, which can be executed on MultiPSI. The designer can check visually that the adjusted program satis es his expectation. If not, heshould consider two types of bugs.
 Bugs in the temporal logic constraints, andChapter 9: MENDELS ZONE149

 Bugs in the KL1 code attached to transitions (i.e., its enable conditions and additional actions),

which are ignored in translating to FSP.
 Bugs hidden when translating unbounded MENDEL nets to bounded nets.

5 Example: Power Plant Control System
Using MENDELS ZONE, we have constructed and evaluated several small-scale and middle-scale reactive
and concurrent systems including a lift control system, a machine control system for processing (i.e.,
etching) printed circuit boards 19 , and a control system for a power plant 20 . This section explains a
middle-scale example of the power plant (Fig. 89) in detail.
Control

Plant RuleDB
DB

plant statuscontrol
commands

Power Plant

Figure 89.

Controller

Power Plant Control System

A requirement of the system is summarized as follows. A controller observes plant status continuously
and periodically, and in response to changes of plant status it selects control commands according to thecontrol rules, then the controller sends commands back to the plant. This control cycle consists of thefollowing steps.
1. The controller periodically watches current plant status and updates a plant database.
2. Changes of plant status is detected by comparing the current status with the previous status in theplant database.
3. The most appropriate control rule is selected based on changes of status from a control rule database.
4. The selected rule is applied to derive control goals.
5. To achieve the control goal, concrete commands are computed and sent to the plant.
First, the designer decomposes the control software into 6 elementary processes (Fig. 90).
Plant
Simulator

Timer

MMI

ActionTransmission
DDC

Figure 90.

Power Plant Control System (Process Structure)

19 This was demonstrated at The National Fifth Generation Computer System Symposium 1991.
20 This was demonstrated at International Conference on Fifth Generation Computer Systems 1992 [FGCS 92].

Chapter 9: MENDELS ZONE

150

 Plant process (Controlled Objects)

This process provides current plant status to the controller, receives control commands from thecontroller and changes the status according to the commands. In our experimental system on
Multi-PSI, a plant simulator is used instead of an actual plant.
 Transmission processThis process transmits plant status and control commands from/to an action process and a DDC
process to/from the plant process.
 Action process
The current plant status and previous plant status stored in the plant database are compared inthis process. The action process detects changes of the plant status, then decides which control rule
is applied. By evaluating the rule, a control goal is derived.
 DDC (Direct Digital Control) process
To achieve the control goal given by the action process, concrete commands are computed and sent
to the transmission process using DDC.
 Timer processThis process provides real-time management to other processes.
 MMI (Man-Machine Interface) processThis process provides the operator interface which includes plant status monitoring and the operator
instruction handling.

First, each process is constructed by the MENDEL net editor. Here, only the action process is
explained in detail. We suppose that the designer initially construct a MENDEL net of the action
process shown in Fig. 91 where data ow among ports, slots, and methods is speci ed but control ow is
missing. Control ow is latter synthesized by program adjustment from temporal logic speci cation.
from_comfrom_act

from_tim

from_mmi

append_data

get_from_act

get_from_tim

get_from_mmi

pre_comtimer_com

mmi_comnewdata1

newdata2

renew_DB

find_changes

changesselect_klgs

init_act

plant_DB

rule_DB

eval

unfold_klgs

trigger_klgs

eval_klgs

messagebypasstrigger

dist_message

to_comto_actFigure 91.

to_timto_ddcMENDEL net of action process

to_mmiChapter 9: MENDELS ZONE151

The action process includes several methods to access the plant database. Some of methods areshown in the textual form as follows. An action part of each method is described by KL1 predicates (e.g.,generate_new_data), which are de ned in a junk part.
method(append_data,_,[from_com(Data),pre_com(Com)],[newdata1(ND1),newdata2(ND2)]) :true | generate_new_data(Data,Com,ND1,ND2).
method(find_changes,_,[newdata2(ND),plant_DB(PDB)],[changes(CL)]) :true | detect_changes(ND,PDB,CL).
method(renew_DB,_,[newdata1(ND1),plant_DB(PDB1)],[plant_DB(PDB2)]) :true | database_update(ND1,PDB1,PDB2).
method(select_klgs,_,[changes(CL),rule_DB(RDB),mmi_com(MC)],[bypass(KLGS)]) :true | select_klgs_from_rdb(MC,CL,RDB,KLGS).
method(trigger_klgs,_,[timer_com(TC1),bypass(KLGS)],[timer_com(TC2),trigger(KLGS)]) :TC1 = ok | TC2 = nil.
method(eval_klgs,_,[trigger(KLGS),plant_DB(PDB)],[eval(NewGoal)]) :true | evaluate_klgs(KLGS,PDB,NewGoal).

For this process, the designer can specify temporal logic speci cation using the PLTL editor. The
speci cation is mainly related to access control of the plant database so as to preserve consistency ofdata.

 : append_data U init_act

Before initializing the plant database, no access to the database is permitted.
 2( append_data  (: renew_DB U find_changes ))The plant database must not be renewed before checking the changes between current and previous
status.
 2( append_data  (: trigger_klgs U renew_DB ))After updating the plant database, rule evaluation is triggered o .
 2( append_data  (: append_data U eval_klgs ))Getting a new plant status is not permitted before rule evaluation is nished.
In this case, these constrains are obviously not satis ed, then MENDELS ZONE adjusts the process
automatically. The adjustment does not require large computing cost (within 1 minute). As a result,
5 state elements are added to the original MENDEL net to satisfy temporal logic speci cation. The
adjusted process can be watched in Fig. 92. In this gure, added state elements are painted halftone,
and slots are not displayed for simplicity.
After all elementary processes are constructed, they are interconnected with the MENDEL net editor.
Figure 93 shows a top-level process in MENDELS ZONE which corresponds to the process structure of
Fig. 90. In the top level, the designer can verify and adjust a MENDEL net again. In this example, heveri es whether it is deadlock free. Actually, several deadlock states are detected. Since they are due
to bugs of elementary processes, he does not use the program adjustment at top level and debugs them
manually. A size of a nal MENDEL net amounts to 4300 lines in MENDEL textual representation.
Finally, all processes (MENDEL program) are compiled into KL1 codes (6200 lines) and executedand monitored visually on MENDELS ZONE. It is reported that development cost is cut down to half
compared with the case that the designer implemented the same system using naked KL1 and Multi-PSI[Uraoka 92]. This cost-down results from reduction of debugging e orts because debugging of the naked
KL1 program is troublesome for ordinary programmers.

6 Related Works

6.1 Comparison with STATEMATESTATEMATE is another CASE tool for reactive and concurrent systems, in which three types of charts(module-chart, activity-chart, and Statechart) are written by the designer. These charts correspond toelements of MENDEL net as shown in Table 15.
We compare MENDELS ZONE with STATEMATE in regard to the following items.

Chapter 9: MENDELS ZONE

152

Figure 92.

MENDELS ZONE (Adjusted Action Process)Figure 93.

MENDELS ZONE (Top-level MENDEL net)

Chapter 9: MENDELS ZONE

153
Table 15.

STATEMATE vs. MENDELS ZONESTATEMATE
module (module-chart)
control activity (activity-chart)
activity (activity-chart)
data store (activity-chart)
state (Statechart)
data ow
control ow
inscription language

MENDELS ZONE
process
coordinatormethodslot, port
state
arrow
arrow
KL1

 State Transition Model Complemented by Data Flow

Both MENDELS ZONE and STATEMATE adopt an extended state transition model (i.e, Petrinet and Statechart) which plays a key part in reactive control systems, while a data ow modelis also utilized complementarily. This approach is favorable in most CASE tools for reactive andconcurrent systems.

 Viewpoint

STATEMATE adopts three type of charts (module-chart, activity-chart, Statechart) and supports a
multi-view design method using them, while MENDELS ZONE adopts one type of chart (MENDELnet) and supports a single-view design method. The multi-view design is suited for analyzing
ambiguous requirements in the earlier design phase and understanding outline of the systems in themaintenance phase. However, it is dicult to keep consistency among three charts. On the other
hand, the single-view design is suited to trace dynamic behaviors in the testing and debugging phasebecause design information is represented uniformly and consistently. However, it is not easy todescribe MENDEL nets in the earlier design phase; a causality matrix is introduced in MENDELS
ZONE.

 Hierarchy

While MENDEL net adopts only process-oriented hierarchy, STATEMATE provides several typesof hierarchy; concept-oriented hierarchy in activity-chart which is useful for top-down stepwise
re nement, and state-oriented hierarchy in Statechart which is useful to specify exception handling.
On the other hand, STATEMATE does not much care about process structure as compared withMENDELS ZONE.

 Analysis

STATEMATE provides a simulation and a global state analysis tool, while MENDELS ZONE
provides veri cation and adjustment using temporal logic. Veri cation ability of temporal logic isstronger than global state analysis in STATEMATE. However, the analysis tools of STATEMATE
is more sophisticated from user's point of view.

 Code Generation

STATEMATE generates C programs or Ada programs from the described three charts, while
MENDELS ZONE generates KL1 programs from MENDEL nets.
From the above consideration, we can summarize comparison between MENDELS ZONE and STATEMATE as follows. MENDELS ZONE and STATEMATE are generally similar, but their target in softwaredevelopment process is di erent. MENDELS ZONE puts emphasis on the design phase where integrationand tractability with a single chart are important, while STATEMATE puts emphasis on the analysis
phase where it is important to collect functions and arrange them in order from three types of charts.

6.2 Comparison with Other Petri Net Tools

Most Petri net tools (DESIGN/CPN, GreatSPN, Cabernet, etc.) are used only for modeling, simulating,and analyzing systems in a prototyping phase. After nishing the prototyping phase, a target concurrent

Chapter 9: MENDELS ZONE

154

program for an actual reactive and concurrent system has to be manually reconstructed in an implementation phase. Some tools can generate program source code written by standard languages. However,these are sequential programming languages. For example, Design/CPN provides the automatic generation of SML (Standard ML) codes [Jensen 92], where SML is not a concurrent programming language.
MENDELS ZONE can automatically generate target concurrent programs directly from high-level Petrinets where generated programs run eciently in the real parallel and distributed environment.

7 SummaryWe have presented an overview and a system structure of MENDELS ZONE and how to constructconcurrent programs using MENDELS ZONE. MENDELS ZONE is just an experimental system in orderto adopt and evaluate novel technologies developed by us (veri cation, adjustment, design method).
Although it is immature, it is reported that in the middle-scale example the designer can constructconcurrent programs easier in MENDELS ZONE than he does it with naked KL1.
Since Multi-PSI is designed for parallel symbol manipulation and not for reactive systems, MENDELSZONE is week in implementation accommodated to the actual reactive and real-time environment. We
shall implement another version of MENDELS ZONE on the other platform in future.

Chapter 10

Conclusion
1 Review of Developments
I have proposed software development techniques for reactive and concurrent systems using Petri net andtemporal logic. These techniques include speci cation, veri cation, synthesis, and design methodology.
Particularly, to put veri cation and synthesis into practical, I introduced the compositional program
veri cation and compositional program adjustment. To embody and evaluate these techniques, I havealso developed a programming environment, MENDELS ZONE. MENDELS ZONE is available to the
public as ICOT Free Software, accessible via Internet (http://www.icot.or.jp/ICOT/IFS/ifs.html)

2 Current Status
MENDELS ZONE shows a typical process and a CASE environment for software development using
Petri net and temporal logic. I believe that MENDELS ZONE can play an important role as a reference
prototype of CASE tools for reactive and concurrent systems. However, since MENDELS ZONE isno more than the prototype, practical domain-speci c CASE tools should be reconstructed based on
MENDELS ZONE for actual software development. In fact, we have been constructing a CASE tool forchemical plant control systems (SAVE/SFC, ref. Chapter 5, Section 5.3), in which several techniques of
MENDELS ZONE have been adopted.
Of course, some of techniques proposed in this thesis are immature and inexperienced for the actual
software development. The relation of Petri net and temporal logic is well researched and mature from thetheoretical point of view. However, from the practical point of view, there is still room for improvementin the ecient veri cation and adjustment techniques. Moreover, Petri-net-oriented design methodology
is a unexplored research subject, and our work is nothing but one of trail-blazing e orts. Three phase
net-oriented software design method [Uchihira 97a] which we recently proposed is another trail-blazing
e ort.

3 Future Works
Our future works can be summarized into the following directions.

 Sophisticated Speci cation Language{ High-level Petri Net: Although a proposed High-level Petri net (MENDEL net) has asucient expressive power, there is still room for improvement in easiness of describing theactual systems. An introduction of domain-speci c macro-expressions seems to be a shorter
way to the solution.
{ Temporal Logic: Although several extended temporal logics handling real-time have been
proposed, there is no extended temporal logics handling controllability and observability explicitly, which are essential feature of reactive systems. We are doing research on the temporal
logic extended to handle controllability and observability.
155Chapter 10: Conclusion

156

 Composite Program Veri cation

To be concerned with ecient program veri cation based on model checking, there are other approaches besides compositional veri cation. One of them is a partial order approach, which isfull of promise and well investigated these years. It is practical to use compositional method
and partial order method case by case and complementarily mentioned in Chapter 5. Furthermore, it is promising to harmonize and integrate both veri cation and conventional validation
techniques like testing/simulation in the common CASE environment. Hypersequential programming [Uchihira 96c, Uchihira 97b, Uchihira 97c] is our latest challenging proposal in this direction.
Hypersequential programming is intended to make actual concurrent programs highly reliable byconventional testing which is strengthened by veri cation techniques.

 Cultivation of Adjustment and Petri-Net-Based Design Methodology

Since program adjustment and Petri-net-based design methodology which I proposed belong topioneer's work, it is very important to cultivate the subjects from now on. In particular, it isnecessary to apply these methods to practical examples, evaluate, and improve them.

Bibliography[Abadi 89]

M. Abadi, L. Lamport, P. Wolper, Realizable and Unrealizable Speci cations of Reactive Systems, 16th International Colloquium on Automata, Languages, and Programming(ICALP), Lecture Notes in Computer Science, Vol.372, Springer-Verlag, 1989.
[Andrews 83] G.R. Andrews and F.B. Schneider, Concept and Notations for Concurrent Programming,
ACM Computing Surveys, Vol.15, No.1, 1983.
[Alur 89]
R. Alur and T.A. Henzinger, A Really Temporal Logic, Proc. IEEE 30th Annual Symp.
on Foundations of Computer Science (FOCS), 1989.
[Alur 90]
R. Alur, C. Courcoubetis, D. Dill, Model-Checking for Real-Time Systems, Proc. 5th IEEE
Symp. on Logic in Computer Science (LICS), 1990.
[Alur 91]
R. Alur and D. Dill, The Theory of Timed Automata, Real-Time: Theory and Practice,
Lecture Notes in Computer Science, Vol.600, Springer-Verlag, 1991.
[Arnold 92] A. Arnold, Finite Transition Systems, Masson (in French), 1992, Prentice Hall (inEnglish), 1994.
[Andersen 92] H.R. Andersen and G. Winskel, Compositional Checking of Satisfaction, Conference
on Computer-Aided Veri cation (CAV'91), Lecture Notes in Computer Science, Vol.575,
Springer-Verlag, 1991.
[Battiston 88] E. Battiston, F. de Cindio, G. Mauri, OBJSA Nets: A Class of High-Level Nets having
Objects as Domains, Advances in Petri Nets, Lecture Notes in Computer Science, Vol.340,
Springer-Verlag, 1988.
[Barringer 84] H. Barringer, R. Kuiper, A. Pnueli, Now You May Compose Temporal Logic Speci cations,
Proc. 16th ACM Symp. on Theory of Computing (STOC), 51{63, 1984.
[Beaten 90] J. Beaten, ed., Application of Process Algebra, Cambridge Univ. Press, 1990.
[Bellettini 93] C. Bellettini, M. Felder, and M. Pezze', Merlot: A Tool for Analysis for Real-Time
Speci cations, Proc. of 7th Internat. Workshop on Software Speci cation and Design(IWSSD), 1993.
[Ben-Ari 83] M. Ben-Ari, A. Pnueli, Z. Manna, The Temporal Logic of Branching Time, Acta Informatica, 20, 1983.
[Bernstein 81] F.A. Bernstein, N.Goodman, Concurrency Control in Distributed Database Systems,
ACM Computing Surveys, Vol.13, No.2, 1981.
[Berthomieu 91] B. Berthomieu and M. Diaz, Modeling and Veri cation of Time Dependent Systems
Using Time Petri Nets, IEEE Trans. on Software Engineering, Vol.17, No.3, 1991.
[Boehm 76] B.W. Boehm, Software Engineering, IEEE Trans. on Computers, Dec., 1976.
[Bolognesi 89] , T. Bolognesi and D.Latella, Techniques for the Formal De nition of the G-LOTOS
Syntax, 1989 IEEE Workshop on Visual Languages, 1989.
[Booch 94] G. Booch, Object Oriented Design with Application, (second edition), The Benjamin/Cummings Publishing, 1994.
157

N. Uchihira: Programming Environment for Reactive and Concurrent Systems[Boudol 89]

158

G. Boudol, V. Roy, R. de Simone, D. Vergamini, Process Calculi, From Theory to Practice:
Veri cation Tools, INRIA Report, No.1098, 1989.
[Brad eld 92] J. C. Brad eld, Verifying Temporal Properties of Systems, Birkhauser , 1992.
[Brauer 91] W.Brauer, R.Gold, W.Vogler, A Survey of Behaviour and Equivalence Preserving Re nements of Petri Nets, Advances in Petri Nets 1990, Lecture Notes in Computer Science,
Vol.493, Springer-Verlag, 1991.
[Bruno 95] G. Bruno, Model-based Software Engineering, Chapman & Hall, 1995.
[Buchi 62] J.R. Buchi, A decision method in restricted second order arithmetic, Proc. Internat. Congr.
Logic, Method. and Philos. Sci., 1960, also Stanford University Press, 1962.
[Burch 90]
J. R. Burch, E. M. Clarke, K. L. McMillan, D. L. Dill, J. Hwang, Symbolic Model
Checking: 1020 States and Beyond, Proc. 5th IEEE Symp. on Logic in Computer Science(LICS), 1990.
[Cherkasova 87] L.A.Cherkasova and V.E.Kotov, The Undecidability of Propositional Temporal Logic forPetri Nets, Computers and Arti cial Intelligence Vol.6, No. 2, 1987.
[Chikayama 88] T. Chikayama, et al. , Overview of the Parallel Inference Machine Operating System (PIMOS), Proc. of Internat. Conf. on Fifth Generation Computer Systems 1988 (FGCS88),
ICOT, 1988.
[Chikayama 92] T. Chikayama, Operating System PIMOS and Kernel Language KL1, Proc. of Internat.
Conf. on Fifth Generation Computer Systems 1992 (FGCS92), ICOT, 1992.
[Christensen 92] S.Christensen, L.Petrucci, Towards a Modular Analysis of Coloured Petri Nets, Proc.
13th Internat. Conf. on Application and Theory of Petri Nets (ICATPN), Lecture Notes
in Computer Science, Vol.616, Springer-Verlag, 1992.
[Christensen 94] S.Christensen, N.D. Hansen, Coloured Petri Nets Extended with Channels for Synchronous Communication, Proc. 15th Internat. Conf. on Application and Theory of PetriNets (ICATPN), Lecture Notes in Computer Science, Vol.815, Springer-Verlag, 1994.
[Clarke 82] E.M. Clarke, and E.A. Emerson, Design and Synthesis of Synchronization Skeletons Using
Branching Time Temporal Logic, Lecture Notes in Computer Science, Vol.131, SpringerVerlag, 1982.
[Clarke 86] E.M. Clarke, E.A. Emerson, and A.P. Sistla, Automatic Veri cation of Finite-state Concurrent Systems Using Temporal Logic Speci cations, ACM Trans. on Programming Languages and Systems, Vol. 8, No. 2, 1986.
[Clarke 87] E.M. Clarke and O. Grumberg, Reaserch on Automatic Veri cation of Finite-state Concurrent Systems, Ann. Rev. Comput.Sci., 1987.2,260-290, 1987.
[Clarke 89] E.M. Clarke, E.E. Long, and K.L. McMillan, Compositional Model Checking, Proc. 4thIEEE Symp. on Logic in Computer Science (LICS), 1989.
[Cleaveland 93] R. Cleaveland, J. Parrow, B. Ste en, The Concurrency Workbench: A Semantics-Based
Tool for the Veri cation of Concurrent Systems, ACM Trans. on Programming Languages
and Systems, Vol.15, No.1, 1993.
[CAV 89]
J. Sifakis, (Ed.), Automatic Veri cation Methods for Finite State Systems. Lecture Notes
in Computer Science, Vol.407, Springer-Verlag, 1989.
[CAV 93]
C. Courcoubetis (Ed.), CAV'93 Conference on Computer-Aided Veri cation, Lecture Notes
in Computer Science, Vol.697, Springer-Verlag, 1993.
[CAV 94]
D. L. Dill (Ed.), CAV'94 Conference on Computer-Aided Veri cation, Lecture Notes in
Computer Science, Vol.818, Springer-Verlag, 1994.
[Conway 71] J. H. Conway, Regular Algebra and Finite Machines, Chapman and Hall, 1971.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

159[Davis 90]
A.M. Davis, Software Requirements Analysis & Speci cation, Prentice Hall, 1990.
[Emerson 82] E.A. Emerson and E.M. Clarke, Using Branching Time Temporal Logic to Synthesize
Synchronization Skeletons, Science of Computer Programming, 2, 1982.
[Emerson 85a] E.A. Emerson and J.Y. Halpern, Decision Procedures and Expressiveness in the Temporal
Logic of Branching Time, J. Computer and System Sciences, 30, 1985.
[Emerson 85b] E.A. Emerson, C.-L. Lei, Modalities for Model Checking: Branching Time Strikes Back,
Proc. 12th ACM Symp. on Principles of Programming Languages (POPL), 1985.
[Emerson 90a] E.A. Emerson, Temporal and Modal Logic, in Handbook of Theoretical Computer Science,
Volume B, Formal Methods and Semantics, The MIT Press, 1990.
[Emerson 90b] E.A. Emerson and J. Srinivasan, A Decidable Temporal Logic to Reason about Many
Processes, Proc. ACM 9th Symp. on Principle of Distributed Computing (PODC), 1990.
[Etessami 91] F.S. Etessami and G.S. Hura, Rule-Based Design Methodology for Solving Control Problems, IEEE Trans. on Software Engineering, Vol.17, No.3, 1991.
[Fantechi 91] A. Fantechi, S. Gnesi, G. Ristori, Compositionality and bisimulation: A negative result,
Information Processing Letters, 39, 109{114, 1991.
[Feldbrugge90] F.Feldbrugge : \Petri Net Tool Overview 1989", Advances in Petri Nets 1989, Lecture
Notes in Computer Science, Vol.424, Springer-Verlag, 1990.
[Felder 94] M. Felder, D. Mandrioli, A. Morzenti, Proving Properties of Real-Time Systems ThroughLogical Speci cations and Petri Net Models, IEEE Trans. on Software Engineering, Vol.20,
No.2, 1994.
[FGCS 92] MENDELS ZONE, Demonstration at Internat. Conf. Fifth Generation Computer Systems(FGCS'92), 1992.
[Fukuoka 91] K. Fukuoka, A. Yokozawa, K. Tamaru, Hierarchical design of a ITRON speci cation
kernel: TR2, Proc. The Eighth TRON Project Symposium, IEEE Comput. Soc. Press,
1991.
[Furukawa 92] K. Furukawa, Logic programming as the integrator of the Fifth Generation Computer
Systems project, Commun. ACM, Vol.35, No.3, 82-92, 1992.
[Gabrielian 91] A. Gabrielian and M.K. Franklin, Multi-level Speci cation and Veri cation of Real-Time
Software, Proc. 12th Internat. Conf. on Software Engineering (ICSE), 1990.
[Galton 81] A. Galton, Temporal Logic and Computer Science: An Overview, Temporal Logics andTheir Applications (A. Galton, ed.), Academic Press, 1 { 52, 1987.
[Genrich 81] H.J. Genrich and K. Lautenbach, System Modeling with High-Level Petri Nets, TheoreticalComputer Science, 13, 1981.
[Ghezzi 93] C. Ghezzi, H. Felder, M. Paul, Real-Time Systems: A Survey of Approaches to Formal
Speci cation and Veri cation, Proc. on 4th European Software Engineering Conference(ESEC), 1993.
[Giovanni91] R. Di Diovanni, Hood Nets, Advances in Petri Nets 1991, Lecture Notes in Computer
Science, Vol.524, Springer-Verlag, 1991.
[Godefroid 91a] P. Godefroid, P. Wolper, A Partial Approach to Model Checking, Proc. 6th IEEE Symp.
on Logic in Computer Science (LICS), 1991.
[Godefroid 91b] P. Godefroid, and P. Wolper, Using Partial Orders for the Ecient Veri cation of
Deadlock Freedom and Safety Properties, Conference on Computer-Aided Veri cation(CAV'91), Lecture Notes in Computer Science, Vol.575, Springer-Verlag, 1991, also Formal methods in System Design, Vol.2, No.2, Kluwer Academic Publishers, 1993.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

160[Godefroid 96] P. Godefroid, Partial-Order Methods for the Veri cation of Concurrent Systems | An Approach to the State-Explosion Problem |, Lecture Notes in Computer Science, Vol.1032,
Springer-Verlag, 1996.
[Gomaa 93] H. Gomaa, Software Design Methods for Concurrent and Real-Time Systems, AddisonWesley , 1993.
[Kawata 95] H. Kawata and N. Uchihira, Automatic Generation of Plant Simulator to Verify Sequence
Control Software (in Japanese), SICE Federated Symposium on Systems and Information,
Toyama, Nov., 1995.
[Kawata 96] H. Kawata and N. Uchihira, Practical Program Validation for Plant Control Systems
Using SFC and Temporal Logic, 1996 IEEE International Conference on Systems, Man,
and Cybernetics (SMC'96), 1996.
[Katai 82]
O. Katai and S. Iwai, Construction of Scheduling Rules for Asynchronous, Concurrent
Systems Based on Tense Logic (in Japanese), Trans. of SICE, Vol. 18, No. 12, 1982.
[Kojima 91] F. Kojima and T. Koike, Advanced Con guration Tolls for DCS, ISA Trans., Vol.30,
No.2, 1991.
[Kanellakis 90] P. C. Kanellakis, S. A. Smolka, CCS Expressions, Finite State Processes and Three
Problems of Equivalence, Information and Computation, 86, 1990.
[Koymans 87] R. Koymans, Specifying Message Passing Systems Requires Extending Temporal Logic,
in Temporal Logic in Speci cation (B. Banieqbal, H. Barringer, A. Pnueli, eds.) Lecture
Notes in Computer Science, Vol.398, Springer-Verlag, 1987.
[Kroger 87] F. Kroger, Temporal Logic of Programs, Springer-Verlag, 1987.
[Hale 87]
R. Hale, Using Temporal Logic for Prototyping: The Design of a Lift Controller, in
Temporal Logic in Speci cation (B. Banieqbal, H. Barringer, A. Pnueli, eds.) Lecture Notes
in Computer Science, Vol.398, Springer-Verlag, 1987.
[Harel 87a] D. Harel, Statechart: A visual formalism for complex systems, Sci. Comput. Program.,
Vol.8, No.3, 1987.
[Harel 87b] D. Harel, A. Pnueli, J.P. Schmidt, R. Sherman, On the Formal Semantics of Statechart,
Proc. 2nd IEEE Symp. on Logic in Computer Science (LICS), 1987.
[Harel 90]
D. Harel, et al., STATEMATE: A Working Environment for the Development of Complex
Reactive Systems, IEEE Trans. on Software Engineering, Vol.16, No.4, 1990.
[Hatley 87] D. Hatley and I. Pirbhai, Strategies for Real-Time System Speci cation, Dorset House,
1987.
[Hennessy 85a] M. Hennessy, and R. Milner, Algebraic Laws for Nondeterminism and Concurrency,
Journal of ACM, Vol. 32, No. 1, 1985.
[Hennessy 85b] M. Hennessy and C. Stirling, The Power of the Future Perfect in Program Logics,
Information and Control, 67, 1985.
[Hennessy 88] M. Hennessy, Algebraic Theory of Processes, MIT Press, 1988.
[Henzinger 91] T. A. Henzinger, Z. Manna, A. Pnueli, Timed Transition Systems, Real-Time: Theory
and Practice, Lecture Notes in Computer Science, Vol.600, Springer-Verlag, 1991.
[Hiraishi 95] K. Hiraishi and M. Nakano, On Symbolic Model Checking in Petri Nets, IEICE Trans.
Fundam. Electron. Commun. Comput. Sci., Vol.E78-A, No.11, 1995.
[Hoare 84] C.A.R. Hoare, Communicating Sequential Processes, Prentice-Hall, 1984.
[Holzmann 91] G. J. Holzmann, Design and Validation of Computer Protocols, Prentice Hall, 1991.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

161[Honiden 86a] S. Honiden, N. Uchihira, T. Kasuya, MENDEL: Prolog Based Concurrent Object Oriented
Language, Proc. IEEE COMPCON'86, 1986.
[Honiden 86b] S. Honiden. N. Uchihira, A. Ohsuga, and T. Kasuya, MENDEL: Meta-Inferential System
Description Language (in Japanese), Trans. Inf. Process. Soc. Japan, Vol. 27, No. 2, 219{
217, 1986.
[Honiden 90] S. Honiden, N. Uchihira, K. Matsumoto, K. Matsumura, M. Arai, An Application of
Structural Modeling and Automated Reasoning to Real-Time Systems Design, Real-Time
Systems, Vol.1, No.4, 313{331, 1990.
[Honiden 91a] S. Honiden, A. Ohsuga, N. Uchihira, An Integration Environment to Put Formal Speci cations into Practical Use in Real-Time Systems, Proc. 6th IWSSD, 1991.
[Honiden 91b] S. Honiden, N. Uchihira, K. Itoh, An Application of Arti cial Intelligence to Prototyping
Process in Performance Design for Real-Time Systems, Proc. on 3rd European Software
Engineering Conference (ESEC), Lecture Notes in Computer Science, Vol.550, SpringerVerlag, 1991.
[Honiden 92] S. Honiden and N. Uchihira, Net-Oriented Analysis and Design, IEICE Trans. Fundam.
Electron. Commun. Comput. Sci., Vol.E75-A, No.10, 1992.
[Honiden 94] S. Honiden, K. Nishimura, N. Uchihira, K. Itoh, An Application of Arti cial Intelligenceto Object-Oriented Performance Design for Real-Time Systems, IEEE Trans. on Software
Engineering, Vol.20, No.11, 1994.
[Honiden 96] S. Honiden, A. Ohsuga, N. Uchihira, MENDELS ZONE: A parallel program development
system based on formal speci cations, Information and Software Technology, Vol.38, 1996.
[Howell 88] R.R. Howell, L.E. Rosier, and H.C. Yen, A Taxonomy of Fairness and Temporal Logic
Problems for Petri Nets, Lecture Notes in Computer Science, Vol.324, Springer-Verlag,
1988.
[Huber 90] P. Huber, et al., Hierarchies in Coloured Petri Nets, Advances in Petri Nets 1990, Lecture
Notes in Computer Science, Vol.483, Springer-Verlag, 1990.
[Ichikawa 85] A. Ichikawa, K. Yokoyama, and S. Kurogi, Reachability and Control of Discrete Event
Systems Represented by Con ict-Free Petri Nets, Proc. IEEE Internat. Symp. on Circuits
and Systems, 1985.
[IEC 1131-3] IEC 1131-3, IEC International Standard for Programmable Controllers, Part 3: Programming Languages (IEC 1131-3), International Electrotechnical Commission, 1993.
[IWSSD 87] Problem Set, in Proceedings of the 4th International Workshop on Software Speci cation
and Design (IWSSD), 1987.
[Jensen 90] K. Jensen, Coloured Petri Nets: A High Level Language for System Design and Analysis,
Advances in Petri Nets 1990, Lecture Notes in Computer Science, Vol.483, Springer-Verlag,
1990.
[Jensen 92] K. Jensen, Coloured Petri Nets, Basic Concept, Analysis Methods and Practical Use, Volume 1, Springer-Verlag, 1992.
[Jensen 95] K. Jensen, Coloured Petri Nets, Basic Concept, Analysis Methods and Practical Use, Volume 2, Springer-Verlag, 1995.
[Josko 87]
B. Josko, MCTL { An Extension of CTL for Modular Veri cation of Concurrent Systems,in Temporal Logic in Speci cation (B. Banieqbal, H. Barringer, A. Pnueli, eds.) Lecture
Notes in Computer Science, Vol.398, Springer-Verlag, 1987.
[Lakos 95] C. Lakos, From Coloured Petri Nets to Object Petri Nets, Proc. 16th Internat. Conf.
on Application and Theory of Petri Nets (ICATPN), Lecture Notes in Computer Science,
Vol.935, Springer-Verlag, 1995.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

162[Lamport 94] L. Lamport, The Temporal Logic of Actions, ACM Trans. on Prog. Lamg. Syst., Vol.16,
No.3, 1994.
[Lee 91]
E. S. Lee, et al., Construction and Implementation of a Speci cation Environment SEGL
Based on G-LOTOS (in Japanese), Trans. Inf. Process. Soc. Japan, Vol.32, No.3, 1991.
[Lee 85]
K. Lee and J. Favrel, Hierarchical Reduction Method for Analysis and Decomposition ofPetri Nets, IEEE Trans. on SMC, Vol.SMC-15, No.2, 1985.
[Lynch 86] N. Lynch and M. Merritt, Introduction to the Theory of Nested Transactions, Proc.
Internat. Conf. on database Theory (ICDT'86), 1986.
[Lynch 88] N. Lynch and M. Tuttle, Introduction to Input/Output Automata, MIT Technical Report
MIT/LCS/TM-373, 1988.
[Marsan 86] M. Ajmone Marsan, G.Balbo and G.Conte, Performance Models of Multiprocessor Systems, The MIT Press, 1986.
[Marsan 95] M. Ajmone Marsan, G. Balbo and G. Conte, S. Donatelli, and G. Franceschinis, Modelingwith Generalized Stochastic Petri Nets, John Wiley & Sons, 1995.
[McMillan 93] K. L. McMillan, Symbolic Model Checking, Kluwer Academic Publishers, 1993.
[Manna 81a] Z. Manna and A. Pnueli, Veri cation of Concurrent Programs, Part I: The Temporal
Framework, Stanford University Technical Report, No.STAN-CS-81-836, 1981.
[Manna 81b] Z. Manna and A. Pnueli, Veri cation of Concurrent Programs, Part II: Temporal Proof
Principles, Stanford University Technical Report, No.STAN-CS-81-843, 1981.
[Manna 84] Z.Manna and P.Wolper, Synthesis of Communicating Processes from Temporal Logic Speci cation, ACM Trans. Program. Lang. & Syst., Vol. 6, No. 1, pages 68 - 93, 1984.
[Manna 92] Z. Manna and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems speci cation -, Springer-Verlag , 1992.
[Milner 81] R. Milner, A Modal Characterization of Observable Machine-behaviour, Lecture Notes in
Computer Science, Vol.112, Springer-Verlag, 1981.
[Milner 89] R. Milner, Communication and Concurrency. Prentice Hall, 1989.
[Mishra 85] B. Mishra, and E.M. Clarke, Hierarchical Veri cation of Asynchronous Circuit Using
Temporal Logic. Theoretical Computer Science, 38, 1985.
[Miyagi 88] P.E.Miyagi, K.Hasegawa, K.Takahashi, A Programming Language for Discrete Event Production Systems Based on Production Flow Schema and Mark Flow Graph, Trans. of theSociety of Instrument and Control Engineering, Vol.24, No.2, Feb. 1988.
[Moszkowski 86] B.C. Moszkowski, Executing Temporal Logic Programs, Cambridge Univ. Press, 1986.
[Murata 89] T. Murata, Petri Nets: Properties, Analysis and Applications, Proc. IEEE, Vol. 77, No.
4, 1989.
[Murata 90] T. Murata and N. Komoda, Real-Time Control Software for Transaction Processing Basedon Colored Safe Petri Net Model, Real-Time Systems, Vol.1, No.4, 299{312, 1990.
[Nagao 92] Y. Nagao, et al., Petri Net Based Programming System for FMS, IEICE Trans. Fundam.
Electron. Commun. Comput. Sci., Vol.E75-A, No.10, 1992.
[Ostro 90] J.S. Ostro , Temporal Logics for Real-Time Systems Research Studies Press, 1990.
[Paige 87]
R. Paige, R.E.Tarjan, Three Partition Re nement Algorithms, SIAM J. Comput., 16,No.6, 1987.
[Park 81]D.Park, Concurrency and automata on in nite sequences, Lecture Notes in Computer
Science, Vol.104, Springer-Verlag, 1981.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

163[Patent KOUKAI H4-259071] M. Arami, N. Uchihira, Graph Generation Method, Japan Patent Oce
KOUKAI H4-259071, 1991.
[Peterson 81] J.L.Peterson, Petri Net Theory and the Modeling of Systems, Prentice-Hall, Inc., 1981.
[Pinci 91]
V.O.Pinci and R.M.Shapiro, An Integrated Software Development Methodology Based on
Hierarchical Colored Petri Nets, Advances in Petri Nets 1991, Lecture Notes in Computer
Science, Vol.524, Springer-Verlag, Springer-Verlag , 1991.
[Pinter 84] S.S. Pinter, P. Wolper, A Temporal Logic for Reasoning about Partially Ordered Computations, Proc. 3rd ACM Symp. on Principles of Distributed Computing, 1984.
[Plaisted 86] D. A. Plaisted, A Decision Procedure for Combinations of Propositional Temporal Logic
and Other Specialized Theories, Journal of Automated Reasoning, 2, 1986.
[Pnueli 77] A. Pnueli, The Temporal Logic of Programs, Proc. 18th IEEE Symp. on Foundations ofComputer Science, 1977.
[Pnueli 81] A. Pnueli, Temporal Semantics of Concurrent Programs, Theoretical Computer Science,
13, 1981.
[Pnueli 86] A. Pnueli, Application of Temporal Logic To the Speci cation and Veri cation of Reactive
Systems: A survey of Current Trends, in Current Trends in Concurrency (J.W. de Backker, W.-P. de Roever, G. Rozenverg, eds.), Lecture Notes in Computer Science, Vol.224,
Springer-Verlag, 1986.
[Pnueli 89a] A. Pnueli and R. Rosner, On the Synthesis of an Asynchronous Reactive Module, 16th
International Colloquium on Automata, Languages, and Programming (ICALP), Lecture
Notes in Computer Science, Vol.372, Springer-Verlag, 1989.
[Pnueli 89b] A. Pnueli and R. Rosner, On the synthesis of a reactive module, Proc. 16th ACM Principleof Programming Languages (POPL), 1989.
[Pnueli 90] A. Pnueli and R. Rosner, Distributed Reactive Systems are Hard to Synthesize, Proc.
IEEE 31st Annual Symp. on Foundations of Computer Science (FOCS), 1990.
[Ramadge 89] P.J. Ramadge and W.M. Wonham, The Control of Discrete Event Systems, Proc. IEEE,
Vol.77, No.1, 81{98, 1989.
[Rescher 71] N. Rescher and A. Urquhart, Temporal Logic, Springer-Verlag, 1971.
[Reisig 87] W. Reisig, Petri Nets in Software Engineering, Advances in Petri Nets, Lecture Notes in
Computer Science, Vol.255, Springer-Verlag, 63{96, 1987.
[Reisig 91] W. Reisig, Petri Nets and Algebraic Speci cation Theoretical Computer Science, 80, 1991.
[Reisig 92] W.Reisig, A Primer in Petri Net Design, Springer-Verlag,1992.
[Ross 77]
D.T. Ross, Structured Analysis: A Language for Communicating Idea, IEEE Trans. on
Software Engineering, Vol.3, No.1, 1977.
[Rumbaugh 91] J.Rumbaugh, et al., Object-Oriented Modeling and Design, Prentice-Hall, 1991.
[Saeki 87]
M. Saeki, Non-Monotonic Propositional Temporal Logic and its Application to Formal
Speci cations (in Japanese), Trans. Inf. Process. Soc. Japan, Vol.28, No.6, 1987.
[Shatz 93]
S. M. Shatz, Development of Distributed Software: Concepts and Tools, Macmillan, New
York, 1993.
[Sistla 84]
A.P. Sistla, E.M. Clarke, N. Francez, A.R. Meyer, Can Message Bu ers Be Axiomatizedin Linear Temporal Logic?, Information and Control, 63, 1984.
[Stankovic 95] J.A. Stankovic, Implications of Classical Scheduling Results for Real-Time Systems, IEEE
Computer, Vol.28, No.6, 1995.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

164[Stirling 87] C. Stirling, Modal Logic for Communicating Systems, Theoretical Computer Science, 49,
1987.
[Stirling 89a] C. Stirling, Temporal Logic for CCS, Lecture Notes in Computer Science, Vol.354,
Springer-Verlag, 1989.
[Stirling 89b] C. Stirling and D. Walker, CCS, Liveness, and Local Model Checking in Linear TimeMu-calculus, Lecture Notes in Computer Science, Vol.407, Springer-Verlag, 1989.
[Suzaki 91] K.Suzaki and T.Chikayama, AYA: Process-Oriented Concurrent Programming Language
on KL1 (in Japanese), Proc. KL1 Programming Workshop'91, 1991.
[Suzuki 89] I. Suzuki and H. Lu, Temporal Petri Nets and Their Application to Modeling and Analysis
of a Handshake Daisy Chain Arbiter, IEEE Trans. on Computers, Vol.38, No.5, 1989.
[Suzuki 90] I. Suzuki, Formal Analysis of the Alternating Bit Protocol by Temporal Petri Nets, IEEE
Trans. on Software Engineering, Vol.16, No.11, 1990.
[Taki 89]
K. Taki, The FGCS Computing Architecture, Information Processing, 89, (Proc. IFIP
11th World Computer Congress), 627{632, 1989.
[Leeuwen 90] J. Van Leeuwen (ed.), Handbook of Theoretical Computer Science, Volme B, Formal Models
and Semantics, The MIT Press/Elsevier, 1990.
[Uchihira 87] N. Uchihira, T. Kasuya, K. Matsumoto, S. Honiden, Concurrent Program Synthesis with
Reusable Components Using Temporal Logic, Proc. IEEE COMPSAC'87, 1987.
[Uchihira 88] N. Uchihira, K. Matsumoto, S. Honiden, H. Nakamura, MENDELS: Concurrent Program
Synthesis System Using Temporal Logic, Proc. 6th Logic Programming Conference (K.
Furukawa, et al., eds.), Lecture Notes in Computer Science, Vol.327, Springer-Verlag, 50{
68, 1988.
[Uchihira 89a] N. Uchihira, K. Nishimura, S. Sumida, and H. Kawata. Veri cation and Debugging of Concurrent Robot Control Programs Using Temporal Logic (in Japanese). The 3rd National
Meeting of Japan Society of Arti cial Intelligence, 1989.
[Uchihira 89b] N. Uchihira and S. Honiden, Concurrent Programming Language Based on Petri Nets onIntelligent Distributed Processing System (in Japanese). IEICE Technical Report CPSY
89-34, 1989.
[Uchihira 90a] N. Uchihira, H. Kawata, K. Matsumoto, M. Ito, S. Honiden, Synthesis of Concurrent
Programs: Automated Reasoning Complements Software Reuse, Proc. IEEE 23rd HawaiiInternational Conference on System Science (HICSS), 1990.
[Uchihira 90b] N. Uchihira and S. Honiden, Veri cation and synthesis of concurrent programs using Petrinets and temporal logic, Trans. on IEICE, Vol.E73, No.12 , 1990.
[Uchihira 92a] N. Uchihira, PQL: Modal Logic for Compositional Veri cation of Concurrent Programs(in Japanese), Trans. IEICE Vol.J75-DI, No.2 , 1992), also its english version, Systems
and Computers in JAPAN, Vol. 25, No.1, Jan., Scripta Technica (John Wiley & Sons),
1994.
[Uchihira 92c] N. Uchihira, Compositional synthesis for cooperating discrete event systems from modular
temporal logic speci cations, IEICE Trans. Fundam. Electron. Commun. Comput. Sci.,
Vol.E75-A, No.3, 1992.
[Uchihira 92b] N. Uchihira, M. Arami, S. Honiden, A Petri-Net-Based Programming Environment andIts Design Methodology for Cooperating Discrete Event Systems, IEICE Trans. Fundam.
Electron. Commun. Comput. Sci., Vol.E75-A, No.10, 1992.
[Uchihira 92d] N. Uchihira and S. Honiden, Petri Net and Temporal Logic (in Japanese), Petri nets andits Application, 240{251, SICE Publishing Oce, 1992.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

165[Uchihira 92e] N. Uchihira and S. Honiden, MENDELS ZONE: Petri-net-based Programming Environment for Cooperative Discrete Event Systems (in Japanese), SICE 10th Workshop on
Discrete Event Systems, 21{28, Niigata, 1992.
[Uchihira 93a] N. Uchihira, M. Arami, H. Kawata, Program Veri cation for Sequence Control Systems,
Toshiba Review, Vol.48, No.10, 1993.
[Uchihira 93b] N. Uchihira and S. Honiden, Software Design Methodology using High-Level Petri Nets
(in Japanese), SICE 12th Workshop on Discrete Event Systems, 73-80, Matsuyama, 1993.
[Uchihira 95a] N. Uchihira, S. Honiden, Compositional Adjustment of Concurrent Programs to Satisfy
Temporal Logic Constraints in MENDELS ZONE, IEEE 28th Hawaii International Conference on System Science (HICSS), 1995, also in J. Systems and Software, Vol.33, No.3,
207-221, 1996.
[Uchihira 95b] N. Uchihira and H. Kawata, Practical Program Validation for State-Based Reactive Concurrent Systems { Harmonization of Simulation and Veri cation {, IEICE Trans. Fundam.
Electron. Commun. Comput. Sci., Vol.E78-A, No.11, 1995.
[Uchihira 96a] N. Uchihira, MENDELS ZONE, Tool Presentation, Proc. 17th Internat. Conf. on Application and Theory of Petri Nets (ICATPN), Osaka, 1996.
[Uchihira 96b] N. Uchihira and S. Honiden, A High-Level Petri Net for Accurate Modeling of Reactive andConcurrent Systems, IEICE Trans. Fundam. Electron. Commun. Comput. Sci., Vol.E79A, No.11, 1996.
[Uchihira 96c] N. Uchihira, S. Honiden, T. Seki, Hypersequential Programming { A Novel Paradigm
for Concurrent Programming {, 1st International Workshop on Software Engineering for
Parallel and Distributed Systems, Berlin, 1996.
[Uchihira 97a] N. Uchihira and S. Honiden, Three Phase Net-Oriented Software Design Method (inJapanese), Trans. Inf. Process. Soc. Japan, Vol.38, No.1, 1997.
[Uchihira 97b] N. Uchihira, H. Kawata, Scenario-Based Hypersequential Programming: Concept and Example, 2nd International Workshop on Software Engineering for Parallel and Distributed
Systems, Boston, 1997.
[Uchihira 97c] N. Uchihira, S. Honiden, T. Seki, Hypersequential Programming | A New Paradigm for
Concurrent Program Development |, IEEE Concurrency, Vol.5, No.3, 1997.
[Ueda 90]
K. Ueda and T. Chikayama, Design of the Kernel Language for the Parallel Inference
Machine, Comput. J., Vol.33, No.6, 494{500 (1990).
[Uraoka 92] T. Uraoka, J. Yamamoto, A. Ohsuga, S. Honiden, An Algebraic Speci cation and Veri cation of a Plant Control Expert System (in Japanese), IPSJ Technical Report, SE 86-15,
1992.
[Valk 83]
R.Valk, In nite Behavior of Petri Nets, Theoretical Computer Science, 25, 1983.
[Valk 85]
R.Valk and M.Jantzen, The Residue of Vector Sets with Applications to Decidability
Problems in Petri Nets, Acta Informatica, 21, 1985.
[Vallejo 94] F. Vellejo, J.A. Gregorio, M. G. Harbour, J.M. Drake, Shared Memory Multimicroprocessor Operating System with an Extended Petri Net Model, IEEE Trans. on Parallel
Distrib. Syst., Vol.5, No.7, 1994.
[Valmari 90] A. Valmari, Stubborn Sets for Reduced State Space Generation, Proc. 11th Internat. Conf.
on Application and Theory of Petri Nets (ICATPN), Lecture Notes in Computer Science,
Vol.483, Springer-Verlag, 491{515, 1990.
[Vardi 86]
M.Y. Vardi and P. Wolper, An Automata-Theoretic Approach to Automatic Program
Veri cation, Proc. 1st IEEE Symp. on Logic in Computer Science (LICS), 1986.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

166

D.J. Walker, Bisimulation and Divergence. Information and Computation, 85, 1990.
P. Ward and S. Mellor, Structured Development for Real-time Systems, Vol.1 { Vol.4,
Prentice Hall, 1985.
[Ward 86]
P. Ward, The Transformation Schema: An Extension of the Data Flow Diagram to
Represent Control and Timing, IEEE Trans. on Software Engineering, Vol.12, No.2, 1986.
[Winskel 90] G. Winskel, On the Compositional Checking of Validity, Proc. 1st Internat. Conf. on Concurrency Theory (CONCUR'90), Lecture Notes in Computer Science, Vol.458, SpringerVerlag, 1990.
[Wolper 83a] P. Wolper, M.Y. Vardi, and A.P. Sistla, Reasoning about In nite Computation Paths,
Proc. IEEE 24th Annual Symp. on Foundations of Computer Science (FOCS), 1983.
[Wolper 83b] P. Wolper, Temporal Logic Can Be More Expressive, Information and Control, 56, 1983.
[Wolper 88] P. Wolper, On the Relation of Programs and Computations to Models of Temporal Logic,
Temporal Logic in Speci cation (B. Banieqbal, H. Barringer, A. Pnueli, eds.), Lecture
Notes in Computer Science, Vol.398, Springer-Verlag, 1987.
[Wolper 93] P. Wolper and P. Godefroid, Partial-Order Methods for Temporal Veri cation, Proc.
4th Internat. Conf. on Concurrency Theory (CONCUR'93),Lecture Notes in Computer
Science, Vol.715, Springer-Verlag, 1993.
[Yoshida 88] K. Yoshida and T. Chikayama, A'UM { Stream-Based Concurrent Object-Oriented Language {, Proc. Internat. Conf. on Fifth Generation Computer Systems 1988 (FGCS88),
ICOT, 1988.
[Yoshida 90] K. Yoshida, A'UM A Stream-Based Concurrent Object-Oriented Programming Language,
Ph.D Thesis, Keio University, 1990.
[Yonezaki 91] N. Yonezaki, Conceptual Modeling in MSL, Advances in Information Modeling and Knowledge Bases, IOS Press, 1991.
[Yoneda 93] T. Yoneda, A. Shibayama, B-H. Schlinglo , E.M. Clarke, Ecient Veri cation of Parallel
Real-Time Systems, Conference on Computer-Aided Veri cation (CAV'93), Lecture Notes
in Computer Science, Vol.697, Springer-Verlag, 1993.
[Yoshimura 93] N. Yoshimura, N. Yonezaki, More Expressive Temporal Logic for Speci cation, 5thInternat. Conf. on Software Engineering and Knowledge Engineering, 1993.
[Zave 82]
P. Zave, An Operational Approach to Requirements Speci cation for Embedded Systems,
IEEE Trans. on Software Engineering, Vol.8, No.3, 1982.
[Zave 91]
P. Zave, An Insider's Evaluation of PAISLey, IEEE Trans. on Software Engineering,
Vol.17, No.3, 1991.
[Zhou 92]
M.C. Zhou, F. DiCesare, A. Desrochers, Hybrid Methodology for Synthesis of Petri Net
Models for Manufacturing Systems, IEEE Trans. Robotics and Automation, Vol.8, No.3 ,1992.
[Walker 90][Ward 85]

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

167

Publications by the Author
Journals
1. N. Uchihira and S. Honiden, Veri cation and synthesis of concurrent programs using Petri nets andtemporal logic, Trans. IEICE, Vol.E73, No.12, 2001-2010, 1990.
2. N. Uchihira, PQL: Modal Logic for Compositional Veri cation of Concurrent Programs (in Japanese),
Trans. IEICE, Vol.J75-DI, No.2, 76-87, 1992, also its English version, Systems and Computers inJAPAN, Vol. 25, No.1, Scripta Technica (John Wiley & Sons), 1994.
3. N. Uchihira, Compositional Synthesis for Cooperating Discrete Event Systems from Modular Temporal Logic Speci cations, IEICE Trans. Fundam. Electron. Commun. Comput. Sci., Vol.E75-A,
No.3, 380-391, March, 1992.
4. N. Uchihira, M. Arami, S. Honiden, A Petri-Net-Based Programming Environment and its Design
Methodology for Cooperating Discrete Event Systems, IEICE Trans. Fundam. Electron. Commun.
Comput. Sci., Vol.E75-A, No.10, 1335-1347, 1992.
5. N.Uchihira and H. Kawata, Practical Program Validation for State-Based Reactive Concurrent
Systems { Harmonization of Simulation and Veri cation {, IEICE Trans. Fundam. Electron.
Commun. Comput. Sci., Vol.E78-A, No.11, 1995.
6. N. Uchihira and S. Honiden, Compositional Adjustment of Concurrent Programs to Satisfy Temporal Logic Constraints in MENDELS ZONE, J. Systems and Software, Vol.33, No.3, 207-221,
1996.
7. N. Uchihira and S. Honiden, A High-Level Petri Net for Accurate Modeling of Reactive and Concurrent Systems, IEICE Trans. Fundam. Electron. Commun. Comput. Sci., Vol.E79-A, No.11,
1797-1808, 1996.
8. N. Uchihira and S. Honiden, Three Phase Net-Oriented Software Design Method (in Japanese),
Trans. Inf. Process. Soc. Japan, Vol.38, No.1, 1997.
9. N. Uchihira, S. Honiden, T. Seki, Hypersequential Programming | A New Paradigm for Concurrent
Program Development |, IEEE Concurrency, Vol.5, No.3, 44-54, 1997.
10. S. Honiden. N. Uchihira, A. Ohsuga, and T. Kasuya, MENDEL: Meta-Inferential System Description Language (in Japanese), Trans. Inf. Process. Soc. Japan, Vol. 27, No. 2, 219-217, 1986.
11. S. Honiden, N. Uchihira, K. Matsumoto, K. Matsumura, M. Arai, An Application of Structural
Modeling and Automated Reasoning to Real-Time Systems Design, Real-Time Systems, Vol.1,
No.4, 313-331, 1990.
12. S. Honiden, N. Sueda, A. Hoshi, N. Uchihira, K. Mikame, Software Prototyping with Reusable
Components, J. Inf. Process. Japan, Vol. 9, No. 3, 123-129, 1986.
13. S. Honiden, A. Ohsuga, and N. Uchihira, An integration method of real time SA and object oriented
design using algebraic and temporal logic speci cations (in Japanese) Trans. Inf. Process. Soc.
Japan, Vol.33, No.2, 173-182, 1992.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

168

14. S. Honiden and N. Uchihira, Net-oriented analysis and design, IEICE Trans. Fundam. Electron.
Commun. Comput. Sci., Vol.E75-A, No.10, 1317-1325, 1992.
15. S. Honiden, K. Nishimura, N. Uchihira, K. Itoh, An Application of Arti cial Intelligence to ObjectOriented Performance Design for Real-Time Systems, IEEE Trans. on Software Engineering,
Vol.20, No.11, 1994.
16. S. Honiden, A. Ohsuga, N. Uchihira, MENDELS ZONE: A parallel program development system
based on formal speci cations, Information and Software Technology, Vol.38, 181{189, 1996.

Conferences
1. N. Uchihira, T. Kasuya, K. Matsumoto, S. Honiden, Concurrent Program Synthesis with Reusable
Components Using Temporal Logic, Proc. IEEE COMPSAC'87, Tokyo, 1987.
2. N. Uchihira, K. Matsumoto, S. Honiden, and H. Nakamura, MENDELS: Concurrent Program
Synthesis System Using Temporal Logic, Proc. the 6th Logic Programming Conference, Tokyo,
1987, also in Lecture Notes in Computer Science, Vol.327, Springer-Verlag, 1988.
3. N. Uchihira, H. Kawata, K. Mastumoto, M. Ito, S. Honiden, Synthesis of Concurrent Programs:
Automated Reasoning Complements Software Reuse, 23rd Hawaii International Conference on
System Science (HICSS), 1990.
4. N. Uchihira and S. Honiden, Compositional Adjustment of Concurrent Programs to Satisfy Temporal Logic Constraints in MENDELS ZONE, Proc. IEEE 28th Hawaii International Conference
on System Science (HICSS), 1995.
5. N. Uchihira, S. Honiden, T. Seki, Hypersequential Programming { A Novel Paradigm for Concurrent
Programming {, 1st International Workshop on Software Engineering for Parallel and Distributed
Systems, Berlin, Chapman & Hall, 1996.
6. N. Uchihira, H. Kawata, Scenario-Based Hypersequential Programming: Concept and Example,
2nd International Workshop on Software Engineering for Parallel and Distributed Systems, Boston,IEEE Computer Society Press, 277-283, 1997.
7. N. Uchihira, H. Kawata, F. Tamura, Scenario-Based Hypersequential Programming: Formulationof Parallelization, International Symposium on High Performance Computing (ISHPC), Fukuoka,
Lecture Notes in Computer Science, Vol.1336, Springer-Verlag, 267-240, 1997.
8. N. Uchihira, How to Make Concurrent Programs Highly Reliable { More Than State Space Analysis,
International Conference on Application of Concurrency to System Design, Aizu-Wakamatsu, IEEE
Computer Society Press, 16-23, 1998.
9. S. Honiden, N. Uchihira, K. Mastumoto, K. Matsumura, M. Arai, An Application of Structural
Modeling and Automated Reasoning to Concurrent Program Design, Proc. IEEE 22th HawaiiInternational Conference on System Science (HICSS), Vol.II: Software Track, 134-141, 1989.
10. S. Honiden, A. Ohsuga, and N. Uchihira, An Integration Environment to Put Formal Speci cations
into Practical Use in Real-time Systems, Proc. the Sixth International Workshop on Software
Speci cation and Design (IWSSD), IEEE Comput. Soc. Press, 102-109, 1991.
11. S. Honiden, N. Uchihira, and K. Itoh, An Application of Arti cial Intelligence to Prototyping
Process in Performance Design for Real-time Systems, Proc. 3rd European Software Engineering
Conference (ESEC), Lecture Notes in Computer Science, Vol.550, Springer-Verlag, 1991.
12. S. Honiden, N. Uchihira, K. Matsumoto, and K. Itoh, A Prototyping Process for Performance
Design in Real-time Systems, Proc. InfoJapan '90, Vol.1, 103-110, North-Holland, 1990.
13. H. Kawata and N.Uchihira, Practival Program Validation for Plant Control Systems Using SFC andTemporal Logic, 1996 IEEE International Conference on Systems, Man, and Cybernetics (SMC'96),
1996.

N. Uchihira: Programming Environment for Reactive and Concurrent Systems

169

Articles
1. S. Honiden, N. Uchihira, K. Matsumoto, Temporal Logic and Petri Nets (in Japanese), Operations
Research, Japan Society of Operations Research, Oct., 1987.
2. S. Honiden, N. Uchihira, H. Nakamura, Automatic Programming for Control Systems (in Japanese),
Inf. Process. Soc. Japan, Vol.28, No.10, 1398-1404, 1987.
3. K. Matsumoto, N. Uchihira, S. Honiden, Temporal Logic and their Applications (in Japanese), Inf.
Process. Soc. Japan, Vol.30, No.6, 651-657, 1989.
4. N. Uchihira, S. Honiden, Petri Nets and Temporal Logic (in Japanese), SICE Special Interest Groupfor Discrete Event Systems (ed.), Petri Nets and Its Applications, SICE, 1992.
5. M. Aoyama, K. Hiraishi, N. Uchihira, Software Development Methodologies Based on High Level
Petri Nets (in Japanese), Computer Software, Vol.11, No.4, 3-19, Japan Society for Software Scienceand Technology (JSSST), 1994.
6. N. Uchihira and H. Kawata, Exhaustive Simulation of Discrete Event Systems (in Japanese), Journalof The Society of Instrument and Control Engineers (SICE), Vol.35, No.10, 763-769, 1996.
7. N. Uchihira and H. Kawata, Testing Control Programs: A Survay (in Japanese), Journal of IPSJ
Vol.39, No.1, 19-25, 1998.
8. N. Uchihira, K. Hiraishi, M. Aoyama, Petri Nets: Book and Tool Review (in Japanese), Journal of
IPSJ Vol.39, No.1, 67-70, 1998.

Books
1. K. Itoh, S. Honiden, N. Uchihira, Prototyping Tools (in Japanese), Keigaku Shuppan, 1987.
2. M. Aoyama, N. Uchihira, K. Hiraishi, Petri Nets { Theory and Practice { (in Japanese), Asakura
Shoten, 1995.

Index-calculus, 28!-automaton, 13!-bisimulation equivalence, 59, 93
!-bisimulation, 59
!-divergence, 59, 93

fairness condition, 22
FCTI program, 91
FGCS, 141
nite automaton, 20
nite branching condition, 20
nite state process, 21
ring rule, 23
formal method, 10
formal speci cation, 37
formula, 24
free state logical variable, 62
function block, 109

abstraction, 108
activity-chart, 151
adjustment, 90
algebraic Petri net, 110
aperiodic task, 33
arbiter, 91
attribute network, 146
AUTO/AUTOGRAPH, 16

G-LOTOS, 124
general temporal logic, 57
general temporal logic (GTL), 57
generalized stochastic Petri net, 24
GTL, 57

Buchi sequential automaton, 20, 43
base-level net, 117
basic adjustment, 91, 96
bisimulation, 59
bisimulation equivalence, 60
branching time temporal logic, 13, 26

harmful nondeterminism, 90
Hennessy-Milner Logic (HML), 57
hierarchical synchronization supervisor, 50
high-level Petri nets, 109
High-level SFC, 109
HML, 57
HMS machine, 75
hypersequential programming, 156

C-net, 110
Cabernet, 16
causality matrix, 127, 128, 145
causality matrix editor, 145
coloured Petri net (CPN), 110
communicating transition systems, 22completeness, 22composition, 61
compositional adjustment, 92, 98
compositional veri cation, 57, 82
computation tree logic (CTL), 26
concurrency control, 106
concurrent tasks, 108
CTL, 26, 56
CTL*, 27
CWB, 16

I/O automata, 23
I/O de nition editor, 145
I/O task, 33
IFC, 109
IHML, 89
indirect communication, 115
inevitably unsatis able behavior, 22
information hiding, 108
initial marking, 23
intended nondeterminism, 90
interleaving semantics, 22internal task, 33
Intuitionistic HML (IHML), 58

DARTS, 15
DESIGN/CPN, 16, 110
divergence, 57
dual-language approach, 13, 41

KL1, 112, 143
Kripke structure, 25

event ag, 108
external deadlock, 57

ladder chart, 109
legal ring sequence, 24
linear time temporal logic, 13, 25
liveness property, 40

failure, 88
failure equivalence, 88, 106
170

N. Uchihira: Programming Environment for Reactive and Concurrent Systems
lower CASE tool, 142
mail box, 108
maximum xed point operator, 63
MENDEL net, 111
MENDEL net editor, 145
MENDEL translator, 147
MENDELS ZONE, 17, 141, 143
meta-level net, 117
meta-place, 117
method, 112
method editor, 145
MFG/PFS, 109
minimum xed point operator, 63
model-checking, 56
module-chart, 151
Multi-PSI, 143
multi-view design method, 153
Net-Oriented Design Method, 139
OBJSA net, 124
observation equivalence, 57
Oleo, 145
OOAD, 15
page, 123
parameterized !-divergence, 88partial bisimulation equivalence, 88partial bisimulation equivalence by global divergence, 88partial bisimulation preorder by local divergence,
88
partial bisimulation preorder with global divergence, 88partial order approach, 83, 156partial order method, 54, 83
path formula, 62
periodic task, 33
persistent nondeterminism, 90
Petri net, 23, 75
Petri net language, 24
Petri-net-oriented design methodology, 127
place, 23
place fusion, 115
place procedure, 110
PLTL, 25
PLTL editor, 147
plug, 115
PQL (Process Query Language), 62
predicate/transition net, 110probe e ect, 36, 142
process library, 145process logic, 57
process place, 118
process status information, 119
process status token, 118
process-oriented hierarchy, 114

171

process-oriented net hierarchy, 123
program adjustment, 90
programmable logic controller (PLC), 109
programming environment, 141
propositional logic, 24
propositional process logic (PPL), 27
Protob, 124
PTSV, 56
RCS, 30
reactive and concurrent system, 30
reactive system, 30
realizable, 97
reduction function, 69
relabeling, 61
rendezvous, 108
RTSAD, 15safety property, 40
satis able behavior, 22
SAVE/SFC, 81
SCR, 110semaphore, 108
SFC, 75, 76, 109
single event condition, 26
single-view design method, 153
software design document (SDD), 37
SPIN, 16SPQL (Strong Process Query Logic), 62
SPQL formula, 62
state explosion problem, 14
state formula, 62
Statechart, 23, 75, 151
STATEMATE, 16, 151
subnet-oriented hierarchy, 114
subnet-oriented net hierarchy, 123
substitution place, 123
substitution transition, 123
supervisory control, 106
symbolic model checking, 54
task communication, 108
task scheduling, 108
task synchronization, 108
temporal logic, 25
TFS, 30
three phase net-oriented software design method,155
time basic net, 24
time Petri net, 24, 54
timed automata, 24
timed graph, 24
timed transition system, 24
token sharing, 117
token-oriented net hierarchy, 124trace equivalence, 88transformational system, 30

N. Uchihira: Programming Environment for Reactive and Concurrent Systems
transition, 23transition fusion, 115
transition system, 19
unrealizable, 97
unsatis able state, 22
upper CASE tool, 142
VERASQUES, 81
veri cation scope, 67
visual monitor, 147

172