báo cáo hệ điều hành contiki

LỜI NÓI ĐẦU
Các đối tượng thông minh thường là các thiết bị đơn giản, nhỏ gọn, giá
thành thấp, sử dụng nguồn năng lượng hạn chế (pin), có thời gian hoạt động lâu
dài. Một trong những đặc điểm nổi bật của một nút mạng các đối tượng thông
minh là sự hạn chế về năng lực tính toán, nguồn năng lượng cung cấp, và giá
thành sản xuất. Mặc dù phần cứng đơn giản nhưng các đối tượng thông minh đã
và đang được ứng dụng rộng rãi trong đời sống.
Việc hỗ trợ cơ sở hạ tầng cho các ứng dụng mạng các đối tượng thông
minh trên hệ điều hành ngày càng trở nên quan trọng. Bản chất, hệ điều hành là
cầu nối giữa phần cứng đơn giản với phần ứng dụng phức tạp.
Hệ điều hành cho mạng các đối tượng thông minh đóng vai trò trung tâm
trong việc xây dựng các ứng dụng phân tán với khả năng mở rộng, có độ tin cậy
và hiệu quả cao. Qua nhiều năm, chúng ta đã thấy xuất hiện nhiều hệ điều hành
khác nhau nhằm dễ dàng cho việc phát triển các ứng dụng mạng với các đối tượng
thông minh. Các chức năng cơ bản của hệ điều hành bao gồm việc trừu tượng hóa
tài nguyên cho các thiết bị phần cứng khác nhau, quản lý ngắt và lập lịch các
nhiệm vụ, điều khiển đồng thời, và hỗ trợ mạng. Dựa trên các dịch vụ được cung
cấp bởi hệ điều hành, những người lập trình ứng dụng có thể thuận tiện sử dụng
các giao diện lập trình ứng dụng mức cao độc lập với phần cứng lớp dưới.
Hệ điều hành Contiki là hệ điều hành mã nguồn mở, được nghiên cứu, thiết
kế và phát triển bởi một nhóm các nhà phát triển từ viện khoa học máy tính Thụy
Điển, người đứng đầu là Adam Dunkels. Nhóm phát triển Contiki gồm nhiều
thành viên đến từ SICS, CISCO, cùng nhiều tổ chức và các trường đại học khác
trên thế giới. Hệ điều hành Contiki được thiết kế cho các vi điều khiển có bộ nhớ
nhỏ, với thông số 2KB RAM và 40KB ROM. Nhờ đó, Contiki được sử dụng rộng
rãi cho các đối tượng thông minh.
Nội dung bài giảng này gồm 4 chương:
Chương 1: Tổng quan về hệ điều hành nhúng cho các đối tượng thông
minh. Chương này khảo sát các hệ điều hành hiện có từ đó đưa ra những so sánh
và những hướng nghiên cứu trong tương lai đối với các hệ điều hành này.
Chương 2: Giới thiệu về hệ điều hành Contiki. Chương này giới thiệu tổng

quan về hệ điều hành Contiki bao gồm lịch sử hình thành và phát triển, các đặc
điểm chính, kỹ thuật lập trình trên hệ điều hành Contiki, vấn đề quản lý bộ nhớ,
các bước cài đặt môi trường phát triển ứng dụng với Contiki trên Ubuntu.
1
Chương 3: Các module trong hệ điều hành Contiki. Chương này trình bày
các module chính trong hệ điều hành Contiki bao gồm ngăn xếp truyền thông uIP,
RIME, các giao diện lập trình ứng dụng, module quản lý bộ nhớ, Contiki system,
các thư viện, các nền tảng phần cứng được hỗ trợ trên hệ điều hành Contiki.
Chương 4: Xây dựng chương trình với Contiki. Chương này trình bày cách
xây dựng chương trình ứng dụng và cách mô phỏng, thực thi chương trình trên
thiết bị thực.
Mặc dù đã hết sức cố gắng nhưng không thể tránh khỏi các thiếu sót. Mọi ý
kiến đóng góp

MỤC LỤC
2
LỜI NÓI ĐẦU 1
MỤC LỤC 2
Chương 1. TỔNG QUAN VỀ HỆ ĐIỀU HÀNH CHO MẠNG CÁC ĐỐI TƯỢNG
THÔNG MINH 4
Chương 2. HỆ ĐIỀU HÀNH CONTIKI 19
Chương 3. CÁC MODULE TRONG HỆ ĐIỀU HÀNH CONTIKI 37
Chương 4. XÂY DỰNG CHƯƠNG TRÌNH 38
ỨNG DỤNG VỚI CONTIKI 38
[edit] The COOJA Simulator 38
[edit] Getting started 38
[edit] Feature requests, bug reporting, and questions 41
Get started with the Cooja simulator 41
Example-Shell Guide 60
Simple Contiki Data Collection on the Tmote Sky 62

Setting up a Low-Power IPv6/RPL Network 72
REST-Example Guide 88
TÀI LIỆU THAM KHẢO 90
3
Chương 1. TỔNG QUAN VỀ HỆ ĐIỀU HÀNH CHO MẠNG CÁC
ĐỐI TƯỢNG THÔNG MINH
1.1. Giới thiệu về các đối tượng thông minh
Các đối tượng thông minh thường là các thiết bị đơn giản, nhỏ gọn, giá
thành thấp, sử dụng nguồn năng lượng hạn chế (pin), có thời gian hoạt động lâu
dài (vài tháng đến vài năm).
Một ví dụ điển hình về các đối tượng thông minh là các nút cảm biến
không dây. Trong đó các nút mạng thường là các thiết bị đơn giản, nhỏ gọn, giá
thành thấp… và có số lượng lớn được phân bố một cách không có hệ thống trên
phạm vi hoạt động rộng, sử dụng nguồn năng lượng hạn chế. Các nút mạng
thường có chức năng cảm nhận, quan sát môi trường xung quanh như nhiệt độ, độ
ẩm, ánh sáng… theo dõi hay định vị các mục tiêu cố định hoặc di động… Các nút
giao tiếp ad-hoc với nhau và truyền dữ liệu về trung tâm (base station) với cách
thức giao tiếp bằng kỹ thuật multi-hop.
Cấu trúc bên trong các đối tượng thông minh thường có một bộ vi điều
khiển chạy các phần mềm. Vi điều khiển là một bộ vi xử lý có bộ nhớ trong, bộ
định thời, và phần cứng cho việc kết nối các thiết bị bên ngoài khác. Vi điều khiển
trông giống như một vi mạch thông thường với một vỏ bọc bằng nhựa, các chân
kết nối bằng kim loại như trong hình 1.1.
4
Hình 1.1: Một bộ vi điều khiển Atmel ATTINY 2313 với 20 chân. Các bộ
ATTINY 2313 có 2kB của ROM và 128byte bộ nhớ RAM.
Do hạn chế về chi phí và năng lượng, các vi điều khiển được sử dụng trong
các đối tượng thông minh thường nhỏ hơn nhiều so các bộ vi xử lý được sử dụng
trong các máy tính cá nhân. Thông thường, một bộ vi điều khiển sử dụng trong nút
cảm biến có một vài KB bộ nhớ của chip và được chạy ở tốc độ xung nhịp một vài

