1. Trang chủ
  2. » Luận Văn - Báo Cáo

Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android

83 1,2K 11

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 83
Dung lượng 5,5 MB

Nội dung

XÂY DỰNG ỨNG DỤNG QUẢN LÝ THIẾT BỊ ĐIỆN TRONG TÒA NHÀ TRÊN ANDROID

Trang 1

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC

Ngành Công nghệ thông tin

Đề tài:

XÂY DỰNG ỨNG DỤNG QUẢN LÝ THIẾT BỊ ĐIỆN TRONG TÒA NHÀ

TRÊN ANDROID

Sinh viên thực hiện: ĐÀO TRUNG SƠN

Giáo viên hướng dẫn: ThS BÙI QUY ANH

Thái Nguyên, tháng 5 năm 2013

Trang 2

LỜI CẢM ƠN

Em xin chân thành cảm ơn:

 Thạc sĩ Bùi Quy Anh – Khoa Công nghệ Điện tử và Truyền thông – Đạihọc Công nghệ thông tin và Truyền thông

 Chủ nhiệm dự án “Exploring future university development tion in rural North Vietnam supported by existing partnerships: a har-vest and seed approach”- mã số ZEIN2011Z099

coopera-Cùng các thầy cô giáo trường Đại học Công nghệ thông tin và Truyền thông đã tạo mọi điều kiện giúp đỡ em trong suốt thời gian thực hiện đồ án.Trong quá trình thực hiện đồ án tốt nghiệp không thể tránh khỏi những sơ suất Vì vậy, em rất mong nhận được sự đóng góp ý kiến của thầy cô và bạn

bè để đồ án được hoàn thiện hơn

Thái Nguyên, tháng 5 năm 2013

Sinh viên

Đào Trung Sơn

Trang 3

LỜI CAM ĐOAN

Em xin cam đoan kết quả đạt được trong đồ án là sản phẩm của riêng cá nhânem,không sao chép lại của người khác Trong toàn bộ nội dung đồ án,những điềuđược trình bày là của cá nhân em hoặc là được tổng hợp từ nhiều nguồn tài liệutham khảo mà em đã chắt lọc được để lấy ra những thông tin cần thiết và bổ íchphục vụ cho đồ án Tất cả tài liệu tham khảo đều có xuất xứ rõ ràng và được tríchdẫn hợp pháp Em xin chịu hoàn toàn trách nhiệm và chịu mọi hình thức kỉ luậttheo quy định cho lời cam đoan của mình

Thái Nguyên, tháng 5 năm 2013

Sinh viên

Đào Trung Sơn

Trang 4

MỤC LỤC

LỜI CẢM ƠN 1

LỜI CAM ĐOAN 2

MỤC LỤC 3

DANH MỤC HÌNH ẢNH 5

LỜI NÓI ĐẦU 7

CHƯƠNG 1 8

CƠ SỞ LÝ THUYẾT 8

1.1 Các giao thức truyền dữ liệu và cơ chế chuyển đổi 8

1.1.1 Giao thức truyền thông HTTP 8

1.1.2 Giao thức CoAP trong mạng cảm biến 9

1.2 Hệ điều hành Android 16

1.2.1 Android là gì? 16

1.2.2 Kiến trúc Android (4 tầng) 17

1.2.3 Vòng đời Android 21

1.2.4 Một số thành phần cơ bản trong Android 25

1.3 Hệ điều hành Contiki 29

1.3.1 Giới thiệu 29

1.3.2 Cấu trúc hệ điều hành Contiki 30

1.3.3 Phương thức hoạt động trong Contiki 31

1.3.3.1 Cơ chế điều khiển sự kiện trong Contiki 31

1.3.4 Kiến trúc giao thức mạng trong Contiki 34

1.4 Mạng cảm biến không dây 36

1.4.1 Giới thiệu chung WSN 36

1.4.2 Mô tả hệ thống WSN 36

1.4.3 Ứng dụng của WSN 37

1.4.4 Cấu trúc mạng cảm biến không dây 40

1.4.5 Kiến trúc giao thức mạng cảm biến không dây 44

CHƯƠNG 2 46

PHÂN TÍCH THIẾT KẾ HỆ THỐNG 46

2.1 Mô hình chung của dự án 46

2.2 Giới thiệu về chương trình 48

Trang 5

2.3 Phân tích thiết kế hệ thống 48

2.3.1 Tổng quan về UML 48

2.3.2 Đặc tả các yêu cầu của hệ thống: 50

2.3.3 Xây dựng biểu đồ Use Case cho hệ thống: 50

2.3.4 Xây dựng biểu đồ lớp cho hệ thống: 51

2.3.5 Xây dựng biểu đồ trình tự cho hệ thống: 54

2.3.6 Xây dựng biểu đồ cộng tác cho hệ thống: 58

2.3.7 Tổng kết: 59

CHƯƠNG 3 60

CÀI ĐẶT CHƯƠNG TRÌNH 60

3.1 Mô tả phần mềm: 60

3.2 Một số hình ảnh khi hoạt động 60

3.3 Trình tự yêu cầu và hồi đáp 67

3.4 Hướng dẫn tích hợp Android plugin vào Eclipse IDE 68

KẾT LUẬN 72

TÀI LIỆU THAM KHẢO 73

PHỤ LỤC 1.1 74

Các chương trình khác trong hệ thống 74

1.1.1 Chương trình xử lý cơ sở dữ liệu trên Server 74

1.1.2 Chương trình Timer kết nối Server với mạng cảm biến không dây 74

1.1.3 Biểu đồ luồng sử dụng 75

PHỤ LỤC 1.2 77

Xây dựng Testbed và Testcase 77

1.2.1 Xây dựng testbed 77

1.2.2 Xây dựng testcase bật 1 bóng đèn trên thiết bị 79

Trang 6

DANH MỤC HÌNH ẢNH

Hình 1.1– Giao thức HTTP giữa thiết bị cá nhân và máy chủ 9

Hình 1.2– Giao thức CoAP giữa server với các node trong mạng cảm biến 10

Hình 1.3- Phân tầng trừu tượng của CoAP 14

Hình 1.4– Các tầng trong hệ điều hành Android 17

Hình 1.5- Biểu đồ miêu tả Activity state 23

Hình 1.6- Lịch sử phát triển Contiki 29

Hình 1.7- Phương thức sử dụng bộ nhớ của Multithreads và Events 32

Hình 1.8- Các luồng điều khiển trong Threads và events 32

Hình 1.9- Ví dụ Protothreads 33

Hình 1.10- Kiến trúc giao thức mạng trong Contiki 35

Hình 1.11- Sơ đồ hoạt động các ứng dụng trong Contiki 35

Hình 1.12– Hệ thống WSN 36

Hình 1.13– WSN ứng dụng trong quân sự 38

Hình 1.14– WSN ứng dụng trong thiên nhiên môi trường 39

Hình 1.15– WSN ứng dụng trong y học 39

Hình 1.16– Cấu trúc mạng cảm biến không dây 41

Hình 1.17– Kiến trúc giao thức mạng cảm biến không dây 44

Hình 2.1– Mô hình chung 3 phần của dự án 47

Hình 2.2– Mô hình thiết bị tổng quan 47

