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

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âudà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ôngminh 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ôngminh 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âmtrong 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ànhkhá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ượngthô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óatà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ácnhiệm vụ, điều khiển đồng thời, và hỗ trợ mạng Dựa trên các dịch vụ được cungcấ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ụngcá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ềuthành viên đến từ SICS, CISCO, cùng nhiều tổ chức và các trường đại học kháctrê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ộngrã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ôngminh 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ổngquan 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ớ,

Chương 3: Các module trong hệ điều hành Contiki Chương này trình bàycá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áchxây dựng chương trình ứng dụng và cách mô phỏng, thực thi chương trình trênthiế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

LỜI NÓI ĐẦU 1

MỤC LỤC 3

Chương 1 TỔNG QUAN VỀ HỆ ĐIỀU HÀNH NHÚNG CHO MẠNG CÁC ĐỐI TƯỢNG THÔNG MINH 5

1.1 Giới thiệu về các đối tượng thông minh 5

1.2 Hệ điều hành nhúng cho các đối tượng thông minh 8

1.2.1 Chức năng của hệ điều hành 8

1.2.2 Những thách thức ảnh hưởng đến việc thiết kế hệ điều hành 8

1.2.3 Các thành phần cơ bản của một hệ điều hành 9

1.2.4 Khảo sát một số hệ điều hành 11

1.2.5 Tiêu chí phân loại hệ điều hành 14

1.2.6 Một số vấn đề cần tiếp tục nghiên cứu 17

Chương 2 HỆ ĐIỀU HÀNH CONTIKI 20

2.1 Giới thiệu về hệ điều hành Contiki 20

2.2 Cấu trúc hệ điều hành Contiki 22

2.3 Kiến trúc phân lớp hệ điều hành Contiki 23

2.4 Ngăn xếp truyền thông trong hệ điều hành Contiki 24

2.4.1 Ngăn xếp uIP 24

2.4.2 Ngăn xếp RIME 25

2.5 Kỹ thuật lập trình trên hệ điều hành Contiki 27

2.5.1 Lập trình Event-driven 27

2.5.2 Lập trình Multi-threaded 28

2.5.3 Lập trình Prothreads 28

2.5.4 So sánh ba mô hình lập trình trong Contiki 29

2.6 Hoạt động định thời trong Contiki 31

2.7 Quản lý bộ nhớ 33

2.8 Cài đặt và thực hành với Contiki 35

2.8.1 Cài đặt Instant-Contiki 35

2.8.2 Chương trình điều khiển LED trên Tmote Sky 38

Chương 3 CÁC MODULE TRONG HỆ ĐIỀU HÀNH CONTIKI 39

Chương 4 XÂY DỰNG CHƯƠNG TRÌNH 40

ỨNG DỤNG VỚI CONTIKI 40

4.1 Giới thiệu về công cụ mô phỏng Cooja 40

4.2 Hướng dẫn sử dụng Cooja 43

4.3 Các bước xây dựng ứng dụng đầu tiên 50

4.4 Ví dụ làm việc với Shell trong Contiki 62

4.5 Giao thức thu thập dữ liệu trên Contiki 64

4.6 Giao thức RPL trên Contiki 74

4.7 Giao thức CoAP trên Contiki 89

TÀI LIỆU THAM KHẢO 91

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âudà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ếnkhô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ênphạm vi hoạt động rộng, sử dụng nguồn năng lượng hạn chế Các nút mạngthườ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útgiao tiếp ad-hoc với nhau và truyền dữ liệu về trung tâm (base station) với cáchthứ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ềukhiể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ểntrô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ânkết nối bằng kim loại như trong hình 1.1

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 trongcác đối tượng thông minh thường nhỏ hơn nhiều so các bộ vi xử lý được sử dụngtrong 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útcả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 ở xungnhị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ớ truycậ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ạmthờ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ểnhiện đại cung cấp một cơ chế để ghi lại ROM, mà nó rất có ích để cập nhật phầnmề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ácvớ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ênngoà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ếpvớ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 cungcấp bộ thu phát đồng bộ/không đồng bộ chung (USART) để giao tiếp với các cổngnối tiếp Một số USART có thể được cấu hình để làm việc như một giao diện busngoạ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ôngminh 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ềmchạ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ầnmề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ềukhiể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ình1.2

