Nghiên cứu và đánh giá hệ thống điều khiển thời gian thực RTOS

Sau khi đánh giá các hệ điều hành, Tác giả tiến hành lựa chọn, xây dựng các bước thực hiện một hệ thống thời gian thực RTAI và ứng dụng hệ thống thời gian thực trên nền tảng PC vào mô ph

TÓM TẮT LUẬN VĂN THẠC SĨ

Đề tài: Nghiên cứu và đánh giá hệ thống điều khiển thời gian thực RTOS

Tác giả luận văn: Nguyễn Xuân Thái Khóa: CHĐKTĐH2009 Người hướng dẫn: Ts Nguyễn Hồng Quang

Nội dung tóm tắt:

Lý do chọn đề tài:

Dưới sự phát triển khoa học kỹ thuật các linh kiện khả trình ngày càng mạnh: giá thành rẻ, tốc độ đáp ứng nhanh, bộ nhớ lớn, tích hợp nhiều chức năng Do đó chúng được tích hợp trong rất nhiều hệ thống điều khiển Để thuận lợi cho việc phát triển, đảm bảo tính ổn định, dễ bảo trì, nâng cấp chương trình trong các chíp khả trình của các hệ thống điều kiển, hệ điều hành đã ra đời Các hệ điều hành này sẽ quản lý các tài nguyên hệ thống điều khiển phục vụ cho việc phát triển chương trình Ngoài ra,

vì các hệ thống điều khiển có yêu cầu về việc đáp ứng thời gian thực là rất quan trọng nên các hệ điều hành này phải là các hệ điều hành thời gian thực Nên tác giả lựa chọn

đề tài “Nghiên cứu và đánh giá hệ thống điều khiển thời gian thực RTOS” đặc biệt là

hệ điều hành thời gian thực mã nguồn mở để có thể giúp quá trình phát triển chương trình điều khiển nhanh và hiệu quả hơn trong các hệ thống điều khiển

Mục đích nghiên cứu của luận văn, đối tượng, phạm vi nghiên cứu:

Mục đích nghiên cứu của luận văn là tìm hiểu các đặc điểm của hệ điều hành thời gian thực, đưa ra các đặc điểm để có thể đánh giá được các hệ điều hành này

Đối tượng nghiên cứu là hệ điều hành thời gian thực

Phạm vi nghiên cứu là nghiên cứu và đánh giá một số hệ điều hành thời gian thực mã nguồn mở dựa trên nền tảng Linux Ngoài ra, Luận văn có tiến hành thực hiện ứng dụng hệ điều hành thời gian thực vào mô phỏng hệ thống điều khiển động cơ điện một chiều trên hệ thống thời gian thực

Tóm tắt cô đọng các nội dung chính và đóng góp mới của tác giả

Luận văn giới thiệu về các khái niệm thời gian thực, hệ điều hành thời gian thực

và tìm hiểu các đặc điểm và yêu cầu của một của hệ điều hành thời gian thực Tiếp theo, luận văn nghiên cứu nguyên lý và đặc điểm của một số hệ điều hành thời gian thực Sau đó dựa trên các đặt điểm của hệ điều hành thời gian thực, Luận văn tiến hành

đánh giá một số hệ điều hành thời gian thực (Xenomai và RTAI) Sau khi đánh giá các hệ điều hành, Tác giả tiến hành lựa chọn, xây dựng các bước thực hiện một hệ thống thời gian thực RTAI và ứng dụng hệ thống thời gian thực trên nền tảng PC vào

mô phỏng điều khiển động cơ điện một chiều Qua quá trình thực hiện luận văn, Tác giả đã đưa ra được các đặc điểm để đánh giá hệ điều hành thời gian thực, thực hiện được hệ thống thời gian thực và ứng dụng hệ điều hành thời gian thực này vào mô phỏng điều khiển động cơ điện một chiều

Phương pháp nghiên cứu

Luận văn sử dụng phương pháp nghiên cứu lý thuyết: từ những yêu cầu của hệ thống điều khiển để đưa ra các đặc điểm để đánh giá hệ điều hành thời gian thực được

sử dụng trong hệ thống điều khiển và phương pháp thực nghiệm: xây dựng hệ điều hành thời gian thực điều khiển động cơ điện một chiều, đánh giá khả năng của hệ điều khiển trong quá trình thiết kế mạch điều khiểm động cơ điện một chiều

Kết luận

Luận văn đã thực hiện được các công việc sau: đưa ra được những yêu cầu, đặc điểm để đánh khả năng đáp ứng thời gian thực của một hệ điều hành thời gian thực; tiến hành đo đạc đánh giá hệ điều hành thời gian thực: RTAI và Xenomai; lựa chọn, xây dựng và ứng dụng hệ điều hành thời gian thực RTAI vào điều khiển động cơ điện một chiều; cho thấy tính linh hoạt của hệ thống thời gian thực RTAI trong việc thiết

kế, kiểm nghiệm hệ thống điều khiển (hệ thống điều khiển được thực hiện bởi các khối trong simulink/Matlab) qua ví dụ mô phỏng điều khiển động cơ điện một chiều Hy vọng những thành quả này của luận văn sẽ được ứng dụng vào thực tế giúp cho công việc thiết kế, nghiên cứu và đánh giá các hệ thống điều khiển được nhanh và thuận lợi hơn

Lời cam đoan

Tôi xin cam đoan đây là luận văn do tôi thực hiện, không sao chép, sửa chữa từ nội dung của luận văn khác

Hà Nội, ngày… tháng … Năm ……

Học viên Nguyễn Xuân Thái

Mục lục

Danh mục các ký hiệu và viết tắt 6

Danh mục các bảng biểu 7

Danh mục các đồ thị, hình vẽ 9

Lời mở đầu 12

CHƯƠNG 1: GIỚI THIỆU VỀ HỆ THỐNG THỜI GIAN THỰC 14

1.1 Hệ thống thời gian thực 14

1.2 Hệ điều hành thời gian thực (Real Time Operating System - RTOS) 14

1.3 Các thông số dùng để đánh giá, phân tích hệ điều hành thời gian thực 15

1.4 Các yêu cầu của hệ điều hành thời gian thực 15

1.5 Lựa chọn nền tảng phát triển 16

CHƯƠNG 2: CÁC HỆ ĐIỀU HÀNH THỜI GIAN THỰC 18

2.1 Xenomai 18

2.1.1 Nguyên lý 18

2.1.2 API (Application programming interface – giao diện lập trình ứng dụng) 19

2.1.3 Các đặc điểm 22

2.1.3.1 Hỗ trợ nhiều luồng 22

2.1.3.2 Hỗ trợ các kiểu đồng bộ cơ bản 22

2.1.3.3 Quản lý bộ thời gian và xung nhịp 22

2.1.3.4 Bộ nhớ chỉ định cở bản 22

2.1.3.5 Các nền tảng hỗ trợ 22

2.2 RTAI – Realtime Application Interface 23

2.2.1 Nguyên lý 23

2.2.2 Adeos 25

2.2.3 Lập lịch trình 27

2.2.4 API 28

CHƯƠNG 3: ĐÁNH GIÁ SO SÁNH CÁC HỆ ĐIỀU HÀNH THỜI GIAN THỰC 30

3.1 Hệ thống kiểm tra 30

3.2 Đánh giá, so sánh trễ ngắt sử dụng kết nối cổng song song lặp vòng 30

3.3 Trễ lập lịch trình 36

3.4 Thời gian chuyển khóa ngữ cảnh 41

3.5 Đánh giá kết quả 44

CHƯƠNG 4: THỰC HIỆN HỆ THỐNG THỜI GIAN THỰC 45

4.1 Cấu trúc hệ thống thời gian thực 45

4.1.1 Phần cứng 45

4.1.2 Hệ điều hành 45

4.1.3 Các phầm mềm được sử dụng 45

4.2 Các bước tiến hành cài đặt hệ điều hành thời gian thực RTAI 46

4.2.1 Chuẩn bị các gói phần mềm cần thiết phục vụ cài dặt các phần mềm 46

4.2.1.1 Các gói phục vụ chung cho tất cả phần mềm 46

4.2.1.2 Các gói phục vụ cho cài đặt nhân 46

4.2.1.3 Các gói phục vụ cho cài đặt rtai 46

4.2.1.4 Các gói phục vụ cho cài đặt comedi-lib 46

4.2.1.5 Các gói phục vụ cho cài đặt comedi-calibrate 46

4.2.1.6 Các gói phục vụ cho cài đặt qrtailab 47

4.2.2 Chuẩn bị các bộ cài cho hệ thống thời gian thực 47

4.2.2.1 Bộ cài Nhân 47

4.2.2.2 Bộ cài RTAI 47

4.2.2.3 Bộ cài COMEDI 47

4.2.2.4 Bộ cài QRTAILab 48

4.2.3 Thực hiện cài đặt các phần mềm 48

4.2.3.1 Thực hiện cài đặt phiên bản quản lý hệ điều hành GRUB 0.97 48

4.2.3.2 Thực hiện cài đặt bản vá nhân hỗ trợ thời gian thực 49

4.2.3.3 Cài đặt các module hỗ trợ lập trình thời gian thực RTAI 51

4.2.3.4 Cài đặt trình điều khiển thiết bị cho các thiết bị mở rộng COMEDI52