Hình 2.3– Thiết bị di động tương tác với tòa nhà qua mạng Internet 48

Hình 2.4– Biểu đồ Use Case của hệ thống 51

Hình 2.5– Biểu đồ lớp ca sử dụng đăng nhập 52

Hình 2.6– Biểu đồ lớp ca sử dụng quản lý các phòng trong tòa nhà 53

Hình 2.7– Biểu đồ lớp ca sử dụng quản lý người dùng 53

Hình 2.8– Biểu đồ trình tự ca sử dụng đăng nhập 54

Hình 2.9– Biểu đồ trình tự ca sử dụng cập nhật trạng thái phòng 55

Trang 7

Hình 2.10– Biểu đồ trình tự ca sử dụng xem thông tin trạng thái phòng 56

Hình 2.11– Biểu đồ trình tự ca sử dụng xem thông tin người dùng 56

Hình 2.12– Biểu đồ trình tự ca sử dụng cập nhật thông tin người dùng 57

Hình 2.13– Biểu đồ cộng tác ca sử dụng đăng nhập 58

Hình 2.14– Biểu đồ cộng tác ca sử dụng xem thông tin trạng thái phòng 58

Hình 2.15– Biểu đồ cộng tác ca sử dụng cập nhật trạng thái phòng 58

Hình 2.16– Biểu đồ cộng tác ca sử dụng xem thông tin người dùng 58

Hình 2.17– Biểu đồ cộng tác ca sử dụng cập nhật thông tin người dùng 59

Hình 3.1– Giao diện khởi động Hình 3.2– Giao diện đăng nhập 61

Hình 3.3– Thông báo lỗi mạng Hình 3.4– Thông báo lỗi đăng nhập 61

Hình 3.5– Giao diện quản lý các phòng 62

Hình 3.6– Giao diện quản lý các phòng khi xoay màn hình và khi bấm menu 63

Hình 3.7– Cài đặt chung 63

Hình 3.8– Cập nhật trạng thái phòng 65

Hình 3.9– Quản lý thông tin user 66

Trang 8

LỜI NÓI ĐẦU

Ngày nay, Công nghệ thông tin là một trong những ngành đang phát triển rấtmạnh mẽ và có ảnh hưởng sâu rộng đến mọi mặt đời sống Nó là nền tảng củanền kinh tế tri thức, là thước đo trình độ phát triển của một quốc gia Xã hội vàkinh tế phát triển đòi hỏi công nghệ cũng phải phát triển Công nghệ phát triển,con người ngày càng phát minh ra những thiết bị công nghệ số thông minh giúpđỡ con người về rất nhiều mặt trong cuộc sống.Cùng với đó là quy mô đô thị hóavới hàng loạt các công trình kiến trúc đồ sộ đã và đang được xây dựng trên mọimiền tổ quốc, góp phần cho sự phát triển kinh tế

Xu hướng và nhu cầu công nghệ hóa ngày càng tăng cao, việc điều khiển cácthiết bị điện và quản lý tòa nhà như ở các nước công nghiệp không còn xa lạ,nhưng việc kiểm soát và điều khiển thiết bị điện trong tòa nhà bằng những thiết

bị di động cầm tay như smartphone hay máy tính bảng thì mới chỉ ở quá trình thửnghiệm hoặc phát triển chưa phổ biến Con người chỉ cần ngồi một chỗ có thểlàm được nhiều việc, điều khiển được các thiết bị điện trong nhà, hoặc đi đâu đó

xa nhà cũng có thể kiểm soát được tình hình trong nhà bằng điện thoại hoặc máytính bảng thông qua mạng Intermet

Xuất phát từ thực tế trên, em chọn đề tài: “Xây dựng ứng dụng quản lý thiết bịđiện trong tòa nhà trên Android.” cho báo cáo thực tập tốt nghiệp Đề tài là mộtphần trong nội dung nghiên cứu của dự án VLIR – Trường ĐH CNTT&TT.Báo cáo được tổ chức thành 3 chương với các nội dung chính như sau:

Chương 1 – Cơ sở lý thuyết: Lý thuyết cơ bản về các giao thức và cơ chế

trong hệ thống, sơ qua về hệ điều hành Android, kiến trúc và hoạt động của ứngdụng Android, hệ điều hành Contiki và mạng cảm biến không dây (WSN)

Chương 2 – Phân tích thiết kế hệ thống: Giới thiệu về ứng dụng, mô hình

chung của hệ thống và trình bày cụ thể về từng chức năng của ứng dụng qua cácbiểu đồ UML

Chương 3 – Cài đặt chương trình:Trình bày về cách cài đặt và sử dụng ứng

dụng, mô tả quá trình hoạt động trên giao diện của ứng dụng kèm hình ảnh minhhọa

Trang 9

CHƯƠNG 1

CƠ SỞ LÝ THUYẾT

1.1 Các giao thức truyền dữ liệu và cơ chế chuyển đổi

1.1.1 Giao thức truyền thông HTTP

HTTP là chữ viết tắt từ HyperText Transfer Protocol (giao thức truyền tảisiêu văn bản) Đây là giao thức cơ bản mà World Wide Web sử dụng HTTP xácđịnh cách các thông điệp (các file văn bản, hình ảnh đồ họa, âm thanh, video, vàcác file multimedia khác) được định dạng và truyền tải ra sao, và những hànhđộng nào mà các Web server (máy chủ Web) và các trình duyệt Web phải làm đểđáp ứng các lệnh rất đa dạng Nói nôm na hơn, HTTP là giao thức truyền tải cácfile từ một Web server vào một trình duyệt Web để người dùng có thể xem mộttrang Web đang hiện diện trên Internet

HTTP là một giao thức ứng dụng chạy ở trên cùng của bộ giao thức TCP/IP(các giao thức nền tảng cho Internet)

Có một tiêu chuẩn chính khác cũng điều khiển cách thức World Wide Weblàm việc là HTML (HyperText Markup Language, ngôn ngữ đánh dấu siêu vănbản), có chức năng quản lý cách thức mà các trang Web được định dạng và hiểnthị

Người ta gọi HTTP là một giao thức “phi trạng thái” (stateless) bởi vì mỗilệnh đều được thực thi một cách độc lập, lệnh sau không biết bất cứ điều gì vềcác lệnh đã đến trước mình Đây chính là một hạn chế, khiếm khuyết của HTTP

Nó là nguyên nhân chính của tình trạng rất khó thực thi các trang Web có khảnăng phản ứng thông minh đối với lệnh mà người dùng nạp vào Và sự hạn chếnày đang được các nhà phát triển khắc phục trong các công nghệ mới nhưActiveX, Java, JavaScript và cookies

Phiên bản mới nhất của HTTP là 1.1 So với phiên bản nguyên thủy (HTTP1.0), phiên bản mới này truyền tải các trang Web nhanh hơn và giảm tình trạng

Trang 10

tắc nghẽn giao thông Web.

Hình 1.1– Giao thức HTTP giữa thiết bị cá nhân và máy chủ

1.1.2 Giao thức CoAP trong mạng cảm biến

Sự hữu ích của các dịch vụ web trên mạng Internet khiến nó ngày càng trở lênphổ biến trong tất cả các ứng dụng, và nó phụ thuộc vào kiến trúc nền tảng củaREST (Representational State Transfer – chuyển đổi trạng thái đại diện) trongweb