Mặc dù hoàn toàn có thể chạy chương trình cho vi điều khiển mà khôngcầ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 chochú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 đốitượ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

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ớncá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 ứngdụ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àycà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 đơngiả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àinguyê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 giaodiệ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òntậ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ượngthô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áchthứ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 ứngdụng Những thách thức chính ảnh hưởng đến việc thiết kế hệ điều hành đượcquan 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ờigian Với các ứng dụng đó, các gói tin cần được chuyển tiếp và gửi đi mộtcá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àmcho 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ôngminh đượ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ểntheo 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ênkế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 đượcliê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ậptrì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ộtkhối hình ảnh nhân ứng dụng, mà nó chỉ yêu cầu truyền bá phần ứng dụngphổ 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)

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ànhnhững trừu tượng hóa tài nguyên dành riêng, những trừu tượng hóa tàinguyên ảo, và những trừu tượng hóa tài nguyên chia sẻ Tài nguyên dànhriêng hỗ trợ cho một người dùng duy nhất Tài nguyên ảo hỗ trợ nhiềungười dùng bằng việc duy trì hàng đợi và lập lịch cho nhiều yêu cầu đồngthờ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ộtkhó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ớinhữ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ậptrì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 saukhi WSN được triển khai Ngăn xếp mạng cho hệ điều hành nên hỗ trợ cácdịch vụ mức cao chẳng hạn như việc thu thập và truyền dữ liệu Nó cũngquản lý các chi tiết mức thấp như cấu hình chip thu phát vô tuyến, điềukhiển truy nhập đường truyền (MAC), và quản lý hàng đợi

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ủanhiệ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 thicủ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 T2cũng cấp sự trừa tượng lồng nhau, nó là sự lai ghép sự phân chia theo phươngngang (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ầncứ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êncạ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, baogồm hỗ trợ cả luồng (ví dụ TinyThreads, và TOSThreads trong TinyOS phiên bản2.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ấpmộ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ênbả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 ứngdụ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àinguyê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 ứngdụ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ìnhhuống ở những thời điểm được xác định bởi người dùng) thông qua các thư việnngười dùng Contiki cũng hỗ trợ cơ chế luồng nhỏ protothreads Phiên bản mớinhấ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

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 khibiên dịch, cho phép các modules được nạp hoặc nạp lại tự động Để hỗ trợ kiếntrú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 bamứ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ớiphiê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ậptrì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ớinhấ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ệngiao 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átmôi trường và giám sát an ninh Nano-RK được phát triển ở Đại học CarnegieMellon, thực hiện hệ điều hành thời gian thực Nano-RK hỗ trợ quyền ưu tiên đanhiệm đảm bảo các nhiệm vụ được đáp ứng đúng thời hạn Nó cũng hỗ trợ việcgià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ácyê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ệctruy cập các chu kỳ CPU kịp thời, đảm bảo và được kiểm soát Để thuận tiện choviệ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ảitiế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 POSIX1003.1b Nó cũng hỗ trợ khả năng nạp các modules và các dịch vụ mạng đachặ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 choviệ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 đốitượ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ủaLiteOS 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)

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ẻohơn và do vậy phù hợp cho những môi trường thay đổi thường xuyên Tuynhiên, chúng không tin cậy ví dụ như một ứng dụng lỗi có thể dễ dànggiành được quá nhiều tài nguyên (ở thời gian chạy ứng dụng), là nguyênnhâ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 đaluồng ngày càng quen thuộc với hầu hết những người lập trình và đượcxem 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ằngviệ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ợ đaluồ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ốnghướ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ụngphản ứng nhanh và điều quan trọng hơn là yêu cầu tài nguyên ít và phù hợpcho các thiết bị hạn chế về tài nguyên Do vậy, một số hệ thống đa luồngcũng vẫn hỗ trợ sự kiện ví dụ như LiteOS cung cấp sự hỗ trợ Events thôngqua 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êndịch thành các phần chương trình riêng lẻ mà chúng có thể được nạp bởinhân hệ điều hành (ví dụ như Contiki, SOS, RETOS) Cách tiếp cận đơnkhối có khả năng phân tích và tối ưu hóa chương trình đầy đủ, và thích hợpkhi ứng dụng ít cần chỉnh sửa Cách tiếp moudle hóa được quan tâm khitừ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ạimạ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ềnthô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ảntin 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 đượcthự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ạngmulti-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ớiRFC, 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ếptruyền thông đơn giản được thiết kế cho truyền thông vô tuyến năng lượngthấ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 Shellgiố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ácnhiệm vụ ưu tiên để đảm bảo việc hỗ trợ thời gian thực hiệu quả của mộtnú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ợ giaodiện lập lịch thời gian thực 1003.1b để đồng thời cho phép gán mức ưu tiêncủ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

 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ônngữ C cũng có một số điểm hạn chế: Một mặt, nó không chuyên sâu trongviệ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ó ítthâ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ạnnhư C++, Java Ngôn ngữ nesC, và LiteC++ trình bày hai giải pháp để giảiquyết hai vấn đề được đề cập ở trên Ngôn ngữ nesC tích hợp với mô hìnhthự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ỏ Tuynhiên, ngôn ngữ nesC có một số điểm riêng, nó buộc những người lập trìnhphải tìm hiểu thêm Ngôn ngữ LiteC++ được thiết kế cho LiteOS để pháttriển ứng dụng Nó bổ sung những đặc điểm cả ngôn ngữ hướng đối tượnghiệ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

 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 Dovậ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 trongTinyOS 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ếnhơ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 trongmạng các đối tượng thông minh Hệ thống tệp cho phép nhiều tệp trên cùngmộ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ệuthô 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êncá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ữngngười phát triển hệ thống có thể cài đặt hay cập nhật ứng dụng mới chomạng hoàn toàn không dây Deluge là một chuẩn cơ chế lập trình lại choTinyOS Bởi vì nguyên lý thiết kế tĩnh của TinyOS nên các ứng dụng đượccài đặt với hạt nhân hệ điều hành như là một hình ảnh đầy đủ Cách tiếpcậ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ạtnhân Để giải quyết vấn đề này, FlexCup hỗ trợ việc liên kết và nạp độngcá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 đơngiả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ươnglai

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ôngminh, 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ậplị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ứngthờ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 đangnổ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ộtvà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

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ụngyê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áckhá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ả địnhrằ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áclĩnh vực ứng dụng mới đã và đang đặt ra nhiều thách thức Chúng ta xem xéttrườ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 (scalarsensors) Do đó trên một node cảm biến duy nhất chúng ta có thể có một ứngdụ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ảmbiế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ộtlú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ệnlậ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 đượccung 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ốngnhất cho các đối tượng thông minh, do đó hầu như mỗi hệ điều hành đều cung cấpcho 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 đốitượ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ếpvới các thiết bị cho phép IP khác Theo phương pháp tiếp cận Contiki, trong phiênbản mới của TinyOS được cung cấp hỗ trợ cho IP để phù hợp với chuẩn6LowPAN 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ếnkhô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 Trongmộ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 truyvấ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ợpphong 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ủanhà phát triển chương trình ứng dụng

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

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 chocá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ênContiki 1.0 năm 2003 Hình 2.1 cho thấy lịch sử phát triển của Contiki trongnhữ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ự ánnhư 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ìnhnhư mô hình uIP được phát hành năm 2001 đã được sử dụng trong hệ thống ứngdụ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, khaithác dầu mỏ,…; mô hình Protothreads được công bố lần đầu tiên năm 2005, đếnnay đã được sử dụng trong nhiều ứng dụng như bộ giải mã kỹ thuật số và đốitượng thông minh nói chung vá mạng cảm biến không dây nói riêng

 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ạnchế 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ênnền TCP/IP

 Có những module cho phép ước lượng và quản lý năng lượng một cáchhiệ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ượngthấ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ớigiao 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ụngcho 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ũngchứ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áccô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ậplị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ếntrì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ìnhhoặ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ệntranh đua (race conditions) Bất kì sự kiện nào đã được lập lịch sẽ chạy cho đếnkhi 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àohàng đợi và sau đó cũng được gửi đến tiến trình đích Cơ chế hỏi vòng được sửdụng trong Contiki có thể xem như là các sự kiện có ưu tiên cao nó đã được lậplị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ủachú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ộtdị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ềuhành Contiki