4.2.3.5 Cài đặt các module hỗ trợ thời gian thực RTAI, cập nhập hỗ trợ thêm

module truy nhập dữ liệu COMEDI 53

4.2.3.6 Cài đặt công cụ giám sát các thông số của hệ thống QRTAILAB 56

4.2.3.7 Cài đặt môi trường phát triển ứng dụng thời gian thực Matlab 57

CHƯƠNG 5: ỨNG DỤNG HỆ ĐIỀU HÀNH THỜI GIAN THỰC TRONG ĐIỀU KHIỂN ĐỘNG CƠ MỘT CHIỀU 60

5.1 Giới thiệu động cơ một chiều 60

5.1.1 Nguyên lý làm việc 60

5.1.2 Mô hình hóa động cơ 61

5.1.3 Đặc điểm làm việc động cơ một chiều khi thay đổi điện áp phần ứng 62

5.2 Giới thiệu mô hình điều khiển tốc độ động cơ điện một chiều 63

5.2.1 Sơ đồ khối điều khiển đốc độ động cơ điện một chiều 63

5.2.2 Sơ đồ cấu trúc điều khiển tốc độ động cơ điện một chiều 64

5.2.3 Hàm truyền và mô hình ảnh laplace của các phần tử trong hệ thống 66

5.2.3.1 Động cơ điện một chiều 66

5.2.3.2 Khối chỉnh lưu cầu ba pha dùng thyristor 67

5.2.3.3 Khâu phản hồi tốc độ 69

5.2.3.4 Khâu phản hồi dòng điện 70

5.2.3.5 Khâu điều chỉnh dòng điện 70

5.2.3.6 Khâu điều chỉnh tốc độ 71

5.3 Tính toán thiết kế hệ thống điều khiển tốc độ 71

5.3.1 Tính toán các thông số cho động cơ điện một chiều tại bộ môn tự động hóa 71

5.3.1.1 Thực hiện tính toán 71

5.3.1.2 Tính toán hàm truyền cho mô hình mô phỏng 72

5.3.2 Tính toán các thông số của bộ chuyển đổi điện áp 73

5.3.2.1 Lựa chọn linh kiện cho bộ biến đổi điện áp 73

5.3.2.2 Hàm truyền của khâu chỉnh l ưu ba pha dùng thyristor 74

5.3.3 Tính toán các thông số của các khối phản hồi 74

5.3.3.1 Khối phản hồi tốc độ 74

5.3.3.2 Khâu phản hồi dòng điện 75

5.4 Tính toán các khối điều chỉnh dòng điện và tốc độ 75

5.4.1 Tính tóa mô hình khâu điều chỉnh dòng điện 75

5.4.2 Tính tóa mô hình khâu điều chỉnh tốc độ 77

5.4.3 Thực hiện các khâu giới hạn vật lý của hệ thống mô phỏng 80

5.5 Mô hình mô phỏng và kết quả mô phỏng 82

5.5.1 Mô hình mô phỏng hệ thống 82

5.5.2 Các tín hiệu đặt để đánh giá hệ thống 83

5.5.3 Đáp ứng của hệ thống với tín hiệu đặt và tải 84

5.6 Mô phỏng với các phân tử chuẩn trong matlab 86

5.6.1 Mô hình hệ thống sử dụng các phần tử chuẩn của Matlab 87

5.6.2 Kết quả mô phỏng 87

5.7 Rời rạc hóa mô hình 89

5.7.1 Mô hình hệ thống sử dụng các phần tử rời rạc 90

5.7.2 Kết quả mô phỏng 90

5.8 Mô phỏng thời gian thực 92

5.8.1 Mô phỏng hệ thồng điều khiển động cơ điện một chiều trên hệ thống thời gian thực 92

5.8.1.1 Sơ đồ mạch điện của toàn bộ hệ thống được sủ dụng mô phỏng 92

5.8.1.2 Thực hiện biên dịch sang chương trình thực thi 93

5.8.1.3 Kết quả mô phỏng của hệ thống 95

5.8.2 Mô phỏng mạch mạch lực và mạch điều khiển của hệ thống trên hai hệ điều hành thời gian thực 97

5.8.2.1 Sơ đồ mạch điện khi hệ thống được tách 97

5.8.2 Kết quả thực hiện chương trình 98

CHƯƠNG 6: ĐÁNH GIÁ KẾT QUẢ VÀ THẢO LUẬN 101

Danh mục các ký hiệu và viết tắt

RTOS Real Time Operating System Hệ điều hành thời gian thực

ISA International Society for

Measurement and Control

Hiệp hội đo lường và điều khiển quốc tế

POSIX Portable Operating System

Interface

Giao tiếp hệ điều hành khả chuyển

GPCPU General purpose central processing

unit

Đơn vị xử lý trung tâm đa dụng

LGPL GNU Lesser General Public

License

Giấy phép công cộng hạn chế

HAL Hardware Abstraction Layer Lớp trừu tượng phần cứng

API Application programming interface Giao tiếp của các chương trình ứng

dụng RTDM Realtime Device Driver Model Mô hình trình điều khiển thiết bị

thời gian thực

Adeos Adaptive Domain Environment for

Operating Systems

Môi trường hoạt động thích nghi cho các hệ điều hành

Danh mục các bảng biểu

Bảng 4.1: Cài đặt các gói phần mềm phục vụ cài đặt chung cho hệ thống 46

Bảng 4.2: Các gói phần mềm phục vụ cài đặt cho nhân hệ thống 46

Bảng 4.3: Các gói phần mềm phục vụ cài đặt cho bản vá thời gian thực RTAI 46

Bảng 4.4: Các gói phần mềm phục vụ cài đặt thư viện trình điều khiển Comedi 46

Bảng 4.5: Các gói phần mềm phục vụ cài đặt kiểm thử trình điều khiển Comedi 46

Bảng 4.6: Các gói phần mềm phục vụ cài đặt phần mềm giám sát quá trình QRTAILAB 47

Bảng 4.7: Các lệnh cài đặt nhân hệ thống 47

Bảng 4.8: Các lệnh cài đặt phần mềm thời gian thực 47

Bảng 4.9: Các lệnh cài đặt trình điều khiển thiết bị Comedi 47

Bảng 4.10: Các lệnh cài đặt phần mềm giám sát quá trình QRTAILAB 48

Bảng 4.11: Các lệnh thực hiện lưu lại cấu hình phiên bản Grub 2 48

Bảng 4.12: Các lệnh thực hiện gỡ bỏ gói phần mềm Grub 2 48

Bảng 4.13: Các lệnh thực hiện cài đặt gói phần mền grub legacy (GRUB 0.97) 49

Bảng 4.14: Các lệnh thực hiện tạo file cấu hình khởi động cho hệ thống 49

Bảng 4.15: Các lệnh thực hiện sửa đổi mã nguồn của nhân 49

Bảng 4.16: Các lệnh thực hiện tạo file cấu hình biên dịch nhân 49

Bảng 4.17: Các lệnh thực hiện biên dịch nhân 51

Bảng 4.18: Các lệnh thực hiện vài đặt nhân 51

Bảng 4.19: Các lệnh thực hiện cài đặt bản vá thời gian thực RTAI 51

Bảng 4.20: Các lệnh thực hiện cài đặt trình điều khiển thiết bị truy nhập dữ liệu 52

Bảng 4.21: Các lệnh thực hiện cài đặt các thư việc hỗ trợ lập trình để khai thác thiết bị truy nhập dữ liệu (thư việc COMEDILIB) 52

Bảng 4.22: Các lệnh thực hiện cài đặt các công cụ căn chỉnh, kiểm định thiết bị truy nhập dữ liệu(COMEDI-CALIBRATE) 52

Bảng 4.23: Thêm các thư viện của trình điều khiển truy nhập dữ liệu mở rộng vào bản vá thời gian thực RTAI 53

Bảng 4.24: Thực hiện biên dịch và cài lại các module RTAI đã tích hợp trình điều

khiển Comedi 54

Bảng 4.25: Tải các module RTAI vào nhân 54

Bảng 4.26: Cài đặt phần mềm giám sát quá trình Qrtailab 56

Bảng 4.27: Tạo đường dẫn cho phép truy nhập vào file matu2k8b.iso 57

Bảng 4.28: Cài đặt matlab 57

Bảng 4.29: Tải mã nguồn của bản vá RTAI vào thư viện toolbox của matlab 58

Bảng 5.1: Các thông số động cơ điện một chiều 71

Danh mục các đồ thị, hình vẽ

Hình 2.1: Cấu trúc của Xenomai 18

Hình 2.2: Lá chắn ngắt trong đường ống pipe ngắt 21

Hình 2.3: sự di chuyển giữa chế độ nguyên thủy và thứ hai 21

Hình 2.4: Kiến trúc của RTAI 24

Hình 2.5: Tính kết thừa RTHAL trong RTAI 25

Hình 2.6: Adeos I-PIPE 26

Hình 3.1: Kết nối cổng song song lặp vòng 31

Hình 3.2: Linux chuẩn không có giành quyền ưu tiên nguyên thủy 32

Hình 3.3: Linux chuẩn với giành quyền ưu tiên nguyên thủy 33

Hình 3.4: Linux chuẩn với bản vá giành quyền ưu tiên thời gian thực 33

