Hướng dẫn sử dụng UPPAAL 4.0

Đại học Bách Khoa Hà Nội
Bài tập lớn môn học Hệ sự kiện rời rạc
Hướng dẫn sử dụng UPPAAL 4.0
Tham khảo: A Tutorial on Uppaal 4.0
Gerd Behrmann, Alexandre David, Kim G. Larsen
Nhóm sinh viên thực hiện:
Phí Trọng Huy
Trịnh Hoàng Minh
Trần Ngọc Sơn
Giảng viên hướng dẫn:
Th.S Đinh Thị Lan Anh
Ngày 23 tháng 11 năm 2012
Mục lục
1 Giới thiệu về phần mềm Uppaal 7
2 Timed-automata trong Uppaal 8
2.1 Ngôn ngữ mô hình hóa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Ngôn ngữ truy vấn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Automat định thời . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Tổng quan về Uppaal Toolkit 17
3.1 Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Stand-alone Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Ví dụ 1: The Train Gate 20
4.1 Nội dung bài toán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Mô hình hóa trên Uppaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Kiểm chứng (Verification) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Ví dụ 2: Fischer’s Protocol 26
5.1 Nội dung bài toán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Mô hình hóa trên Uppaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Kiểm chứng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 Ví dụ 3: The Gossiping Girls 28
6.1 Nội dung bài toán . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2 Mô hình hóa trên UPPAAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Kiểm chứng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7 Các thiết kế mẫu 31
7.1 Giảm biến số . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2 Truyền giá trị đồng bộ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.3 Truyền giá trị đồng bộ(tiếp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2
7.4 Đa hướng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.5 Atomicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.6 Urgent Edges (Cạnh khẩn cấp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.7 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.8 Kiểm tra phạm vi sống . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.9 Trừu tượng hóa và mô phỏng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8 Các demo khác trong Uppaal 46
8.1 Demo: 2 doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.2 Demo: Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9 So sánh Automata và Petri Nets 54
10 Kết luận 57
3
Danh sách hình vẽ
2.1 Automat đơn giản của một chiếc đèn bàn . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Ngữ nghĩa của TA: Các vận hành khác nhau của TA từ cùng một trạng thái đầu . 10
2.3 Khai báo hằng và biến, ví dụ về đồng bộ kênh giữa hai template. . . . . . . . . . 11
2.4 Khai báo hằng và biến, ví dụ về đồng bộ kênh giữa hai template. . . . . . . . . . 12
2.5 Ví dụ đầu tiên với bộ quan sát . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Automat khi không còn bộ quan sát . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Ví dụ trên khi sử dụng guard và không dùng invariant . . . . . . . . . . . . . . . 15
2.8 Ba automata song song minh họa các trạng thái normal, urgent và committed.
Các clocks là các biến local, tức là P0.x khác P1.x . . . . . . . . . . . . . . . . . . 16
3.1 Demo The Train Gate(chương 4). Nút Select có thể chọn được. Ở chế đọ này người

dùng có thể di chuyển các địa điểm và edge hay sửa các nhãn. Chế độ còn lại dùng
để thêm vào các địa điểm, edge, nail (đỉnh của edge). Địa điểm mới thì mặc định
không có tên. Có 2 chỗ người dùng có thể đặt tên và tham số. . . . . . . . . . . . 18
3.2 Các khai báo toàn cục và cục bộ trong demo The Train Gate . . . . . . . . . . . . 19
4.1 Hình 12. View of the verification tab for the train gate example. . . . . . . . . . . 21
4.2 Ví dụ Train Gate: Train4 sắp qua cầu, Train3 phải dừng lại, Train2 nhận lệnh
dừng và đang dừng lại. Train1 đang tiến đến cầu và gửi một tín hiệu appr! tới
controller, sau đó controller gửi lại một lệnh stop!. Các khoảng thời gian giữa các
sự kiện lần lượt là (10, 10, 3 5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Lúc này train4 đã đi qua cầu và gửi về tín hiệu leave!. Bộ điều khiển lúc này cho
phép train3 sử dụng cầu với lệnh go!. Train2 lúc này đang đợi lệnh để khởi động
lại và train1 lúc này đang dừng lại. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Automat của bộ điều khiển ga tàu điện. . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 Automat của hàng đợi trong bộ điều khiển. . . . . . . . . . . . . . . . . . . . . . 25
5.1 Automat chung của một giao thức Fischer. Automat này có id là một biến toàn
cục, còn các biến địa phương gồm clock x; và hằng số const k 2; . . . . . . . . . . 27
4
6.1 Mô hình hóa cho bài toán The Gossiping Girls. . . . . . . . . . . . . . . . . . . . 29
6.2 Thời gian và dung lượng bộ nhớ cần thiết để chạy mô phỏng bài toán Gossiping
Girl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1 Mô hình hàng đợi trong ví dụ cổng tầu dùng 2 lần giảm biến hoạt động. Cả hai
trường hợp là trên cạnh từ Shiftdown đến Start: Phần tử tự do trong hàng đợi
được reset đến giá trị khởi tạo và cũng như biến đếm i. . . . . . . . . . . . . . . . 32
7.2 Có 4 cách truyền biến đồng thời-một chiều-hai chiều-không điều kiện-có điều kiện. 34
7.3 Trái với mã hóa hai chiều ở hình 22, mã hóa này là đối xứng theo nghĩa cả hai
automat dùng mã hóa hoàn toàn giống nhau. Tính đối xứng đến với chi phí không
gian trạng thái lớn hơn một chút. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.4 Truyền một mảng giá trị. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.5 Gửi đa hướng từ một sender tới N receivers (N=3 trong ví dụ này) . . . . . . . . 37
7.6 Khi loại bỏ phần tử đầu từ hàng đợi, tất cả các phần tử khác phải bị dịch xuống.

Điều này làm xong trong vòng lặp trong vị trí Shiftdown. Để tránh việc chèn không
cần thiết, vị trí này được đánh dấu là chuyển tiếp (committed). Chú ý rằng cạnh
vào Shiftdown đồng bộ trên kênh rem. Điều quan trọng là vị trí đích của cạnh
đồng bộ trên rem trong các quá trình khác không được đánh dấu là chuyển tiếp. . 38
7.7 Ví dụ sử dụng cạnh khẩn cấp: Kênh go được định nghĩa là một cạnh khẩn cấp . . 39
7.8 Ví dụ một timer sử dụng cạnh khẩn cấp mỗi khi được khởi động . . . . . . . . . . 40
7.9 Mẫu của mô hình timer. Mẫu (a) có int value; chan set là tham số và mẫu (b) có
bool active; chan set; const T0 là tham số. Cả hai mẫu có khai báo cục bộ clock x. 41
7.10 Ví dụ The Train Gate được điều chỉnh để cho phép kiểm tra phạm vi tính sống . 43
7.11 Mô hình một hệ thống pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.12 Một gợi ý cho việc trừu tượng hóa và atomat để kiểm tra gợi ý đó . . . . . . . . . 45
8.1 Automat của cánh cửa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2 Automat của người mở cửa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.3 Kiểm chứng demo 2doors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.4 Automat Soldier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5 Automat Touch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.6 Kiểm chứng bài toán Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1 Việc lập sơ đồ của chuyển tiếp bộ ba (x, e, x

) trong G đến hai vị trí, một chuyển
tiếp ghi nhãn và hai cung trong hình của Petri Net N. . . . . . . . . . . . . . . . 55
5
Giới thiệu chung
Tài liệu này sẽ bắt đầu bằng vài nét về lịch sử phần mềm Uppaal ở chương 1. Tiếp theo,
chương 2 đề cập đến các automat định thời. Giới thiệu về các tính năng của phần mềm Uppaal
sẽ có ở chương 3. Để minh họa cách sử dụng Uppaal, ba demo khác nhau được phân tích trong
các chương 4, 5, 6. Chương 7 tập trung giới thiệu những mô hình mẫu hay được sử dụng nhiều
khi mô hình hóa bằng Uppaal. Chương 8 giải thích các demo được cung cấp kèm theo trong
phần mềm Uppaal. Chương 9 so sánh Automat và Petri Nets, hai phương án thông dụng hiện
nay để mô hình hóa các hệ sự kiện rời rạc. Cuối cùng, chương 10 là tổng kết chung và một số

suy nghĩ của nhóm về bài tập lớn này.
Do trình độ có hạn và cũng do sự phức tạp của môn học Hệ sự kiện rời rạc nói chung và
phần mềm Uppaal nói riêng, tài liệu này chắc chắn có những lỗi sai. Nhiều thuật ngữ tiếng Anh
hiện còn chưa có được những thuật ngữ chuẩn tương ứng bằng tiếng Việt đã được nhóm hoặc
tạm dịch sao cho thoát được ý, hoặc vẫn giữ nguyên tiếng Anh. Để có được thông tin một cách
chính xác nhất, bạn đọc nên cùng lúc tham khảo tài liệu gốc "A Tutorial on Uppaal 4.0" của
Gerd Behrmann, Alexandre David, Kim G. Larsen. Hi vọng trong tương lai những tài liệu về hệ
sự kiện rời rạc và phần mềm Uppaal sẽ sớm được xuất bản tại Việt Nam.
6
Chương 1
Giới thiệu về phần mềm Uppaal
Uppaal là một phần mềm để kiểm tra những hệ thống thời gian thực, được phát triển bởi Đại
học Uppsala và Đại học Aalborg. Phần mềm được ứng dụng thành công trong những nghiên
cứu ở nhiều lĩnh vực như giao thức truyền thông hay ứng dụng multimedia. Công cụ này dùng
để kiểm định những hệ thống được mô hình hóa thành hệ thống những automat định thời với
những biến số nguyên, cấu trúc dữ liệu, hàm người dùng, và đồng bộ các kênh.
Phiên bản đầu tiên của Uppaal ra đời vào 1995. Kể từ đó phần mềm đã phát triển không
ngừng để theo kịp với những tiến bộ vè cấu trúc dữ liệu, giảm bậc hệ thống, bản phân phối của
UPPAAL, hỗ trợ tính năng tối thiểu hóa chi phí, hỗ trợ UML Bản 4.0 . Đã có những nghiên
cứu tiến sĩ thực hiện bằng Uppall. Nó hỗ trợ Java và có phần kiểm chứng được viết bằng ngôn
ngữ C++.
7
Chương 2
Timed-automata trong Uppaal
Khả năng kiểm chứng mô hình của Uppaal dựa trên giả thuyết là automat thời gian và ngôn
ngữ mô hình hóa hỗ trợ những tính năng như biến số nguyên có giới hạn. Ngôn ngữ truy vấn
của Uppaal, sử dụng để kiểm tra tính chất của hệ là tập con của TTCL (Timed Computation
Tree Logic: tính toán logic rẽ nhánh theo thời gian). Ở phần này chúng ta sẽ nghiên cứu cách
mô hình hóa và ngôn ngữ truy vấn của Uppaal và giải thích rõ ràng về thời gian trong automat
thời gian.

2.1 Ngôn ngữ mô hình hóa
Hệ thống của các automat thời gian: automat thời gian là 1 máy có số trạng thái hữ hạn mở rộng
với đồng hồ giá trị thực. Tất cả các đồng hồ này được đồng bộ hóa với nhau. Trong UPPAAL,
một hệ thống được mô hình là mạng của những automat thời gian sắp xếp song song. Mô hình
được mở rộng với các biến rời rạc bị chặn ở trạng thái. Những biến này được sử dụng tỏng ngôn
ngữ lập trình: có thể đọc, ghi và thực hiện các phép tính số học. Một trạng thái của hệ thống
định nghĩa bởi vị trí của các automat, giá trị đồng hồ và các biến rời rạc. Mỗi automat có thể
thay đổi (không nên hiểu là sự chuyển tiếp) độc lập hay đồng bộ với 1 automat khác, dẫn đến 1
trạng thái khác.
Hình 2.1(a) thể hiện automat thời gian mô hình 1 cái đèn. Đèn có 3 mức: tắt, sáng yếu và sáng
mạnh. Nếu người dùng bấm 1 nút, chẳng hạn đồng bộ với Press? , thì đèn sẽ bật. Nếu ấn 1 lần
nữa, đèn tắt. Bấm 2 lần liên tiếp, đèn chuyển sang sáng mạnh. Mô hình như vậy ở hình 2.1(b).
Người dùng có thể ấn nhiều lần hoặc không ấn gì cả. Đồng hồ y để kiểm tra xem người dùng ấn
nhanh (y<5) hay chậm (y>=5).
Sau đây ta sẽ đưa ra định nghĩa về automat thời gian một cách đơn giản, bỏ qua những tính
năng cao cấp có trong Uppaal. Chú ý rằng: C là tập đồng hồ, B(C) là tập các sự kết hợp dựa
trên những điều kiện đơn giản của x,y thuộc C.
8
CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL 2.1. NGÔN NGỮ MÔ HÌNH HÓA
Hình 2.1: Automat đơn giản của một chiếc đèn bàn
Định nghĩa 1 Automat định thời (Timed Automata, TA) được định nghĩa bởi bộ (L, l
0
, C, A, E, I),
với L là một tập các trạng thái, l
0
∈ L là các trạng thái ban đầu, C là tập các đồng hồ, A là tập
các actions, co-actions and the internal τ-action, E ⊆ LxAxB(C)x2CxL là tập các cung nối các
trạng thái, trên E có các action, guard và một tập các đồng hồ có thể reset, và I : L → B(C)
gán các invariants ở các trạng thái.
Trong ví dụ ở hình 2.1, y:=0 là reset của đồng hồ y, các nhãn press? và press! chỉ chuỗi hành

động.
Tiếp theo ta sẽ định nghĩa về ngữ nghĩa của automat thời gian. Hàm u : C → R
>=0
từ tập các
đồng hồ đến số thực không âm chỉ giá trị của đồng hồ. R
C
là tập các giá trị đồng hồ. u
0
(x) = 0
với mọi x ∈ C.
Hình 2.1 thể hiện ngữ nghĩa của TA. Từ một trạng thái nhất định, ta có thể lựa chọn action
hoặc delay. Phụ thuộc vào thời gian delay, có những action có thể bị cấm.
TA thường bao gồm một mạng những TA dựa trên một tập đồng hồ và chuyển tiếp, chứa n
automat A
i
, 1 ≥ x ≥ n.
Aptomat định thời(TA) trong UPPAAL Ngôn ngữ mô hình hóa của UPPAAL mở rộng
với những tính năng sau:
Templates automat có thể được khai báo với tập những tham số nhận mọi kiểu giá trị (int,
char ). Những tham số này thay thế cho đối số trong khai báo quá trình.
Constants khai báo là const name value. Hằng không thể thay đổi và phải có giá trị là số
nguyên.
Bounded integer variables biến nguyên bị chặn, được khai báo là int[min, max] name, min
và max là cận trên và dưới. Guard, invariant và assignment có thể diễn tả bởi các biến này.
9
2.1. NGÔN NGỮ MÔ HÌNH HÓA CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL
Hình 2.2: Ngữ nghĩa của TA: Các vận hành khác nhau của TA từ cùng một trạng thái đầu
Nếu vi phạm các cận thì sẽ dẫn tới trạng thái không tồn tại. Nếu không có cận thì mặc
định là từ -32768 dến 32768.
Binary synchronisation kênh khai báo là chan c. Một cạnh dán nhãn c! đồng bộ với nhãn

khác là c?. Cặp đồng bộ chọn ngẫu nhiên nếu có nhiều khả năng kết hợp xảy ra.
Broadcast channel khai báo là broadcast chan c. Trong broadcast synchronisation 1 người gửi
c! có thể đồng bộ với số lượng tùy y các người nhận c?
Urgent synchronisation kênh được khai báo khi thêm vào khai báo kênh cú pháp urgent. Nếu
có kênh có nhãn urgent thì sẽ không có trễ khi đồng bộ chuyển tiếp.
Urgent location tương đương với 1 đồng hồ thêm x về mặt ngữ nghĩa, reset ở mọi cạnh đến
và có bất biến. Do đó, thời gian không được thay đổi khi hệ thống đang ở Urgent location.
Committed location điều kiện còn chặt chẽ hơn urgent. Một trạng thái là committed nếu mọi
location trong trạng thái đó là committed.
Arrays dùng được cho đông hồ, kênh, hằng và biến nguyên. Ví dụ: chan c[4], clock a[2]
Initialisers dùng để khởi tạo biến nguyên và mảng của nó. Ví dụ: int i=2; hay int i[3]=1,2,3;
Record types khai báo với struct như trong C.
Custom types tương tự như typedef trong C.
10
CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL 2.1. NGÔN NGỮ MÔ HÌNH HÓA
Hình 2.3: Khai báo hằng và biến, ví dụ về đồng bộ kênh giữa hai template.
User functions có thể khai báo toàn cục hay địa phương trong các templates. Cách sử dụng
tương tự như C nhưng không có con trỏ.
Expressions in UPPAAL Expressions in Uppaal range over clocks and integer variables. Ex-
pression được dùng với các nhãn sau:
Select một danh sách diễn đạt name : type trong đó name là tên biến và type là kiểu biến.
Những biến này chỉ có thể truy nhập khi ở cạnh tương ứng và nhận giá trị không định
trước trong kiểu của nó.
Guard diễn đạt thỏa mãn những điều kiện sau: không hiệu ứng phụ , trả về dạng boolean, chỉ
liên quan đến đồng hồ, biến nguyên và hằng, chênh lệch giữa các đồng hồ chỉ so sánh với
11
2.2. NGÔN NGỮ TRUY VẤN CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL
Hình 2.4: Khai báo hằng và biến, ví dụ về đồng bộ kênh giữa hai template.
diễn tả nguyên.
Synchronisation diễn tả bằng Expression! hay Expression? hay nhãn trống. Biểu diễn này

phải không có hiệu ứng phụ, đánh giá kênh, chỉ đến số nguyên, hằng hoặc các kênh.
Update danh sách ngăn cách bởi dấu phẩy với hiệu ứng phụ, chỉ có thể chỉ đến đồng hồ, biến
nguyên và hằng. Có thể gọi được hàm.
Invariant thỏa mãn những điều kiện sau: không hiệu ứng phụ, chỉ đồng hồ, biến nguyên và
hằng là liên quan.
2.2 Ngôn ngữ truy vấn
Mục đích chính của kiểm chứng mô hình là kiểm tra xem nó có thỏa mãn những tính chất cho
trươc không. Cũng như mô hình, các tính chất này cũng cần thể hiện bằng ngôn ngữ mà máy
có thể hiểu được. UPPAAL sử dụng dạng đơn giản của TTCL. Cũng như trong TTCL, ngôn
ngữ truy vấn bao gồm path formulae và state formulae. State formulae biểu diễn trạng thái, ở
đó Path formulae các định sô lượng path và trace của mô hình. Path formulae có thể phân loại
thành Reachability, Safety và Liveness.
12
CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL 2.2. NGÔN NGỮ TRUY VẤN
State formulae là cách biểu diễn cho trạng thái mà không cần quan tâm đến mô hình. Ví dụ
như cách biểu diễn đơn giản như i == 7, nó là đúng ở một trạng thái bất cứ khi nào i băng
7. Cú pháp của State formulae là tập bao của guard, nhưng so với guard thì phép tuyển
không bị cấm. Ta cũng có thể kiểm tra xem quá trình đang ở địa điểm nào nếu biểu diển
P.1 chẳng hạn, trong đó P là quá trình và 1 là địa điểm. Trong UPPAAL, khóa chết được
biểu diễn nhớ 1 State formulae đặc biệt. Formula sử dụng từ kháo deadlock và thỏa mãn
mọi trạng thái khóa chết. Do hạn chế của Uppaal, trạng thái kháo cứng chỉ có thể sử dụng
với State formulae dạng reachability và invariantly.
Reachbility Properties (tính có thể đạt được) dạng đơn giản nhất của Properties trong
đó hỏi 1 state formula có thể thỏa mãn bới bất cứ trạng thái đạt đến (reachable state) nào
được không. Nói cách khác, có 1 cách đi nào từ trạng thái ban đấu, mà tính chất đó có thể
thỏa mãn trên cách đi đó. Reachbility Properties thường được sử dụng khi thiết kế mô hình
mà cần kiểm tra 1 tính chất nào đó. Ví dụ, khi thiết kế giao tiếp giữa gửi và nhận, thường
ta cần biết người gửi có thể gửi được không, và người nhận có thể nhận được không. Nó
không chứng minh sự đứng đắn của mô hình (thông điệp có thể dần được gửi), nhưng nó
kiểm tra hoạt động cơ bản của mô hình. Trong UPPAAL, cú pháp là E<>ϕ.

Safety Properties (SP) Tính chất này đảm bảo các sự cố không bao giờ xảy ra. Ví dụ, trong
mô hình của nhà máy điện nguyên tử, SP có thể là nhiệt độ của lò luôn ở dưới một ngưỡng,
nếu không lõi sẽ bị tan chảy. Nó cũng có thể đươc hiểu là: điều gì đó sẽ khó có thể xảy ra.
Ví dụ như khi chơi game, SP đảm bảo ta có thể thằng hoặc ít nhất là không thua. Trong
UPPAAL, ta thể hiện theo nghĩa tích cực như điều tốt là bất biến đúng. Gọi ϕ là một state
formulae. Khi đó biểu diễn có thể đúng ở mọi trạng thái đến được bằng path formulae A
trong đó E chỉ ra có một đường đi mà ϕ luôn đúng. Trong Uppaal, ta viết A[] ϕ và E[] ϕ
tương ứng.
Liveness Properties Tính chất này đảm bảo một điều gì đó trước sau gì cũng xảy ra, ví dụ
như khi bấm chuyển kênh trên TV thì sau đó TV sẽ sang kênh khác. Hoặc trong giao tiếp
thì thông điệp nào gửi đi cũng sẽ được nhận. Ở dạng đơn giản, liveness biểu diễn với path
formulae A  ϕ chỉ ra rằng ϕ sẽ được thỏa mãn. Thường dùng là cách biểu diễn dẫn đến
hay phản hồi, viết là ϕ ∼→ ψ được hiểu là khi ϕ thỏa mãn thì ψ cũng thỏa mãn. Trong
UPPAAL, các biểu diễn này được viết là A<>ϕ và ϕ − − > ψ tương ứng.
13
2.3. AUTOMAT ĐỊNH THỜI CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL
2.3 Automat định thời
Invariants và Guard mô hình thời gian của UPPAAL là liên tục. Ta minh họa khái niệm thời
gian qua một ví dụ bộ quan sát (observer). Thường thì observer phụ trách việc theo dõi sự kiện
mà không cần thay đổi hệ quan sát. Ở đây clock reset (x:=0) dùng làm observer cho minh họa.
Hình 2.3 cho thấy mô hình với bộ quan sát. Có 2 automat song song. Cái thứ nhất có 1 vòng lặp
Hình 2.5: Ví dụ đầu tiên với bộ quan sát
với điều kiện là x>=2, x là clock, đồng bộ với kênh reset với automat thứ 2. Cái thứ 2, bộ quan
sát, phát hiện khi nào vòng lặp được thực hiện với địa điểm taken và sau đó quay lại idle đồng
thời reset đồng hộ x. Mục đích của việc chuyển reset từ test sang observer là để xem điều gì xảy
ra ở bước chuyển trước khi có reset. Taken được chọn là committed để tránh delay khi đến đây.
Những tính chất sau có thể kiểm chứng ở UPPAAL. Gọi tên bộ quan sát là Obs ta có: - A[ ]
Obs.taken imply x>=2 : sẽ reset x khi x>=2. Nó chỉ ra rằng cứ khi nào ở Obs.taken thì x>=2.
- E<> Obs.idle and x>3: chỉ ra rằng có thể đến được E khi Obs ở idle và x>3.
Ta bổ sung mô hình trên bằng cách thêm vào invariant ở phần loop trong hình 2.3. Invariant

là điều kiện chạy: hệ thống không được phép ở 1 trạng thái quá 3 đơn vị thời gian, phải chuyển
trạng thái ngay và reset đồng hồ. ĐỒng hồ x có 3 là hạn trên. Những tính chất sau là có được:
- A [] Obs.taken imply (x>=2 and x<=3): chuyển giữa thời điểm 2 và 3.
- E <> Obs.idle and x>2: co thể chuyển được khi x ở giữa 2 và 3.
- A [] Obs.idle imply x<=3: thỏa mãn điều kiện hạn trên. Tính chất E<> Obs.idle and x>3 ở
trên không có nữa.
Bây giờ nếu ta bỏ invariant và thay vào đó là guard với x>=2 và x<=3, tưởng như giống nhau
nhưng thực ra không phải! Hệ thống không cón điều kiện chạy. Nhìn hình 2.3 ta thấy hệ thống
có thể chuyển trạng thía như cũ nhưng lại có thể xảy ra deadlock. Điều đó xảy ra khi nó không
14
CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL 2.3. AUTOMAT ĐỊNH THỜI
Hình 2.6: Automat khi không còn bộ quan sát
Hình 2.7: Ví dụ trên khi sử dụng guard và không dùng invariant
chịu chuyển sau 3 đơn vị thời gian. Bản chất là tính chất sau không được thỏa mãn: A [] not
deadlock. Tính chất A [] Obs.idle imply x<=3 cũng không còn và deadlock được minh họa là
tính chất A [] x>3 imply not Obs.taken.
Committed và Urgent Locations Có 3 kiểu trạng thái (locations) trong UPPAAL: kiểu bình
thường (normal) không có invariant, kiểu urgent và kiểu committed. Hình 2.3 minh họa 3 au-
tomat để so sánh sự khác nhau. Địa điểm có chữ u là urgent, có chữ c là committed. Đồng hồ là
riêng, x ở P0 khác P1.
Để so sánh giữa địa điểm bình thường và urgent ta quan tâm đến các tính chất sau:
- E <> P0.S1 and P0.x>0: có thể đợi ở S1 trong P0.
- A [] P1.S1 imply P1.x==0: không thể đợi ở S1 trong P1.
Trạng thái urgent tương đương với trạng thái mà sườn lên reset đồng hồ y và được gán nhãn
invariant y<=0. Ở trạng thái urgent, thời gian không trôi.
15
2.3. AUTOMAT ĐỊNH THỜI CHƯƠNG 2. TIMED-AUTOMATA TRONG UPPAAL
Hình 2.8: Ba automata song song minh họa các trạng thái normal, urgent và committed. Các
clocks là các biến local, tức là P0.x khác P1.x
Trạng thái committed còn chặt chẽ hơn: ở mọi trạng thái mà P2.S1 là tích cực, chuyển trạng

thái duy nhất xảy ra khi có xung lên từ P2.S1. Trạng thái có địa điểm committed tích cực gọi
là trạng thái tích cực: không cho phép trễ, và địa điểm committed phải giữ nguyên ở trạng thái
tiếp theo (hoặc 1 committed khác).
16
Chương 3
Tổng quan về Uppaal Toolkit
UPPAAL sử dụng kiến trúc máy trạm-máy chủ mà trong đó phân chia chương trình ra gồm 2
phần: giao diện đồ họa và hệ thống kiểm tra mô hình. Giao diện đồ họa, hay client, viết bằng
Java, và server được đóng gói tùy vào HĐH (Linux, Windows, Solaris). Do có kiến trúc như vậy
nên hai phần của CT sẽ kết nối với nhau qua giao thức TCP/IP. CŨng có phiên bản sử dụng
dòng lệnh.
3.1 Java Client
Ý tưởng của chương trình là mô hình hóa hệ thống automat thời gian sử dụng công cụ đồ họa,
mô phỏng và kiểm chứng sụ hoạt động của nó, và cuối cùng là kiểm tra xem nó có thỏa mãn
những tính chất cho trước hay không. GUI của Java client thực hiện ý tưởng này bằng cách
chia nó lám 3 phần: Khung soạn thảo (Editor), Mô phỏng (Simulator) và Kiểm chứng (Verifier)
được xếp vào các tab. Khung soạn thảo (KST) hệ thống được định nghĩa là 1 tập hợp các
automat thời gian được tiến hành song song gọi là quá trình trong CT. Quá trình được tạo ra từ
1 template định trước. KST chia làm 2 phần: cửa sổ dạng cây để chọn các template và khai báo
khác nhau và 1 bản vẽ. Địa điểm được dán tên. Invariant và edge dán điều kiện guard (e==id),
đồng bộ (go?) hay phép gán (x:=0).
Sơ đồ cây bên trái cho phép ta lựa chọn nhiều phần thông tin của hệ thống:
Global Declaration chứa biến toàn cục, đồng hồ, kênh đồng bộ và hằng, Templates Train,
Gate và IntQueue là các kiểu khác nhau của automat thời gian. Template co thể có khai báo
biến, kênh và hằng cục bộ. Process assignment từ template ta tạo ra các quá trình. Phần
gán quá trình chứa những khai báo cho nó. System definition danh sách những quá trình
trong hệ thống. Cú pháp của các nhãn và khai báo cos thể tìm thấy trong phần Help. Hình 3.1
đưa ra những khai báo cục bộ và toàn cục. Phần đồ họa lấy ý tưởng từ automat thời gian sử
dụng trong phần 2.
17

3.2. STAND-ALONE VERIFIER CHƯƠNG 3. TỔNG QUAN VỀ UPPAAL TOOLKIT
Hình 3.1: Demo The Train Gate(chương 4). Nút Select có thể chọn được. Ở chế đọ này người
dùng có thể di chuyển các địa điểm và edge hay sửa các nhãn. Chế độ còn lại dùng để thêm vào
các địa điểm, edge, nail (đỉnh của edge). Địa điểm mới thì mặc định không có tên. Có 2 chỗ
người dùng có thể đặt tên và tham số.
3.2 Stand-alone Verifier
Khi thực hiện những bài toán lớn, khó có thể làm hết được trong GUI. Khi đó ta có thể dùng
kiểm chứng riêng bằng dòng lênh bằng chương trình verifier. Nó cho phép ta thực hiện chức năng
tương tự như GUI bằng các dòng lênh. Cách này thích hợp cho những máy có cấu hình yếu và
phải chia sẻ bộ nhớ cho những ứng dụng khác.
18
CHƯƠNG 3. TỔNG QUAN VỀ UPPAAL TOOLKIT 3.2. STAND-ALONE VERIFIER
Hình 3.2: Các khai báo toàn cục và cục bộ trong demo The Train Gate
19
Chương 4
Ví dụ 1: The Train Gate
Mô phỏng(Simulation) có thể dùng bằng 3 cách: cho hệ thống chạy bằng tay và chọn chuyển
trạng thái mong muốn, chạy ngấu nhiên để hệ thống tự làm việc, hoặc chạy theo lộ trình tự chọn
để xem 1 trạng thái có thể tiến đến được không. Nó được chia làm 4 phần:
Control Part dùng để chọn chuyển trạng thái, theo lộ trình hay mô phỏng ngẫu nhiên.
Variable View cho biết giá trị các biến và giới hạn đồng hồ. UPPAAL không thể hiện trạng
thái gián đoạn với giá trị thực của đồng hồ vì có vô số trạng thía như vậy. Thay vào đó, nó cho
biết 1 tập các trạng thái chia sẻ chung 1 địa điểm gọi là symbolic state. Nó có chung cả giá trị
những biến gián đoạn. Giá trị có thể của đồng hồ thể hiện bằng những giới hạn.
System View cho biết những automat và địa điểm tích cực ở trạng thái nhất định.
Message Sequence Chart cho biết đồng bộ giữa những quá trình và địa điểm tích cực ở mỗi
bước.
Kiểm chứng Danh sách Overview cho phép ta chọ những tính chất, người dùng có thể chọn
nhiều cái 1 lúc, thêm bớt và xem giải thích của từng tính chất trong danh sách. Khi 1 tính chất
được chọn, ta có thể thay đổi định nghĩa của nó hoặc thêm những bình luận riêng của mình.

Cửa sổ Status ở dưới cùng cho biết giao tiếp với máy chủ.
Khi ta chọn 1 lộ trình mình muốn và phần kiểm tra mô hình tìm được lộ trình đó, người dùng
sẽ được hỏi có muốn đưa nó vào mô phỏng không?. Những tính chất đạt được sẽ có màu xanh,
không được có màu đỏ. Nhiều trường hợp không thể kết luận được thì sẽ có màu vàng.
4.1 Nội dung bài toán
Ví dụ The Train Gate (Ga tàu điện) là một demo được phân phối cùng phần mềm Uppaal.
Demo này mô hình hóa một hệ thống điều khiển đường ray. Hệ thống này điều khiển việc sử
dụng một cây cầu chung đồng lúc cho nhiều tàu. Chiếc cầu chỉ được sử dụng bởi một chiếu tàu
20
CHƯƠNG 4. VÍ DỤ 1: THE TRAIN GATE 4.2. MÔ HÌNH HÓA TRÊN UPPAAL
tại một thời điểm. Hệ thống gồm một số lượng tàu (trong demo này là 4) và một bộ điều khiển.
Khi một tàu dừng lại hoặc khi tàu khởi động lại đều mất một khoảng thời gian. Bởi vậy, có
những điều kiện ràng buộc về thời gian với các tàu trước khi được sử dụng cầu. Khi tiến tới tàu,
mỗi tàu gửi một tín hiệu appr!. Ngay sau đó, nó có 10 đơn vị thời gian để có thể nhận một tín
Hình 4.1: Hình 12. View of the verification tab for the train gate example.
hiệu stop. Tín hiệu stop này giúp tàu có thể dừng an toàn ở phía trước cầu. Sau 10 đơn vị thời
gian, nếu không nhận được tín hiệu stop, tàu có 10 đơn vị thời gian nữa để qua cầu. Nếu một
chiếc tàu phải dừng lại để chờ, nó sẽ được khởi động lại khi bộ điều khiển gửi một tín hiệu go!.
Tín hiệu go! được gửi khi chiếc tàu sử dụng cầu đã đi qua cầu và gửi về bộ điều khiển một tín
hiệu leave!. Hình 4.1 và Hình 4.2 chỉ ra hai trường hợp này.
4.2 Mô hình hóa trên Uppaal
Mô hình ga tàu điện có 3 khuôn mẫu:
Train là mô hình của một chiếc tàu, được thể hiện ở Hình 3.1.
Gate là mô hình của bộ điều khiển hoạt động của nhà ga, được thể hiện trên Hình 4.2
21
4.2. MÔ HÌNH HÓA TRÊN UPPAAL CHƯƠNG 4. VÍ DỤ 1: THE TRAIN GATE
Hình 4.2: Ví dụ Train Gate: Train4 sắp qua cầu, Train3 phải dừng lại, Train2 nhận lệnh dừng và
đang dừng lại. Train1 đang tiến đến cầu và gửi một tín hiệu appr! tới controller, sau đó controller
gửi lại một lệnh stop!. Các khoảng thời gian giữa các sự kiện lần lượt là (10, 10, 3 5).
IntQueue là mô hình của hàng đợi trong bộ điều khiển, được cho ở Hình 4.2. Nó được tách

riêng khỏi mô hình bộ điều khiển để giảm độ phức tạp cho mô hình bộ điều khiển.
Khuôn mẫu của đối tượng Train Khuôn mẫu này được trình bày trong Hình 3.1, gồm năm
trạng thái: Safe, Appr, Stop, Start, và Cross. Trạng thái ban đầu là Safe, ứng với khi tàu
chưa đi tới cây cầu chung. Trạng thái này không ứng với một sự kiện nào, điều đó có nghĩa là
chiếc tàu có thể ở trạng thái này trong một khoảng thời gian vô hạn. Khi một chiếc tàu đi tới
cầu, nó thông báo với bộ điều khiển thông. Việc này được thực hiện nhờ sự kiện appr! khi tàu
chuyển từ trạng thái Safe sang trạng thái Appr. Bộ điều khiển có tương ứng sự kiện appr?.
Đồng hồ x được reset và tham biến e được đặt để nhận diện tàu. Biến này được sử dụng bởi
hàng đơi queue và bộ điều khiển controller để biết chiếc tàu nào được phép tiếp tục đi hoặc phải
dừng lại chờ để khởi động lại sau. Trạng thái Appr có điều kiện x ≤ 20, điều kiện ấy đảm bảo
rằng tàu sẽ không ở trạng thái này quá 20 đơn vị thời gian. Hai sự kiện chuyển trạng thái được
đảm bảo bởi hai ràng buộc x ≤ 10 và x ≥ 10, tương ứng với hai khả năng: có thể dừng hoặc
không thể dừng lại. Nếu x = 10, cả hai sự kiện đều xảy ra, điều này cho phép chúng ta kiểm tra
liệu trường hợp xung đột có thể xảy ra không. Nếu chiếc tàu có thể dừng lại (x ≤ 10) thì tàu
chuyển đến trạng thái Stop, ngược lại tàu sẽ chuyển đến trạng thái Cross. Sự kiện chuyển tới
Stop được kiểm tra đồng thời thêm điều kiên e == id và stop?. Khi bộ điều khiển quyết định
dừng một tàu, nó quyết định dừng tàu nào (bằng cách gán biến e tương ứng) và cùng lúc gửi
một tín hiệu điều khiển stop!.
22
CHƯƠNG 4. VÍ DỤ 1: THE TRAIN GATE 4.2. MÔ HÌNH HÓA TRÊN UPPAAL
Hình 4.3: Lúc này train4 đã đi qua cầu và gửi về tín hiệu leave!. Bộ điều khiển lúc này cho phép
train3 sử dụng cầu với lệnh go!. Train2 lúc này đang đợi lệnh để khởi động lại và train1 lúc này
đang dừng lại.
Trạng thái Stop: mỗi tàu có thể dừng trong một khoảng thời gian vô hạn trước khi nhận được
một tín hiệu go?. Điều kiện e == id chắc chắn rằng lệnh được gửi đến đúng tàu. Mô hình này
đã được đơn giản hóa so với phiên bản trong [60], với việc giai đoạn giảm tốc độ không được mô
phỏng. Chúng ta có thể coi rằng một tàu có thể nhận được một sự kiện go? khi nó chưa dừng
hẳn, và điều đó có thể dẫn tới việc không thể xác định được thời điểm khởi động lại.
Trạng thái Start có biến x ≤ 15 và và sự kiện để đi khỏi trạng thái đó có ràng buộc x ≥ 7.
23

4.3. KIỂM CHỨNG (VERIFICATION) CHƯƠNG 4. VÍ DỤ 1: THE TRAIN GATE
Hình 4.4: Automat của bộ điều khiển ga tàu điện.
Điều này có nghĩa rằng tàu được khởi động lại và tới chỗ vượt cầu vào một thời điểm bắt kì
nằm giữa 7 và 15 đơn vị thời gian.
Tương tự trạng thái Start, kể từ khi tàu tới, trạng thái Cross cũng ràng buộc tàu phải chuyển
sang trạng thái khác giữa 3 và 5 đơn vị thời gian.
4.3 Kiểm chứng (Verification)
Chúng ta kiểm tra khả năng hoạt động của Automata qua mọi trạng thái, tính an toàn, khả
năng bị rơi vào trạng thái deadlock, và các tính chất khác. Để kiểm tra khả năng hoạt động qua
mọi trạng thái ta kiểm tra liệu hệ có tới được những trạng thái nhất định hay không:
- E<> Gate.Occ: liệu nhà ga có thể nhận và lưu id của các tàu đang đi tới cầu hay không.
- E<> Train1.Cross: kiểm tra xem train1 có thể qua cầu hay không. Chúng ta có thể kiểm tra
tính chất này tương tự với các tàu khác.
- E<> Train1.Cross and Train2.Stop: train1 có vượt cầu khi train2 đang dừng hay không?
Tương tự kiểm tra với các tàu khác.
- E<> Train1.Cross && Train2.Stop && Train3.Stop && Train4.Stop: tương tự như câu
truy vấn trên, kiểm tra liệu chỉ có train1 vượt cầu khi các tàu khác đợi không?
Các tính chất an toàn sau phải thỏa mãn:
24
CHƯƠNG 4. VÍ DỤ 1: THE TRAIN GATE 4.3. KIỂM CHỨNG (VERIFICATION)
Hình 4.5: Automat của hàng đợi trong bộ điều khiển.
- textttA[] Train1.Cross+Train2.Cross+Train3.Cross+Train4.Cross<=1: Không có lúc nào có
nhiều hơn một tàu qua cầu. Biểu thức này dựa vào việc Train1.Cross nhận giá trị True và False
tương ứng là 1 và 0.
– A[] Queue.list[N-1] == 0: Không bao giờ có N tàu trong hàng đợi, tức là mảng sẽ không
bao giờ bị tràn. Thực ra, để kiểm tra, mô hình sẽ định nghĩa N là một số hữu hạn tàu + 1 để
kiểm tra tính chất này. Có thể dùng một hàng đợi có kích thức bằng số tàu và kiểm tra tính chất
này như sau: A[] (Gate.add1 or Gate.add2) imply Queue.len < N-1 với trạng thái add1 và
add2 là các trạng thái duy nhất trong mô hình mà từ đó sự kiện add! có thể xảy ra.
Tính liveness của hệ được kiểm chứng với biểu thức: Train1.Appr –> Train1.Cross: mỗi khi

một tàu đi tới cầu, nó chắc chắn phải qua được cầu.Cuối cùng, để kiểm tra Automat có bị rơi
vào trạng thái deadlock hay không, ta kiểm tra bằng biểu thức: A[] not deadlock.
Giả sử ta mắc một lỗi khi tạo hàng đợi, ví dụ như viết e:=list[1] (trong khuôn mẫu IntQueue)
thay vì viết e:=list[0] ứng với sự kiện hd?. Chúng ta sẽ cho rằng hệ sẽ bị mất hết các tính chất
trên do việc đánh số thứ tự sai. Tuy nhiên, mọi tính chất vẫn được giữ nguyên, chỉ ngoại trừ
tính liveness. Việc kiểm chứng cho một phản ví dụ đó là trường hợp có một tàu đi qua cầu còn
những tàu còn lại phải dừng lại. Khi tàu đã vượt xong, hàng đợi được dịch và tàu đầu hàng đợi
bắt đầu khởi động để qua cầu. Tàu được khởi động này sẽ không bao giờ là tàu đầu tiên (đánh
số 0) mà là tàu đánh số 1, bởi vậy tàu ở đầu hàng đợi (đánh số 0) không bao giờ được khởi động
lại nên sẽ không bao giờ được qua cầu.
25