Hình 2.2: Kiến trúc hệ điều hành Contiki2.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, IPV6giúp hệ điều hành truyền thông qua mạng Internet và Rime được thiết kế chonhữ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áctruyề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 đếnflooding dữ liệu đáng tin cậy trên nhiều nút mạng

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ứcTCP/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ăngkế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ạngtoàn cầu

Những thiết bị nhúng có khả năng đáp ứng được đầy đủ những đặc tínhcủ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ềutài nguyên gồm cả dung lượng code và bộ nhớ sử dụng, không thể được đáp ứngtrong 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ụctiê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 đủ uIPchỉ 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()

 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ếnkhô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ànmạ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ồmnhữ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ôngphù 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êucầu dừng lại

 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ảiliê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 đượcxá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óitin 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 chocá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ếptheo 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 ứngdụ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 Khinhận được một gói, gói nhận được được lưu trong bộ đệm gói, đồng thờiRIME 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áctrì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ácProtothread, 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

2.5.1 Lập trình Event-driven

Lập trình hướng sự kiện (Event-driven) là một phương pháp hiệu quả về bộnhớ để viết phần mềm cho các nút cảm biến Với kiểu lập trình này, phần mềmđược biểu diễn như là các trình xử lý sự kiện: Các đoạn mã ngắn gọn mô tả làmthế nào mà hệ thống đáp ứng được các sự kiện Ví dụ về các sự kiện như là mộtgói tin vô tuyến đến từ một nút lân cận, sự kiện đọc dữ liệu cảm biến từ một trongcác bộ cảm biến, và sự kiện từ bộ định thời Khi sự kiện diễn ra, nút cảm biến trảlời bằng cách thực thi một phần phần mềm của nó