Hình 3.5: Xenomai không có giành uyền ưu tiên nguyên thủy 34

Hình 3.6: Xenomai với giành quyền ưu tiên nguyên thủy 34

Hình 3.7: RTAI không có giành quyền ưu tiên nguyên thủy 35

Hình 3.8: RTAI với giành quyền ưu tiên nguyên thủy 35

Hình 3.9: Linux chuẩn không có giành quyền ưu tiên (“SCHED_OTHER”) 36

Hình 3.10: Linux chuẩn không có giành quyền ưu tiên (“SCHED_FIFO”) 37

Hình 3.11: Linux với bản vá giành quyền ưu tiên thời gian thực SCHED_OTHER38 Hình 3.12: Linux với bản vá giành quyền ưu tiên thời gian thực SCHED_FIFO 38

Hình 3.13: Xenomai nhiệm vụ không gian người dùng 39

Hình 3.14: Xenomai Nhiệm vụ không gian nhân 39

Hình 3.15: Xenomai bộ thời gian IRQ 40

Hình 3.16: RTAI nhiệm vụ không gian người dùng 40

Hình 3.17: RTAI nhiệm vụ không gian nhân 41

Hình 3.18: Thời gian chuyển khóa ngữ cảnh Xenomai (không giành ưu tiên) 42

Hình 3.19: Thời gian chuyển khóa Xenomai (với giành quyền ưu tiên) 43

Hình 3.20: Thời gian chuyển khóa ngữ cảnh RTAI (không có giành quyền ưu tiên) 43

Hình 3.21: Thời gian chuyển khóa ngữ cảnh RTAI (có giành quyền ưu tiên) 44

Hình 4.1: Giao diện cấu hình biên dịch nhân 50

Hình 4.2: Giao diện cấu hình biên dịch các module RTAI 54

Hình 4.3: Kết quả kiểm tra các module RTAI được nạp bằng lệnh dmesg 56

Hình 4.4: Giao diện của phần mềm giám sát QRTAILAB 57

Hình 4.5: Giao diện cài đặt phần mềm matlab 58

Hình 4.6: Các module RTAI được hỗ trợ trong Matlab 59

Hình 5.1: Mô hình động cơ điện một chiều 61

Hình 5.2: Mô hình điều khiển tốc độ động cơ một chiều sử dụng thyristor 62

Hình 5.3: Đặc tính cơ động cơ một chiều kích từ độc lập 62

Hình 5.4: Sơ đồ khối hệ thống điều khiển tốc độ động cơ điện một chiều 64

Hình 5.5: Sơ đồ cấu trúc hệ thống điều chỉnh tốc độ động cơ điện một chiều 65

Hình 5.6: Mô hình động cơ điện một chiều 66

Hình 5.7: Mô hình tuyết tính hóa động cơ điện một chiều 67

Hình 5.8: Sơ đồ mạch cầu chỉnh lưu ba pha dùng thyristor 67

Hình 5.9: Hoạt động của bộ chỉnh lưu ba pha 68

Hình 5.10: Mô hình dạng cấu trúc mô phỏng 72

Hình 5.11: Đáp ứng của mô hinh động cơ một chiều với nguồn một chiều 220V 73

Hình 5.13: Mô hình vòng điều chỉnh dòng điện 75

Hình 5.14: Mô hình điều chỉnh dòng i 76 ' a Hình 5.15: Mô hình khâu điều chỉnh dòng điện 76

Hình 5.16: Mô hình mạch điều khiển tốc độ 77

Hình 5.17: Mô hình của động cơ 82

Hình 5.18: Tốc độ đặt để điều khiển động cơ 83

Hình 5.19: Đường đặt tính của tải 84

Hình 5.20: Tốc độ động cơ 84

Hình 5.21: Đáp ứng của động cơ tại thời điểm thay đổi của tải từ 0 lên 30Nm tại 4s 85

Hình 5.22: Đáp ứng của động cơ tại thời điểm thay đổi của tải từ 30 lên 46Nm tại

7s 85

Hình 5.23: Dòng điện của động cơ 86

Hình 5.24: Mô hình mô phỏng sử dụng các phần tử chuẩn trong matlab 87

Hình 5.25: Tốc độ động cơ mô hình liên tục 88

Hình 5.26: Dòng điện phần ứng động cơ của mô hình liên tục 88

Hình 5.27: Mô hình mô phỏng sử dụng các phần tử rời rạc 90

Hình 5.28: Tốc độ của động cơ của mô hình rời rạc 91

Hình 5.29: Dòng điện của động cơ của mô hình rời rạc 91

Hình 5.30: Sơ đồ hệ thống được sử dụng mô phỏng trên hệ điều hành thời gian thực 93

Hình 5.31: Bảng điều khiển 94

Hình 5.32: Bảng cài đặt môi trường thực hiện biên dịch 95

Hình 5.33: Tốc độ động cơ trong mô phỏng thời gian thực 96

Hình 5.34: Dòng điện phần ứng động cơ trong mô phỏng thời gian thực 97

Hình 5.35: Mạch điều khiển 97

Hình 5.36: Mạch Lực 98

Hình 5.37: Tốc độ động cơ trong mô phỏng thời gian thực thực hệ kết nối hai hệ thống 99

Hình 5.38: Dòng điện động cơ trong mô phỏng thời gian thực thực hệ kết nối hai hệ thống 100

Lời mở đầu

Khoa học kỹ thuật phát triển mạnh, các linh kiện số ngày càng hoàn thiện, các nhược điểm của hệ thống số được khắc phục (như tốc độ nhanh hơn, độ phân giải số cao hơn…), nên các linh kiện số được ứng dụng rất rộng dãi trong các hệ thống điều khiển Giá thành linh kiện số rẻ hơn trước, việc thiết kế mạch điều khiển logic dần được thay thế bằng các phần tử có thể lập trình (cho giá thành rẻ hơn, linh hoạt, mềm dẻo, bảo trì nâng cấp dễ hơn trong các bài toán điều khiển) Các phần tử này sử dụng các lệnh để thực hiện điều khiển thực hiện các chứng năng của hệ thống Trong đó các chíp có khả năng lập trình được là trung tâm của hệ thống, các chíp này sẽ chứa các chương trình điều khiển Các chương trình điều khiển này có thể được phát triển từ đầu bao gồm toàn bộ công việc như quả lý bộ nhớ, vào ra, thời gian …, như vậy sẽ làm mất rất nhiều thời gian phát triển, kiểm nghiệm tính ổn định của từng mô-đun chương trình Để khắc phục nhược điểm này các hệ điều hành ra đời, các hệ điều hành này sẽ thực hiện công việc quản lý tài nguyên (bộ nhớ, ngắt, vào ra, thời gian …) và các chương trình sẽ gọi các mô-đun này (các mô-đun này đã được nhà phân phối hệ điều hành kiểm nghiệm nên tính ổn định cao ) để thực hiện công việc Như vậy việc nghiên cứu hệ điều hành để áp dụng vào bài toán điều khiển là rất cần (giảm thời gian phát triển, chi phí kiểm nghiệm …) Ngoài ra trong bài toán điều khiển cần đảm bảo tính thời gian thực của hệ điều hành, do đó luận văn này sẽ nghiên cứu đánh giá hệ điều hành thời gian thực cho các hệ thống điều khiển

Luận văn tiến hành đánh giá các hệ điều hành thời gian thực (hệ điều hành thời gian thực RTAI và xenomai) , dựa trên ba đặc điểm quan trọng của hệ điều hành thời gian thực: Trễ, dao động, và thời gian chuyển ngữ cảnh Từ đánh giá đó tiến hành lựa chọn hệ điều hành thời gian thực và ứng dụng vào bài toán điều khiển động điện cơ một chiều

Luận văn thực hiện theo phương pháp thực nghiệm: tìm hiểu các đặt điểm quan trọng để có thể đánh giá được tính thời gian thực của hệ điều hành thời gian

thực Xây dựng hệ thống thời gian thực sử dụng hệ điều hành thời gian thực RTAI trên nền tảng PC (nền tảng x86) sử dụng hệ điều hành Ubuntu phục vụ mục đích thử nghiệm, ứng dụng vào các bài toán điều khiển Tìm hiểu sử dụng phần mềm MATLAB để biên dịch các mô đun khối simulink thành các ứng dụng có thể thực thi thời gian thực Thử nghiệm hệ thống với mô hình động cơ điện một chiều

Kết cầu của luận văn gồm 6 chương:

Chương 1: Tìm hiểu các khái niệm về hệ thống thời gian thực, hệ điều hành thời gian thực, và các yêu cầu của một hệ điều hành thời gian thực,

Chương 2: Tìm hiểu nguyên lý, đặc điểm làm việc của hai hệ điều hành thời gian thực RTAI và xenomai

Chương 3: Đánh giá hệ điều hành thời gian thực RTAI và xenomai dựa trên

ba đặc điểm thời gian thực: Trễ, dao động, chuyển ngữ cảnh

Chương 4: Nêu các bước tiến hành xây dựng hệ thống thời gian thực RTAI trên nền tảng PC

Chương 5: Thực hiện tính toán hệ thống điều khiển động cơ điện một chiều

và ứng dụng hệ thống thời gian thực RTAI vào mô hình trên