MHz. Trong khi đó, máy tính hiện đại có đến hàng Gbytes bộ nhớ và chạy ở xung
nhịp một vài Ghz.
Vi điều khiển có hai loại bộ nhớ: Bộ nhớ chỉ đọc (ROM) và bộ nhớ truy
cập ngẫu nhiên (RAM). ROM được sử dụng để lưu trữ mã chương trình còn RAM
được sử dụng cho các dữ liệu tạm thời của chương trình phần mềm. Dữ liệu tạm
thời bao gồm việc lưu trữ các biến chương trình và bộ nhớ đệm để xử lý lưu lượng
vô tuyến. Nội dung của ROM được ghi vào thiết bị khi nó được sản xuất và
thường không bị thay đổi sau khi nút đã được triển khai. Tuy nhiên, vi điều khiển
hiện đại cung cấp một cơ chế để ghi lại ROM, mà nó rất có ích để cập nhật phần
mềm sau khi các nút đã được triển khai.
Ngoài bộ nhớ thì bộ vi điều khiển còn có bộ định thời và cơ chế tương tác
với các thiết bị bên ngoài như thiết bị truyền thông, cảm biến. Các bộ bộ định thời
có thể được sử dụng bởi các phần mềm chạy trên vi điều khiển. Các thiết bị bên
ngoài được kết nối vật lý với các chân của vi điều khiển. Các phần mềm giao tiếp
với các thiết bị sử dụng các cơ chế được cung cấp bởi vi điều khiển, thông thường
ở dạng một cổng nối tiếp hoặc các Bus nối tiếp. Hầu hết các bộ vi điều khiển cung
cấp bộ thu phát đồng bộ/không đồng bộ chung (USART) để giao tiếp với các cổng
5
nối tiếp. Một số USART có thể được cấu hình để làm việc như một giao diện bus
ngoại vi nối tiếp (SPI) để giao tiếp với cảm biến.
Ngày nay, Pin là nguồn năng lượng phổ biến nhất cho các đối tượng thông
minh. Chúng có nhiều hình dạng và kiểu dáng. Các Pin Lithium hiện nay là phổ
biến nhất. Với việc quản lý năng lượng thích hợp, một đối tượng thông minh có
thể có tuổi đời hàng năm trên tiêu chuẩn tế bào pin lithium.
Mọi hoạt động của một đối tượng thông minh được xác định bởi phần mềm
chạy trên bộ vi điều khiển. Các phần mềm thường được viết tương tự như phần
mềm cho các máy tính. Các chương trình được viết bằng một ngôn ngữ lập trình,
chẳng hạn như C, và được biên dịch với một trình biên dịch mã máy cho vi điều
khiển. Các mã máy được ghi vào ROM của vi điều khiển. Khi được bật nguồn, thì
bộ vi điều khiển sẽ chạy các phần mềm. Quá trình này được minh họa trong hình

1.2.
Mặc dù hoàn toàn có thể chạy chương trình cho vi điều khiển mà không
cần sử dụng một hệ điều hành nào, nhưng hầu hết các đối tượng thông minh sử
dụng hệ điều hành. Bởi vì các hạn chế về tài nguyên nên các hệ điều hành cho
chúng rất khác với các hệ điều hành cho máy tính. Các hệ điều hành cho các đối
tượng thông minh nhỏ gọn hơn nhiều và tiêu tốn ít tài nguyên.
Hình 1.2: Quá trình phát triển phần mềm cho đối tượng thông minh.
Mã nguồn được được biên dịch thành mã máy mà được ghi
vào ROM trong bộ vi điều khiển.
6
1.2. Hệ điều hành nhúng cho các đối tượng thông minh
1.2.1. Chức năng của hệ điều hành
Một mạng các đối tượng thông minh điển hình bao gồm một số lượng lớn
các nút với kích thước nhỏ, nguồn năng lượng pin hạn chế, một bộ xử lý, và khả
năng truyền thông.
Mặc dù phần cứng của các đối tượng thông minh đơn giản nhưng các ứng
dụng mạng của các đối tượng thông minh bao gồm nhiều ứng dụng khác nhau và
theo nhu cầu. Việc hỗ trợ cơ sở hạ tầng cho các ứng dụng trên hệ điều hành ngày
càng trở nên quan trọng. Bản chất, hệ điều hành là cầu nối giữa phần cứng đơn
giản với phần ứng dụng phức tạp.
Các chức năng cơ bản của hệ điều hành bao gồm việc trừu tượng hóa tài
nguyên cho các thiết bị phần cứng khác nhau, quản lý ngắt và lập lịch các nhiệm
vụ, điều khiển đồng thời, và hỗ trợ mạng. Dựa trên các dịch vụ được cung cấp bởi
hệ điều hành, những người lập trình ứng dụng có thể thuận tiện sử dụng các giao
diện lập trình ứng dụng mức cao (APIs) độc lập với phần cứng lớp dưới. Bởi vì
hầu hết các thiết bị có tài nguyên hạn chế do vậy một hệ điều hành không nên chỉ
cung cấp các dịch vụ đa dạng để thuận lợi cho việc lập trình các ứng dụng mà còn
tận dụng tài nguyên một cách tối ưu.
1.2.2. Những thách thức ảnh hưởng đến việc thiết kế hệ điều hành
Hiện tại, việc nghiên cứu và phát triển hệ điều hành cho các đối tượng

thông minh đang gặp phải một số thách thức cần phải giải quyết. Những thách
thức chính là các ràng buộc về tài nguyên của phần cứng và các yêu cầu của ứng
dụng. Những thách thức chính ảnh hưởng đến việc thiết kế hệ điều hành được
quan tâm nhất đó là:
• Kích thước nhỏ: Với bộ nhớ bị giới hạn chỉ vài KB nên đòi hỏi hệ điều
hành phải được thiết kế với kích thước rất nhỏ. Đây là đặc điểm cơ bản của
hệ điều hành cho các đối tượng thông minh và đó cũng là lý do chính mà
tại sao nhiều hệ điều hành nhúng tinh vi (như uC/OS, VxWorks) không thể
dễ dàng cài đặt được trên các thiết bị này.
• Hiệu quả năng lượng: Các đối tượng thông minh thường hoạt động bằng
pin do vậy vấn đề năng lượng cũng cần phải quan tâm.
• Đảm bảo thời gian thực: Nhiều ứng dụng của các đối tượng thông minh
ví dụ như là ứng dụng giám sát thường có khuynh hướng nhạy cảm với thời
7
gian. Với các ứng dụng đó, các gói tin cần được chuyển tiếp và gửi đi một
cách kịp thời, vấn đề đảm bảo thời gian thực là yêu cầu để đáp ứng cho các
ứng dụng đó.
• Khả năng cấu hình lại: Là điều cần thiết với các hệ thống mạng tài
nguyên hạn chế có thể được lập trình lại sau khi mạng được triển khai. Khả
năng cấu hình lại hệ thống là một đặc điểm cần thiết của hệ điều hành làm
cho mạng có thể lập trình lại dễ dàng và hiệu quả.
• Sự tiện lợi cho lập trình: Các ứng dụng của mạng các đối tượng thông
minh là khác nhau và tùy theo yêu cầu. Do vậy, sự tiện lợi cho lập trình là
một điều quan trọng nhất để rút ngắn thời gian triển khai các ứng dụng.
Thường thì rất khó để đạt được sự tối ưu trong tất cả các vấn đề nêu ra ở
trên. Hầu hết các giải pháp hiện tại được áp dụng cho các kịch bản ứng dụng cụ
thể và tạo ra những thỏa hiệp nhằm giải quyết các thách thức thiết kế ở trên.
1.2.3. Các thành phần cơ bản của một hệ điều hành
Các thành phần chính cấu thành nên hệ điều hành cho các đối tượng thông
minh được liệt kê dưới đây:

• Lập lịch nhiệm vụ: Thành phần lập lịch nhiệm vụ cung cấp cho người lập
trình ứng dụng môi trường nhiệm vụ cho việc thực thi đoạn mã ứng dụng.
Hiện tại, có ba cơ chế lập lịch nhiệm vụ là: Lập lịch nhiệm vụ điều khiển
theo sự kiện (event-driven), lập lịch nhiệm vụ đa luồng (multi-threaded) và
lập lịch nhiệm vụ Prototheads.
• Nạp và liên kết động: Thành phần nạp và liên kết động cho phép các phần
ứng dụng được nạp hoàn toàn động và cải thiện khả năng tự cấu hình hệ
điều hành khi lập trình lại mạng. Khi phần ứng dụng được nạp, trình liên
kết và nạp định vị không gian nhớ cho phần mã và dữ liệu của ứng dụng,
liên kết các ký hiệu tới các địa chỉ vật lý của chúng, và sao chép phần được
liên kết tới không gian bộ nhớ dành riêng. Cơ chế này rất hữu ích khi lập
trình lại một ứng dụng trên các nút mạng: Không phải truyền bá cả một
khối hình ảnh nhân ứng dụng, mà nó chỉ yêu cầu truyền bá phần ứng dụng
phổ biến nhỏ hơn nhiều do vậy hiệu quả hơn về năng lượng.
• Quản lý bộ nhớ: Bộ nhớ trong các thiết bị có thể được phân loại gồm:
RAM (cho việc lưu trữ dữ liệu nhanh), bộ nhớ trong (cho việc lưu trữ mã),
EEPROM (cho lưu trữ dữ liệu), và bộ nhớ ngoài (cho việc lưu trữ dữ liệu).
8
Ví dụ như, với MicaZ có 4KB RAM, 128KB bộ nhớ trong, 4KB EEPROM,
và 512KB bộ nhớ ngoài. Bộ nhớ RAM là quan trọng cho việc truy nhập dữ
liệu nhanh trong khi bộ nhớ bên ngoài là quan trọng cho lưu trữ dữ liệu.
Việc quản lý bộ nhớ RAM cũng có thể là tĩnh hoặc động. Việc quản lý bộ
nhớ ngoài có thể cung cấp sự trừu tượng mức cao chẳng hạn như tệp (ví dụ
với hệ điều hành LiteOS) hoặc những trừu tượng mức thấp như khối (ví dụ
với hệ điều hành TinyOS).
• Trừu tượng hóa tài nguyên: Thành phần trừu tượng hóa tài nguyên cung
cấp giao tiếp truy nhập mức cao và an toàn với các thiết bị phần cứng. Ví
dụ như, trừu tượng hóa tài nguyên trong TinyOS được phân loại thành
những trừu tượng hóa tài nguyên dành riêng, những trừu tượng hóa tài
nguyên ảo, và những trừu tượng hóa tài nguyên chia sẻ. Tài nguyên dành

riêng hỗ trợ cho một người dùng duy nhất. Tài nguyên ảo hỗ trợ nhiều
người dùng bằng việc duy trì hàng đợi và lập lịch cho nhiều yêu cầu đồng
thời theo kiểu tuần tự. Tài nguyên chia sẻ cũng hỗ trợ nhiều người dùng,
nhưng các người dùng phải cạnh tranh các trình điều khiển thông qua một
khóa.
• Các giao diện cảm biến: Các giao diện cảm biến cung cấp cho người lập
trình ứng dụng cách thức truy cập để đọc dữ liệu cảm biến một cách dễ
dàng và theo dạng chuẩn. Những mô tả chi tiết mức thấp được gắn với
những cấu hình cảm biến cũng được trừu tượng hóa với những người lập
trình ứng dụng.
• Ngăn xếp mạng: Ngăn xếp mạng thuận tiện cho việc phát triển các ứng
dụng WSN phân tán. Nó cũng cần thiết cho việc duy trì hệ thống từ xa sau
khi WSN được triển khai. Ngăn xếp mạng cho hệ điều hành nên hỗ trợ các
dịch vụ mức cao chẳng hạn như việc thu thập và truyền dữ liệu. Nó cũng
quản lý các chi tiết mức thấp như cấu hình chip thu phát vô tuyến, điều
khiển truy nhập đường truyền (MAC), và quản lý hàng đợi.
1.2.4. Khảo sát một số hệ điều hành
Mục này của báo cáo sẽ mô tả các hệ điều hành tiên tiến hiện nay. Cần phải
chú ý rằng, hầu hết các hệ điều hành vẫn đang được phát triển, do vậy mục này chỉ
mô tả những đặc điểm chính trong các phiên bản hiện tại của các hệ điều hành
này.
1.2.4.1. TinyOS
9
Hệ điều hành TinyOS được phát triển ở UC Berkeley, có lẽ là hệ điều hành
nhúng cho các đối tượng thông minh sớm nhất. Nó cho phép một kiến trúc mềm
dẻo và tiêu thụ tài nguyên thấp, việc lập trình trên TinyOS dựa trên các thành phần
được kết nối với nhau để tạo một ứng dụng ở thời điểm thiết kế. Những tương tác
giữa các thành phần xảy ra theo hai chiều, tức là một thành phần sử dụng lệnh
được cung cấp bởi một thành phần khác; ngoài ra, một thành phần có thể báo hiệu
các sự kiện tới một thành phần khác. Mô hình thực thi của TinyOS bao gồm các