Các môi trường RESTful web có tài nguyên hạn chế (ConstrainedRESTfulEnvironments - CoRE) hướng đến kiến trúc REST trong một khuôn dạng thíchhợp dành cho hầu hết các nút mạng có tài nguyên bị hạn chế (vd : các vi điềukhiển 8-bit với dung lượng RAM & ROM bị hạn chế) và các mạng tài nguyênhạn chế (vd : 6LoWPAN) Các mạng có tài nguyên hạn chế như 6LoWPAN hỗtrợ việc phân đoạn (với chi phí đắt) của các gói tin IPv6 packets sang các Frames

có kích thước nhỏ của lớp liên kết vật lý (link – layer) Vì thế các nghiên cứu tậptrung vào phát triển giao thức CoAP (Constrained Application Protocol) giúp giữchi phí các bản tin message overhead nhỏ và hạn chế sự sử dụng của cơ chế phânđoạn

Một trong những mục đích chính của CoAP là thiết kế một giao thức webchung dành cho các yêu cầu đặc biệt trong môi trường mạng bị giới hạn về mặttài nguyên này, đặc biệt tập trung vào vấn đề năng lượng, cấu hình tự động vàcác ứng dụng machine-to-machine (M2M) khác Mục đích của CoAP không phải

để nén HTTP, mà đúng hơn là mang lại một tập con các REST chung với HTTPnhưng được tối ưu dành cho các ứng dụng M2M Mặc dù CoAP có thể được sử

Trang 11

dụng cho nén các giao diện HTTP đơn giản, nhưng đóng góp quan trọng của nó

đó là đưa ra các đặc điểm gắn liền với các ứng dụng dành cho M2M như là khámphá (discovery) tài nguyên, hỗ trợ multicast và trao đổi các bản tin không đồngbộ

Hình 1.2– Giao thức CoAP giữa server với các node trong mạng cảm biến

1.1.3.1 Đặc điểm CoAP

Coap có các đặc điểm chính như sau :

 Giao thức web hạn chế phục vụ đầy đủ các yêu cầu M2M

 Sử dụng UDP với các tùy chọn hỗ trợ truyền tin tin cậy dành cho các yêucầu unicast và multicast

 Trao đổi các bản tin không đồng bộ

 Chi phí header thấp (low header overhead) và chuyển dạng phức tạp

 Hỗ trợ URI và các kiểu nội dung

 Proxy đơn giản và có khả năng nhớ đệm

 Ánh xạ HTTP phi trạng thái, cho phép các proxy được dựng lên và đưa racác truy cập đến nguồn tài nguyên CoAP theo hướng như HTTP trong mộtdạng đồng nhất hoặc cho các giao diện HTTP đơn giản được dựng lên đểthay thế CoAP

 Kết nối an toàn tới lược đồ dữ liệu bảo mật tầng giao vận (DatagramTransport Layer Security - DTLS)

Trang 12

để thuận tiện cho việc dễ hiểu.

Endpoint:Một thực thể tham gia vào giao thức Coap Nhìn chung, một

điểm cuối hoạt động như là một nút mạng “Node” Nút “Host” thường tồntại lâu hơn so với nút “Client” trong mạng Internet

Sender:Điểm đầu tiên của một bản tin Khi diện mạo tập trung vào một

đối tượng bên gửi cụ thể nó sẽ được gọi là điểm nguồn“source endpoint”

Recipient:Điểm cuối cùng của một bản tin Khi diện mạo tập trung vào

một đối tượng bên nhận cụ thể nó sẽ được gọi là điểm đích “destinationendpoint”

Client:Điểm ban đầu của một yêu cầu, điểm đích của một đáp ứng trả về.

Server:Điểm cuối của một yêu cầu, điểm ban đầu của một đáp ứng trả về.

Origin Server:Máy chủ trong đó mà một tài nguyên biết trước lưu trú

hoặc được tạo ra

Intermediary:Một điểm đầu cuối CoAP mà có vai trò hoạt động như một

server hoặc một client (có thể theo hướng trung gian hơn nữa) hướng vềmột Origin server Có hai loại trung gian phổ biến đó là : proxy và reverseproxy Trong một số trường hợp thì một điểm đầu cuối có thể cư xử nhưmột origin server, proxy hoặc reverse proxy, vai trò chuyển đổi dựa theotrạng thái tự nhiên của mỗi yêu cầu

Proxy:Một “proxy” là một endpoint được lựa chọn bởi một client, thường

được cấu hình cục bộ, để biểu diễn các yêu cầu thay cho các client, thựchiện bất kì việc dịch (translation) cần thiết nào Một vài chuyển dịch đượctối thiểu, như là các proxy phục vụ các yêu cầu dành cho “coap” URI,

Trang 13

trong khi các yêu cầu khác có thể yêu cầu dịch ra hoặc dịch về các thựcthể khác nhau các giao thức tầng ứng dụng.

Reverse Proxy:Là một endpoint mà hoạt động như một lớp phía trên một

vài máy chủ và thỏa mãn các yêu cầu thay thế cho chúng, thực hiện bất kỳ

cơ chế dịch cần thiết nào Không giống như một proxy, reverse proxynhận các yêu cầu khi nó là nút gốc cho tài nguyên đích; client phát ra yêucầu sẽ không ý thức được rằng nó đang giao tiếp với một reverse proxy

Confirmable Message:Một vài bản tin yêu cầu cần có phúc đáp trả về.

Các bản tin này gọi là “Confirmable” (xác nhận) Khi mà không có gói tinnào bị mất, mỗi bản tin xác nhận sẽ có chính xác một bản tin trả về theokiểu ACK hoặc kiểu Reset

Non-confirmable message:Một vài bản tin không yêu cầu phúc đáp Đây

là đặc tính riêng của một vài bản tin thường được lặp lại dành cho các yêucầu ứng dụng, như là lặp lại việc đọc từ một cảm biến khi đủ các sự kiệnnối tiếp

Acknowledgment message:Một bản tin phúc đáp sẽ phúc đáp lại một bản

tin confirmable khi nó đến Nó không chỉ ra sự thành công hay thất bại

của bất kỳ yêu cầu được bao gồm nào

Reset message:Một bản tin reset message chỉ thị rằng một bản tin cụ thể

(confirmable hoặc non-confirmable) đã nhận được, nhưng đôi khi nó

không được sử lý đúng Điều này thường xảy ra khi nút nhận đã khởi độnglại và đã quên một vài trạng thái mà yêu cầu cần đưa ra lời giải thích vềbản tin

Piggy-backed Response:Nó bao gồm đúng một bản tin CoAP ACK mà

được gửi tới bên nhận phúc đáp của yêu cầu dành cho đáp ứng này

Separate Response:Khi một bản tin confirmable mang một yêu cầu được

phúc đáp trả về với một bản tin trống (vd : bởi vì máy chủ trả lời không

đúng cách), một đáp ứng riêng (separate response) được gửi đi trong một

Trang 14

Critical Option: Một tùy chọn cần các điểm đầu cuối nhận bản tin hiểu

được để xử lý đúng bản tin Chú ý rằng việc triển khai critical option, như