Chương 6: Đánh giá kết quả và bàn luận

CHƯƠNG 1: GIỚI THIỆU VỀ HỆ THỐNG THỜI GIAN THỰC

1.1 Hệ thống thời gian thực

Thông thường thời gian thực (Real-Time) được được hiểu với nghĩa là khi thực hiện một sự kiện sẽ cho đáp ứng trong khoảng thời gian ngắn có thể xác định trước Trong kỹ thuật điều khiển, một tiến trình (xử lý) được gọi là thời gian thực nếu nó có sự ràng buộc thời gian nào đó và tiến trình được hoàn thành trong thời gian định trước mà không xuất hiện lỗi Một hệ thống thời gian thực là sự kết hợp các tiến trình với các ràng buộc về thời gian Kỳ hạn (deadline) là một ví dụ về ràng buộc về thời gian mà hệ thống thời gian thực mong muốn đạt được

Hệ thống thời gian thực được chia thành hai loại: thời gian thực cứng (hard real-time) và thời gian thực mềm (soft real-time) Tiêu chuẩn chính để phân loại hệ thống thời gian thực là mức độ yêu cầu của tiến trình trong hệ thống với kỳ hạn của

nó Trong hệ thống thời gian thực cứng, kỳ hạn của nó là phải đạt được, nếu vượt quá kỳ hạn có thể gây hỏng hóc hoặc hoạt động sai cả hệ thống Mức độ yêu cầu về

kỳ hạn của hệ thống phụ thuộc vào nhiệm vụ thực hiện Ví dụ về thời gian thực cứng đó là các lò phản ứng hạt nhân Với hệ thống thời gian thực mềm, hệ thống có thể chấp nhận việc tiến trình vượt quá kỳ hạn mong muốn trong khoảng dung sai chấp nhận được Sự vượt kỳ hạn này không ảnh hưởng tới hoạt động của hệ thống

Sự quan trọng của kỳ hạn phụ thuộc vào ứng dụng Ví dụ, nếu một máy video mất một hoặc hai khung ảnh là có thể chấp nhận được nhưng lại có sự giới hạn về số lượng mất khung ảnh và tần số mất Trong hệ thống thời gian thực mềm có thể xảy

ra vượt kỳ hạn nhưng không được thường xuyên

1.2 Hệ điều hành thời gian thực (Real Time Operating System - RTOS)

Để đạt tính ổn định, mềm dẻo, dễ ràng trong bảo trì nâng cấp các ứng dụng trong hệ thống thời gian thực, các hệ thống thời gian thực ngày nay thường sử dụng

hệ điều hành thời gian thực

Một hệ điều hành (Operate System – OS) là một chương trình hệ thống cung cấp giao tiếp giữa các chương trình ứng dụng và phần cứng của hệ thống Hệ điều hành thời gian thực (Real Time Operating System – RTOS) là một hệ điều hành (Operate System – OS) có khả năng đảm bảo chắc chắn thiết lập ràng buộc (liên kết) về thời gian Các chương trình trong hệ điều hành thời gian thực có các nhiệm

vụ (task) phải đảm bảo sẽ hoàn thành trước kỳ hạn và nhận được kết quả đúng RTOS phải có khả năng đáp ứng lại sự kiện không dự đoán trước được trong khoảng thời gian định trước và xử lý nhiều sự kiện đồng thời Các nguồn tài nguyên của hệ thống thời gian thực phải được quản lý rõ ràng cho mục đích thời gian thực

1.3 Các thông số dùng để đánh giá, phân tích hệ điều hành thời gian thực

Trễ (Latency): Để phân tích trễ ta coi hệ thống sử dụng RTOS như hộp đen,

và kiểm tra đáp ứng của hệ thống với ngắt Trễ là khoảng thời gian sai lệch giữa thời điểm một ngắt được sinh ra và thời điểm điều khiển ngắt của hệ thống đưa ra đáp ứng Khi kiểm tra đánh giá ngắt, hệ thống phải trạng thái làm việc tải lớn (tải CPU lớn và vào ra dữ liệu lớn)

Dao động (Jitter): Trong hệ thống thời gian thực, dao động tác động tới hoạt

động của hệ thống là hiển nhiên Ví dụ, Trong điều khiển động cơ bước, việc phát xung trong khi điều khiển động cơ quay, nhưng dao động thời điểm phát xung làm cho mômem được tạo ra sớm hoặc muộn hơn theo dao động Sự thay đổi vị trí (góc quay) của động cơ () sẽ dao động theo sự dao động của xung (t) ( = .t), nguyên nhân dẫn tới mất bước của động cơ [Protor and Shackleford 2001] Dao động là thời gian sai lệnh giữa hai trễ ngắt liên tiếp Cuối cùng, sai lệch lớn nhất được chọn như là dao động (tồi nhất) của hệ thống này

Thời gian đáp ứng xấu nhất (Worst Case Response Time): Thời gian đáp

ứng xấu nhất được xác định theo phương pháp của ISA (International Society for Measurement and Control) Phương pháp xác định tần số ngắt lớn nhất theo ISA: khi nhận được tín hiệu vào hệ thống đưa trực tiếp tới đầu ra, thực hiện đo số lượng xung vào và ra Khi hệ thống hoạt động ổn định thì số lượng xung hai cổng là bằng nhau Tăng tần số tín hiệu vào cho tới khi số lượng xung hai cổng khác nhau Tại thời điểm này, tần số được giảm xuống cho tới tần số hệ thống làm việc ổn định trở lại Tần số tín hiệu vào đo được là tần số hoạt động lớn nhất của hệ thống Đáp ứng thời gian xấu nhất là ngịch đảo của tần số lớn nhất nhận được Kiểm tra thực hiện với tải hệ thống lớn (tải CPU và tải vào ra dữ liệu lớn)

1.4 Các yêu cầu của hệ điều hành thời gian thực

Khả năng đa nhiệm (Multitasking Capabilities): Một ứng dụng thời gian

thực chia thành nhiều nhiệm vụ Việc chia này sẽ sử dụng tối đa năng lực CPU

Trễ ngắt thấp (Short Interrupt Latency): Trễ ngắt là sự trễ của phần cứng

khi sử lý tín hiệu ngắt + thời gian để hoàn thành câu lệnh hiện tại + thời gian thực hiện mã hệ thống chuẩn bị cho truyền sự thực hiện tới thiết bị điều khiển ngắt

Chuyển ngữ cảnh nhanh (Fast Context Switch): Là thời gian khi hệ điều

hành nhận được sự kiện tới khi bắt đầu của thực hiện nhiệm vụ phục vụ sự kiện đó được gọi là thời gian chuyển ngữ cảnh (dispatch latency – trễ điều độ) Trong hệ thống thời gian thực yêu cầu thời gian chuyển ngữ cảnh phải là nhỏ

Sự quản lý bộ nhớ (Control of Memory Management): một hệ điều hành

cung cấp cách để nhiệm vụ khóa (lưu trữ) mã và dữ liệu của nó vào trong bộ nhớ thực vì vậy nó có thể đảm bảo đáp ứng dự đoán trước được với ngắt

Lập lịch trình thích hợp (Proper Scheduling): Hệ điều hành cung cấp cách

thức để lập lịch trình dễ ràng các nhiệm vụ ràng buộc về thời gian

Dịch vụ bộ thời gian đảm bảo mịn (Fine granularity Timer Services): độ

phân giải hàng milli giây là thô nhất Độ phân giải hành micro giây là yêu cầu trong vài trường hợp

Nhiều cơ chế giao tiếp giữa các nhiệm vụ (Rich set of Inter Task Communication Mechanism): Hàng đợi thông điệp (Message queues), chia sẻ bộ

nhớ (shared memory), sự đồng bộ - cờ hiệu (semaphores), cờ sự kiện (event flags)

1.5 Lựa chọn nền tảng phát triển

Các hệ thống thời gian thực đều được thiết kế dựa trên bộ xử lý tín hiệu số,

và chúng có thể đạt được thời gian thực bởi thực hiện chương trình từ dòng lệnh cơ bản (dạng mã máy) của bộ xử lý tín hiệu số đó Nhưng việc này đòi hỏi người phát triển cần phải hiểu biết sâu về phần cứng và môi trường phát triển cho vi điều khiển

đó Điều này sẽ kéo theo chi phí thời gian lớn để thực hiện, gây khó khăn cho phát triển và việc đánh giá tính ổn định của hệ thống phức tạp hơn Do đó ngày nay để nâng cao hiệu năng lập trình, tính ổn định và giảm chi phí duy trì, phát triển ứng dụng người ta sử dụng hệ điều hành thời gian thực trong các hệ thống điều khiển thời gian thực

Ngày nay có rất nhiều hệ điều hành thời gian thực khác nhau có cả các bản

mã nguồn mở, thương mại khác nhau Các hệ điều hành này có thể thực hiện trên nền tảng Windows hoặc Linux Trong đó, RTOS dựa trên Linux là rất quan trọng vì

nó có mã nguồn mở và giấy phép công cộng (Public License) Các nhà nghiên cứu,

phát triển và lập trình ưa thích Linux vì nền tảng mở tạo ra sự mềm dẻo trong đánh giá và phát triển ứng dụng