ngắt (interrupt) và các nhiệm vụ (task). Các ngắt được thực thi ở mức ưu tiên cao
hơn và có thể được ưu tiên thực thi trước các nhiệm vụ. Các nhiệm vụ được thực
thi ở mức ưu tiên thấp hơn và được lập lịch theo kiểu vào trước ra trước FIFO
(First In First Out). Các nhiệm vụ trong TinyOS được viết theo kiểu run-to-
completion (chạy đến khi hoàn thành), và chúng không thể giành được quyền ưu
tiên trước (preempt) hoặc tạm ngưng (suspend). Vì lý do này, việc xuất nhập
(I/Os) được chia thành các giai đoạn. Tức là một yêu cầu (request) được thực hiện
vào lúc kết thúc một nhiệm vụ trong khi tín hiệu (signal) gọi đến sự bắt đầu của
nhiệm vụ tiếp theo. Để hỗ trợ tốt hơn cho kiến trúc thành phần và mô hình thực thi
của TinyOS thì ngôn ngữ nesC được thiết kế cho việc lập trình dựa trên TinyOS.
Phiên bản 2 của TinyOS (T2) cải tiến sa với phiên bản 1 ở một số mặt. T2
cũng cấp sự trừa tượng lồng nhau, nó là sự lai ghép sự phân chia theo phương
ngang (cho mức thấp hơn để hỗ trợ nhiều loại thiết bị phần cứng khác nhau), và sự
phân chia theo phương đứng (cho mức cao hơn để hỗ trợ chức năng nền tảng phần
cứng độc lập), và làm cho nó dễ dàng hỗ trợ các nền tảng phần cứng mới. Bên
cạnh những cải tiến kiến trúc, có một số cải tiến quan trọng trong sự thực thi, bao
gồm hỗ trợ cả luồng (ví dụ TinyThreads, và TOSThreads trong TinyOS phiên bản
2.1), hỗ trợ bảo vệ bộ nhớ. Hơn nữa, T2 cung cấp dịch vụ phân tán và cung cấp
một nhóm các thành phần (ví dụ các dịch vụ) để cải thiện độ tin cậy của hệ thống.
Bên cạnh những cải tiến kiến trúc, có một số cải tiến quan trọng trong sự thực thi,
bao gồm hỗ trợ cả luồng (ví dụ TinyThreads, và TOSThreads trong TinyOS phiên
bản 2.1), hỗ trợ bảo vệ bộ nhớ.
1.2.4.2. Contiki
Các thành phần trong TinyOS được kết nối hoàn toàn tĩnh để tạo một ứng
dụng hay một nhân đơn duy nhất. Cách tiếp cận này có thể tối ưu việc tiêu thụ tài
10
nguyên nhưng cũng rất phức tạp để tự động cấu hình lại hay cập nhật các ứng
dụng. Để giải quyết vấn đề này, Viện khoa học máy tính Thụy Điển đã nghiên cứu
và phát triển hệ điều hành Contiki. Contiki hỗ trợ các thành phần có thể nạp tự
động. Để giải quyết những khó khăn trong kiểu lập trình dựa trên sự kiện (ví dụ

trong TinyOS), Contiki hỗ trợ hoạt động đa luồng (tức là sự chuyển đổi tình
huống ở những thời điểm được xác định bởi người dùng) thông qua các thư viện
người dùng. Contiki cũng hỗ trợ cơ chế luồng nhỏ protothreads. Phiên bản mới
nhất của Contiki thực thi một tệp hệ thống trong bộ nhớ ROM gọi là Coffee và
kiến trúc Chameleon cho ngăn xếp vô tuyến năng lượng thấp Rime.
1.2.4.3. SOS
Hệ điều hành SOS được phát triển ở Đại học California, Los Angeles, cũng
hỗ trợ các module có thể tự động nạp. Nó sử dụng kiến trúc dựa trên module. Có
một điều lưu ý là có sự khác nhau giữa các thành phần trong TinyOS và các
modules trong SOS. Các thành phần trong TinyOS chỉ có thể nhìn thấy từ góc
nhìn của những người lập trình và chúng không thấy khi được biên dịch thành
đoạn mã nhị phân. Mặt khác, các modules trong SOS vẫn còn các thông tin mã nhị
phân (ví dụ như điểm bắt đầu của một module, các hàm của một module) sau khi
biên dịch, cho phép các modules được nạp hoặc nạp lại tự động. Để hỗ trợ kiến
trúc này, SOS cũng hỗ trợ việc định vị bộ nhớ động.
Mô hình thực thi SOS phức tạp hơn không nhiều so với TinyOS. Các trình
xử lý bản tin SOS (giống như các các tasks trong TinyOS) được giải quyết theo ba
mức ưu tiên. Phiên bản mới nhất của SOS là phiên bản 2.0.1, cải tiến hơn so với
phiên bản cũ ở một số điểm, bao gồm sự hỗ trợ nhiều nền phần cứng và hỗ trợ
việc bảo vệ bộ nhớ. Tuy nhiên, kể từ 24/11/2008, SOS không được phát triển bởi
vì các thành viên phát triển chính đã tốt nghiệp.
1.2.4.4. MantisOS
Mantis OS được phát triển ở đại học Colorado. Mantis OS cho phép hỗ trợ
đa luồng thực hiện đa luồng phân chia theo thời gian ưu tiên. Để cho phép lập
trình đa luồng, nhân Mantis cũng hỗ trợ đồng bộ I/Os (ngược với chia giai đoạn
I/Os), và một tập các bộ điều khiển đồng thời Semaphores. Phiên bản Mantis mới
nhất cải thiện sự ổn định của hệ thống và sửa một số lỗi. Ngoài ra, nó thực hiện
11
giao thức CTP (Collection Tree Protocol) cho các nền phần cứng MicaZ và
TelosB.

1.2.4.5. Nano-RK
Hỗ trợ các ứng dụng mạng không dây nhạy cảm với thời gian như giám sát
môi trường và giám sát an ninh. Nano-RK được phát triển ở Đại học Carnegie
Mellon, thực hiện hệ điều hành thời gian thực. Nano-RK hỗ trợ quyền ưu tiên đa
nhiệm đảm bảo các nhiệm vụ được đáp ứng đúng thời hạn. Nó cũng hỗ trợ việc
giành trước độ rộng dải tần mạng và CPU, tức là các nhiệm vụ có thể chỉ định các
yêu cầu tài nguyên của chúng và hệ điều hành cung cấp băng thông mạng và việc
truy cập các chu kỳ CPU kịp thời, đảm bảo và được kiểm soát. Để thuận tiện cho
việc lập trình, Nano-RK cung cấp các APIs cho các trừu tượng hóa giống như
socket, và hệ thống chung hỗ trợ định tuyến và lập lịch mạng.
1.2.4.6. RETOS
RETOS được phát triển ở Đại học Yonsei Hàn Quốc, được thiết kế để cải
tiến một số điểm ở các công việc trước. Nó cải tiến khả năng phục hồi hệ thống
bởi việc hỗ trợ chế độ vận hành kép (tức là chế độ hạt nhân và chế độ người dùng)
cũng như việc kiểm tra mã ứng dụng ở thời điểm thiết kế và thời điểm chạy.
Nó tối ưu sự thực thi đa luồng và hỗ trợ việc lập lịch thời gian thực POSIX
1003.1b. Nó cũng hỗ trợ khả năng nạp các modules và các dịch vụ mạng đa
chặng. Phiên bản mới nhất của RETOS hỗ trợ nhiều nền phần cứng khác nhau, tối
ưu hóa lớp mạng và cải thiện sự an toàn hệ thống.
1.2.4.7. LiteOS
LiteOS được phát triển ở Đại học Illinois tại Urbana Champaign, được thiết
kế để cung cấp môi trường lập trình ứng dụng cho mạng không dây giống như
UNIX truyền thống. Nó bao gồm: Hệ thống file phân cấp và wireless shell cho sự
tương tác với người dùng sử dụng các lệnh giống Unix; Hỗ trợ các hạt nhân cho
việc thực thi nạp tự động các ứng dụng đa luồng; Ngôn ngữ lập trình hướng đối
tượng được sử dụng một tập con của ngôn ngữ C++. Phiên bản mới nhất của
LiteOS có sự hỗ trợ một số nền tảng phần cứng IRIS của Crossbow. Hơn nữa, nó
hỗ trợ cơ chế Virtual Battery và hệ thống gỡ rối từ xa (Declarative Tracepoints).
12
1.2.5. Tiêu chí phân loại hệ điều hành