ngụ ý “option” của nó, nhìn chung : không hỗ trợ việc tùy chọn dẫn đếnviệc loại bỏ bản tin

Elective Option:Một tùy chọn mang ý định bị bỏ qua bởi một điểm đầu

cuối mà không hiểu về nó Xử lý bản tin thậm chí không cần hiểu về tùychọn được cho phép

Resource Discovery:Tiến trình trong đó một CoAP client gửi truy vấn

đến một máy chủ về danh sách các máy chủ lưu trữ tài nguyên

1.1.3.3 Mô hình giao thức CoAP

Mô hình tương tác của giao thức Coap tương tự như mô hình client/server củaHTTP Tuy nhiên, các kết quả tương tác M2M trong một triển khai Coap đóngvai trò như cả client và server Một yêu cầu CoAP sẽ giống như yêu cầu trongHTTP, nó được gửi từ một client để yêu cầu một xử lý trên một tài nguyên (đượcnhận dạng bởi một địa chỉ URI) trên một server Máy chủ sau đó gửi lại một đápứng trả về với một mã đáp ứng; đáp ứng này có thể bao gồm một sự trình bày tàinguyên

Không giống với HTTP, CoAP phân tán các bản tin trao đổi này không đồng

bộ qua một lược đồ dữ liệu có hướng như là UDP Điều này được thực thi mộtcách logic sử dụng một lớp các bản tin mà hỗ trợ các tùy chọn tin cậy CoAPđịnh nghĩa 4 loại bản tin : Confirmable, Non)confirmable, Acknowledgment,Reset; các method codes và các response codes bao gồm một vài bản tin làm chochúng mang các yêu cầu đi hoặc mang các đáp ứng trả về Sự trao đổi cơ bảnnhất của 4 loại bản tin này hơi có tính trực giao giữa các bản tinrequest/response; các yêu cầu có thể được mang trong bản tin Confirmable hoặcNon)confirmable, các đáp ứng trả về cũng có thể được mang trên hai loại bản tinnày hoặc chúng được cõng trên bản tin phúc đáp

CoAP có thể được tiếp cận theo mô hình logic 4 lớp, một lớp bản tin CoAP

sử dụng để truyền dữ liệu UDP và một lớp bất đồng bộ tự nhiên của các tương

Trang 15

tác, lớp các tương tác request/response sử dụng các mã yêu cầu và các mã đápứng Coap sử dụng một đơn giao thức, với việc gửi bản tin và request/responsetạo lên các đặc điểm của Coap header.

Hình 1.3- Phân tầng trừu tượng của CoAP

độ tin cậy

Lớp request/response

Nghĩa của CoAP request/response là mang theo các bản tin CoAP, chúng baogồm hoặc là mã yêu cầu hoặc là mã đáp ứng Các thông tin tùy chọn (hoặc mặcđịnh) cho request và response như là URI và kiểu nội dung tải trọng payloadđược mang đi như là các tùy chọn của CoAP Một thẻ bài tùy chọn được sử dụng

để phối hợp response với request độc lập với các bản tin lớp dưới

Trang 16

Trung gian và nhớ đệm

Giao thức CoAP hỗ trợ việc nhớ đệm các đáp ứng để phục vụ hiệu quả đầy đủcác yêu cầu Nhớ đệm đơn giản được cho phép khi sử dụng các thông tin tươimới và thông tin kiểm tra được mang cùng với các đáp ứng CoAP Vùng nhớđệm được định vị trong các điểm đầu cuối hoặc các trung gian

Chuyển đổi từ CoAP → HTTP

Nếu yêu cầu (Request) đến có chứa trường tùy chọn ProxyURI Option vớicác địa chỉ URI bắt đầu là ‘http’ hoặc ‘https’ [RFC2616], sau đó các điểm cuốinhận bản tin CoAP (được gọi là “proxy – máy ủy quyển) được yêu cầu đưa rahoạt động cụ thể theo phương pháp yêu cầu (Request Method) bên phía HTTPđưa ra và trả về kết quả của yêu cầu đến máy khách (client) Trong phần này sẽchỉ ra các cách thức để bất kỳ yêu cầu CoAP và các đáp ứng CoAP sẽ đượcProxy xử lý và trả lại máy khách

Do CoAP và HTTP cùng có chung tập các phương thức cơ bản (requestmethod), việc biểu diễn một yêu cầu CoAP đến một tài nguyên HTTP sẽ khôngkhác nhiều so với việc yêu cầu này đến tài nguyên CoAP Một số các phươngthức riêng của CoAP khi biểu diễn vào nguồn tài nguyên HTTP sẽ được trình bàychi tiết bên dưới

Nếu máy ủy quyền (Proxy) không thể phục vụ một yêu cầu mang địa chỉHTTP URI, mã đáp ứng 5.05 (Proxying Not Supported) sẽ được trả về cho máykhách Nếu máy Proxy phục vụ yêu cầu đến của máy khách bằng cách hợp tácvới một bên thứ 3 (như là máy chủ HTTP gốc) và không thể đạt được kết quảtrong một khung thời gian hợp lý, đáp ứng 5.04 (Gateway Timeout) sẽ được trảvề; nếu có kết quả trả về nhưng kết quả này không được hiểu, một đáp ứng 5.02(Bad Gateway) sẽ được trả về

Chuyển đổi từ HTTP → CoAP

Nếu một yêu cầu HTTP mà bên trong địa chỉ URI của yêu cầu có chứa cáctiêu đề ‘coap’ hoặc ‘coaps’, điểm cuối nhận yêu cầu HTTP (máy ủy quyền –Proxy) được yêu cầu để biểu diễn các hoạt động được chỉ ra bởi phương thức yêu

Trang 17

cầu (request method) lên tài nguyên CoAP đã chỉ định và trả về kết quả cho máykhách.

Trong phần này chỉ ra cách bất kỳ yêu cầu HTTP (HTTP request) và đáp ứng HTTP (HTTP response) mà máy ủy quyền (Proxy) sẽ trả về cho máy khách.Cách thức làm thế nào proxy sẽ xử lý làm thỏa mãn các yêu cầu tới, mặc dùtrường hợp thông thường máy ủy quyền sẽ dịch và chuyển tiếp yêu cầu tới máychủ CoAP gốc Chi tiết về các phương thức HTTP (HTTP method) sẽ được trìnhbày sau đây Nếu một máy ủy quyền không thể phục vụ một yêu cầu đến với địachỉ URI của CoAP, một mã đáp ứng 501 (Not Implemented) được trả về máykhách Nếu máy ủy quyền phục vụ yêu cầu bằng cách hợp tác với bên thứ 3 (như

là máy chủ CoAP gốc) và không thể thu được kết quả trong một khung thời gianhợp lý, mã đáp ứng 504 (Gateway Timeout) sẽ được trả về; nếu có kết quả thu vềnhưng lại không được máy ủy quyền hiểu, mã đáp ứng 502 (Bad Gateway) đượctrả về

Lợi thế chính của việc sử dụng Android để phát triển ứng dụng là Androidcung cấp cách tiếp cận tốt nhất để phát triển ứng dụng Các nhà phát triển chỉ cầnphát triển cho Android là các ứng dụng đó có thể chạy trên rất nhiều thiết bị khác