Do tính mở và được sự hỗ trợ rộng lớn của cộng đồng phát triển, nên Linux ngày càng được qua tâm Rất nhiều nhà phát triển hệ thống thời gian thực, kể cả các nhà cung cấp hệ điều hành thời gian thực thương mại đều có xu hướng cung cấp môi trường phát triển sản phẩn của họ sang môi trường Linux

Ngoài ra, hệ điều hành Linux còn có các đặc điểm của một hệ điều hành thời gian thực mềm: Linux hỗ trợ đa luồng và hỗ trợ giao tiếp hệ điều hành khả chuyển (POSIX) , các thư viện phù hợp là sẵn có, ví dụ thư viện luồng đơn vị dấu phải động (FSU Pthread) Trong đó, chuẩn POSIX định nghĩa hệ điều hành và chương trình giao tiếp như thế nào với thiết bị phần cứng Tiêu chuẩn POSIX 1003.13 định nghĩa

là hệ thống thời gian thực đa người dùng cho phép các tiến trình thời gian thực thực hiện theo thứ tự bằng cách sử dụng trình lập lịch đặc biệt và tự khóa nó trong bộ nhớ để tránh sự phân trang nhớ trên đĩa cứng

Từ những đặc điểm nổi bật của Linux: là hệ điều hành thời gian thực mềm

mã nguồn mở, miễn phí và được hỗ trợ bở nhiều nhà phát triển Nên luận văn này lựa chọn hệ điều hành thời gian thực được phát triển dựa trên nền Linux

Trong các máy tính cá nhân hiện, đơn vị xử lý trung tâm đa dụng (General purpose central processing unit – GPCPU) là không phù hợp cho các ứng dụng thời gian thực vì có vài nhân tố không đảm bảo như bộ nhớ ảo và sự quản lý bộ nhớ dẫn tới cản trở trễ mặc định Nhưng với đặc điểm tích toán tốc độ cao của GPCPU ngày nay (số lượng của tính toán dấu phẩy động trên giây là hàng triệu) với lệnh đơn có thể chứa nhiều dữ liệu và đa xử lý đối nên nó có thể thực hiện được các hệ thống điều khiển phức tạp Để sử dụng các GPCPU vào ứng dụng thời gian thực cứng người ta đã thực hiện thay đổi nhân của hệ điều hành để có thể đáp ứng điều điều khiển thời gian thực, bao gồm khả năng dự đoán trước, khả năng giành ưu tiên, hỗ trợ lập lịch trình đa luồng, khả năng ưu tiên, và thiết bị chia sẻ nguồn dự trữ tránh đảo lộn thứ tự ưu tiên Việc sử đổi nhân này sẽ tạo ra hệ điều hành thời gian thực sử dụng các CPU của máy tính cá nhân để ứng dụng trong điều khiển Luận văn sẽ chọn đơn vị xử lý tín hiệu số là CPU của máy tính cá nhân do tính sẵn có của nó

CHƯƠNG 2: CÁC HỆ ĐIỀU HÀNH THỜI GIAN THỰC

Như đã nói ở chương 1, ta sẽ lựa chọn các hệ điều hành thời gian thực dựa trên nền tản máy tính cá nhân PC sử dụng Linux đó là Xenomai và RTAI Chương này sẽ giới thiệu về cấu trúc và nguyên tắc hoạt động của chúng

2.1 Xenomai

Dự án Xenomai đặt ra năm 2001, và được duy trì tới hiện nay bởi Philippe Gerum, Bruno Rouchouse và Gilles Chanteperdrix Mục tiêu chính của dự án là cung cấp khả năng thời gian thực dựa trên lõi RTOS trừu tượng (có mô phỏng các RTOS như: VxWorks, pSOS…) Các ứng dụng được viết cho RTOS truyền thống

có thể thực hiện thông qua lõi RTOS trừu tượng này Nói chung, Xenomai nhắm tới tính mềm dẻo, tính mở rộng, và khả năng duy trì hơn là cố gắng giành được khả năng có trễ khả thi thấp nhất như RTAI làm Nhân Xenomai đăng ký giấy phép công cộng (General Public Licens - GPL) Tuy nhiên, nó vẫn có thể phân phối ứng dụng độc quyền bằng thư viện không gian người dùng, đăng ký dưới giấy phép GNU Lesser General Public License (LGPL)

2.1.1 Nguyên lý

Hình 2.1: Cấu trúc của Xenomai

Ta tìm hiều về nguyên lý của Xenomai thông qua kiến trúc tổng quan trên

Hình 2.1 Xenomai bao gồm vài lớp trừu tượng khác nhau Các lớp này mang lại

tính mềm dẻo to lớn cho xenomai Phía trên của phần cứng là chỗ nhân nano Adeos làm việc Lớp trừu tượng phần cứng (Hardware Abstraction Layer – HAL) nằm phía trên Adeos là phần phụ thuộc kiến trúc của Xenomai Để xuất Xenomai có thể chạy trên nền tảng phần cứng khác, lớp HAL phải tương thích với kiến trúc mới để lớp Adeos có thể hoạt động với kiến trúc đo Phần trung tâm của hệ thống là hạt nhân RTOS trừu tượng chạy phía trên HAL Nó thực hiện đặt các dịch vụ RTOS chung (lớp Real-time nucleus) cho hầu hết các hệ thống Các ứng dụng có thể sử dụng các dịch vụ thời gian thực thông qua API nguyên thủy Xenomai hoặc qua các RTOS-API truyền thống (các API hỗ trợ cho các RTOS truyền thống) khác được xây dượng phía trên của hạt nhân lớp nucleus Việc lõi RTOS hỗ trợ cho API cho RTOS truyền thống giúp việc chuyển các ứng dụng tới kiến trúc Xenomai không cần viết lại toàn bộ Xenomai cho phép người dùng chạy ứng dụng của họ trong không gian nhân hoặc không gian người dùng Trong không gian người dùng, thời gian thực hiện nhiệm vụ lâu hơn Các nhiệm vụ được chạy trong ngữ cảnh không gian người dùng để đảm bảo sự tin cậy của hệ thống, bởi vì sự cố của một tiến trình trong không gian nhân có thể dẫn tới một hỏng hóc toàn bộ hệ thống Phần tiếp theo

sẽ tập trung thảo luận vài đặt điểm của API truyền thống

2.1.2 API (Application programming interface – giao diện lập trình ứng dụng)

Xenomai hỗ trợ cả các RTOS-API truyền thống (API của RTOS truyền thống) và cả các API nguyên thủy (API của Xenomai), các API này có thể sử dụng độc lập hoàn toàn Nó được thực hiện trong module nhân “xeno_native.ko” Cung cấp các dịch vụ:

- Quản lý nhiệm vụ (Task management)

- Dịch vụ thời gian (Timing services)

- Hỗ trợ đồng bộ (đếm cờ hiệu (semaphores), Mutexes, các biến điều kiện, nhóm cờ sự kiện)

- Truyền thông và thông điệp (hàng đợi thông điệp, đường ống thông điệp,

Bộ nhớ heap)

- Điều khiển thiết bị I/O

- Hỗ trợ đăng ký (cho phép thực hiện từ các không gian thực thi khác nhau).API là độc lập ngữ cảnh, nghĩa là gần như có thể đặt các dịch vụ thời gian

thực là như nhau để có thể sử dụng trong không gian nhân hoặc không gian người dùng Ví dụ một nhiệm vụ là luôn luôn biểu diễn bởi từ khóa RT_TASK và hàng đợi thông điệp bởi miêu tả từ khóa RT_QUEUE bất chấp không gian thực hiện chúng sử dụng Hơn nữa, các từ khóa có thể chia sẻ giữa các không gian thực hiện

và cho phép gọi dịch vụ từ các đối tượng được tạo ra từ không gian đối lập

Xenomai hỗ trợ chế độ thực hiện pha trộn cho phép các nhiệm vụ trong không gian người dùng có thể thực hiện trong miền Xenomai Nghĩa là sau khi bắt đầu các tiến trình thời gian thực mới thì nó chạy tiếp tục trong miền Xenomai, hay còn gọi là “miền nguyên thủy” – Primary Domain Nhiệm vụ có sự bảo vệ bộ nhớ nhưng được lập lịch trình trực tiếp bởi Xenomai Chạy trong chế độ này trễ lập lịch trình trường hợp xấu nhất là luôn luôn gần giới hạn phần cứng và dự đoán được Nó

có thể giành quyền ưu tiên của bất kỳ hoạt động của Linux nào mà không có trễ

Khi nhiệm vụ thời gian thực trong miền nguyên thủy cho phép hệ thống Linux gọi, thì nhiệm vụ được chuyển ngay lập tức tới miền Linux (“miềm thứ hai”- Secondary Domain) Nó nằm dưới trình lập lịch của Linux, nghĩa là nó thể bắt đầu thực hiện tại điểm lập lịch trình lại gần nhất tiếp theo của nhân Linux Thời gian di chuyển phụ thuộc vào sự đản bảo của nhân Linux Rõ ràng, thời gian dài nhất giữa hai lần thực hiện của việc lập lịnh trình lại trong Linux là trường hợp xấu nhất Nó cho phép các sự kiện nhiệm vụ thời gian thực chạy trong miền thứ hai có thể dự đoán được

Một nhiệm vụ chạy trong miền thứ hai truy nhập tất cả các dịch vụ Linux thông thường Tuy nhiên, lời gọi hệ thống được thiết kế để đảm bảo công bằng và