Lập trình hướng sự kiện đòi hỏi ít bộ nhớ hơn so với lập trình đa luồng bởi

vì không có luồng nào yêu cầu bộ nhớ ngăn xếp Toàn bộ hệ thống có thể chạynhư một luồng duy nhất, trong đó chỉ yêu cầu một ngăn xếp duy nhất

Kiểu lập trình hướng sự kiện cũng phù hợp tự nhiên với bản chất hướng sự kiệncủa các nút cảm biến Vì nút cảm biến tương tác với một môi trường điều khiểnhướng sự kiện, nên mô hình lập trình nắm bắt được hành vi có thể quan sát đượccủa hệ thống

2.5.2 Lập trình Multi-threaded

Đa luồng là một kỹ thuật lập trình cho phép nhiều chương trình có thể chạyđồng thời trên một bộ xử lý duy nhất Trong lập trình đa luồng, mỗi chương trình

được định sẵn một luồng điều khiển riêng của nó, và luồng đó chạy cùng với tất cảcác luồng khác trong hệ thống Mỗi luồng được định sẵn thời gian nhất định đểchạy trên bộ vi xử lý Để cho phép chạy nhiều chương trình cùng một lúc, hệ điềuhành chuyển đổi giữa các luồng để chúng cùng nhau nhận được sự chia sẻ côngbằng của bộ vi xử lý.

Lập trình đa luồng được sử dụng rộng rãi trong các hệ thống điều hànhthông dụng, ở đó các luồng tự bảo vệ lẫn nhau sao cho một luồng không thể tiếpcận một luồng khác mà không đi qua các giao diện đã quy định Khi các luồng tựbảo vệ lẫn nhau, chúng thường được gọi là các tiến trình thay vì gọi là các luồng

Đối với các đối tượng thông minh, tồn tại một vấn đề đa luồng là mỗi luồngyêu cầu một phần bộ nhớ của riêng mình để giữ trạng thái của các luồng này, đượcgọi là ngăn xếp của luồng Các ngăn xếp chứa các biến cục bộ mà luồng sử dụng

và các giá trị trả về cho các hàm mà luồng gọi đến, nhưng cũng bao gồm mộtlượng tương đối lớn bộ nhớ không sử dụng Bộ nhớ này phải được cấp phát bởi vì

nó chưa biết trước được có bao nhiêu bộ nhớ ngăn xếp mà mỗi luồng cần dùng

Do đó, bộ nhớ ngăn xếp thường vượt quá sự cấp phát

2.5.3 Lập trình Prothreads

Protothreads là một cách để kết hợp ưu điểm của các mô hình lập trìnhhướng sự kiện và đa luồng Protothreads là cơ chế lập trình được phát triển chocác hệ thống có bộ nhớ hạn chế, nó kết hợp mô hình lập trình hướng sự kiện và đaluồng theo một phương thức hiệu quả về bộ nhớ Với Protothreads, chương trìnhđược cấu trúc theo tuần tự, giống như trong mô hình đa luồng, nhưng sử dụng ít

bộ nhớ tương tự như mô hình hướng sự kiện Protothreads có thể thực hiện đượchiệu quả trong ngôn ngữ lập trình C mà không cần bất kỳ ngôn ngữ lập trình bậcthấp hay các thay đổi nào với trình biên dịch Điều hạn chế là các lập trình viênphải lưu trữ các biến một cách rõ ràng khi các Protothreads dừng Bởi vì cácProtothreads được thực hiện bởi ngôn ngữ C, nên chúng rất tiện lợi trên các nềntảng phần cứng khác nhau