Mục này trình bày sự phân loại các hệ điều hành dựa trên việc khảo sát một
số đặc điểm hệ điều hành quan trọng.
• Tĩnh hay động: Trong các hệ thống tĩnh (ví dụ như TinyOS, Nano-PR),
người lập trình ứng dụng phải định vị tất cả các tài nguyên ở thời điểm thiết
kế. Mặt khác, trong các hệ thống động (ví dụ như SOS, Contiki, Mantis,
RETOS, LiteOS), những người lập trình ứng dụng có thể định vị và định vị
lại các tài nguyên ở thời điểm chạy ứng dụng. Các hệ thống động mềm dẻo
hơn và do vậy phù hợp cho những môi trường thay đổi thường xuyên. Tuy
nhiên, chúng không tin cậy ví dụ như một ứng dụng lỗi có thể dễ dàng
giành được quá nhiều tài nguyên (ở thời gian chạy ứng dụng), là nguyên
nhân làm cho toàn bô hệ thống bị sụp đổ.
• Hướng sự kiện hay đa luồng: Trong các hệ thống hướng sự kiện (ví dụ
như TinyOS, SOS), người lập trình ứng dụng cần phải duy trì trạng thái
ứng dụng và sử dụng chia giai đoạn I/Os. Mặt khác, các hệ thống đa luồng
(ví dụ như Mantis, Nano-RK, RETOS), người lập trình ứng dụng có thể sử
dụng cách lập trình như các luồng truyền thống. Do vậy, các hệ thống đa
luồng ngày càng quen thuộc với hầu hết những người lập trình và được
xem như là thân thiện với người dùng hơn các hệ thống hướng sự kiện. Có
một lượng lớn các dự án tập trung cải tiến hệ thống hướng sự kiện bằng
việc cung cấp thêm sự hỗ trợ đa luồng. Ví dụ như TinyThread,
TOSThreads là các thư viện luồng dựa trên TinyOS. Contiki hỗ trợ đa
luồng ưu tiên thông qua một thư viện trên hạt nhân hướng sự kiện, và nó
cũng thực thi một cơ chế luồng con được gọi là protothreads. Các hệ thống
hướng sự kiện cũng rất hữu dụng bởi vì: Chúng phù hợp cho các ứng dụng
phản ứng nhanh và điều quan trọng hơn là yêu cầu tài nguyên ít và phù hợp
cho các thiết bị hạn chế về tài nguyên. Do vậy, một số hệ thống đa luồng
cũng vẫn hỗ trợ sự kiện ví dụ như LiteOS cung cấp sự hỗ trợ Events thông
qua các hàm Callback.
• Đơn khối hay module hóa: Một ứng dụng có thể được biên dịch với hệ
điều hành như một khối chương trình (ví dụ TinyOS) hoặc có thể được biên

13
dịch thành các phần chương trình riêng lẻ mà chúng có thể được nạp bởi
nhân hệ điều hành (ví dụ như Contiki, SOS, RETOS). Cách tiếp cận đơn
khối có khả năng phân tích và tối ưu hóa chương trình đầy đủ, và thích hợp
khi ứng dụng ít cần chỉnh sửa. Cách tiếp moudle hóa được quan tâm khi
từng ứng dụng riêng lẻ cần chỉnh sửa đều đặn thông qua việc lập trình lại
mạng. Mặc dù, nó làm tăng thêm sự phức tạp cho hệ điều hành bởi việc hỗ
trợ liên kết và nạp, nhưng nó giảm đáng kể chi phí khi lập trình lại mạng.
• Hỗ trợ mạng: Với nhiều hệ điều hành, TCP/IP là một tiêu chuẩn. Hầu hết
các hệ điều hành mạng các đối tượng thông minh cung cấp việc truyền
thông đơn bước phía trên mạng đa chặng. Ví dụ bao như TinyOS, SOS,
Mantis. TinyOS sử dụng ngăn xếp truyền thông dựa trên việc sử dụng bản
tin AM (Active Message) . Ngoài dữ liệu, mỗi AM cũng chứa AM ID được
sử dụng cho nút đích để gửi đi các AM tới bộ xử lý tương ứng của nó khi
đến đích. Có một điều chú ý rằng một số giao thức mạng lớp cao hơn được
thực thi trên lớp AM này, bao gồm cả các giao thức truyền tin trong mạng
và các giao thức thu thập. Một số hệ điều hành mạng hỗ trợ trực tiếp mạng
multi-hop. Ví dụ như Contiki, Nano-RK, RETOS. Contiki chứa hai ngăn
xếp truyền thông là uIP và Rime. uIP là ngăn xếp TCP/IP tương thích với
RFC, giúp cho hệ điều hành Contiki có thể truyền thông qua Internet. Gần
đây, Contiki còn thực hiện thêm uIPv6 hỗ trợ IPv6. Rime là ngăn xếp
truyền thông đơn giản được thiết kế cho truyền thông vô tuyến năng lượng
thấp. Rime hỗ trợ nhiều giao thức truyền thông nguyên thủy, từ quảng bá
vùng cục bộ best-effort, đến ngập lụt dữ liệu multi-hop. LiteOS bổ sung sự
hỗ trợ cho việc truyền các file giữa các nút mạng, sử dụng các lệnh Shell
giống như Unix truyền thống chẳng hạn như cp, mv.
• Hỗ trợ thời gian thực: Việc hỗ trợ thời gian thực cho các hệ điều hành có
thể xảy ra ở cấp độ nút ở đó hệ điều hành nên thực hiện việc lập lịch các
nhiệm vụ ưu tiên để đảm bảo việc hỗ trợ thời gian thực hiệu quả của một
nút. Nano-RK là một hệ điều hành thời gian thực hỗ trợ quyền ưu tiên và

kịp thời thông qua việc phân tích việc lập lịch off-line. RETOS hỗ trợ giao
diện lập lịch thời gian thực 1003.1b để đồng thời cho phép gán mức ưu tiên
của người lập trình và quản lý ưu tiên động của hạt nhân hệ điều hành.
14
• Hỗ trợ ngôn ngữ: Hầu hết các hệ điều hành sử dụng ngôn ngữ C cho cả
việc phát triển hệ điều hành và phát triển ứng dụng (ví dụ như Contiki,
SOS, Mantis, RETOS). Bởi vì ngôn ngữ C là hiệu quả, thuận tiện và là
ngôn ngữ chính cho việc phát triển các hệ thống nhúng. Tuy nhiên, ngôn
ngữ C cũng có một số điểm hạn chế: Một mặt, nó không chuyên sâu trong
việc kiểm tra ngữ nghĩa, tối ưu hóa, và tùy chỉnh hạt nhân; mặt khác nó ít
thân thiện với người dùng so với các ngôn ngữ hướng đối tượng chẳng hạn
như C++, Java. Ngôn ngữ nesC, và LiteC++ trình bày hai giải pháp để giải
quyết hai vấn đề được đề cập ở trên. Ngôn ngữ nesC tích hợp với mô hình
thực thi trong TinyOS và áp dụng mô hình lập trình dựa trên thành phần. Vì
nó có thể thực hiện kiểm tra tĩnh, tối ưu và phân tích toàn bộ chương trình,
nên sinh ra toàn bộ hình ảnh hạt nhân ứng dụng với kích thước rất nhỏ. Tuy
nhiên, ngôn ngữ nesC có một số điểm riêng, nó buộc những người lập trình
phải tìm hiểu thêm. Ngôn ngữ LiteC++ được thiết kế cho LiteOS để phát
triển ứng dụng. Nó bổ sung những đặc điểm cả ngôn ngữ hướng đối tượng
hiện đại. Do vậy, nó gần gũi với ngưới lập trình và thân thiện với người
dùng hơn cả với ngôn ngữ C và nesC.
• Các tập tin hệ thống: Một đối tượng thông minh có khả năng lưu trữ hạn
chế, ví dụ như MicaZ chỉ có 4KB EEPROM và 512 KB bộ nhớ ngoài. Do
vậy, các tệp hệ thống phải có chi phí tài nguyên thực hiện rất nhỏ. Cả
Matchbox và ELF đều được thực thi dựa trên phiên bản thứ nhất trong
TinyOS. Chúng cung cấp sự tổ chức tệp cấp riêng lẻ và những trừu tượng
cơ bản cho sự hoạt động của tệp chẳng hạn như ghi và đọc. LiteOS cải tiến
hơn so với các hệ điều hành trước bằng việc hỗ trợ tổ chức tệp phân cấp và
có nhiều hơn các APIs để thao tác với tệp. Gần đây, Contiki đưa ra hệ
thống tệp dựa trên bộ nhớ flash (Coffee) cho việc lưu trữ dữ liệu trong