dự đoán được sẽ là nguyên nhân vài vấn đề ở đây Khi vào miền thứ hai, nhiệm vụ thời gian thực không mất ưu tiên của nó Giản đồ ưu tiên là nhất quán qua các miền, nghĩa là nhân Linux kế thừa bộ ưu tiên của nhiệm vụ thời gian thực Nó tranh giành nguồn tài nguyên CPU với các tiến trình thời gian thực còn lại Đây là sự khác biệt

cơ bản với cách RTAI/LXRT thực hiện, trong đó sự kế thừa ưu tiên được tối ưu Trong RTAI/LXRT nhiệm vụ thời gian thực lấy ưu tiên thấp nhất định nghĩa bởi trình lập lịch RTAI

Trong khi nhiệm vụ vào miền thứ hai, vẫn có thể bị giành ưu tiên bởi điều khiển ngắt Linux chuẩn Cái này có thể là nguyên nhân trễ không mong muốn vì vậy cần phải tạo cho nó “lá chắn ngắt” – Interrupt Shield Nó làm trễ mỗi khi điều khiển ngắt Linux cho đến khi không có bất kỳ nhiệm vụ thời gian thực nào đang chạy trong miền thứ hai Lá chắn ngắt có thể cho phép trong khi cấu hình bản vá

nhân qua từ khóa “CONFIG_XENO_OPT_ISHIELD” Bên cạnh đó, nó có thể cho phép/không cho phép lá chắn ngắt trong thời gian thực hiện thông qua lời gọi hệ thống Xenomai “rt_task_set_mode” (cờ: T_SHIELD) Lá chắn ngắt tự coi nó dường

như là như miền Adeos (nhìn hình 2.2)

Hình 2.2: Lá chắn ngắt trong đường ống pipe ngắt

Nhưng đặc điểm này vẫn có thể dẫn tới vấn đề đảo lộn ưu tiên Nhiệm vụ thời gian thực có thể đông cứng khi thực hiện hoạt động vào ra (ví dụ trình điều khiển thiết bị Linux thông thường) Từ khi chắn ngắt được cho phép, sự phân phối của một ngắt có thể trễ cho tới khi không có bất kỳ một nhiệm vụ thời gian thực nào được tích cực trong không gian thứ hai Điều này có thể là nguyên nhân đảo ngược

ưu tiên và do đó cần phải viết trình điều khiển thiết bị mới dựa trên miềm Xenomai hay miền nguyên thủy Mô hình trình điều khiển thiết bị thời gian thực (Realtime Device Driver Model - RTDM) hỗ trợ phát triển những trình điều khiển đó Điều trở ngại ở đây là trình điều khiển đó đã có trong nhân Linux chuẩn là không phù hợp cho sử dụng trong môi trường thời gian thực và vì vậy phải viết lại

Hình 2.3 thể hiện sự di chuyển của tiến trình nhiệm vụ thời gian thực giữa

chế độ nguyên thủy và chế độ thứ hai

Hình 2.3: sự di chuyển giữa chế độ nguyên thủy và thứ hai

2.1.3 Các đặc điểm

Phần tiếp theo này sẽ đưa ra vài đặc điểm quan trọng của hạt nhân

Xenomai là các điểm chủ đạo để có thể so sánh với các bản phối thời gian thực Linux khác

2.1.3.1 Hỗ trợ nhiều luồng

- Thuật toán lập lịch trình có ưu tiên (preemptive scheduling algorithm)

- Mức ưu tiên cho các luồng là số nguyên 32 bits (32 bit integer priorities)

- Lập lịch trình vòng tròn cho các luồng (thread) có cùng ưu tiên (lượng tử hóa thời gian)

- Các cảnh giới cho luồng (thời gian đợi một nguồn tài nguyên là giới hạn) (watchdogs)

- Mô hình 5 trạng thái cho tiến trình (khởi tạo, treo, lấy tài nguyên, trễ do bộ đếm, sẵn sàng thực hiện)

- Hỗ trợ kế thừa ưu tiên

- Hỗ trợ (đơn vị dấu phảy động) FPU trên luồng

2.1.3.2 Hỗ trợ các kiểu đồng bộ cơ bản

- Hỗ trợ kế thừa ưu tiên, thực hiện chia sẻ mã trình lập lịch

- Hỗ trợ giới hạn thời gian đợi và xáo bỏ cưỡng bức sự đợi

2.1.3.3 Quản lý bộ thời gian và xung nhịp

- Chế độ chu kỳ và không chu kỳ (nếu phần cứng hỗ trợ)

- Hạt nhân chuyển khóa trong suốt từ dao động chu kỳ tới giá trị bộ đếm thời gian phục thuộc vào chế độ hoạt động bộ thời gian

- Giới hạn thời gian trường hợp xấu nhất khi khởi động, dừng và cất giữ bộ thời gian

- Bộ thời gian sử dụng thuật toán quay tròn

Sự phát triển của giao diện ứng dụng thời gian thực (RTAI) bắt đầu từ năm

2000 bởi giáo sư Mategazza tại Dipartimeto di Ingegneria Aerospaziale ở Mailand

Nó là một nhánh của dự án RTLinux Các nền tảng được hỗ trợ bởi RTAI:

 ARM7: họ clps711x, Cirrus Logic EP7xxx, CS89712, PXA25x

 ARM9: bo mạch Cirrus EDB9301 phát triển với EP9301 CPU (ARM920T)

 Không phải luôn luôn có bản vá cho cả hai nhân Linux phiên bản 2.4/2.6 RTAI là rất giống với Xenomai do có sự sát nhập trong dự án RTAI/Fusion trong năm 2002 Nhiều lời gọi API Xenomai là API nguyên thủy có bản sao của nó trong API của RTAI, chỉ phân biệt bởi tên Tuy nhiên RTAI không theo quan niệm cung cấp nhiều API cho người dùng như Xenomai làm Việc cung cấp khả năng để chạy ứng dụng kế thừa từ RTOS truyền thống là nằm ngoài phạm vi của RTAI Ở RTAI không có nhiều lớp trừu tượng khác nhau thực hiện phía trên các lớp khác

như trường hợp Xenomai Hình 2.4 đưa ra kiến trúc của RTAI

Cho tới cuối năm 2003, Lớp trừu tượng hóa phần cứng còn được gọi là lớp trừu tượng hóa phần cứng thời gian thực (RTHAL) Về cơ bản, nó bao gồm sự đặt các con trỏ hàm, được sửa đổi trong nhân Linux Đầu tiên, các con trỏ được trỏ tới

các hàm Linux chuẩn vì vậy không ảnh hưởng tới hoạt động của nhân Linux (hình

2.4(đường A)) Sau khi tải các module RTAI, các con trỏ hàm được chuyển tới làm

việc dưới sự điều khiển của RTAI Hình 2.4(đường B) miêu tả cách thực hiện này

Các tiến trình này kết hợp chặt chẽ xử lý bẫy và xử lý ngắt cơ bản chính Sự tiện lợi của phương pháp này là ảnh hưởng rất ít tới nhân Linux Chỉ vào khoảng 70 dòng code (Lines Of Code - LOC) phải được thay đổi hoặc thêm vào Tuy nhiên giấy phép của dự án RTLinux ép buộc RTAI chuyển HAL của họ tới hạt nhân nano Adeos Các mã cơ bản không có bất kỳ gì chung với RTLinux Các bộ phận thuộc nhân của dự án RTAI là đăng ký giấy phép công cộng (GNU General Public License (GPL)) Thư việc không gian người dùng là đăng ký giấy phép công cộng hạn chế (GNU Lesser General Public License (LGPL)) Vì vậy, nó có thể được phân phối độc quyền ứng dụng không gian người dùng thời gian thực dựa trên RTAI/LXRT và/hoặc RTDM

Hình 2.4: Kiến trúc của RTAI

Như trong Xenomai, RTAI coi nhân Linux chuẩn như tiến trình nhàn rỗi với

ưu tiên thấp nhất, được thực thi chỉ khi không có các tiến trình thời gian thực khác được lập lịch trình Bộ thời gian trong RTAI có thể lập trình được để làm việc hoặc trong chế độ chu kỳ hoặc trong chế độ oneshot Chế độ oneshot đảm bảo mịn hơn với tổng chi phí ít hơn, vì bộ thời gian có thể lập trình lại

RTAI đưa ra các kiểm định gọi là “showroom”, phủ được hầu hết mọi đặc điểm có trong RTAI Nó là rất mạnh để kiểm tra các chức năng của RTAI và có thể

sử dụng được cho các phép đo cơ bản, ví dụ trễ lập lịch trình, dưới các hoàn cảnh khác nhau

Hơn nữa, Nó có công cụ “RTAI-Lab Toolchain” cho phép sử dụng để chuyển các sơ đồ khối thành các ứng dụng có thể thực hiện trong RTAI và giám sát hoạt động của chúng trong đích (hệ thống) khác nhau Sơ đồ có thể được phát triển bằng Scilab/Scicos hoặc Matlab/Simulink/RTW Chức năng đặc biệt này là điểm tiện lợi cơ bản so với Xenomai không có sẵn đặc điểm này

Hình 2.5: Tính kết thừa RTHAL trong RTAI