2.5.4 So sánh ba mô hình lập trình trong Contiki

Mô hình lập trình Multi-threaded có khả năng thực hiện đồng thời mộtchuỗi các threads Tuy nhiên, các threads đòi hỏi phải được thực hiện trên nhữngngăn nhớ riêng, tạo ra chuỗi các luồng điều khiển tuần tự Multi-threaded đượcxây dựng như một thư viện, cung cấp cho các Process khi cần thiết

Trong khi đó, mô hình lập trình Event-driven chỉ hoạt động trên một ngănnhớ và thực hiện các luồng điều khiển tùy theo các sự kiện đến Do đó Event-

driven đòi hỏi bộ nhớ ít hơn và cung cấp cơ chế điều khiển linh hoạt theo các sựkiện.

Hình 2.6: Phương thức sử dụng bộ nhớ của Multi-threaded và Event-driven.

Hình 2.7: Các luồng điều khiển trong Multi-Threaded và Event-driven.

Nhờ sự kết hợp các đặc tính của hai cơ chế Multi-threaded và Event-driven,Protothreads có khả năng cung cấp cơ chế điều khiển kiểu event-driven, cung cấpcác luồng điều khiển liên tục, đồng thời sử dụng dung lượng bộ nhớ nhỏ với mộtngăn nhớ duy nhất

Trong API của Contiki bao gồm 4 loại Protothreads cơ bản:

- PT_INIT (pt): khởi tạo một Protothread.

- PT_BEGIN (pt): bắt đầu một Protothread.

- PT_WAIT_UNTIL (pt, điều kiện): điều khiển đợi một sự kiện.

- PT_END (pt): kết thúc một Protothread.

Hình 2.8 là một ví dụ về Protothreads

Hình 2.8 Ví dụ lập trình Protothreads.

Hình 2.9 trình bày một ví dụ của một chương trình được thực thi với môhình lập trình đa luồng và mô hình lập trình hướng sự kiện Hình 2.10 trình bàymột chương trình tương tự được thực hiện với Protothreads Sự khác biệt giữa môhình không chỉ là cấu trúc đoạn mã mà còn cả chiều dài của đoạn mã Mặc dù môhình lập trình hướng sự kiện có nhiều dòng mã hơn, nhưng nó hiệu quả về bộ nhớhơn so mô hình đa luồng

Hình 2.9: Ví dụ vềlập trìnhđaluồng(trái) và lập trình hướng sự kiện (phải)

Hình 2.10: Ví dụ của lập trình Protothreads.

2.6 Hoạt động định thời trong Contiki

Trong Contiki sử dụng 4 loại định thời:

 Timer: là loại định thời thụ động, chỉ sử dụng để lưu lại vết các thời điểmkhi bộ định thời hết hạn

 Rtimer: là loại định thời thời gian thực, sử dụng để gọi một hàm tại mộtthời điểm cụ thể nào đó

 Event timer (etimer): là loại định thời hoạt động, được kích hoạt trong cácProcess và sử dụng để gửi một sự kiện đến Process khi bộ định thời hếthạn

 Callback timer (ctimer): là loại định thời hoạt động, có thể được sử dụng ởbất kỳ vị trí nào trong chương trình, có chức năng gọi một hàm xử lý mỗikhi bộ định thời hết hạn Ctimer được sử dụng trong module RIME củaContiki

Hình 2.11 minh họa ví dụ sử dụng Etimer trong Contiki:

Hình 2.11 Ví dụ sử dụng Etimer.

Ví dụ trên cho thấy cách sử dụng bộ định thời kiểu Etimer trong Contiki đểthay đổi trạng thái của Led sau mỗi giây Các bộ định thời kiểu Etimer thườngđược khai báo kiểu tĩnh và được kích hoạt trong Process.

Hình 2.12 Ví dụ sử dụng Ctimer trong Contiki.

Hình 2.12 minh họa ví dụ trên cho thấy cách sử dụng bộ định thời kiểuCtimer trong các chương trình Contiki Chương trình trên có chức năng thay đổitrạng thái LED mỗi giây cho đến khi có một sự kiện nào đó xảy ra Bộ định thờiđược sử dụng để gọi hàm led_toggler sau mỗi giây