Trang 18

nhau, miễn là thiết bị đó hỗ trợ Android Trong thế giới của điện thoại thôngminh thì vấn đề thích hợp phần cứng là điểm quan trọng đối với các ứng dụng,khi đã sử dụng Android làm nền tảng để phát triển thì sẽ có được rất nhiều lợi thế

về mặt này vì các sản phẩm thiết bị thông minh hỗ trợ Android ngày càng đuợc

ưa chuộng

1.2.2 Kiến trúc Android (4 tầng)

Hình bên dưới cho thấy các tầng khác nhau tạo nên hệ điều hành Android

Hình 1.4– Các tầng trong hệ điều hành Android

1.2.2.1 Tầng hạt nhân Linux (Linux Kernel layer)

Hệ điều hành Android được phát trển dựa trên hạt nhân linux, cụ thể là hạtnhân linux phiên bản 2.6, điều đó được thể hiện ở lớp dưới cùng ở hình 1.1 Tất

cả mọi hoạt động của điện thoại muốn thi hành được thì đều được thực hiện ởmức cấp thấp ở lớp này bao gồm quản lý bộ nhớ (memory management), giaotiếp với phần cứng (driver model), thực hiện bảo mật (security), quản lý tiến trình(process)

Trang 19

Tuy được phát triển dựa vào nhân linux nhưng thực ra nhân linux đã được nângcấp và sửa đổi rất nhiều để phù hợp với tính chất của những thiết bị cầm tay nhưhạn chế về bộ vi xử lý, dung lượng bộ nhớ, kích thước màn hình, nhu cần kết nốimạng không dây

Tầng này có các thành phần chủ yếu :

Display Driver : Điều khiển việc hiển thị lên màn hình cũng như thu nhận

những điều khiển của người dùng lên màn hình (di chuyển, cảm ứng )

Camera Driver : Điều kiển hoạt động của camera, nhận luồng dữ liệu từ

camera trả về

Bluetooth Driver : Điều khiển thiết bị phát và thu sóng Bluetooth.

USB driver : Quản lý hoạt động của các cổng giao tiếp USB.

Keypad driver : Điều khiển bàn phím.

Wifi Driver : Chịu trách nhiệm về việc thu phát sóng wifi.

Audio Driver : điều khiển các bộ thu phát âm thanh, giải mã các tính hiệu

dạng audio thành tín hiệu số và ngược lại

Binder IPC Driver : Chịu trách nhiệm về việc kết nối và liên lạc với

mạng vô tuyến như CDMA, GSM, 3G, 4G, E để đảm bảo những chứcnăng truyền thông được thực hiện

M-System Driver : Quản lý việc đọc ghi lên các thiết bị nhớ như thẻ

SD, flash

Power Madagement : Giám sát việc tiêu thụ điện năng.

1.2.2.2 Tầng Library và android runtime

Phần này có 2 thành phần là phần Library và Android Runtime

1 Phần Libraries:

Trang 20

Phần này có nhiều thư viện được viết bằng C/C++ để các phần mềm có thể sửdụng, các thư viện đó được tập hợp thành một số nhóm như :

Thư viện hệ thống (System C library) : thư viện dựa trên chuẩn C, được

sử dụng chỉ bởi hệ điều hành

Thư viện Media (Media Libraries) : Có nhiều codec để hỗ trợ việc phát

và ghi các loại định dạng âm thanh, hình ảnh, video thông dụng

Thư viện web (LibWebCore) : Đây là thành phần để xem nội dung trên

web, được sử dụng để xây dựng phần mềm duyệt web (Android Browse)cũng như để các ứng dụng khác có thể nhúng vào Nó cực kỳ mạnh, hỗ trợđược nhiều công nghệ mạnh mẽ như HTML5, JavaScript, CSS, DOM,AJAX…

Thư viện SQLite : Hệ cơ sở dữ liệu để các ứng dụng có thể sử dụng.

2 Phần Android runtime:

Phần này chứa các thư viện mà một chương trình viết bằng ngôn ngữ Java cóthể hoạt động Phần này có 2 bộ phận tương tự như mô hình chạy Java trên máytính thường Thứ nhất là các thư viện lõi (Core Library) , chứa các lớp như JAVA

IO, Collections, File Access Thứ hai là một máy ảo java (Dalvik VirtualMachine)

Mặc dù cũng được viết từ ngôn ngữ Java nhưng một ứng dụng Java của hệđiều hành android không được chạy bằng JRE của Sun (nay là Oracle) (JVM) mà

là chạy bằng máy ảo Dalvik do Google phát triển

1.2.2.3 Tầng Application Framework

Tầng này xây dựng bộ công cụ - các phần tử ở mức cao để các lập trình viên

có thể nhanh chóng xây dựng ứng dụng Nó được viết bằng Java, có khả năng sửdụng chung để tiết kiệm tài nguyên

Đây là một nền tảng mở, điều đó có 2 lợi thế:

Trang 21

Với các hãng sản xuất điện thoại : Có thể tùy biến để phù hợp với cấu hìnhđiện thoại mà họ sản xuất cũng như để có nhiều mẫu mã, phong cách hợp thị hiếungười dùng.

Vì thế nên tuy cùng chung nền tảng Android mà điện thoại của Google có thểkhác hẳn với Motorola, HTC, T-Mobile, Samsung

Với lập trình viên : Cho phép lập trình viên có thể sử dụng các API ở tầngtrên mà không cần phải hiểu rõ cấu trúc bên dưới, tạo điều kiện cho lập trình viên

tự do sáng tạo bởi vì chỉ cần quan tâm đến nội dung mà ứng dụng họ làm việc.Một tập hợp API rất hữu ích được xây dựng sẵn như hệ thống định vị, các dịch

vụ chạy nền, liên lạc giữa các ứng dụng, các thành phần giao diện cấp cao Giới thiệu một số thành phần của tầng này:

Activity Manager : Quản lý các chu kỳ sống của một ứng dụng cũng như

cung cấp công cụ điều khiển các Activity

Telephony Manager : Cung cấp công cụ để thực hiện việc liên lạc như

gọi điện thoại

XMPP Service : Cung cấp công cụ để liên lạc trong thời gian thực.

Location Manager : Cho phép xác định vị trí của điện thoại thoại dựa vào

hệ thống định vị toàn cầu GPS và Google Maps

Window Manager : Quản lý việc xây dựng và hiển thị các giao diện

người dùng cũng như tổ chức quản lý các giao diện giữa các ứng dụng

Notication Manager : Quản lý việc hiển thị các thông báo (như báo có tin

nhắn,có e-mail mới )

Resource Manager : Quản lý tài nguyên tĩnh của các ứng dụng bao gồm

các file hình ảnh, âm thanh, layout, string (Những thành phần không đượcviết bởi ngôn ngữ lập trình)

Trang 22

1.2.2.4 Tầng Application

Đây là lớp ứng dụng giao tiếp với người dùng, bao gồm các ứng dụng như:Các ứng dụng cơ bản, được cài đặt đi liền với hệ điều hành là gọi điện(phone), quản lý danh bạ (Contacts), duyệt web (Browser), nhắn tin (SMS), lịchlàm việc (Calendar), đọc e-mail (Email-Client), bản đồ (Map), quay phim chụpảnh (camera)