mạng các đối tượng thông minh. Hệ thống tệp cho phép nhiều tệp trên cùng
một bộ nhớ vật lý và có hiệu suất gần giống với thông lượng truyền dữ liệu
thô của bộ nhớ.
• Việc lập trình lại không dây: Việc lập trình lại mới được nghiên cứu
trong những năm gần đây. Thông thường, các ứng dụng được lập trình trên
15
các thiết bị thông qua kết nối có dây. Với việc hỗ trợ lập trình lại thì những
người phát triển hệ thống có thể cài đặt hay cập nhật ứng dụng mới cho
mạng hoàn toàn không dây. Deluge là một chuẩn cơ chế lập trình lại cho
TinyOS. Bởi vì nguyên lý thiết kế tĩnh của TinyOS nên các ứng dụng được
cài đặt với hạt nhân hệ điều hành như là một hình ảnh đầy đủ. Cách tiếp
cận này phải chịu chi phí tài nguyên lớn bởi vì bao gồm cả chi phí hạt
nhân. Để giải quyết vấn đề này, FlexCup hỗ trợ việc liên kết và nạp động
các thành phần nhị phân, do vậy cho phép cập nhật mã trên mỗi phần cơ
bản. Cơ chế nạp và liên kết động được hỗ trợ bởi SOS, Contiki, RETOS, và
LiteOS.
1.2.6. Một số vấn đề cần tiếp tục nghiên cứu
Việc hỗ trợ hệ điều hành là quan trọng để thuận lợi cho việc triển khai và
bảo trì mạng các đối tượng thông minh. Với sự hỗ trợ mạnh từ các hệ điều hành,
chúng ta có thể hình dung được rằng việc phát triển ứng dụng sẽ vô cùng đơn
giản. Dưới đây sẽ là một số hướng nghiên cứu phát triển hệ điều hành trong tương
lai.
1.2.6.1. Hỗ trợ các ứng dụng thời gian thực
Có nhiều lĩnh vực ứng dụng thời gian thực cho mạng các đối tượng thông
minh, ví dụng như trong tự động hóa công nghiệp, giám sát quá trình hóa học, xử
lý và truyền dẫn dữ liệu đa phương tiện. Trong một vài hệ điều hành, các bộ lập
lịch được thiết kế để hỗ trợ các phần mềm cũng như đối với hoạt động phần cứng
thời gian thực. Trong tương lai, đòi hỏi các thuật toán lập lịch có thể thích ứng cả
phần mềm và yêu cầu phần cứng thời gian thực của các ứng dụng.
1.2.6.2. Quản lý bộ nhớ thứ cấp

Thời gian qua, các lĩnh vực mới cho mạng các đối tượng thông minh đang
nổi lên và các ứng dụng yêu cầu nhiều bộ nhớ nhiều hơn nữa. Một cơ sở dữ liệu
đặc yêu cầu bộ nhớ lưu trữ thứ cấp đối với các đối tượng thông minh. Chỉ có một
vài hệ điều hành cung cấp một file hệ thống để quản lý lưu trữ thứ cấp. Nếu chúng
ta xem xét định luật Moore’s, trong tương lai không xa, chúng ta có thể hi vọng sẽ
có các đối tượng thông minh sẽ có bộ nhớ lưu trữ thứ cấp lớn hơn. Do đó những
16
nỗ lực nghiên cứu cần thực hiện để xây dựng được một hệ thống tập tin có khả
năng mở rộng (phân tán) cho mạng các đối tượng thông minh.
1.2.6.3. Hỗ trợ bộ nhớ ảo
Một đối tượng thông minh có bộ nhớ RAM bị giới hạn và các ứng dụng
yêu cầu nhiều RAM hơn nữa. Do đó, trong tương lai chúng ta cần giới thiệu các
khái niệm về bộ nhớ ảo trong các hệ điều hành cho các đối tượng thông minh.
Chúng ta cần phát minh các công nghệ quản lý bộ nhớ ảo để sử dụng năng lượng
và bộ nhớ hiệu quả.
1.2.6.4. Hỗ trợ nhiều ứng dụng
Hệ điều hành cho các đối tượng thông minh đã được phát triển với giả định
rằng chỉ có một ứng dụng sẽ chạy trên thiết bị. Nhưng đối với sự xuất hiện của các
lĩnh vực ứng dụng mới đã và đang đặt ra nhiều thách thức. Chúng ta xem xét
trường hợp đối tượng thông minh là một nút cảm biến không dây đa phương tiện,
trong đó các nút cảm biến được trang bị với một bộ cảm biến giọng nói
(microphone), cảm biến hình ảnh như là máy ảnh, và cảm biến vô hướng (scalar
sensors). Do đó trên một node cảm biến duy nhất chúng ta có thể có một ứng
dụng nó sử dụng là bộ cảm biến hình ảnh. Tức là, quay video, áp dụng kỹ thuật xử
lý ảnh trên nó và gửi video nén tới trạm cơ sở. Tương tự như vậy, chúng ta có thể
có các ứng dụng khác mà chúng đang sử dụng bộ cảm biến tiếng nói và bộ cảm
biến vô hướng. Vì vậy, các hệ điều hành cần phải chứa nhiều ứng dụng cùng một
lúc.
1.2.6.5. Hỗ trợ ngăn xếp giao thức truyền thông
Nhiều hệ điều hành cho các đối tượng thông minh cung cấp một giao diện

lập trình ứng dụng API truyền thông để cho phép các ứng dụng gửi và nhận dữ
liệu. Mặt khác, nhưng API này sử dụng ngăn xếp giao thức truyền thông được
cung cấp bởi hệ điều hành. Không có thỏa thuận về một chồng giao thức thống
nhất cho các đối tượng thông minh, do đó hầu như mỗi hệ điều hành đều cung cấp
cho riêng mình cài đặt tùy chỉnh một ngăn xếp giao thức truyền thông. Kết quả là,
không thể truyền thông giữa hai thiết bị sử dụng hệ điều hành khác nhau. Trước
đây, Contiki đã cung cấp cài đặt của một ngăn xếp micro IPv6 cho mạng các đối
tượng thông minh. Điều này cho phép các thiết bị sử dụng địa chỉ IP và giao tiếp
17
với các thiết bị cho phép IP khác. Theo phương pháp tiếp cận Contiki, trong phiên
bản mới của TinyOS được cung cấp hỗ trợ cho IP để phù hợp với chuẩn
6LowPAN. Cung cấp một cài đặt giao thức ngăn xếp uIP cho phép hai thiết bị sử
dụng hệ điều hành khác nhau có thể giao tiếp với nhau.
1.2.6.6. Quản lý cơ sở dữ liệu hệ thống
Nhiệm vụ của một đối tượng thông minh ví dụ như một nút cảm biến
không dây là cảm nhận, thực hiện tính toán, truyền tải, và lưu trữ dữ liệu. Trong
một số mạng cảm biến, dữ liệu chỉ gửi tới trạm cơ sở trong đáp ứng của một truy
vấn, vì vậy một nút cảm biến phải có thể lưu trữ dữ liệu và hiểu được ngôn ngữ
truy vấn. Một nỗ lực nghiên cứu là cần thiết để thiết kế một hệ thống quản lý cơ
sở dữ liệu cho nút cảm biến phù hợp đối với các đặc trưng của chúng.
1.2.6.7. Hỗ trợ các giao diện lập trình ứng dụng APIs cho xử lý ảnh và tín
hiệu
Vì các lĩnh vực ứng dụng cho các đối tượng thông minh trong lĩnh vực xử
lý hình ảnh đang nổi lên, do vậy hệ điều hành cần phải cung cấp một tập hợp
phong phú các API xử lý tín hiệu để tạo điều kiện thuận lợi cho các nhiệm vụ của
nhà phát triển chương trình ứng dụng.
18
Chương 2. HỆ ĐIỀU HÀNH CONTIKI
2.1. Giới thiệu về hệ điều hành Contiki
Hệ điều hành Contiki là hệ điều hành mã nguồn mở, được nghiên cứu, thiết