Bằng cách sử dụng các bộ định thời một cách phù hợp, kết hợp với sử dụngcác Protothreads, các chương trình Contiki có khả năng hỗ trợ hiệu quả cho cácchương trình, giao thức phù hợp với những yêu cầu khắt khe về bộ nhớ, khả năng

xử lý, năng lượng, … của mạng các đối tượng thông minh

2.7 Quản lý bộ nhớ

Do những hạn chế nghiêm trọng như năng lượng tiêu thụ, kích thước vật lý

và chi phí của các bộ vi điều khiển được sử dụng cho các nút cảm biến, nên bộnhớ bị hạn chế Do đó, bộ nhớ phải được quản lý một cách hiệu quả Có một số kỹthuật được thực hiện cho hầu hết các bộ nhớ hạn chế trong một nút cảm biến.Không giống như các máy tính thông thường, mà ở đó bộ nhớ có thể hoán đổi mộtcách linh động vào một ổ đĩa cứng, thì bộ nhớ trong vi điều khiển của các đốitượng thông minh thường không thể được di chuyển tới bộ lưu trữ thứ hai

Ở phần mềm, bộ nhớ được cấp phát có thể là tĩnh tại thời điểm biên dịchhoặc cấp phát động ở thời điểm chạy Bộ nhớ được cấp phát tĩnh cho phép các lậptrình viên biết trước là chương trình sẽ phù hợp với bộ nhớ của vi điều khiển,nhưng nó không cho phép hệ thống đáp ứng một cách linh hoạt với các yêu cầutrong thời gian chạy Mặt khác, sự cấp phát bộ nhớ động có thể đáp ứng được bộ

nhớ mà hệ thống yêu cầu thực tế, nhưng nó không thể dự đoán được hành vi của

hệ thống sẽ như thế nào

Hình 2.13: Cấp phát bộ nhớ tĩnh (trái), sự cấp phát động từ một vùng bộ nhớ tĩnh

(giữa) và cấp phát động từ một Heap (phải)

Bởi vì những ưu điểm và những hạn chế khác nhau của các phương phápcấp phát động và tĩnh, nên một phương pháp lai thường được sử dụng Trong phầnnày, chúng ta hãy xem ba phương pháp:

 Cấp phát tĩnh: Tất cả bộ nhớ được cấp phát tại thời điểm biên dịch vàkhông bộ nhớ nào được cấp phát trong thời gian chạy

 Cấp phát động từ vùng bộ nhớ tĩnh: Bộ nhớ có thể được cấp phát độngtrong thời gian chạy từ một tập hợp cố định của các vùng bộ nhớ tĩnh Kíchthước của mỗi cấp phát được xác định trước và không thể thay đổi trongthời gian chạy

 Cấp phát động từ một vùng lưu trữ đặc biệt Heap: Bộ nhớ có thể được cấpphát động trong thời gian chạy và kích thước của mỗi cấp phát có thể đượcxác định tại thời gian chạy

Hình 2.13 cho thấy bộ nhớ được cấp phát với cấp phát tĩnh, cấp phát động

từ một vùng bộ nhớ tĩnh và cấp phát động từ một vùng lưu trữ đặc biệt Heap Hìnhnày cho thấy các vùng nhớ A và B được cấp phát với ba phương pháp khác nhau.Với cấp phát tĩnh, hai cấp phát xuất hiện trong bộ nhớ từ khi hệ thống được khởiđộng đến khi hệ thống được tắt Bộ nhớ được dành riêng cho hai cấp phát vàkhông thể được sử dụng cho bất cứ chương trình nào khác

Với cấp phát động, thì bộ nhớ cho các cấp phát không được dành riêng chochúng, mà vùng nhớ đó cũng có thể được sử dụng bởi các cấp phát khác Khi bộnhớ được cấp phát động từ một vùng bộ nhớ tĩnh, thì các vùng bộ nhớ đã được cấpphát tĩnh Các cấp phát tĩnh này sau đó sẽ được chia thành các phân đoạn cố định

về kích thước Bộ nhớ có thể được cấp phát từ các phân đoạn có kích thước cốđịnh này Sau khi một phân đoạn đã được cấp phát, nó chỉ có thể được sử dụng

bởi chương trình đã được cấp phát nó Khi chương trình thực hiện xong với phânđoạn, chương trình sẽ trả lại phân đoạn đến vùng bộ nhớ Bộ cấp phát bộ nhớ đánhdấu sự phân đoạn là nhàn rỗi và có thể cấp nó tới một chương trình khác đề nghịlấy nó.