2.2.2 Adeos

Thiết kết chung của hạt nhân nano Adeos được đề nghị bởi Karim Yaghmour trong năm 2001 Adeos là lớp nguồn ảo hóa có trong bản vá nhân Linux Nó cho phép các “miền - Domains” khác nhau cùng tồn tại trên cùng phần cứng Một miền

có thể là hệ điều hành thời hoàn chỉnh như Linux Các miền tự chúng không thể nhìn được nhau, nhưng mọi miền đều có thể nhìn được Adeos Đó là tại sao nhân

Linux chuẩn cần phải vá để có thể làm việc với Adeos Các miền cạnh tranh với nhau để xử lý sự kiện ngoài (ngắt) và sự kiện trong (bẫy và ngoại lệ) Đặc điểm khác của Adeos là khả năng xuất các API chung tới các miền khách không phụ thuộc với kiến trúc của CPU Vì vậy, hầu hết các khó khăn khi xuất ra miền khách nằm ở lớp Adeos

Mỗi miền được liên kết tới cấu trúc dữ liệu trung tâm gọi là “sự kiện đường ống – event pipeline”hoặc “I-Pipe” đem lại khả năng báo cho các miền khi có ngắt ngoài, lời gọi hệ thống được cho phép bởi Linux hoặc các trigơ sự kiện hệ thống

khác của hạt nhân (xem hình 2.6) Ngoài ra, mỗi miền được gán cho ưu tiên tĩnh,

được sử dụng để gửi đi theo đúng thứ tự của các sư kiện Ví dụ, một ngắt ngoài xuất hiện nó đầu tiên được điều khiển bởi miền có ưu tiên cao nhất Sau đó nó được xử

lý, nó sẽ được đưa tới tất cả các miền liên quan khác Nhân Linux tự nó vẫn thực hiện vai trò đặc biệt như là một miền gốc Các miền khác cần Linux để cài đặt chúng thông thường bằng cách là nạp các module hạt nhân để đưa vào hoạt động

Thứ tự để gửi các sự kiện ngắt ngoài được quyết định theo các ưu tiên, Adeos cung cấp khả năng dừng các sự kiện Nghĩa là, trong khi điều khiển ngắt ở cấp “n” miền “n” có thể làm đông sự lan truyền của ngắt cho tất cả các cấp “k, k > n” Như vậy, Miền “0”

Hình 2.6: Adeos I-PIPE

là miền có ưu tiên cao nhất Theo nguyên tắc này, một miền với ưu tiên thấp hơn sẽ không được phép giành ưu tiên của một miền ưu tiên cao hơn khác Các ngắt được chứa trong bộ phận lưu giữ ngắt của CPU (per-CPU Interrupt log) và sẽ được gửi

đi sau khi gọi thủ tục Adeos đặc biệt để bỏ sự dừng sự kiện ngắt Kết quả là nhân Linux chuẩn làm đông các ngắt để thực hiện các phân đoạn, không ảnh hưởng tới nhiệm vụ thời gian thực trong miền nằm phía trước nó trong đường ống ngắt

Sự “trì hoãn” điều khiển ngắt được giới hạn đối với các sự kiện ngoài Sự kiện trong được tạo bởi nhân Linux chuẩn, như lỗi phân trang hoặc loại khác của bẫy, được đồng bộ trong nhân Linux chuẩn Không thể dừng chúng trong đường ống ngắt khi chúng cần được điều khiển ngay lập tức

2.2.3 Lập lịch trình

RTAI có trình lập lịch không bị giới hạn bởi khả năng của trình lập lịch của Linux chuẩn Nó cho phép có thể lựa chọn giữa hai trình lập lịch khác nhau, được thực hiện trong module rtai_sched.ko và rtai_lxrt.ko Có hai cách chỉ khác nhau ở kiểu của đối tượng chúng có thể lập lịch trình trong không gian nhân Trong không gian người dùng trình lập lịch các ứng dụng là như nhau

Với rtai_sched.ko, Các luồng nhân RTAI chuyên dụng có thể được lập lịch trình tốt như bất kỳ đối tượng có thể lập lịch trình nào như tiến trình Linux, luồng Linux và các luồng hạt nhân Linux

Mục đích của trình lập lịch thời gian thực Linux (LinuX RealTime- LXRT) trong rtai_lxrt.ko là đưa ra API đối xứng (API giống nhau) của các nhiệm vụ RTAI thời gian thực và các tiến trình Linux Ứng dụng không gian người dùng dựa trên API này có thể đơn giản chuyển sang ngữ cảnh thời gian thực cứng bởi lời gọi

“rt_make_hard_realtime()” Về cơ bản, việc sử dụng của LXRT luôn luôn tạo ra luồng hạt nhân có thể được lập lịch trình bởi trình lập lịch thời gian thực của RTAI

Rõ ràng, đây là điểm tiện lợi lớn khi phát triển các ứng dụng thời gian thực mới Công cụ gỡ rối không gian người dùng là sẵn có và trong khi phát triển tiến trình các mã chương trình chạy trong môi trường an toàn Sau khi đạt tới ổn định các ứng dụng cuối cùng có thể chuyển tới thực hiện nhiệm vụ thời gian thực RTAI rễ ràng bởi sự đối xứng của API LXRT

Tuy nhiên, khi tạo ra lời gọi hệ thống Linux, ứng dụng không gian người dùng là di chuyển ngược tới Linux và nằm dưới trình lập lịch Linux chuẩn Khi dịch

vụ yêu cầu đã đáp ứng đủ, nhiệm vụ lại được điều khiển trở lại bởi trình lập lịch RTAI Thay vì, việc API của RTAI có thể được sử dụng mà không chuyển tới Linux Vì vậy, sử dụng lời gọi hệ thống POSIX chuẩn sẽ được tránh bởi vì nhiệm

vụ sẽ mất ngữ cảnh thời gian thực

2.2.4 API

API của RTAI có các hàm khác nhau để xây dựng, quản lý, và hủy nhiệm vụ thời gian thực đối với các ngắt ngoài Hơn nữa, LXRT API cung cấp các nhiệm vụ thời gian thực cứng trong không gian người dùng Trong khi tiến hành cấu hình, các đặc điểm có thể cho phép/không cho phép riêng rẽ RTAI có các chức năng chính như sau:

- Điều khiển ngắt thời gian thực và dịch vụ đồng hồ (rtai_hal.ko)

- Quản lý an toàn ngắt trong không gian người dùng (rtai_usi.ko)

- Dịch vụ lập lịch trình

 Luật lập lịch trình giành quyền ưu tiên, cố định ưu tiên ngoài, thuật toán

ưu tiên round robin (vòng tròn) hoặc fifo (vào trước ra trước) trong lớp cùng mức ưu tiên

 Lập lịch trình thời gian thực cứng cho các nhiệm vụ thời gian thực nhỏ RTAI (rtai_sched.ko)

 Lập lịch trình thời gian thực cứng của tất cả các đối tượng có thể lập lịch trình của Linux (rtai_lxrt.ko)

- Truyền dữ liệu giữa các tiến trình

 Hòm thư (rtai_mbx.ko)

 Thông điệp (rtai_msg.ko)

 Hàng đợi thông điệp RTAI (rtai_tbx.ko)

 Hàng đợi tin POSIX (rtai_mq.ko)

 Chia sẻ bộ nhớ (rtai_shm.ko)

 Vào trước ra trước thời gian thực fifo (rtai_fifos.ko)

 Truyền thông mạng thời gian thực NetRPC (rtai_netrpc.ko)

 hỗ trợ mô hình điều kiển thời gian thực (RTDM), dùng một API đơn nhất

để phát triển trình điều khiển thiết bị (rtai_rtdm.ko)

 Trình điều khiển thời gian thực cho cổng nối tiếp (rtai_serial) và 16550A UART (rtai_16550A.ko, dựa trên RTDM)

 Quản lý bộ nhớ thời gian thực (rtai_malloc.ko)

 Hỗ trợ dấu phẩy động trong hạt nhân (rtai_math.ko)

 Chức năng watchdog mềm cho giám sát các nhiệm vụ thời gian thực (rtai_wd.ko)

 hỗ trợ gỡ dối LED gỡ rỗi (rtai_leds.ko)

Hỗ trợ POSIX cho các API luôn luôn là điều mong muốn đạt được Trong thực tế, RTAI cung cấp các tập con POSIX thời gian thực mở rộng đã được đề nghị trong IEEE 1003.1b-1993 và IEEE 1003.1d-1999 Các hàm POSIX trong RTAI:

- Các luồng (threads) POSIX

- Các cờ hiệu (semaphores) POSIX

- POSIX mutex (độc quyền truy nhập nguồn tài nguyền xác định)

- POSIX barries (lớp chắn tiến trình để đồng bộ các tiến trình – một tiến trình

sẽ phải đợi tiến trình khác thực hiện xong)

- POSIX condition variables (các biến điều kiện)

- POSIX locks ( Các khóa đọc/nghi và khóa vòng -spinlocks)

- POSIX message queues (hàng đợi thông điệp)

Như ta thấy nguyên tắc hoạt động của hai hệ điều hành này có sự khác biệt Xenomai tập trung vào việc nâng cao khả năng chuyển đổi giữa các nền tảng phần cứng khác nhau cho chương trình điều khiển, còn RTAI thì tập chung vào đạt được tối ưu về đáp ứng thời gian của hệ thống Còn các hỗ trợ quản lý hệ thống của hai