Các ứng dụng được cài thêm như các phần mềm chứng khoán (Stock), các tròchơi(Game), từ điển

Các chương trình có các đặc điểm là :

 Viết bằng Java, phần mở rộng là apk

 Khi mỗi ứng dụng được chạy, nó có một phiên bản Virtual Machine đượcdựng lên để phục vụ cho nó Nó có thể là một Active Program : Chươngtrình có giao diện với người sử dụng hoặc là một background : chươngtrình chạy nền hay là dịch vụ

 Android là hệ điều hành đa nhiệm, nghĩa là trong cùng một thời điểm, cóthể có nhiều chương trình cùng chạy một lúc, tuy nhiên, với mỗi ứng dụngthì có duy nhất một thực thể (instance) được phép chạy mà thôi Điều đó

có tác dụng hạn chế sự lạm dụng tài nguyên, giúp hệ thống hoạt động tốthơn

 Các ứng dụng được gán số ID của người sử dụng nhằn phân định quyềnhạn khi sử dụng tài nguyên, cấu hình phần cứng và hệ thống

 Android là một hệ điều hành có tính mở, khác với nhiều hệ điều hành diđộng khác, android cho phép một ứng dụng của bên thứ ba được phépchạy nền Các ứng dụng đó chỉ có một hạn chế nhỏ đó là nó không đượcphép sử dung quá 5~10% công suất CPU, điều đó nhằn để tránh độcquyền trong việc sử dụng CPU

Ứng dụng không có điểm vào cố định, không có phương thức main để bắt đầu

Trang 23

1.2.3 Vòng đời Android

Android có cơ chế quản lý các process theo chế độ ưu tiên Các process cópriority thấp sẽ bị Android giải phóng mà không hề cảnh báo nhằm đảm bảo tàinguyên

Foreground process: là process của ứng dụng hiện thời đang được người

dùng tương tác

Visible process: là process của ứng dụng mà activity đang hiển thị đối với

người dùng (onPaused() của activity được gọi)

Service process: là Service đang được chạy

Background process: là process của ứng dụng mà các activity của nó ko

hiển thị với người dùng (onStoped() của activity được gọi)

Empty process: process không có bất cứ 1 thành phần nào active Theo

chế độ ưu tiên thì khi cần tài nguyên, Android sẽ tự động kill process,trước tiên là các empty process

Vòng đời của Android Activity:

Như đã giới thiệu ở trên, Actitvity là thành phần quan trọng nhất và đóng vaitrò chính trong xây dựng ứng dụng Android Hệ điều hành Android quản lýActivity theo dạng stack: khi một Activity mới được khởi tạo, nó sẽ được xếp lên

đầu của stack và trở thành running activity, các Activity trước đó sẽ bị tạm dừng

và chỉ hoạt động trở lại khi Activity mới được giải phóng

Activity bao gồm 4 state:

active (running): Activity đang hiển thị trên màn hình (foreground).

paused: Activity vẫn hiển thị (visible) nhưng không thể tương tác (lost

focus) VD: một activity mới xuất hiện hiển thị giao diện đè lên trênactivity cũ, nhưng giao diện này nhỏ hơn giao diện của activity cũ, do đó

Trang 24

ta vẫn thấy được 1 phần giao diện của activity cũ nhưng lại không thểtương tác với nó.

stop: Activity bị thay thế hoàn toàn bởi Activity mới sẽ tiến đến trạng

thái stop.

killed: Khi hệ thống bị thiếu bộ nhớ, nó sẽ giải phóng các tiến trình theo

nguyên tắc ưu tiên Các Activity ở trạng thái stop hoặc paused cũng có

thể bị giải phóng và khi nó được hiển thị lại thì các Activity này phải khởiđộng lại hoàn toàn và phục hồi lại trạng thái trước đó

Hình 1.5- Biểu đồ miêu tả Activity state

Trang 25

Vòng đời của Activity:

Entire lifetime: Từ phương thức onCreate( ) cho tới onDestroy( )

Visible liftetime: Từ phương thức onStart( ) cho tới onStop( )

Foreground lifetime: Từ phương thức onResume( ) cho tới onPause( )

Khi xây dựng Actitvity cho ứng dụng cần phải viết lại phương

thức onCreate() để thực hiện quá trình khởi tạo Các phương thức khác có cần

viết lại hay không tùy vào yêu cầu lập trình

Các phương thức của vòng đời:

Phương thức: onCreate()

 Được gọi khi activity lần đầu tiên được tạo

 Ở đây bạn làm tất cả các cài đặt tĩnh – tạo các view, kết nối dữ liệu đếnlist…

 Phương thức này gửi qua một đối tượng Bundle chứa đựng từ trạng tháitrước của Activity

 Luôn theo sau bởi onStart()

 Được gọi trước khi một activity visible với người dùng

 Theo sau bởi onResume() nếu activity đến trạng thái foreground hoặc Stop() , nó trở nên ẩn

on-Phương thức: onResume()

 Được gọi trước khi activity bắt đầu tương tác với người dùng

Trang 26

 Tại thời điểm này activity ở trên đỉnh của stack activity.

 Luôn theo sau bởi onPause()

Phương thức: onPause()

 Được gọi khi hệ thống đang resuming activity khác

 Phương thức này là điển hình việc giữ lại không đổi dữ liệu

 Nó nên được diễn ra một cách nhanh chóng bởi vì activity kế tiếp sẽkhông được resumed ngay cho đến khi nó trở lại

 Theo sau bởi onResume() nếu activity trở về từ ở trước, hoặc bởi onStop()nếu nó trở nên visible với người dùng

 Trạng thái của activity có thể bị giết bởi hệ thống

Phương thức: onStop()

 Được gọi khi activity không thuộc tầm nhìn của người dùng

 Nó có thể diễn ra bởi vì nó đang bị hủy, hoặc bởi vì activity khác vừađược resumed và bao phủ nó

 Được theo sau bởi onRestart() nế activity đang trở lại để tương tác vớingười dùng, hoặc onDestroy() nếu activity đang bỏ

 Trạng thái của activity có thể bị giết bởi hệ thống

Phương thức: onDestroy()

 Được gọi trước khi activity bị hủy

 Đó là lần gọi cuối cùng mà activity này được nhận

 Nó được gọi khác bởi vì activity đang hoàn thành, hoặc bởi vì hệ thốngtạm thời bị hủy diệt để tiết kiệm vùng nhớ

1.2.4 Một số thành phần cơ bản trong Android

Các layout:

Trang 27

Layout được dùng để quản lý các thành phần giao diện khác theo một trật tựnhất định

FrameLayout: Layout đơn giản nhất, hiển thị các thành phần con vào

góc trên bên trái của màn hình

LinearLayout: Hiển thị các thành phần con theo một chiều nhất định

(ngang hoặc dọc) LinearLayout làm cho các thành phần trong nókhông bị phụ thuộc vào kích thước của màn hình Các thành phần trongLinearLayout được dàn theo tỷ lệ cân xứng vào các ràng buộc giữu cácthành phần Đây là layout được sử dụng nhiều nhất

RelativeLayout: Hiển thị các thành phần con dựa trên mối quan hệ với