kế và phát triển bởi một nhóm các nhà phát triển từ viện khoa học máy tính Thụy
Điển, người đứng đầu là Adam Dunkels. Nhóm phát triển Contiki gồm nhiều
thành viên đến từ SICS, CISCO, cùng nhiều tổ chức và các trường đại học khác
trên thế giới. Hệ điều hành Contiki được thiết kế cho các vi điều khiển có bộ nhớ
nhỏ, với thông số 2KB RAM và 40KB ROM. Nhờ đó, Contiki được sử dụng cho
các hệ thống nhúng và các ứng dụng trong mạng các đối tượng thông minh.
Contiki bắt đầu được nghiên cứu từ năm 2001 và phát hành phiên bản đầu tiên
Contiki 1.0 năm 2003. Hình 2.1 cho thấy lịch sử phát triển của Contiki trong
những năm qua. Phiên bản hiện nay của Contiki là 2.5, với nhiều thay đổi, bổ sung
và phát triển vượt bậc. Trong thực tế, Contiki đã được ứng dụng trong nhiều dự án
như giám sát đường hầm xe lửa, theo dõi nước trong biển Baltic,… Nhiều cơ chế,
ý tưởng trong Contiki đã được ứng dụng rộng rãi trong công nghiệp. Điển hình
như mô hình uIP được phát hành năm 2001 đã được sử dụng trong hệ thống ứng
dụng của hàng trăm công ty trong các lĩnh vực hàng hải, thông tin vệ tinh, khai
thác dầu mỏ,…; mô hình Protothreads được công bố lần đầu tiên năm 2005, đến
nay đã được sử dụng trong nhiều ứng dụng như bộ giải mã kỹ thuật số và đối
tượng thông minh nói chung vá mạng cảm biến không dây nói riêng.
19
Hình 2.1: Lịch sử phát triển Contiki.
Hệ điều hành Contiki được lập trình bằng ngôn ngữ C và có những đặc
điểm phù hợp với các đối tượng thông minh:
• Contiki được chia thành nhiều module hoạt động độc lập. Nhờ đó các ứng
dụng có thể sử dụng các module một cách linh động và chỉ nạp những
module cần thiết.
• Cơ chế hoạt động điều khiển sự kiện làm giảm năng lượng tiêu hao và hạn
chế dung lượng bộ nhớ cần sử dụng.
• Có thể sử dụng IP trong mạng thông qua uIP stack được xây dựng dựa trên
nền TCP/IP.
• Có những module cho phép ước lượng và quản lý năng lượng một cách
hiệu quả.

• Các giao thức tương tác giữa các lớp và các node trong mạng dễ dàng hơn.
• Sử dụng RIME stack phục vụ các giao thức dành cho mạng năng lượng
thấp một cách hiệu quả.
Bên cạnh đó, Contiki còn cung cấp những công cụ hỗ trợ mô phỏng với
giao diện đơn giản, dễ sử dụng và hỗ trợ tốt những thiết bị trong thực tế, phục vụ
những mục đích nghiên cứu, mô phỏng và triển khai những giao thức mới.
2.2. Cấu trúc hệ điều hành Contiki
Bất kỳ phiên bản Contiki nào cũng gồm 7 thư mục là: apps, core, cpu, docs,
example, platform và tools.
• Thư mục apps: Chứa các tập tin nguồn của các tiện ích phát triển cho Contiki.
Chúng có sẵn để sử dụng và bao gồm các thiết lập cơ bản của các ứng dụng
20
cho mạng các đối tượng thông minh . Ứng dụng tiêu biểu trong thư mục này là
trình duyệt web, máy chủ Web, FTP, email
• Thư mục Core: Như tên gọi cho thấy, nó chứa các hạt nhân của hệ điều hành
Contiki. Nó chứa khoảng 300 files, gần một nửa trong số đó là tập tin tiêu đề
chứa các khai báo và còn lại là các tập tin nguồn chứa cài đặt.
• Thư mục CPU: Chứa các bộ xử lý cụ thể cho việc thực hiện các chức năng
khác nhau được sử dụng trong hệ điều hành.
• Thư mục Docs: Được sử dụng trong việc chuẩn bị tài liệu cho Contiki. Nó
chứa thông tin sẽ được sử dụng bởi một hệ thống tài liệu điển hình như
Doxygen.
• Thư mục Examples: Chứa các chương trình ví dụ đơn giản bắt đầu với
“Hello-world”, như là bước đầu tiên hướng tới lập trình ứng dụng trên Contiki.
• Thư mục Platform: Bao gồm thông tin cụ thể liên quan đến nền tảng phần
cứng cho các nút cảm biến như ESB, Sky mote,…
• Thư mục Tools: Là thư mục chứa các công cụ phần mềm đặc biệt. Ví dụ như
'Cooja' là một chương trình Java để mô phỏng cho Contiki.Thư mục này cũng
chứa các công cụ cho các nền tảng phần cứng cụ thể. Ví dụ điển hình là các
công cụ cho nút cảm biến Tmote Sky của Sentilla.

2.3. Kiến trúc phân lớp hệ điều hành Contiki
Hệ điều hành Contiki theo kiểu kiến trúc module. Tại mức hạt nhân nó theo
mô hình điều khiển hướng sự kiện (event-driven), nhưng lại cung cấp các phương
tiện tùy chọn luồng tới các tiến trình riêng lẻ. Nhân Contiki bao gồm một bộ lập
lịch sự kiện làm nhiệm vụ gửi đi các sự kiện tới các tiến trình đang chạy. Các tiến
trình thực thi được kích hoạt bằng các sự kiện gửi đi bởi hạt nhân tới các tiến trình
hoặc bằng cơ chế hỏi vòng. Cơ chế hỏi vòng được sử dụng để tránh các điều kiện
tranh đua (race conditions). Bất kì sự kiện nào đã được lập lịch sẽ chạy cho đến
khi nó hoàn thành. Tuy nhiên, các trình xử lý sự kiện cũng có thể sử dụng các cơ
chế nội để ưu tiên.
Có hai loại sự kiện được hỗ trợ bởi hệ điều hành Contiki: Các sự kiện đồng
bộ và không đồng bộ. Sự khác nhau giữa hai loại sự kiện này đó là, sự kiện loại
đồng bộ được gửi đi ngay lập tức tới tiến trình đích bởi vì nó đã được lập lịch.
Còn đối với các sự kiện không đồng bộ thì chậm hơn, thủ tục gọi được xếp vào
hàng đợi và sau đó cũng được gửi đến tiến trình đích. Cơ chế hỏi vòng được sử
21
dụng trong Contiki có thể xem như là các sự kiện có ưu tiên cao nó đã được lập
lịch giữa mỗi sự kiện không đồng bộ. Khi một hỏi vòng đã được lập lịch thì tất cả
các tiến trình đó thực hiện một trình xử lý hỏi vòng được gọi là thứ tự ưu tiên của
chúng.
Tất cả các công cụ của hệ điều hành ví dụ như, bộ cảm biến xử lý dữ liệu,
truyền thông, và các trình điều khiển thiết bị được cung cấp dưới dạng các dịch
vụ. Mỗi dịch vụ có một giao diện và cài đặt của nó. Các ứng dụng sử dụng một
dịch vụ cụ thể cần hiểu được giao diện dịch vụ. Một ứng dụng không quan tâm
đến cài đặt của một dịch vụ. Hình 2.2 minh họa kiến trúc phân lớp của hệ điều
hành Contiki.
Hình 2.2: Kiến trúc hệ điều hành Contiki
2.4. Ngăn xếp truyền thông trong hệ điều hành Contiki
Contiki cơ bản gồm 2 stack truyền thông là uIP với TCP/UDP, IPV4, IPV6
giúp hệ điều hành truyền thông qua mạng Internet và Rime được thiết kế cho