Cấp phát động từ một vùng lưu trữ đặc biệt Heap phức tạp hơn cấp phátđộng từ một vùng nhớ Với cấp phát động từ một vùng lưu trữ đặc biệt Heap, bộnhớ được cấp phát là từ một phần của bộ nhớ được gọi là Heap Bất kỳ kích thướcnào của bộ nhớ có có thể được cấp phát từ Heap, miễn là có đủ Byte trống liêntiếp trên Heap Mỗi lần một phần nào của Heap được cấp phát, phần này của bộnhớ không thể được di chuyển hoặc được cấp phát bởi chương trình khác Khichương trình thực hiện xong với bộ nhớ của nó, nó trả lại bộ nhớ cho Heap

Hình 2.14 Vấn đề với cấp phát động Heap: cấp phát cho C không thể được cấp

phát, thậm chí nếu có đủ bộ nhớ trên Heap, bởi vì bộ nhớ đã bị phân mảnh.

Lợi ích của việc cấp phát động Heap là các phân đoạn bộ nhớ có kích thướcbất kỳ có thể được cấp phát Cái giá cho cho ưu điểm này là Heap có thể bị phânmảnh do đó bộ nhớ không thể được cấp phát từ Heap, ngay cả khi có đủ số Bytenhàn rỗi còn lại Điều này được minh họa trong hình 2.14, nơi cấp phát bộ nhớcho C không thể được cấp phát bởi vì không có đủ Byte liên tiếp lại còn lại trênHeap Thậm chí cả khi số lượng các Byte nhàn rỗi trên Heap lớn hơn kích thướccấp phát cho C, bộ nhớ có thể không được cấp phát do sự phân mảnh

Bởi vì các vấn đề về phân mảnh trong cấp phát Heap, nên hầu hết các nútcảm biến sử dụng cấp phát tĩnh cho hầu hết các mục đích và sử dụng việc cấp phátvùng nhớ động khi cấp phát bộ nhớ động là cần thiết Bởi vì các nút cảm biếnthường được thiết kế cho một nhiệm vụ duy nhất, nên cấp phát tĩnh thường là mộtchiến lược để cấp phát bộ nhớ Nhưng bởi vì khối lượng công việc có thể thay đổi,nên cũng cần thiết một lượng nhất định các cấp phát động

2.8 Cài đặt và thực hành với Contiki

2.8.1 Cài đặt Instant-Contiki

Bước 1: Download và giải nén các phần mềm cần thiết.

- Download VMware tại địa chỉ: http://www.vmware.com/download/player/

- Download Instant – Contiki tại địa chỉ:

Hình 2.15 Giao diện VMware Player.

- Mở Instant-Contiki: Chọn Open và chọn đường dẫn đến thư mục Contiki vừagiải nén Chọn Instant-Contiki

Hình 2.16 Chọn đường dẫn đến Instant-Contiki.

- Điền username là “user” rồi ấn enter Màn hình đăng nhập hiện lên:

Hình 2.17 Giao diện đăng nhập username

- Điền password là “user” rồi ấn enter

Hình 2.18 Giao diện nhập Password

Hình 2.19 Giao diện Instant-Contiki được cài trên Ubuntu.

2.8.2 Chương trình điều khiển LED trên Tmote Sky

Tmote Sky là một nền tảng phần cứng cho nút các đối tượng thông minhcủa hãng Sentilla Nền tảng phần cứng này đã được giả lập trên công cụ mô phỏngCooja Trong phần này, em thực hiện viết một chương trình đơn giản để điềukhiển 3 LED trên Tmote Sky Dưới đây là đoạn mã chương trình:

Hình 2.20 Kết quả mô phỏng với Cooja.

Chương 3 CÁC MODULE TRONG HỆ ĐIỀU HÀNH CONTIKI

- Tham khảo tài liệu: Contiki2.x Reference Manual

Chương 4 XÂY DỰNG CHƯƠNG TRÌNH

ỨNG DỤNG VỚI CONTIKI 4.1 Giới thiệu về công cụ mô phỏng Cooja

[ edit ] The COOJA Simulator

The section gives a high-level overview of sensor network simulations in COOJA This information is not strictly needed for using COOJA, but may help users to more easily understand problems, limitations, and features in the simulator

[ edit ] Contiki level: the Contiki Mote Type