hệ điều hành này đều đầy đủ để các chương trình có thể gọi tới hệ thống

CHƯƠNG 3: ĐÁNH GIÁ SO SÁNH CÁC HỆ ĐIỀU HÀNH THỜI GIAN

THỰC

Mục này sẽ tiến hành đánh giá chất lượng của các hệ thời gian thực Xenomai

và RTAI về các khía cạnh thời gian thực là trễ ngắt ngoài và trễ lập lịch trình Các thông số khác có thể đưa ra để đánh giá hiệu năng thời gian thực là thời gian chuyển ngữ cảnh, trễ xử lý thông điệp và thời gian để xác định khối lượng bộ nhớ

Bản phân phối Linux thời gian thực được sử dụng các phiên bản sau

- Bản vá ưu tiên thời gian thực của Ingo Molnar, bản vá 2.6.18-rt7” với Linux 2.6.18

“patch Xenomai 2.2.4, bản vá Adeos I“patch PIPE “adeos“patch ipipe“patch 2.6.17“patch i386“patch 1.5“patch 00.patch”

“adeos-ipipe-2.6.17-i386-1.5 RTAI 3.4, bản vá “hal“adeos-ipipe-2.6.17-i386-1.5 linux“adeos-ipipe-2.6.17-i386-1.5 2.6.17“adeos-ipipe-2.6.17-i386-1.5 i38601.3“adeos-ipipe-2.6.17-i386-1.5 08.patch”

Tải trên hệ thống kiểm tra x86 được thực hiện theo cách sau:

- Tải vào/ra: Dùng lệnh lặp ping để kiểm tra hệ thống và sử dụng “dd”

- Tải CPU: CPU Burn-in v1.00

http://cpuburnin.com/downloads/cpuburn- in.tar.gz

3.2 Đánh giá, so sánh trễ ngắt sử dụng kết nối cổng song song lặp vòng

Sử dụng kết nối công song song lặp vòng (theo cách Thomas Wiedemann thực hiện) để xác định thời gian đáp ứng với ngắt ngoài để đánh khả năng thời gian thực Thời gian đáp ứng ngắt được xác định bằng thời gian giữa sự xuất hiện của tín

hiệu ngoài và bắt đầu đáp ứng dịch vụ ngắt (ISR) Kết nối được minh họa trên hình

3.1

Hình 3.1: Kết nối cổng song song lặp vòng

Đầu tiên trễ được đo bởi nhân Linux chuẩn không có bất kỳ sự giành quyền

ưu tiên nào được cho phép Tiếp theo từ khóa “CONFIG_PREEMPT” được cho phép để đánh giá sự nâng cấp giành quyền ưu tiên của nhân Linux Cuối cùng, module nhân được biên dịch lại để thực hiện với các API Linux thời gian thực khác nhau Tất cả các phép đo được sử dụng ngắt tần số 1ms và dưới tải nặng (gồm có tải

vào/ra và tải CPU) Các kết quả được minh họa qua biểu đồ Hình 3.2 tới 3.4

Từ các kết quả cho thấy kết quả của Linux chuẩn là mâu thuân với lý thuyết Nhân không có giành quyền ưu tiên nguyên thủy thể hiện trễ lớn nhất là thấp nhất, tiếp theo đó là nhân có giành quyền ưu tiên nguyên thủy được tích cực và nhân Linux với bản vá ưu tiên thời gian thực của Ingo Molnar Nguyên nhân có thể là sự sửa đổi trong nhân Linux có thêm vài chi phí quản lý Tuy nhiên, chúng ta sẽ lấy giới hạn thời gian đáp ứng trong trường hợp xấu nhất, có thể cao hơn trường hợp nhân không có bản vá giành quyền ưu tiên Các phép đo đã thực hiện trong khoảng thời gian khoảng 1 phút

Hình 3.2: Linux chuẩn không có giành quyền ưu tiên nguyên thủy

Các biểu đồ trong hình 3.5 tới 3.8 thể hiện thời gian đáp ứng ngắt của

Xenomai và RTAI Các trễ lớn nhất là thấp hơn khoảng 30% so với nhân Linux

không thực hiện vá giành quyền ưu tiên và thấp hơn 95% so với trong biểu đồ Hình

3.4 Đây là điều quan trọng nhất cho ứng dụng thời gian thực Tuy nhiên, trường

hợp thời gian đáp ứng trung bình và nhỏ nhất là kém hơn nhân Linux không sửa đổi Điều đó có thể giải thích bởi chi phí quản lý đường ống ngắt Adeos

Xenomai thể hiện trễ cao hơn nếu giành quyền ưu tiên nguyên thủy của nhân Linux được cho phép, mặc dù đáp ứng ngắt là được khởi tạo trong ngữ cảnh điều khiển ngắt Giành quyền ưu tiên nguyên thủy chỉ cung cấp các kết quả tốt hơn chỉ khi chuyển khóa tới miều thứ hai xảy ra Điều này có thể là dấu hiệu từ khóa

“CONFIG_PREEMPT” làm xấu hơn tỉ lệ truy cập vùng lưu trữ Nó được lưu giữ lại

và không tạo ra bất kỳ dấu hiệu gì để bật “CONFIG_PREEMPT” nếu luồng thời gian thực không cho phép bất kỳ lời gọi hệ thống Linux nào

Hình 3.3: Linux chuẩn với giành quyền ƣu tiên nguyên thủy

Hình 3.4: Linux chuẩn với bản vá giành quyền ƣu tiên thời gian thực

Hình 3.5: Xenomai không có giành uyền ƣu tiên nguyên thủy

Hình 3.6: Xenomai với giành quyền ƣu tiên nguyên thủy

Hình 3.7: RTAI không có giành quyền ƣu tiên nguyên thủy

Hình 3.8: RTAI với giành quyền ƣu tiên nguyên thủy

3.3 Trễ lập lịch trình

Trong kiểm tra này, sẽ quan sát các dao động thời gian của một nhiệm vụ chu kỳ Nhân Linux chuẩn được biên dịch với bộ thời gian chuẩn chính xác 250Hz (4ms) Độ phân giải này rất thô nếu sử dụng cho ứng dụng thời gian thực và vì vậy phải chu kỳ của nhiệm vụ phải được điều chỉnh lên tới 10ms Các phép đo được thực hiện trên nhân Linux chuẩn và trên nhân sau khi thực hiên vá giành quyền ưu tiên thời gian thực, của Ingo Molnar Ngoài ra, công việc chu kỳ có thể thực hiện theo thuật toán lập lịch trình “SCHED_FIFO” hoặc “SCHED_OTHER” Các kết

quả thể hiện trên biểu đồ hình 3.9 tới 3.12

Hình 3.9: Linux chuẩn không có giành quyền ưu tiên (“SCHED_OTHER”)

Các phép đo của nhân Linux chuẩn (có vá hoặc không vá giành quyền ưu tien) cho thấy thuật toán lập lịch trình “SCHED_FIFO” có thể ảnh hưởng trên dao động lập lịch trình trong trường hợp xấu nhất Khe 4ms giữa hai đỉnh tương ứng với

bộ thời gian phân giải 250Hz Từ khóa “PREEMPT_RT” của bản vá nhân cho thấy dao động lập lịch trình trường hợp xấu nhất thấp nhất với luật “SCHED_FIFO” và

Hình 3.10: Linux chuẩn không có giành quyền ưu tiên (“SCHED_FIFO”)

xung quanh hai-ba mẫu có khoảng nghỉ khoảng 2ms Sự phân tán của phép đo cũng thấp hơn nhiều với luật “SCHED_OTHER”

Với Xenomai và RTAI độ phân giải bộ thời gian là chính xác hơn rất nhiều, cho phép đặt nhiệm vụ đang chạy với chu kỳ 100s Tất cả các phép đo được thực hiện trong một chu kỳ 1 phút (600000 mẫu) và dưới tải nặng (tải vào/ra và tải CPU)

Các kết quả minh họa qua biểu đồ hình 3.13 tới 3.17

Xenomai và RTAI có thể đạt được kết quả tốt hơn rất nhiều Các phép đo với điều khiển ngắt bộ thời gian chu kỳ cho thấy dao động lập lịch trình thấp nhất so với nhiệm vụ không gian nhân, nhiệm vụ thuộc không gian người dùng xấu hơn chút ít nhưng phân phối các trễ cũng hợp lý

Kết quả của nhiệm vụ chu kỳ trong không gian người dùng với RTAI là tương tự như Xenomai Cả hai là ngần như tương đương Tuy nhiên, Các phép đo trễ lập lịch trình của nhiệm vụ không gian nhân RTAI thật sự rất ấn tượng Gần như tất cả trễ dưới 2s tốt hơn rất nhiều nhiệm vụ không gian nhân Xenomai Nguyên

nhân có thể do sự khác nhau cách thực hiện nhiệm vụ trong không gian nhân của RTAI

Hình 3.11: Linux với bản vá giành quyền ƣu tiên thời gian thực SCHED_OTHER

Hình 3.12: Linux với bản vá giành quyền ƣu tiên thời gian thực SCHED_FIFO