những liên kết không dây năng lượng thấp, nó cung cấp một phạm vi rộng lớn các
truyền thông nguyên thủy từ những cách thức quảng bá nội vùng hiệu quả cao đến
flooding dữ liệu đáng tin cậy trên nhiều nút mạng.
22
Hình 2.3: Kiến trúc giao thức mạng trong hệ điều hành Contiki.
2.4.1. Ngăn xếp uIP
Trong những năm gần đây, cùng với sự thành công của Internet, giao thức
TCP/IP đã trở thành tiêu chuẩn toàn cầu trong lĩnh vực truyền thông, TCP/IP là
giao thức cơ bản được sử dụng cho những mục đích truyền tải các trang web, gửi
và nhận email, truyền dữ liệu…Các hệ thống nhúng sử dụng TCP/IP có khả năng
kết nối những hệ thống trực tiếp đến một mạng nội bộ, hoặc thậm chí là một mạng
toàn cầu.
Những thiết bị nhúng có khả năng đáp ứng được đầy đủ những đặc tính
củaTCP/IP sẽ là những thiết bị có tính ưu việt, có khả năng giao tiếp một cách đầy
đủ với tất cả các thiết bị khác trong mạng.
Tuy nhiên, sự triển khai giao thức TCP/IP truyền thống đòi hỏi quá nhiều
tài nguyên gồm cả dung lượng code và bộ nhớ sử dụng, không thể được đáp ứng
trong các hệ thống nhúng 8 hoặc 16 bit.
Xuất phát từ ý tưởng đó, uIP được thiết kế dựa trên ngôn ngữ C với mục
tiêu tối ưu hóa tuyệt đối các đặc tính cần thiết cho một stack TCP/IP đầy đủ. uIP
chỉ có thể hoạt động với một giao diện mạng duy nhất và bao gồm các giao thức :
IP, ICMP, UDP, TCP.
Một số hàm trong API – uIP
 Khởi tạo một kết nối : tcp_connect(), tcp_listen(), udp_new().
 Ngắt một kết nối : uip_close(), uip_abort().
 Gửi một gói kiểu TCP: uip_send().
 Gửi một gói kiểu UDP : uip_udp_packet_send().
23
 Nhận một gói từ mạng : uip_newdata(), uip_datalen().
 Gửi lại một gói dữ liệu : uip_rexmit().

 Mở và Kiểm tra cổng kết nối : uip_listen() – mở một cổng kết nối ;
 uip_connected()- kiểm tra kết nối.
2.4.2. Ngăn xếp RIME
Rime stack cung cấp một cấu trúc phân tầng của giao thức mạng cảm biến
không dây, từ một bộ phát quảng bá đơn giản tới việc định tuyến rắc rối trong toàn
mạng. Rime triển khai một giao thức phức tạp, với nhiều phần, mỗi phần lại gồm
những module phức tạp được tạo nên từ những module nhỏ lẻ đơn giản hơn. Dưới
đây là toàn thể tổ chức của giao thức Rime:
Hình 2.4: Tổ chức của RIME
• Abc: phát sóng quảng bá, nó chỉ gửi một gói tin qua các trình điều khiển vô
tuyến và nhận tất cả các gói tin từ các trình điều khiển vô tuyến khác.
• Broadcast: phát sóng xác định, nó thêm địa chỉ người gửi để gửi đi các gói
dữ liệu và chuyển nó vào module abc.
• Unicast: module này cho biết thêm một địa chỉ đích cho các gói tin được
truyền cho khối phát sóng. Ở bên nhận, nếu địa chỉ đích của gói tin không
phù hợp với địa chỉ của nút thì gói tin đó sẽ bị loại bỏ.
• Stunicast: là các unicast “cứng đầu “, khi được hỏi để gửi một gói tin đến một
nút, nó sẽ gửi nhiều lần với một khoảng thời gian nhất định cho đến khi yêu
cầu dừng lại.
24
• Runicast: là các unicast đáng tin cậy, nó sẽ gửi một gói tin bằng cách sử dụng
các stunicast chờ một gói tin xác nhận. Khi nhận được, nó dừng việc truyền tải
liên tục của các gói tin. Một số lượng tối đa các gói tin truyền lại phải được
xác định, để tránh gửi vô hạn.
• Polite và ipolite: hai module gần như giống hệt nhau, khi một gói tin đã được
gửi đi trong một khung thời gian nhất định, module chờ một nửa thời gian,
kiểm tra xem nó có nhận được gói tin nó định gửi hay không. Nếu trùng, gói
tin không được gửi đi, nếu không nó sẽ gửi gói tin. Điều này rất hữu ích cho
các kỹ thuật flooding để tránh việc truyền lại không cần thiết.
• Multihop: module này đòi hỏi chức năng bảng định tuyến, và khi định gửi một

gói tin, nó yêu cầu bảng định tuyến cho hop tiếp theo và gửi gói tin đến nó
bằng cách unicast. Khi nó nhận được một gói tin, nếu hop đó là đích, gói tin sẽ
được truyền tới các lớp trên, nếu không nó sẽ yêu cầu thông tin về hop tiếp
theo từ bảng định tuyến và chuyển tiếp các gói tin đến nó. Khi gửi gói, các ứng
dụng lưu gói vào bộ nhớ đệm và gọi các hàm xử lý liên quan để gửi gói đi. Khi
nhận được một gói, gói nhận được được lưu trong bộ đệm gói, đồng thời
RIME stack gọi các hàm “callback” tương ứng để xử lý gói đầu vào.
Hình 2.5: Quá trình truyền dữ liệu của RIME.
2.5. Kỹ thuật lập trình trên hệ điều hành Contiki
Contiki hoạt động dựa trên cơ chế điều khiển sự kiện. Các Process hay các
trình xử lý được gọi mỗi khi có một sự kiện xảy ra như các sự kiện về cảm biến,
trình khởi động, trình kết thúc,… Quá trình gọi các Process hoàn toàn không bị
ngăn chặn hay cản trở trong các chương trình. Process hoạt động dựa trên các
Protothread, tạo ra các luồng điều khiển liên tiếp theo cơ chế event -driven.
Protothread là sự kết hợp giữa hai cơ chế điều khiển: “Multithreads” – Lập trình
đa luồng và “event – driven” – Lập trình hướng sự kiện.
25