các thành phần khác hoặc với biên của layout

TableLayout: Hiển thị các thành phần con dựa trên một lưới các ô

ngang và dọc

AbsoluteLayout: Hiển thị các thành phần con dựa theo tọa độ x, y.

Layout được sử dụng nhằm mục đích thiết kế giao diện cho nhiều độ phângiải Thường khi lập trình nên kết hợp nhiều layout với nhau để tạo ra giao diệnmong muốn

Mã:

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="tunghuynh.com"

Trang 28

Cụ thể những công việc mà AndroidManifest.xml thực hiện:

 Đặt tên cho Java package của ứng dụng

 Mô tả các thành phần (component) của ứng dụng: activity, service,broadcast receiver hoặc content provider

 Thông báo những permission mà ứng dụng cần có để truy nhập cácprotected API và tương tác với các ứng dụng khác

 Thông báo những permission mà các ứng dụng khác cần có để tươngtác với ứng dụng hiện thời

 Thông báo level thấp nhất của Android API mà ứng dụng cần để chạy.(Android 1.0 là level 1, 1.1 là level 2, 1.5 level 3, 1.6 level 4 và 2.0 làlevel 5)

Ngoài ra, từ khoá screenOrientation cho phép thiết lập giao diện khi

vào ứng dụng theo chiều dọc (portrait – mặc định) hay ngang

Trang 29

(landcape), theme cho phép sử dụng style có sẵn của android là

fullscreen (không có thanh status nữa)

File R.java

FileR.java là một file tự động sinh ra ngay khi tạo ứng dụng, file này được sửdụng để quản lý các thuộc tính được khai báo trong file XML của ứng dụng vàcác tài nguyên hình ảnh

Mã nguồn của file R.java được tự động sinh khi có bất kỳ một sự kiện nàoxảy ra làm thay đổi các thuộc tính trong ứng dụng Chẳng hạn như, kéo và thảmột file hình ảnh từ bên ngoài vào project thì ngay lập tức thuộc tính đường dẫnfile đó cũng sẽ được hình thành trong file R.java hoặc xóa một file hình ảnh thìđường dẫn tướng ứng đến hình ảnh đó cũng tự động bị xóa

Có thể nói file R.java hoàn toàn không cần phải đụng chạm gì đến trong quátrong cả quá trình xây dựng ứng dụng

CheckBox và RadioButton

CheckBox và RadioButton đều tạo ra các ô chọn CheckBox cho phép chọnđược nhiều ô cùng lúc, còn RadioButton chỉ cho phép chọn 1 ô tại 1 thời điểm

Làm việc với List view

Được sử dụng để thể hiện một danh sách các thông tin theo từng cell Mỗi

Trang 30

cell thông thường được load lên từ một file XML đã được cố định trên đó sốlượng thông tin và loại thông tin cần được thể hiện Có 2 kiểu List view đó làListView và SpinnerView Cả 2 đều dùng để hiển thị nhưng với SpinnerView thìhiển thị dưới dạng hộp chọn.

Trang 31

1.3 Hệ điều hành Contiki

1.3.1 Giới thiệu

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 chocác hệ thống nhúng và các ứng dụng trong mạng cảm biến không dây Contikibắt đầu được nghiên cứu từ năm 2001 và phát hành phiên bản đầu tiên Contiki1.0 năm 2003 Hình 1.6 cho thấy lịch sử phát triển của Contiki trong những nămqua Phiên bản hiện nay của Contiki là 2.4, với nhiều thay đổi, bổ sung và pháttriể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 ứ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à thiết bịcảm biến rung không dây

Trang 32

Hình 1.6- 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, hoạt động dựa trên cơchế event - driven và có những đặc điểm phù hợp với các hệ thống nhúng vàmạng cảm biến không dây:

 Contiki được chia thành nhiều modul hoạt động độc lập Nhờ đó cácứng dụng có thể sử dụng các modul một cách linh động và chỉ loadnhững modul 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 cảm biến thông qua uIP stack được xâydựng dựa trên nền TCP/IP

 Có những modul 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ànghơn

 Sử dụng RIME stack phục vụ các giao thức dành cho mạng nănglượ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 giaodiệ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

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

Bất kỳ bản Contiki nào cũng gồm 7 thư mục : apps, core, cpu, docs, example,platform và tools

“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 ứngdụng cho mạng cảm biến không dây Ứng dụng tiêu biểu trong thư

Trang 33

mục này là trình duyệt web, máy chủ Web, FTP, email và máy tính

“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 file, gần một nửa trong số đó là tập tintiê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

“cpu” chứa bộ xử lý cụ thể 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

“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

“examples” chứa các chương trình ví dụ đơn giản bắt đầu với

“Hello-world”, mà phục vụ như là bước đầu tiên hướng tới Contiki lập trình

“platform” bao gồm thông tin cụ thể liên quan đến nền tảng Node

cảm biến như ESB, Sky, vv "native" là một nền tảng đặc biệt là xâydựng một hệ thống toàn bộ Contiki như một chương trình chạy trên hệthống phát triển

“tools” là thư mục mà các công cụ phần mềm đặc biệt được lưu trữ.

'Cooja' là một Java dựa trên mô phỏng cho Contiki.Thư mục này cũngchứa các công cụ nền tảng cụ thể ví dụ điển hình là các công cụ choSky

1.3.3 Phương thức hoạt động trong Contiki

1.3.3.1 Cơ chế điều khiển sự kiện trong 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” – điều khiển

Trang 34

Cơ chế Multithread có khả năng thực hiện đồng thời một chuỗi các thread.Tuy nhiên, các thread đòi hỏi phải được thực hiện trên những ngăn nhớ riêng, tạo

ra chuỗi các luồng điều khiển tuần tự Multithreads được xây dựng như một thưviện, cung cấp cho các Process khi cần thiết

Trong khi đó, cơ chế event – driven chỉ hoạt động trên một ngăn nhớ và thựchiệ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 đến

Hình 1.7- Phương thức sử dụng bộ nhớ của Multithreads và Events.

Hình 1.8- Các luồng điều khiển trong Threads và events.

Trang 35

Nhờ sự kết hợp các đặc tính của hai cơ chế Multithread và event - driven,Protothread có khả năng cung cấp cơ chế điều khiển kiểu event - driven, cungcấp các luồng điều khiển liên tục, đồng thời sử dụng dung lượng bộ nhớ nhỏ vớimột ngă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 1.9- Ví dụ Protothreads.

Trong các chương trình Contiki, bằng cách xây dựng các khối chương trình

sử dụng các Protothread có thể tạo ra những Process theo kiểu event – driven.Trong đó sử dụng một hàng đợi sự kiện trung tâm để lưu địa chỉ của tất cả cácProcess và gọi các process đó khi có sự kiện đến tương ứng Các sự kiện đến cóthể được tạo ra bởi các nhân tố từ bên ngoài như nhận một bản tin đến thông quasóng radio, khi công tắc được nhấn, … Hoặc được tạo ra từ những nhân tố bêntrong như bộ định thời hết hạn, một process chuyển một thông điệp đến một

Trang 36

process khác,…