A simulated Contiki Mote in COOJA is an actual compiled and executing Contikisystem The system is controlled and analyzed by COOJA This is performed bycompiling Contiki for the native platform as a shared library, and loading the library intoJava using Java Native Interfaces (JNI) Several different Contiki libraries can becompiled and loaded in the same COOJA simulation, representing different kind ofsensor nodes (heterogeneous networks) COOJA controls and analyzes a Contiki systemvia a few functions For instance, the simulator informs the Contiki system to handle anevent, or fetches the entire Contiki system memory for analysis This approach gives thesimulator full control of simulated systems Unfortunately, using JNI also has someannoying side-effects The most significant is the dependency of external tools such ascompilers and linkers and their run-time arguments COOJA was originally developedfor Cygwin/Windows and Linux platform, but has later been ported to MacOS

[ edit ] Getting started

Java version 1.6 or later is required to run COOJA We recommend using the latestversion from Sun In addition, the build tool ant is also required for building COOJA ForWindows users, we recommend using Cygwin Add the Cygwin binaries path (forexample c:\cygwin\bin) to your PATH environmental variable To compile and startCOOJA:

 **> cd contiki-2.x/tools/cooja**

 **> ant run**

COOJA builds and the simulator is started However, before you can simulate a Contiki system, you need to configure COOJA to correctly interface your toolchain

 Open //Menu >// //Settings > External tools paths//

This dialog displays your current COOJA configuration: compiler paths and arguments, abunch of regular expressions used to parse information from these tools, etc **Thesesettings are stored in your home directory: .cooja.user.properties**, such as in///home/myuser// or //C:\Documents And Settings\myuser//

[ edit ] Configuration Wizard

(This wizard replaces the old JNI tests in /tools/cooja/examples/jni_tests.) Theconfiguration wizard helps configuring COOJA for using JNI, a challenging task onmany systems The wizard consists of 4 steps and tests compiling, linking, loadinglibraries, analyzing library memory, and controlling library execution

 Open //Menu >// //Settings > Compiler configuration wizard//

Complete all 4 steps Note that you may have to change the recommended settings Anychanges can later be reviewed in the //External tools paths// dialog

[ edit ] Create a Hello World simulation

After completing the configuration wizard, we are now ready to create a simulation

 Open //File > New simulation//, and click //Create//

A simulation without motes and using the default parameters is created Before addingmotes to the simulation, we first need to create a mote type The mote type determinesthe type of sensor hardware and which Contiki applications are to be simulated

 Open //Mote Types > Create mote type > Contiki Mote Type//

A dialog allowing you to configure the new mote type appears

 Enter a suitable description: "My first hello world mote type"

 Click Browse, and select the Contiki Hello World application**: hello-world.c**

 Compile the Contiki shared library by clicking **Compile**

 When the compilation finishes, load the library and create the mote type by clicking **Create**

We have now added a mote type, however, the simulation does not yet contain any simulated motes

 Enter **10** and click **Create and Add**

You may later add further motes of this type by menu //Menu > Motes > Add motes oftype >// //My first hello world mote type// A few plugins are started: a control panel forstarting and pausing the simulation, a visualizer that shows the node positions, and a loglistener showing printouts of all simulated nodes

 Press **Start** (or CTRL+S) in the **Control Panel** plugin to start simulating

[ edit ] Save and load simulations

Cooja allows for saving and loading simulation configurations A simulationconfiguration contains the simulated modes and mote types, radio medium configuration,active plugins, etc

Note that only the configuration, not the state of the simulation is saved Hence, when asimulation is loaded, the simulation will start over from time 0

To save the current simulation:

 Open //Menu >// //File > Save simulation//

 Enter suitable name Configuration files are stored with the file extension

**.csc**

To load a simulation:

 Open //Menu >// //File > Open simulation > Browse //

 Select configuration file to load

The simulation is loaded, and the plugins will appear after a while Loading a simulationwith several mote types may take some time, since Contiki is recompiled in thebackground

A similar functionality as saving and loading simulation, is **reloading** a simulation

To reload the current simulation:

 Open //Menu >// //File > Reload simulation > same random seed//

[ edit ] COOJA configs for Contiki development: sharing simulation configs

When developing Contiki applications, you should normally keep all your code in aproject directory Your project directory may be a subfolder of Contiki (i.e //contiki-2.x/examples/myproject///), or external to Contiki (i.e ///home/user/mycontikiproject//)