1.3.3.2 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ểm khi 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ột thờ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ác Process và sử dụng để gửi một sự kiện đến Process khi bộđịnh thời hết hạ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ỗi khi bộ định thời hết hạn Ctimer được sử dụng trong moduleRIME của Contiki

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 Protothread, 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ảm biến không dây

1.3.4 Kiến trúc giao thức mạng trong Contiki

Contiki cung cấp các ứng dụng trên nền IP gồm cả IPv4 và IPv6 thông qua 2stack giao tiếp: uIP và Rime Các ứng dụng có thể hoạt động trên một trong haigiao thức uIP hoặc Rime, đồng thời trên cả hai giao thức hoặc có thể hoạt độngkhông dựa trên giao thức nào Bên cạnh đó, các ứng dụng uIP có thể hoạt độngdựa trên Rime và ngược lại, các ứng dụng trên nền Rime cũng có thể hoạt độngdựa trên nền uIP

Trang 37

Hình 1.10- Kiến trúc giao thức mạng trong Contiki.

Trang 38

Hình 1.11- Sơ đồ hoạt động các ứng dụng trong Contiki.

1.4 Mạng cảm biến không dây

1.4.1 Giới thiệu chung WSN

Khái niệm mạng cảm nhận không dây dựa trên công thức đơn giản sau:

Cảm nhận + CPU + Radio = WSN

Từ công thức đơn giản trên, rất nhiều ứng dụng xuất hiện Tuy nhiên, việc kếthợp các cảm biến, radios, và CPU vào một mạng cảm nhận không dây (wirelesssensor network-WSN) đòi hỏi hiểu biết chi tiết về khả năng và giới hạn của cácthành phần phần cứng, cũng như hiểu rõ các công nghệ mạng hiện đại, lý thuyếtphân bố hệ thống Một thách thức là ánh xạ toàn bộ yêu cầu hệ thống vào mộtthiết bị riêng lẻ Để làm cho WSN trở nên thực tế, một kiến trúc cần được pháttriển để tổng hợp các ứng dụng dựa trên khả năng của phần cứng Để phát triểnkiến trúc hệ thống cần đi từ yêu cầu ứng dụng mức cao xuống các yêu cầu phầncứng mức thấp Để giới hạn số các ứng dụng phải xem xét, cần tập trung vào mộttập các dạng ứng dụng được sử dụng nhiều trong thực tế Sử dụng các dạng ứng

Trang 39

dụng này để tìm ra các yêu cầu mức hệ thống cho toàn bộ kiến trúc Từ các yêucầu mức hệ thống này, có thể có các yêu cầu cho các nút mạng riêng lẻ.

1.4.2 Mô tả hệ thống WSN

Hình 1.12– Hệ thống WSN

Các mạng cảm biến liên kết theo giao thức Multihop, phân chia các Clusterchọn ra các node có khả năng tốt nhất làm node trung tâm, tất cả các node loạinày sẽ truyền về node xử lý chính Nhờ vậy , năng lượng cũng như băng thôngkênh truyền sẽ đc sử dụng hiệu quả hơn Tuy nhiên, có thể thấy cấu trúc mạngphức tạp và giao thức phân chia Cluster và định tuyến sẽ trở nên khó khăn hơn.Một vài đặc điểm của mạng cảm biến:

 Các node phân bố dày đặc

 Các node dễ bị hư hỏng

 Giao thức mạng thay đổi thường xuyên

 Node mạng bị hạn chế về công suất, khả năng tính toán và bộ nhớ

 Các Node có thể không đc đồng nhất toàn hệ thống vì số lượng lớn cácnode

1.4.3 Ứng dụng của WSN

Trang 40

Cảm biến thường được chia thành nhiều nhóm chức năng như: cơ, hóa, nhiệt,điện, từ, sinh học, quang, chất lỏng, sóng siêu âm có thể được đưa ra bên ngoàimôi trường nguy hại, nhiệt độ cao, mức dao động, nhiễu lớn, môi trường hóa chấtđộc hại, trong hệ thống robot tự động hay trong hệ thống nhà xưởng sản xuất…Nhờ đó, mà mạng cảm biến được ứng dụng một cách rộng rãi trong nhiều lĩnhvực của cuộc sống.

Những ứng dụng trong quân sự, an ninh

Với kích thước nhỏ gọn, đặc tính triển khai nhanh đi kèm khả năng tự cấuhình và chịu lỗi, mỗi nút cảm biến đã trở thành một cấu phần quan trọng đượctích hợp trong hệ thống điều khiển, giám sát, tính toán, theo dõi mục tiêu quân sựnhư đánh giá mức độ nguy hiểm của chiến trường, phát hiện, do thám việc tấncông bằng vũ khí hóa học, sinh học, hạt nhân, điều khiển tự động các thiết bị,robot…

Hình 1.13– WSN ứng dụng trong quân sự

Những ứng dụng trong thiên nhiên, môi trường

Ngày đăng: 27/04/2014, 10:16

HÌNH ẢNH LIÊN QUAN

Hình 1.2– Giao thức CoAP giữa server với các node trong mạng cảm biến - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.2 – Giao thức CoAP giữa server với các node trong mạng cảm biến (Trang 9)
Hình 1.4– Các tầng trong hệ điều hành Android - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.4 – Các tầng trong hệ điều hành Android (Trang 16)
Hình 1.5- Biểu đồ miêu tả Activity state - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.5 Biểu đồ miêu tả Activity state (Trang 22)
Hình 1.7- Phương thức sử dụng bộ nhớ của Multithreads và Events. - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.7 Phương thức sử dụng bộ nhớ của Multithreads và Events (Trang 31)
Hình 1.9- Ví dụ Protothreads. - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.9 Ví dụ Protothreads (Trang 32)
Hình 1.10- Kiến trúc giao thức mạng trong Contiki. - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.10 Kiến trúc giao thức mạng trong Contiki (Trang 34)
Hình 1.11- Sơ đồ hoạt động các ứng dụng trong Contiki. - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.11 Sơ đồ hoạt động các ứng dụng trong Contiki (Trang 34)
Hình 1.12– Hệ thống WSN - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.12 – Hệ thống WSN (Trang 35)
Hình 1.13– WSN ứng dụng trong quân sự - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.13 – WSN ứng dụng trong quân sự (Trang 37)
Hình 1.14– WSN ứng dụng trong thiên nhiên môi trường - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.14 – WSN ứng dụng trong thiên nhiên môi trường (Trang 38)
Hình 1.15– WSN ứng dụng trong y học - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.15 – WSN ứng dụng trong y học (Trang 38)
Hình 1.16– Cấu trúc mạng cảm biến không dây - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 1.16 – Cấu trúc mạng cảm biến không dây (Trang 40)
Hình 2.18– Mô hình chung 3 phần của dự án - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 2.18 – Mô hình chung 3 phần của dự án (Trang 46)
Hình 2.19– Mô hình thiết bị tổng quan - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 2.19 – Mô hình thiết bị tổng quan (Trang 46)
Hình 2.20– Thiết bị di động tương tác với tòa nhà qua mạng Internet - Đồ án xây dựng phần mềm điều khiển nhà thông minh bằng thiết bị Android
Hình 2.20 – Thiết bị di động tương tác với tòa nhà qua mạng Internet (Trang 47)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w