NHIỆM VỤ VÀ NỘI DUNG: Tìm hiểu chuẩn truyền nhận dữ liệu trên các thiết bị phần cứng trong mạng cảm biến không dây, từ đó đưa ra lựa chọn chuẩn truyền nhận dữ liệu phù hợp dùng trong ma
Mở đầu
Tổng quan
Trong những năm gần đây, việc ứng dụng các thành tựu của công nghệ thông tin nói chung và của hệ thống nhúng nói riêng vào phục vụ nhu cầu sinh hoạt hằng ngày của con người diễn ra khá phổ biến trên thế giới cũng như ở Việt Nam Việc này đã mang lại nhiều lợi ích cho các ngành công nghiệp, cơ khí, chế biến nông - thủy sản…Tuy việc áp dụng các thành tựu vào trong ngành nuôi trồng thủy sản đang phát triển nhưng chưa đưa ra mô ̣t hê ̣ thống hoàn thiê ̣n về các yếu tố như năng lượng, có khả năng giao tiếp ra ngoài internet và sự chuẩn hóa trong quá trình quản lý truyền nhâ ̣n dữ liê ̣u
Theo báo cáo hằng năm của Hội liên hiệp xuất khẩu hải sản Việt Nam [1], trong những năm gần đây, tỷ lệ nuôi tôm, cá thành công là 66% Có năm doanh nghiê ̣p mất cả hàng trăm tỷ đồng khi xảy ra di ̣ch bê ̣nh Điều này nói lên hiệu suất của việc nuôi trồng thủy sản không cao Có nhiều nguyên nhân dẫn đến việc này
Để cải thiện chất lượng nuôi trồng thủy sản, cần thiết phải xây dựng hệ thống giám sát chất lượng môi trường nuôi một cách tự động, chính xác và liên tục Các hệ thống giám sát hiện tại thường yêu cầu thao tác thủ công và thụ động, không đáp ứng yêu cầu giám sát liên tục và chính xác chất lượng nước trong nuôi trồng thủy sản.
Hiê ̣n nay trên thi ̣ trường, chúng ta đã có những hê ̣ thống tự đô ̣ng lấy mẫu thông tin của nhiê ̣t đô ̣, pH, đô ̣ mă ̣n của nguồn nước ta ̣i các điểm trong các khu vực nuôi trồng thủy sản và có các hê ̣ thống xử lý nguồn nước Nhưng khi sử du ̣ng những hê ̣ thống đó, con người phải đảm nhâ ̣n viê ̣c thu thâ ̣p, phân tích, đánh giá các dữ liê ̣u mô ̣t cách thủ công rồi mới đưa ra kết luâ ̣n có nên xử lý nguồn nước hay không Điều này làm tốn công sức người nuôi trồng thủy sản và đôi lúc la ̣i không chính xác nên sẽ làm giảm năng suất nuôi trồng Sự theo dõi nguồn nước như vâ ̣y là hoàn toàn bi ̣ đô ̣ng và không liên tu ̣c Ma ̣ng cảm biến không dây được xem xét như là mô ̣t giải pháp cho vấn đề này
Dữ liệu trên các hệ thống nhúng hiện nay chủ yếu được thu thập và truyền nhận cục bộ, chỉ thông qua việc gửi nhận các gói tin văn bản thông thường Điều này gây khó khăn cho việc phát triển và bảo trì hệ thống, đặc biệt là các hệ thống mạng cảm biến không dây yêu cầu sự ổn định về năng lượng Do đó, cần phải có cơ chế quản lý việc truyền nhận gói tin và cho các thiết bị ngủ khi cần thiết để tăng thời gian hoạt động của hệ thống.
Tính khả thi của đề tài
Đề tài “Quản lý truyền nhận dữ liê ̣u trong nuôi trồng thủy sản dùng mạng cảm biến không dây” tâ ̣p trung vào nghiên cứu và phát triển giải pháp cho viê ̣c truyền nhâ ̣n dữ liê ̣u trên những thiết bi ̣ cảm biến không dây Nhằm mu ̣c đích cung cấp hê ̣ thống giám sát chất lượng nước mô ̣t cách tự động, chính xác và liên tục Hiê ̣n nay trong ma ̣ng cảm biến không dây tuy chưa cung cấp nhiều chuẩn network stack nhưng vẫn có các chuẩn được dùng rô ̣ng rãi như Zigbee, 802.15.4,
6Lowpan Việc áp du ̣ng các giao thức ở lớp mạng giúp ta có thể dễ dàng phát triển, mở rộng ứng dụng trong việc truyền nhâ ̣n dữ liê ̣u trong ma ̣ng cảm biến không dây
Bên ca ̣nh các network stack, trong lĩnh vực ma ̣ng cảm biến không dây cũng cung cấp khá nhiều các hê ̣ điều hành như TinyOS, Contiki, LiteOS, MANTIS… [2] [3]
Vớ i viê ̣c cung cấp các hê ̣ điều hành cho ma ̣ng cảm biến không dây, ta hoàn toàn có thể quản lý các tài nguyên trong ma ̣ng cũng như điều kiển hoa ̣t đô ̣ng của toàn bô ̣ ma ̣ng
Ngoài ra vấn đề năng lượng luôn luôn là vấn đề quan trọng, cốt lõi trong ma ̣ng cảm biến không dây Để giải quyết vấn đề này, chúng ta cần lựa cho ̣n các thiết bi ̣ được thiết kế với mu ̣c đích tối ưu về năng lượng như các dòng chip MSP430Fxxx [4] củ a hãng Texas Instruments Bên cạnh các giải pháp về phần cứng, chúng tôi còn xem xét các giải pháp về phần mềm như cho ̣n những hê ̣ điều hành được thiết kế với mục tiêu năng lượng thấp; phân tích các mức tiêu thu ̣ năng lượng của các tác vu ̣ cơ bản trong hê ̣ thống, từ đó đưa ra cơ chế, hoă ̣c cấu hình để giảm thiểu sự tiêu thu ̣ năng lượng, giúp hê ̣ thống hoa ̣t đô ̣ng liên tu ̣c
3 Từ những giải pháp cho các vấn đề được phân tích ở trên, chúng tôi tin rằng hê ̣ thống “Quản lý truyền nhâ ̣n dữ liê ̣u trong nuôi trồng thủy sản dùng ma ̣ng cảm biến không dây” có khả thi và ứng du ̣ng cao đối với các hô ̣, các công ty nuôi trồng ở
Đóng góp của luâ ̣n văn
Những đóng góp chính của luâ ̣n văn:
Kiến trúc tổng quát cho các loa ̣i node trong ma ̣ng cảm biến không dây
Dựa vào các yêu cầu trong hệ thống mà đưa ra các kiến trúc khác nhau cho mỗi loại node
Thiết kế các tài nguyên, di ̣ch vu ̣ cho viê ̣c truyền nhâ ̣n trong ma ̣ng cảm biến không dây dựa vào đă ̣c tính của hê ̣ thống
Cung cấp cơ chế trong viê ̣c tối ưu hóa năng lượng tiêu thu ̣ của các thiết bi ̣ dựa trên các di ̣ch vu ̣ đang dùng
Xây dựng ứng du ̣ng hiển thi ̣ các thông tin về chất lượng nước cho người dùng Đưa ra các cảnh báo ki ̣p thời khi phát hiê ̣n sự cố Cung cấp cho người dùng giao diê ̣n có thể cấu hình thông số liên quan của hê ̣ thống mô ̣t cách dễ dàng.
Cấu trúc của luâ ̣n văn
Sau phần giới thiê ̣u, những phần tiếp theo của luâ ̣n văn sẽ được trình bày với cấu trúc sau:
Chương 2: Trình bày các kiến thức nền tảng liên quan đến đề tài bao gồm ma ̣ng cảm biến không dây, hê ̣ điều hành, các network stack dùng trong ma ̣ng cảm biến không dây và các công trình liên quan đến đề tài trước đây
Chương 3: Trình bày chuẩn giao tiếp dùng trong ma ̣ng cảm biến không dây
(Constrained Application protocol - CoAP), định da ̣ng gói tin của CoAP, cách thức giao tiếp và thời gian đáp ứng của CoAP trong ma ̣ng cảm biến không dây
Chương 4: Trình bày cách thiết kế kiến trúc cho các node trong ma ̣ng cảm
4 biến không dây, cách thức trao đổi dữ liê ̣u trên các di ̣ch vu ̣ của CoAP, cung cấp cơ chế để quản lý năng lượng tiêu thu ̣ cũng như điều hành hê ̣ thống
Chương 5: Trình bày cách hiê ̣n thực và thử nghiê ̣m hê ̣ thống, bao gồm viê ̣c đánh giá thời gian đáp ứng của chương trình, mức năng lượng tiêu thu ̣ và khả năng áp du ̣ng vào thực tế của sản phẩm
Chương 6: Kết luâ ̣n và đề xuất hướng phát triển tiếp theo
Cơ sở lý thuyết
Ma ̣ng cảm biến không dây
Mạng cảm biến không dây là mạng lưới các nút, mỗi mạng có từ vài nút đến vài trăm nút và mỗi nút được kết nối với ít nhất một nút khác Mỗi nút được bố trí trong không gian, có các cảm biến dùng để giám sát, đo lường các điều kiện môi trường như nhiệt độ, ánh sáng, áp suất, độ pH Mỗi nút còn có bộ vi xử lý dùng để tính toán và mô-đun truyền nhận không dây để liên lạc với các nút khác trong mạng Dữ liệu đo được từ môi trường sẽ được truyền về trung tâm qua các nút trung gian Hiện nay, mạng cảm biến không dây được ứng dụng nhiều trong công nghiệp và các ứng dụng phục vụ người dùng như nuôi trồng thủy sản, chăm sóc sức khỏe, nhà thông minh, hệ thống cảnh báo cháy rừng, hệ thống theo dõi chất lượng các công trình như cầu đường.
Hình 2-1 Mô hình ma ̣ng cảm biến không dây
Hình 2-1 mô tả cách áp du ̣ng ma ̣ng cảm biến không dây trong viê ̣c nuôi trồng thủy sản Mỗi hồ nuôi thủy sản có các node để đo đa ̣c, giám sát chất lượng nước
Các node có thể truyền dữ liệu trực tiếp đến gateway hoặc thông qua router Gateway kết nối với Internet bên ngoài thông qua mạng điện thoại hoặc Internet.
6 đây, người dùng có thể truy xuất vào ma ̣ng để lấy theo dõi chất lượng nước của các hồ nuôi
2.1.1 Phân loa ̣i node trong ma ̣ng cảm biến không dây
Mỗi node trong ma ̣ng cảm biến không dây được xem như là mô ̣t máy tính thu nhỏ Tùy theo chức năng, vai trò của mỗi node trong ma ̣ng mà ta chia ra thành 3 loa ̣i cơ bản như sau:
Node cảm biến (node cảm biến) [9]: làm nhiê ̣m vu ̣ đo đa ̣c dữ liê ̣u từ môi trường bên ngoài thông qua các cảm biến gắn trên node sau đó sẽ truyền dữ liê ̣u về trung tâm thông qua router hay trực tiếp đến gateway
Router: nhiê ̣m vu ̣ chính là tìm đường cho các gói tin trong ma ̣ng cảm biến, nhâ ̣n gói tin từ node cảm biến hay là từ rounter khác Router đóng vai trò trung chuyển, điều đó giúp tăng khoảng cách giao tiếp trong hê ̣ thống ma ̣ng cảm biến không dây
Gateway: là node trung tâm nhằm thu thâ ̣p các dữ liê ̣u từ các router, các node cảm biến Gateway kết nối ma ̣ng cảm biến bên trong với ma ̣ng internet bên ngoài Ngoài ra, gateway còn gởi cảnh báo, thông báo đến người dùng đầu cuối khi phát hiê ̣n các sự cố bất thường trong hê ̣ thống…
2.1.2 Kiến trúc phần cứng cơ bản của node
Hình 2-2 Kiến trúc phần cứng tổng quát của node cảm biến Hình 2-2 mô tả kiến trúc phần cứng cơ bản bên trong node Mỗi node sẽ có ít nhất mô ̣t trong những thành phần sau [10]:
Micro-controller: bô ̣ xử lý trung tâm, đảm nhâ ̣n các công viê ̣c tính toán, điều khiển các thành phần khác trong node
Memory: bộ nhớ dành cho viê ̣c lưu trữ Viê ̣c lưu trữ dữ liê ̣u trên các node là nhu cầu cần thiết cho những trường hợp xảy ra sự cố về đường truyền cũng như các sự cố về nguồn năng lượng Hiê ̣n nay, công nghê ̣ lưu trữ đã phát triển và có thể chế ta ̣o những chip nhớ có dung lượng lớn và kích thước nhỏ Điều đó đảm bảo viê ̣c lưu trữ có thể hoa ̣t đô ̣ng trong thời gian dài
Transceiver: bô ̣ truyền/nhâ ̣n sóng
Power source: bộ nguồn thiết bi ̣ Nguồn năng lượng trên các node cảm biến thường là pin hoă ̣c tấm năng lượng mă ̣t trời hoă ̣c sự kết hợp giữa mô ̣t trong 2 nguồn trên Nguồn năng lượng trên router và gateway thường là pin hoă ̣c nguồn điê ̣n trực tiếp vì vi ̣ trí đă ̣t của các thiết bi ̣ đó gần các nguồn năng lượng trực tiếp như trong nhà, trên bờ ao (nơi mà các đường dây điê ̣n có thể kéo đến) Năng lượng cho node cảm biến là mô ̣t trong những vấn đề quan tro ̣ng trong ma ̣ng cảm biến không dây Do đó, để hê ̣ thống hoa ̣t đô ̣ng trong thời gian dài thì cần phải có cơ chế quản lý năng lượng phù hợp
Sensor: là các cảm biến, làm nhiê ̣m vu ̣ đo đa ̣c các điều kiê ̣n môi trường xung quanh Trên mỗi node cảm biến thườ ng gắn mô ̣t hay nhiều loa ̣i cảm biến khác nhau như cảm biến nhiê ̣t đô ̣, cảm biến pH, cảm biến đo nồng đô ̣ oxy trong nước…
ADC: chuyển các tín hiê ̣u tương tự (analog) đo được từ các cảm biến thành tín hiê ̣u số (digital) Các tín hiê ̣u số được chuyển đến MCU để xử lý
2.1.3 Công nghê ̣ trong ma ̣ng cảm biến không dây
Trên thị trường hiện nay, có nhiều thiết bị cảm biến không dây, mỗi thiết bị lại có những tính năng và ứng dụng khác nhau Để tìm hiểu thêm về các thiết bị cảm biến không dây, độc giả có thể tham khảo bảng 2-1 trong tài liệu tham khảo [11].
8 Bảng 2-1 Danh sách các thiết bị trong mạng cảm biến không dây
Tên MCU Module truyền nhận Bộ nhớ Bộ nhớ ngoài
Chipcon 10 KB RAM 48 KB flash Nes C TinyOS
512 KB flash Nes C TinyOS IMote 2.0
Atmel AT86RF230 8 KB RAM 128 KB flash Nes C
TI CC2420 802.15.4/ZigB ee compliant radio
4 KB RAM 128 KB flash Nes C
TCP/IP and Bluetooth Profiles: LAP, DUN, PAN and
Chipcon CC2420 10 KB RAM 48 KB flash C/Nes
10 KB RAM 48 KB flash C/Nes
Contiki, TinyOS, SOS and MantisOS
Hình 2-3 đến hình 2-7 là các platform được dùng phổ biến trong ma ̣ng cảm biến không dây
9 Hình 2-3 WisMote Dev được tích hợp MCU MSP430F5437
Hình 2-4 Tmote Sky tích hợp MCU MSP430
Hình 2-5 TelosB tích hợp MCU MSP430
10 Hình 2-6 MicaZ tích hợp MCU Atmel Atmega 128
Hình 2-7 Mica tích hợp MCU Atmega 128L Dựa vào bảng danh sách trên và tìm hiểu về các MCU (Micro control Unit) cũng như radio module thông qua viê ̣c so sánh và phân tích thì đề tài đã cho ̣n mô ̣t platform tương tự là ProFLEX01-R2 [12] ProFLEX01-R2 gồm MCU là Texas Instruments MSP430F5437A [4] và module Radio là Texas Instruments CC2520 [5] – CC2591 [6] Vì các đă ̣c điểm sau của ProFLEX01-R2 mà đề tài đã cho ̣n làm platform cho ứ ng du ̣ng của mình:
Texas Instruments CC2520 – CC2591: có công suất phát lớn, vì có phần khuếch đa ̣i CC2591, đô ̣ nha ̣y khi nhâ ̣n cao và có khả năng truyền xa lên đến 1Km [12] [13], do đó phù hợp với ứng du ̣ng của đề tài
MCU Texas Instruments MSP430F5437A: cung cấp nhiều mode tiết kiê ̣m năng lượng (ở mức tiết kiê ̣m tối đa, dòng điê ̣n có thể đa ̣t mức 2μA)
Bô ̣ gói ProFLEX01-R2 (MCU Texas Instruments MSP430F5437A, Texas
Hê ̣ điều hành cho ma ̣ng cảm biến không dây
Không giống như các hê ̣ điều hành đa nghiê ̣m dành cho PC, hê ̣ điều hành thiết kế cho hê ̣ thống nhúng cũng như ma ̣ng cảm biến không dây không cần phức ta ̣p để xử lý nhiều loa ̣i task khác nhau Do đă ̣c thù của hê ̣ thống nhúng, hê ̣ điều hành chỉ xử lý những task chuyên biê ̣t nên nó cần phải thiết kế đơn giản, đáp ứng nhanh, sử du ̣ng ít năng lượng, quản lý chi tiết các bô ̣ nhớ, đáp ứng được thời gian thực…
Dưới đây là danh sách các hê ̣ điều hành dành cho ma ̣ng cảm biến không dây [3]:
Ta xem xét 2 hê ̣ điều hành được xem là có đô ̣ phổ biến và có tính năng nổi bâ ̣t hơn là:
TinyOS là một hệ điều hành nguồn mở được thiết kế dành riêng cho các thiết bị tiết kiệm năng lượng Hệ điều hành này thường được sử dụng trong các mạng cảm biến không dây, hệ thống nhúng, nhà thông minh và đồng hồ đo thông minh.
TinyOS bắt đầu với sự cộng tác giữa Trường đại học University of California, Berkeley với Viện nghiên cứu của Intel và công ty Crossbow Technology Hiện đã phát triển thành một hiệp hội quốc tế TinyOS (TinyOS Alliance)
TinyOS được xây dựng trên nền ngôn ngữ nesC (network embedded systems C), một loại ngôn ngữ mới dựa trên C nhưng theo mô hình kiến trúc component- based và event-driven Ngôn ngữ nesC là ngôn ngữ được dung trong hệ điều hành TinyOS
14 Ngoài ra, Tiny OS còn phát triển ứng du ̣ng go ̣i là tinyDB, là ứng du ̣ng cho viê ̣c quản lý dữ liê ̣u, có thể coi là mô ̣t hê ̣ quản tri ̣ cơ sở dữ liê ̣u Bên ca ̣nh đó còn hỗ trợ viê ̣c quản lý năng lượng, quản lý cấp phát bô ̣ nhớ Tích hợp các giao thức cơ bản nhất cho viê ̣c truyền nhâ ̣n dữ liê ̣u…
Contiki [16] [17]là hê ̣ điều hành mở được thiết kế cho hệ thống network, cho những hê ̣ thống có ràng buô ̣c về bô ̣ nhớ, cũng như viê ̣c tiết kiê ̣m năng lượng
Contiki được áp du ̣ng rô ̣ng rãi trong các ngành, lĩnh vực về quản lý hê ̣ thống đèn đường, âm thanh trong các thành phố thông minh, các hê ̣ thống chăm sóc sức khỏe, hê ̣ thống cảnh báo…Contiki được ta ̣o ra bởi Adam Dunkels vào năm 2002, và sau đó được phát triển bởi các team của Atmel, Cisco, Enea, ETH Zurich, Redwire, RWTH Aachen University, Oxford University, SAP, Sensinode, SICS, ST Microelectronics, Zolertia và các cô ̣ng đồng ma ̣ng Contiki
Contiki được viết dựa trên ngôn ngữ C và tích hợp sẵn 3 network stack cho viê ̣c truyền nhâ ̣n dữ liê ̣u: 6lowpan stack cho IPv6, uIP TCP/IP stack cho ipv4 và
Rime cung cấp các giao thức truyền nhâ ̣n đơn giản
Cả 2 hê ̣ điều hành đều đáp ứng các yêu cầu của đề tài, do đó sẽ tiến hành thử nghiê ̣m về đô ̣ ổn đi ̣nh và tính dễ phát triển, dễ triển khai chương trình của hê ̣ điều hành rồi từ đó đưa ra sự lựa cho ̣n hê ̣ điều hành nào phù hợp với ứng du ̣ng của đề tài hơn Sau quá trình thử nghiê ̣m, đề tài đã cho ̣n Contiki làm hê ̣ điều hành để phát triển cho ma ̣ng cảm biến không dây vì nó ổn đi ̣nh và dùng ngôn ngữ C nên dễ phát triển chương trình mà không cần tốn thêm thời gian để ho ̣c và vâ ̣n du ̣ng ngôn ngữ mới NesC như bên TinyOS.
Network stack
Khác với network stack cho ma ̣ng máy tính, network stack trong ma ̣ng cảm biến không dây không có nhiều chuẩn và đa da ̣ng Tuy nhiên, vẫn có các chuẩn được dùng rô ̣ng rãi sau:
Các chuẩn được đề câ ̣p ở trên đều có các chức năng đầy đủ của mô ̣t network stack để giúp chuyển gói tin trên đường đi Bên ca ̣nh đó, nó còn cung cấp cơ chế truyền nhiều đoạn (multi hop) để có thể truyền xa khi khoảng cách từ nguồn đến đích vượt quá khoảng cách mà mô ̣t node có thể truyền Ngoài ra, các chuẩn này còn cung cấp cơ chế thức/ngủ radio Nhờ có cơ chế này, ta có thể tiết kiê ̣m được năng lượng khi hê ̣ thống không thu thâ ̣p dữ liê ̣u, đảm bảo nguồn năng lượng cho viê ̣c hê ̣ thống cha ̣y liên tu ̣c từ năm này sang năm khác
Trong lúc khảo sát hê ̣ điều hành, đề tài đã đưa ra quyết đi ̣nh cho ̣n hệ điều hành
Contiki cũng mô ̣t phần do 6loWPAN [19] Network stack này dùng hê ̣ thống đi ̣a chỉ
IPv6 là hê ̣ thống đang được triển khai hiê ̣n nay Ngoài ra, nó còn đưa ra khái niê ̣m
Thuật ngữ "Internet vạn vật" mô tả hiện tượng mà các thiết bị hệ thống nhúng có thể trực tiếp kết nối và truy cập internet, giống như các thiết bị điện tử thông minh hiện đại.
Các công trình nguyên cứu liên quan
Internet of Things (IoT) [20] [21] [22] là thuâ ̣t ngữ được đề xuất bởi Kevin Ashton vào năm 1999 Đây là thuâ ̣t ngữ thể hiê ̣n xu hướng mới hiê ̣n nay IoT nói về sự kết hợp những thiết bi ̣ nhúng, những thiết bi ̣ ha ̣n chế về tài nguyên có thể kết nối vào internet Trước đây, các thiết bi ̣ nhúng chỉ đơn thuần hoa ̣t đô ̣ng offline, mức đô ̣ giao tiếp trực tiếp với internet bên ngoài rất ít Do đó, viê ̣c tương tác với các thiết bi ̣ nhúng lúc bấy giờ sẽ khó khăn Ngày nay, IoT đưa ra các kết nối phù hợp với các thiết bi ̣, các hê ̣ thống, các di ̣ch vu ̣ nên viê ̣c tương tác với các thiết bi ̣ nhúng dễ dàng hơn Viê ̣c hàng tỷ thiết bi ̣ nhúng kết nối được internet giúp hình thành ma ̣ng lưới rô ̣ng lớn và có thể áp du ̣ng trong nhiều lĩnh vực khác nhau
Hiê ̣n nay, hầu hết các lĩnh vực đều có sự xuất hiê ̣n của các thiết bi ̣ hê ̣ thống nhúng Do đó, các ứng du ̣ng IoT có thể áp du ̣ng cho nhiều lĩnh vực như các hê ̣
Có 16 bộ phận giám sát điều kiện môi trường, hệ thống quản lý cơ sở hạ tầng, các ứng dụng trong công nghiệp, quản lý giao thông…
2.4.2 Chuẩn truyền nhâ ̣n trong ma ̣ng cảm biến không dây
IoT dùng đi ̣a chỉ IP để xác đi ̣nh thiết bi ̣, nhưng hiê ̣n nay không gian đi ̣a chỉ
Ipv4 đang ha ̣n he ̣p Do đó, Hue và Culler đề xuất đi ̣a chỉ Ipv6 cho ma ̣ng cảm biến không dây [23] Họ đã chứng minh ma ̣ng cảm biến không dây dựa vào đi ̣a chỉ Ipv6 có thể đảm bảo các thuô ̣c tính như đô ̣ trễ, thời gian sống của gói tin, tốc đô ̣ thu nhâ ̣n dữ liê ̣u… Tuy nhiên, viê ̣c phát triển các ứng du ̣ng dựa trên network stack dùng Ipv6 còn chưa hiê ̣n thực được trên nền Ipv6 Sau đó, Shelby đề xuất áp du ̣ng kiến trúc dùng cho các di ̣ch vu ̣ web (REST architecture) [24] vào trong ma ̣ng cảm biến không dây Shelby đề xuất viê ̣c sử du ̣ng giao thức giống như giao thức html để xây dựng các di ̣ch vu ̣ truyền nhâ ̣n trên các thiết bi ̣ cảm biến (giao thức đó go ̣i là
2.4.3 Giao thức ở lớp ứng du ̣ng trong ma ̣ng cảm biến không dây
Tùy thuô ̣c vào yêu cầu đă ̣c thù ứng du ̣ng mà đă ̣t ra các giao thức cho lớp ứng du ̣ng khác nhau Dưới đây là các lớp ứng du ̣ng đã được đề xuất dùng trong ma ̣ng cảm biến không dây [25]
Sensor management protocol (SMP): giao thứ c này truy xuất các node thông qua các thuâ ̣t tính dựa vào tên (attribute-based naming) và đi ̣a chỉ local (local-based addressing) củ a node đó Giao thức SMP cung cấp các task như: o Cung cấp các tâ ̣p luâ ̣t cho viê ̣c tổng hợp dữ liê ̣u o Trao đổi dữ liê ̣u thông qua giải thuâ ̣t tìm kiếm cu ̣c bô ̣ o Đồng bô ̣ thời gian giữa các node o Điều khiển viê ̣c tắt/mở cảm biến o Truy xuất các cấu hình của ma ̣ng cảm biến, các tra ̣ng thái của các node và tái cấu hình la ̣i ma ̣ng cảm biến o Quản lý viê ̣c di chuyển của node o Xác thực và bảo mâ ̣t dữ liê ̣u trên kênh truyền
Task assignment and data advertisment Protocol (TADAP): giao thứ c thường được áp du ̣ng trong viê ̣c routing Mô ̣t node có thể gởi mô ̣t sự kiê ̣n, mô ̣t thuô ̣c tính nào đó của nó đến node khác hoă ̣c đến mô ̣t phần hay toàn bô ̣ ma ̣ng
Ngoài ra, nó còn quảng cáo các biến dữ liê ̣u của nó đến người dùng Từ đó, người dùng có thể truy xuất các thông tin mà ho ̣ quan tâm
Giao thức truy vấn cảm biến và truyền phát dữ liệu (SQDDP) cung cấp khuôn khổ để phát ra truy vấn, phản hồi lại truy vấn và thu thập phản hồi Một ứng dụng dựa trên SQDDP là "ngôn ngữ truy vấn và nhiệm vụ cảm biến" Ứng dụng này hỗ trợ ba loại sự kiện được xác định bằng ba từ khóa: "nhận", "mỗi" và "hết hạn".
Giao thức Constrained Application Protocol
Giới thiê ̣u
Ngày nay các ứng du ̣ng internet trên nền web service đều dựa vào kiến trúc cơ bản là kiến trúc Representational State Transfer (REST) [26] [24] Để áp du ̣ng kiến trúc REST cho các thiết bi ̣, hê ̣ thống ha ̣n chế về tài nguyên người ta đi ̣nh nghĩa ra Constrained RESTful Enviroments (CoRE) hay còn go ̣i là Constrained application protocol [25] [27] (CoAP)
CoAP là mô ̣t giao thức đă ̣c biê ̣t cho viê ̣c truyền nhâ ̣n dựa vào nền web (web transfer) và được thiết kế cho các nodes, các ma ̣ng có giới ha ̣n gới ha ̣n về tài nguyên Các nodes trong hê ̣ thống nhúng thường ha ̣n chế dung lượng RAM và
ROM Các network stack cho các ma ̣ng giới ha ̣n về tài nguyên như IPv6 thông qua ma ̣ng không dây năng lượng thấp (Ipv6 over low-power wireless personal area networks) thường có tỉ lê ̣ lỗi khi truyền cao Do đó, CoAP được thiết kế để ha ̣n chế các vấn đề trên Ngoài ra, CoAP còn được thiết kế cho ứng du ̣ng da ̣ng machine-to- machine (M2M) [22] như các ứng du ̣ng về năng lượng thông minh, nhà tự đô ̣ng…
CoAP còn cung cấp các mô hình tương tác yêu cầu/phản hồi (request/response) giữa các ứng du ̣ng đầu cuối, hỗ trợ dịch vụ phát hiện tài nguyên (discovery resources/services) Ngoài ra, CoAP còn cung cấp các Uniform resource identifier (UIRs) để xác đi ̣nh các di ̣ch vu ̣ và tài nguyên cha ̣y trên các thiết bi ̣ CoAP được thiết kế để dễ dàng giao tiếp với HTTP nhằm tích hợp lên web service nhưng vẫn đảm bảo các yêu cầu như ít overhead, dùng những cơ chế đơn giản.
Format của CoAP
Gói tin CoAP (CoAP message) được mã hóa như định dạng được mô tả trong hình 3-1
Ver T TKL Code Message ID
Token (if any, TKL bytes) Options (if any)
Hình 3-1 Format của CoAP message
Gói CoAP được cấu trúc gồm 4 byte header cố định dẫn đầu, theo sau là Token có độ dài biến đổi (từ 0 đến 8 byte) nếu có Tiếp đến là các tùy chọn dựa trên trường TLV (kiểu-độ dài-giá trị), nếu có Cuối cùng, gói CoAP có thể bao gồm cả phần tải trọng (payload) nếu cần.
Trong header các trường chia ra thành:
Version (Ver): trường 2 bit unsigned integer, chỉ CoAP version Hiê ̣n ta ̣i giá tri ̣ mă ̣c đi ̣nh của version là 10 binary, các giá tri ̣ khác được dùng cho sau này
Nếu message không xác đi ̣nh được version thì message đó sẽ được bỏ qua mà không có thông báo hay phản hồi nào
Type (T): trườ ng 2 bit unsigned integer, xác đi ̣nh các kiểu message bao gồm Confirmable, Non-Confirmable, Acknơledgment hay Reset
Token length (TKL) là trường 4 bit unsigned integer xác định chiều dài của trường Token TKL xác định từ 0 đến 8 byte của trường Variable-length Token, các giá trị từ 9-15 được dùng cho sau này, và sẽ được đánh dấu là lỗi message khi dùng giá trị từ 9 – 15.
Code: trườ ng 8 bit unsigned integer, được chia thành 2 nhóm Đó là nhóm 3 bit cao gọi là class và nhóm 5 bit thấp go ̣i là detail và được biểu diễn như là
“c.dd” Giá tri ̣ của c từ 0 đến 7, giá tri ̣ của dd từ 0 đến 31 Bảng 3-1 biểu diễn mã phản hồi từ server về client
20 Bảng 3-1 Mã phản hồi từ CoAP server
4.00 Bad Request 4.01 Unauthorized 4.02 Bad Option
4.05 Method Not Allowed 4.06 Not Acceptable 4.12 Precondition Failed 4.13 Request Entity Too Large 4.15 Unsupported Content-Format 5.00 Internal Server Error
5.03 Service Unavailable 5.04 Gateway Timeout 5.05 Proxying Not Supported
3.00 – 331 Để dùng cho sau này Các giá tri ̣ khác Chưa gắn chức năng
Message ID: trường số nguyên dương 16 bit, dùng để xác đi ̣nh sự trùng lă ̣p gói tin và để xác đi ̣nh că ̣p yêu cầu và phản hồi (response và request).
Phương thức truyền nhâ ̣n dữ liê ̣u
Mô hình giao tiếp/tương tác của CoAP cũng tương tự mô hình client-server của giao thức http Khi client gởi mô ̣t gói tin đến server thì nó dùng một trong các phương thức GET, PUT, POST, DELETE, các dịch vụ trong CoAP được xác đi ̣nh bằng URI Server sẽ phản hồi (response) la ̣i client mô ̣t mã phản hồi (response code)
CoAP dùng cố đi ̣nh 4 byte header, theo sau header là các tùy chọn và payload (options và payload) Bên trong 4 byte header của CoAP có 1 trường 16 bit là message identifier (MID), trườ ng này là trường xác định gói tin CoAP, nhằm mu ̣c đích phát hiê ̣n trùng lă ̣p gói tin hoă ̣c dùng để tăng tính tin câ ̣y của viê ̣c truyền nhâ ̣n Để đơn giản trong quá trình thiết kế, CoAP dùng giao thức UDP trong viê ̣c truyền nhâ ̣n dữ liê ̣u Vì giao thức UDP là giao thức không tin câ ̣y Do đó, để tăng tính tin
21 câ ̣y của viê ̣c truyền nhâ ̣n dữ liê ̣u, CoAP đi ̣nh nghĩa 4 kiểu truyền message sau:
Confirmable, Non-confirmable, Acknowledgement, Reset
Giao thức truyền tin đáng tin cậy (CON) đảm bảo tính tin cậy cao trong quá trình truyền nhận Khi máy khách gửi yêu cầu đến máy chủ, nếu yêu cầu không đến đích thì máy khách sẽ gửi lại sau một khoảng thời gian chờ (timeout), tăng dần theo hàm mũ back-off ở mỗi lần gửi lại Máy khách sẽ liên tục gửi lại yêu cầu cho đến khi nhận được phản hồi từ máy chủ có cùng ID tin nhắn hoặc vượt quá số lần gửi lại tối đa (k).
Non-confirmable (NON): dù ng cho viê ̣c truyền nhâ ̣n mà không quan tâm đến tính tin câ ̣y Client chỉ gởi một yêu cầu duy nhất đến server và không cần quan tâm đến viê ̣c server có nhận được hay là không nhận được yêu cầu đó Tuy không quan tâm đến viê ̣c gói yêu cầu từ client có đến được server hay không nhưng gói yêu cầu trong kiểu NON message cũng chứa số MID để phát hiê ̣n trùng gói tin Kiểu message này thường được dùng cho những việc thu thâ ̣p dữ liê ̣u lă ̣p đi lă ̣p la ̣i như là thu tập các điều kiện ở môi trường xung quanh và gởi về cho gateway theo chu kỳ
Acknowledgement (ACK): dù ng cho viê ̣c xác đi ̣nh loại tin nhắn confirmable đã đi đến được đích bằng cách gởi la ̣i gói phản hồi (acknowledgement) ngược lại cho client
Reset (RST): dù ng cho viê ̣c xác đi ̣nh là gói confirmable hay gói Non- Confirmable đã đến được đích nhưng bên nhâ ̣n gă ̣p mô ̣t số vấn đề khi xử lý gói tin đó Điều này thường xảy ra khi server sau khi khởi động lại và bỏ qua 1 số tra ̣ng thái để xử lý gói tin nhâ ̣n đến Ngoài ra ta có thể dùng gói tin reset để kiểm tra viê ̣c còn sống của 1 node nào đó
Tổng kết 4 kiểu message dùng trong viê ̣c truyền nhâ ̣n Ký tự “*” có nghĩa là gói tin rỗng (empty) có thể dùng trong lúc gởi nhâ ̣n thông thường mà còn dùng trong gói tin reset như là gói CoAP ping
Bảng 3-2 Tổng kết các kiểu message tương ứng với từng trường hợp
22 CoAP còn thiết kế cơ chế cho viê ̣c đáp ứng la ̣i từ server Khi server nhâ ̣n request từ client, nếu ngay sau đó server gởi phản hồi đến client Phản hồi này được go ̣i là “piggybacked response” Khi server nhâ ̣n được yêu cầu từ client mà server không thể phản hồi lại ngay lúc đó, khi đó server sẽ phản hồi la ̣i mô ̣t gói tin empty ACK đến client Lúc đó, client sẽ ta ̣m dừng gởi la ̣i gói yêu cầu đến server cho đến khi server gởi la ̣i gói CON message đến client Phản hồi này được go ̣i là “separate response” send packet
Hình 3-2 Kiểu truyền nhâ ̣n không tin câ ̣y a) Client gở i yêu cầu nhưng bi ̣ mất b) Client gởi yêu cầu và được phản hồi từ server send packet resend response (d)
2 n x Time In terval send packet resend resend n times
Hình 3-3 Kiểu truyền nhâ ̣n tin câ ̣y c) Client gở i yêu cầu nhưng bi ̣ mất d) Client gởi yêu cầu và được phản hồi từ server.
Thời gian đáp ứng chương trình
Đối với viê ̣c truyền nhâ ̣n dữ liê ̣u tin câ ̣y, sau khi client gởi gói yêu cầu đến server, nó sẽ chờ phản hồi từ server Nếu server phản hồi ngược la ̣i cho client và client nhâ ̣n được phản hồi đó, client sẽ kết thúc quá trình truyền nhâ ̣n Nếu client
23 chưa nhâ ̣n được gói phản hồi từ server khi quá khoảng thời gian xác định trước thì client sẽ gởi la ̣i yêu cầu cho server, và sau đó nó sẽ nhân đôi thời gian chờ lên, viê ̣c này lă ̣p la ̣i cho đến khi client nhâ ̣n được phản hồi từ server hay khi số lần gởi của nó bằng mô ̣t số k cho trước, rồi kết thúc quá trình truyền nhâ ̣n dữ liê ̣u
Thời gian tính từ lúc bắt đầu gởi request của client cho đến lúc client kết thúc quá trình gởi được go ̣i là thời gian đáp ứng của chương trình (application response time) Thời gian đáp ứng được tính bằng công thức:
tx Rx Idle response Time Time Time
K cha ̣y từ 1 đến N, với N là số là tối đa gởi la ̣i gói tin
Time transmit là thời gian 1 lần gởi yêu cầu
Interval time là thời gian giữa 2 lần gởi liên tiếp Interval time ban đầu được tính bằng công thức:
Interval time = response timeout + (random() % timeout back-off mask) (2)
Interval time sẽ được nhân đôi sau khi mỗi lần gởi
Bảng 3-3 mô tả các thông số mă ̣c đi ̣nh được dùng để tính toán trong viê ̣c truyền nhâ ̣n dữ liê ̣u
Bảng 3-3 Các thông số trong viê ̣c truyền nhâ ̣n dữ liê ̣u theo chuẩn CoAP
Tên thông số Giá tri ̣ mă ̣t đi ̣nh
Thiết kế hê ̣ thống
Thiết kế kiến trúc tổng quát của ma ̣ng cảm biến không dây
Dựa trên vai trò của từng node, hệ thống được chia thành 3 loại chính: node cảm biến, gateway và router Thiết kế mỗi loại node cần phù hợp với vai trò cụ thể của chúng, đảm bảo sự hoạt động hiệu quả và trơn tru của hệ thống tổng thể.
4.1.1 Kiến trúc tổng quát của node cảm biến
Nhiệm vụ chính của node cảm biến là thu thập các điều kiện môi trường xung quanh, chuyển dữ liệu thu thập được lên gateway Tuy nhiên, node cảm biến gặp phải vấn đề về năng lượng vì các vị trí đặt node cảm biến thường ở những nơi hạn chế về nguồn điện trực tiếp như trên mặt nước, trong rừng, trên các công trình cầu cống Việc thay thế nguồn năng lượng ở trong những trường hợp đó thường khó khăn và gây ra sự gián đoạn trong hệ thống Dựa trên các nhiệm vụ và vấn đề gặp phải của node cảm biến, chúng tôi đưa ra kiến trúc tổng quát như hình 4.1.
Hình 4-1 Kiến trúc tổng quát của mô ̣t node cảm biến
Senssing: làm nhiê ̣m vu ̣ thu thâ ̣p các thông số điều kiê ̣n môi trường xung quanh rồi chuyển các thông số đó qua cho CoAP client dưới sự điều khiển của controller Sau khi chuyển các thông số đó cho CoAP, sensing sẽ yêu cầu hê ̣ cơ sở dữ liê ̣u lưu la ̣i các dữ liê ̣u đó để truy xuất la ̣i khi các dữ liê ̣u gởi lên gateway không thành công
Power management: nhiệm vu ̣ chính là quản lý viê ̣c thức/ngủ của cả hê ̣ thống nhằm mu ̣c đích giảm thiểu năng lượng tiêu thu ̣ Bên ca ̣nh đó, nó cũng đóng vai trò điều khiển các di ̣ch vu ̣ khác trong node cảm biến
CoAP client thực hiện dịch vụ CoAP để truyền nhận dữ liệu, cấu hình node cảm biến tới gateway qua stack mạng Ngoài ra, CoAP client còn có thể truy cập đến hệ cơ sở dữ liệu để truy vấn dữ liệu hoặc cấu hình được lưu trữ trong hệ cơ sở dữ liệu đó.
Database: hệ quản tri ̣ cơ sở dữ liê ̣u, cung cấp các di ̣ch vu ̣ cơ bản trong viê ̣c truy xuất dữ liê ̣u
Network stack: cung cấp các di ̣ch vu ̣ về ma ̣ng để hê ̣ thống có thể giao tiếp với các thiết bi ̣ khác
Uart: interface dù ng để debug hoă ̣c dùng để cấu hình các thông số trong node cảm biến
4.1.2 Kiến trúc tổng quát của gateway
Nhiê ̣m vu ̣ chính của gateway là thu thâ ̣p các dữ liê ̣u gởi lên từ node cảm biến, kết nối ma ̣ng cảm biến không dây với internet, quản lý và điều hành ma ̣ng cảm biến không dây Khác với node cảm biến, gateway thường được đă ̣t trong môi trường có nguồn điê ̣n trực tiếp như trong nhà, trên các bờ của hồ nuôi tôm Do đó, gateway thường không gă ̣p phải các vấn đề về năng lượng Dựa trên các nhiê ̣m vu ̣ của gateway, chú ng tôi đưa ra kiến trúc tổng quát như hình 4-2
Hình 4-2 Kiến trúc tổng quát của mô ̣t gateway
Controller: đóng vai trò là trung tâm điều kiển của gateway
CoAP server: cung cấp các di ̣ch vu ̣ của CoAP để cho CoAP client từ node cảm biến dù ng trong viê ̣c truyền nhâ ̣n dữ liê ̣u cũng như các thông số cấu hình của node cảm biến lên gateway thông qua network stack Coap server cũng có thể truy xuất vào hê ̣ cơ sở dữ liê ̣u để truy vấn dữ liê ̣u hoă ̣c các cấu hình được lưu trong hê ̣ cơ sở dữ liê ̣u đó
Database: hệ quản tri ̣ cơ sở dữ liê ̣u, cung cấp các di ̣ch vu ̣ cơ bản trong viê ̣c truy xuất dữ liê ̣u
Network stack: cung cấp các di ̣ch vu ̣ về ma ̣ng để hê ̣ thống có thể giao tiếp với các thiết bi ̣ khác
Uart: interface dù ng để debug hoă ̣c dùng để cấu hình các thông số trong node cảm biến
Module SIM900: dùng di ̣ch vu ̣ ma ̣ng viễn thông để truyền dữ liê ̣u ra ngoài internet Từ đó, người dùng có thể truy xuất các dữ liê ̣u đó trên website hoă ̣c trên ứng du ̣ng điê ̣n thoa ̣i di đô ̣ng Ngoài ra, module SIM900 còn cung cấp các cú pháp giúp người dùng có thể điều chỉnh các thông số trong ma ̣ng cảm biến không dây
4.1.3 Kiến trúc tổng quát của router
Router có vai trò cơ bản là định tuyến các gói tin, giúp mở rộng khoảng cách giao tiếp giữa các thiết bị đầu cuối (node cảm biến) với trung tâm kiểm soát (gateway).
Cũng giống như gateway, router thường sẽ không gă ̣p các vấn đề về năng lượng vì nó thường đă ̣t gần nguồn năng lượng trực tiếp Do đó, kiến trúc của mô ̣t router khá đơn giản, chỉ có phần network stack cho viê ̣c truyền nhâ ̣n gói tin và được miêu tả trong hình 4-3
27 Hình 4-3 Kiến trúc tổng quát của mô ̣t router
4.1.4 Cách thức giao tiếp trong ma ̣ng cảm biến không dây
Bên ca ̣nh viê ̣c thiết kế kiến trúc cho từng loa ̣i node, chúng tôi còn đưa ra cách thức giao tiếp các node trong ma ̣ng cảm biến không dây hoă ̣c giữa ma ̣ng cảm biến không dây và ma ̣ng internet Hình 4-4 mô tả cách thức giao tiếp đó Các nét màu đỏ thể hiê ̣n viê ̣c giao tiếp bên ngoài node Các nét màu xanh thể hiê ̣n sự tương tác bên trong của mô ̣t node Trong hình, ta thấy node cảm biến có thể giao tiếp trực tiếp với gateway bằng nét đứt hoă ̣c có thể giao tiếp với gateway thông qua router bằng nét liền Viê ̣c giao tiếp giữa gateway và ma ̣ng internet sẽ do SIM900 đảm nhâ ̣n thông qua các di ̣ch vu ̣ ma ̣ng viễn thông cung cấp
Hình 4-4 Kiến trúc tổng quát của hê ̣ thống ma ̣ng cảm biến không dây
Thiết kế các tài nguyên CoAP
Chúng tôi cung cấp các dịch vụ tài nguyên để trao đổi dữ liệu và các thông số cấu hình Dưới đây là danh sách các tài nguyên phục vụ cho trao đổi dữ liệu và các thông số cấu hình:
Configuration resource là di ̣ch vu ̣ dùng để gởi thông tin cấu hình của node cảm biến lên gateway Configuration resource dùng URI là “/config” để đi ̣nh danh tài nguyên trên server Configuration resource dù ng phương thức PUT trao đổi
Configuration resource sẽ dùng kiểu trao đổi tin câ ̣y CON message để truyền thông tin Nhằm mu ̣c đích đảm bảo rằng gateway sẽ nhâ ̣n thông tin cấu hình từ node tương ứng Node cảm biến sẽ gởi cấu hình của nó đến gateway khi nó vừa mới khởi đô ̣ng lên hoă ̣c có sự thay đổi về phần cứng như thay sensor khác loa ̣i, sensor bi ̣ hư
… Các thông tin cấu hình của node cảm biến gởi lên gateway bao gồm:
ID của node cảm biến (node ID): dùng để xác đi ̣nh node nào gởi
ID của hồ (pond ID): dùng để xác đi ̣nh node đó thuô ̣c khu vực quản lý của hồ, khu vực nào
Số lượng cảm biến (Number of sensor devices): số lượng các cảm biến (sensor) hiện ta ̣i đang hoa ̣t đô ̣ng trên node cảm biến
Các ID của các cảm biến (device IDs): xác đi ̣nh các ID của các cảm biến đang hoa ̣t đô ̣ng có trên node cảm biến
Các đơn vi ̣ đo (unit of sensor devices): xác đi ̣nh đơn vi ̣ đo hiê ̣n ta ̣i của cảm biến tương ứng có trên node cảm biến
Ngưỡng cảnh báo (warning – alarm thresholds): đối với mỗi cảm biến khác nhau thì sẽ có các mức cảnh báo khác nhau Trong mô ̣t cảm biến sẽ có 2 mức đô ̣ cảnh báo cơ bản là cảnh báo và báo đô ̣ng Dùng 8 giá tri ̣ để xác đi ̣nh cách chia các cảnh báo trên 8 giá tri ̣ sẽ chia thành 4 nhóm: o Nhóm báo động khi vượt qua giá tri ̣ đi ̣nh trước: nhóm này có 2 giá tri ̣
Vượt qua giá tri ̣ câ ̣n trên sẽ gởi báo đô ̣ng đến người dùng Dưới mức giá tri ̣ câ ̣n dưới sẽ hủy viê ̣c gởi báo đô ̣ng đến người dùng o Nhóm cảnh báo khi vượt qua giá tri ̣ đi ̣nh trước: nhóm này có 2 giá tri ̣
Vượt qua giá tri ̣ cao sẽ gởi cảnh báo đến người dùng Dưới mức giá tri ̣ thấp sẽ hủy viê ̣c gởi cảnh báo đến người dùng o Nhóm cảnh báo khi nằm dưới giá tri ̣ đi ̣nh trước: nhóm này có 2 giá
29 tri ̣ Nằm dưới giá tri ̣ câ ̣n dưới sẽ gởi cảnh báo đến người dùng Nằm trên mức giá tri ̣ câ ̣n trên sẽ hủy viê ̣c gởi cảnh báo đế người dùng o Nhóm báo động khi nằm dưới giá tri ̣ đi ̣nh trước: nhóm này có 2 giá tri ̣ Nằm dưới giá tri ̣ câ ̣n dưới sẽ gởi báo đô ̣ng đến người dùng Nằm trên mức giá tri ̣ câ ̣n trên sẽ hủy viê ̣c gởi báo đô ̣ng đế người dùng
Trong các cấu hình cần gởi trên, hê ̣ thống sẽ chia ra thành nhiều lần gởi cấu hình đến gateway Lần đầu, hê ̣ thống sẽ gởi các thông tin: ID của node, ID của hồ, số lượng cảm biến đang hoa ̣t đô ̣ng, version của hê ̣ thống trong header, phần payload sẽ gởi các id của các cảm biến và các đơn vi ̣ tương ứng mà các cảm biến đó đang dùng Ở những lần gởi tiếp theo, hê ̣ thống sẽ gởi 8 mức cảnh báo ứng với các cảm biến tương ứng Mỗi cảm biến và cảnh báo của nó được gởi trong cùng mô ̣t gói tin
Ví du ̣ về configuration resource, trong hình 2-1 ta có node 2 thuô ̣c hồ 1, node này có 4 cảm biến là nhiê ̣t đô ̣ (sensor ID là 1101, đơn vi ̣ của cảm biến nhiê ̣t đô ̣ là
0C), pH (sensor ID là 1201, đơn vi ̣ của cảm biến pH là NULL), DO (sensor ID là
1301, đơn vị của cảm biến oxy là mg/l) và NH 3 (sensor ID là 1401, đơn vi ̣ của cảm biến NH3 là mg/l) Khi đó, nó sẽ gởi các gói tin có thông tin sau đến gateway Ban đầu nó sẽ gởi các gói tin có header là: nodeId=1&PondId=1&numberofDev=2, có payload là: &ss1Id01&Unit1ID=1 &ss2Id01&Unit2ID=5
Mỗi "unit" trong gói tin tương ứng với một đơn vị định trước (ví dụ: unit = 1 là 0 độ C, unit = 2 là 0 độ F, ) Sau khi thành công với gói tin đầu, cảm biến node tiếp tục gửi các gói tin sau với tiêu đề là "nodeId=1&ss1Id=ssss", còn nội dung là "alarmHigh&alarmLow&alarmHightamp&alarmLowamp&alarmHightamp&alarmLow&alarmHigh=gg&alarmLow=hh" Trong đó, các giá trị aa, bb, cc, dd, ee, ff, gg, hh là các mức cảnh báo của cảm biến có ID là ssss, đã được trình bày ở phần trước Hệ thống sẽ tiếp tục gửi cho đến khi tất cả các cảm biến đang hoạt động đều gửi mức cảnh báo của mình đến cổng.
Report resource là di ̣ch vu ̣ dùng để gởi các thông số về điều kiê ̣n môi trường nơi node cảm biến giám sát đến gateway Report resource dùng URI là “/report” để
30 đi ̣nh danh tài nguyên trên server Report resource dùng phương thức POST trao đổi
Vì bản chất của report là thu thâ ̣p các thông số về điều kiê ̣n môi trường xung quanh, điều này diễn ra có tính chất lă ̣p la ̣i và đôi khi giá tri ̣ của môi trường ở tra ̣ng thái ổn đi ̣nh Do đó, để tiết kiê ̣m năng lượng, hê ̣ thống Report resource dùng cả 2 kiểu trao đổi tin câ ̣y CON message và không tin câ ̣y NON message để truyền thông tin Khi dùng cả 2 kiểu trong trao đổi dữ liê ̣u, report resource sẽ chia ra thành 2 trường hợp là trường hợp bình thường (normal case) và trường hợp khẩn cấp (emergency case)
Trường hợp bình thường (normal case): trường hợp mà tất cả giá tri ̣ đo được của các điều kiê ̣n môi trường xung quanh nằm trong khoảng đã được đi ̣nh trước Ví du ̣ trường hợp đo nhiê ̣t đô ̣ ta ̣i hồ nuôi tôm là 35 0 C, nhiê ̣t đô ̣ sống của tôm sú là từ khoảng 28 0 C đến 30 0 C, nên 29 0 C là nhiê ̣t đô ̣ lý tưởng cho tôm Vì vâ ̣y, ta xếp trường hợp này vào trường hợp bình thường Lúc đó, report resource dùng kiểu trao đổi không cần tính tin câ ̣y NON message để gởi thông số môi trường đến gate
Trường hợp khẩn cấp (emergency case): trường hợp mà mô ̣t trong các giá tri ̣ đo được của các điều kiê ̣n môi trường xung quanh nằm ngoài khoảng đã được đi ̣nh trước Ví du ̣ trường hợp đo nhiê ̣t đô ̣ ta ̣i hồ nuôi tôm là 33 0 C Ta biết rằng ở nhiê ̣t đô ̣ đó, tôm có khả năng sẽ chết Vì vâ ̣y, ta xếp trường hợp này vào trường hợp khẩn cấp Lúc đó, report resource dùng kiểu trao đổi tin câ ̣y CON message để báo cáo thông số này cho người dùng đầu cuối
Thiết kế flowchart
Bên ca ̣nh các resource, hê ̣ thống cần xem xét cơ chế điều hành để hê ̣ thống đảm bảo hoa ̣t đô ̣ng được tốt Để giảm thiểu năng lượng, node cảm biến sẽ đi vào tra ̣ng thái ngủ khi hoàn thành công viê ̣c ở mỗi chu kỳ Nếu ta ̣i thời điểm sensor ở tra ̣ng thái ngủ mà gateway gởi gói tin đến cho sensor, gói tin đó sẽ bi ̣ mất Gateway sẽ phải liên tu ̣c gởi gói tin đó cho đến khi nào node cảm biến thức dâ ̣y và gởi phản hồi la ̣i cho gateway Điều này sẽ làm tiêu hao năng lượng của hê ̣ thống Để khắc phu ̣c hiê ̣n tượng trên, trong quá trình truyền nhâ ̣n dữ liê ̣u, hê ̣ thống được cung cấp cơ chế cho phép sensor ngủ mà đảm bảo dữ liê ̣u không bi ̣ mất và tốn ít năng lượng hơn
Hình 4-1 mô tả hoa ̣t đô ̣ng của mô ̣t node cảm biến Có 3 bước cơ bản từ lúc khởi đô ̣ng:
Bướ c cấu hình (Configuration phase): gởi cấu hình của node cảm biến đến gateway
Bướ c thiết lâ ̣p thông số (Setup phase): thiết lâ ̣p các thông số của hê ̣ thống như thời gian, chu kỳ đo…
Bước điều hành (Operating phase): thực hiê ̣n đo đa ̣c và tiến hành truyền các thông số đó về gateway
Reaction poll cmd Operation phase Configuration phase Request time response N
Measure environmental conditions Wake up
Hình 4-5 Flowchart điều khiển hoa ̣t đô ̣ng của node cảm biến
Khi node cảm biến hoàn tất viê ̣c khởi đô ̣ng, nó sẽ chuyển vào phần cấu hình
Trong phần này, nó sẽ gởi thông tin cấu hình đến gateway Các thông tin cấu hình bao gồm node ID, thông tin hồ nào, số lượng cảm biến (sensor) đang hoa ̣t đô ̣ng trên node, các cảm biến ID đang hoa ̣t đô ̣ng trên node đó, các đơn vi ̣ của mỗi cảm biến đang dùng Sau khi gởi thành công cấu hình trên, node cảm biến sẽ gởi trường cảnh báo ứng với mỗi thiết bi ̣ cảm ứng đang hoa ̣t đô ̣ng trên node Nếu node nhâ ̣n được phản hồi thành công từ gateway, node sẽ chuyển sang bước thiết lâ ̣p hê ̣ thống (setup phase) Nếu node không nhâ ̣n được phản hồi từ gateway, nó sẽ tiến hành ngủ và sẽ gởi la ̣i các cấu hình trên khi nó thức dâ ̣y
Trong bước thiết lâ ̣p hê ̣ thống (setup phase), node cảm biến sẽ chủ đô ̣ng go ̣i di ̣ch vu ̣ poll command với yêu cầu câ ̣p nhâ ̣t thời gian cho node đó (poll resquest
35 code = sync time) Khi nhâ ̣n được yêu cầu được câ ̣p nhâ ̣t về thời gian từ node cảm biến thông qua di ̣ch vu ̣ poll command, gateway sẽ phản hồi gói tin chứa thời gian la ̣i cho node Nếu node cảm biến nhâ ̣n được gói tin đó, nó sẽ câ ̣p nhâ ̣t la ̣i thời gian của nó và chuyển qua bước điều hành (operation phase) Nếu node không nhâ ̣n được phản hồi từ gateway, nó sẽ tiến hành ngủ và sẽ gởi la ̣i các yêu cầu câ ̣p nhâ ̣t thời gian sau khi thức dâ ̣y
Trong bước điều hành (operation phase), khi đến chu kỳ, node cảm biến sẽ thức dâ ̣y và đo đa ̣c các thông số điều kiê ̣n môi trường xung quanh Sau đó, node cảm biến sẽ gởi tín hiê ̣u alive đến gateway Nếu node cảm biến không nhâ ̣n được phản hồi từ gateway, chứng tỏ rằng đường truyền có vấn đề gì đó Khi đó, nó sẽ không cố gắng gởi la ̣i tín hiê ̣u alive mà sẽ ngủ và chờ đến khi thức dâ ̣y để gởi la ̣i tín hiê ̣u alive Nếu node cảm biến nhâ ̣n được tín hiê ̣u phản hồi từ gateway, nó sẽ dùng di ̣ch vu ̣ poll command để yêu cầu tác vu ̣ cu ̣ thể nào đó hoă ̣c để nhâ ̣n yêu cầu nào đó từ gateway Điều đó giúp node cảm biến không bỏ lỡ yêu cầu từ gateway mà vẫn có thể giảm thiểu về năng lượng Sau khi gởi poll command đến gateway, nếu node cảm biến nhâ ̣n được phản hồi của gateway, nó sẽ ghi nhâ ̣n và đáp ứng la ̣i phản hồi đó Dựa vào kết quả đo các điều kiê ̣n môi trường xung quanh, nếu các điều kiê ̣n đó bi ̣ xếp vào trường hợp khẩn cấp (emergency case), hê ̣ thống sẽ ngay lâ ̣p tức dùng kiểu truyền nhâ ̣n tin câ ̣y để gởi dữ liê ̣u đến người dùng Nếu viê ̣c gởi dữ liê ̣u bi ̣ mất, hê ̣ thống sẽ cố gắng gởi la ̣i nhiều lần để đảm bảo Nếu các điều kiê ̣n đó xếp vào trường hợp bình thường (normal case), hê ̣ thống sẽ dùng kiểu truyền nhâ ̣n không tin câ ̣y để truyền dữ liê ̣u đó đi Khi đó, nếu gateway yêu cầu gởi la ̣i mô ̣t số dữ liê ̣u bi ̣ mất, node cảm biến tiến hành gởi dữ liê ̣u đó sau khi đã gởi xong các thông số về điều kiê ̣n môi trường hiê ̣n ta ̣i
Hiê ̣n thực và thử nghiê ̣m hê ̣ thống
Hiê ̣n thực và cài đă ̣t hê ̣ thống
Chúng tôi hiê ̣n thực hê ̣ thống giám sát chất lượng nước trên nền của hê ̣ điều hành Contiki [16] [17] Hê ̣ điều hành Contiki hỗ trợ các chuẩn như 6lowpan và
CoAP cung cấp nhiều dịch vụ quan trọng: CoAP server cho gateway, CoAP client cho node cảm biến; dịch vụ configuration để cấu hình node cảm biến; dịch vụ report để gửi dữ liệu đo đạc về gateway; dịch vụ poll command để node cảm biến chủ động yêu cầu tác vụ từ gateway; dịch vụ alive để thông báo trạng thái hoạt động của node cảm biến đến gateway Ngoài ra, CoAP còn cung cấp cơ chế điều khiển chế độ ngủ/thức của node cảm biến, kiểm soát quá trình truyền nhận dữ liệu của các node trong mạng tout cho phép các node cảm biến được ngủ để tiết kiệm năng lượng.
Hệ thống được thực thi trên phần cứng là board có tích hợp mô đun truyền nhận ProFlexX01-R2 Mô đun này tích hợp bộ vi điều khiển MSP4305F5xx, bộ thu phát sóng CC2520 và bộ khuếch đại CC2591 của Texas Instruments Với các tính năng nổi trội về năng lượng, mô đun ProFlexX01-R2 là nền tảng lý tưởng cho các hệ thống cần tối ưu về năng lượng.
Hình 5-2 mô tả cấu trúc bên trong của module Proflex01
37 Hình 5-1 Platform có tích hợp module ProFlex01-R2
Hình 5-2 Cấu trúc bên trong của module Proflex01 Quá trình thử nghiê ̣m hê ̣ thống trải qua 2 giai đoa ̣n: a) Giai đoa ̣n 1
Giai đoa ̣n này chúng tôi sẽ thử nghiê ̣m hê ̣ thống trên mô phỏng dùng Cooja – Cooja là mô ̣t công cu ̣ mô phỏng ma ̣ng trên Contiki [30] Cooja tích hợp MSPsim [31], một công cu ̣ mô phỏng về bô ̣ vi điều khiển MSP340F430 và CC2520 Do đó,
Cooja có thể mô phỏng trên platform tương đương với platform hiê ̣n ta ̣i nhóm đang dùng Ngoài ra, Cooja có thể mô phỏng chính xác đến mức đô ̣ bit trong quá trình truyền nhâ ̣n radio Trong giai đoa ̣n này, nhóm sẽ xây dựng hê ̣ thống với 4 node cảm biến và mô ̣t gateway Mỗi node cảm biến có thể mô phỏng được 4 thiết bi ̣ cảm ứng: nhiê ̣t đô ̣, pH, DO, và NH 3 như hình 5-3 Mu ̣c đích của thử nghiê ̣m này là đánh giá đô ̣ đúng đắn của chương trình cũng như tìm ra những lỗi về phần mềm nhằm tiết kiê ̣m thời gian khi triển khai ra thực tế
Gian đoa ̣n 2 chúng tôi sẽ cha ̣y ứng du ̣ng trên board thâ ̣t để có thể đo đa ̣c về năng lượng, khoảng cách truyền nhâ ̣n, tỷ lê ̣ mất gói Cuối cùng đưa ra kết quả cha ̣y thực tế ở môi trường doanh nghiê ̣p Ở giai đoa ̣n này, chúng tôi sẽ dùng 4 ki ̣ch bản để test hê ̣ thống Trong mỗi ki ̣ch bản, chúng tôi tiến hành gởi gói tin report từ node cảm biến lên gateway Kiểu truyền nhâ ̣n trong ki ̣ch bản là kiểu truyền nhâ ̣n tin câ ̣y Trong hê ̣ thống giám sát, những gói tin report dữ liê ̣u là những gói cơ bản và chiếm phần lớn trong viê ̣c truyền nhâ ̣n của ma ̣ng Do đó, chúng tôi tiến hành thử nghiê ̣m đo đa ̣c các thông số dựa trên gói tin này Chiều dài của gói tin là 90 byte, đủ để truyền các thông số của 4 thiết bi ̣ cảm biến gắn trên mô ̣t node Đối với mỗi ki ̣ch bản, chúng tôi sẽ xem xét trường hợp xấu nhất và trường hợp tốt nhất Trường hợp tốt nhất là trường hợp node cảm biến gởi yêu cầu đến server và server phải hồi la ̣i ngay lâ ̣p tức Trường hợp xấu nhất là trường hợp node cảm biến gởi yêu cầu đến gateway mà gói tin đó không đến được nên client phải gởi la ̣i nhiều lần sau các khoảng thời gian interval time Các ki ̣ch bản khác nhau chủ yếu dựa vào 2 thông số là thời gian timeout (interval time) giữa 2 lần gởi yêu cầu và số lần gởi la ̣i gói tin trong kiểu truyền nhâ ̣n tin câ ̣y (các thông số này được trình bày trong phần “thời gian đáp ứng chương trình” chương 3) Các thông số cho mỗi ki ̣ch bản được trình bày trong bảng 5-1
Bảng 5-1 Các thông số cấu hình cho mỗi ki ̣ch bản thử nghiê ̣m
Thời gian interval (interval time)
Số lần thử la ̣i (number of resending)
Ki ̣ch bản 1 2 giây 4 lần
Ki ̣ch bản 2 2 giây 3 lần
Ki ̣ch bản 3 1 giây 4 lần
Ki ̣ch bản 4 1 giây 3 lần
39 Hình 5-3 Mô hình thử nghiê ̣m hê ̣ thống trên công cu ̣ mô phỏng Cooja.
Kết quả thử nghiê ̣m
5.2.1 Kết quả về dung lượng RAM, FLASH
Bảng 5-2 liê ̣t kê các yêu cầu về RAM, FLASH cho node cảm biến và gateway khi hiê ̣n thực ứng du ̣ng cho hê ̣ thống quản lý chất lượng nguồn nước trong nuôi trồng thủy sản dùng ma ̣ng cảm biến không dây
Bảng 5-2 Kích thước code và yêu cầu về bô ̣ nhớ của ứng du ̣ng trên module Proflex01
Kiểu node RAM (bytes) FLASH (bytes)
Kết quả thử nghiệm cho thấy board tích hợp mô đun Proflex01 có bộ vi điều khiển MSP430F5xx với dung lượng RAM 16KB, dung lượng Flash 256KB đáp ứng đủ yêu cầu về RAM và Flash của ứng dụng CoAP trên nền Contiki.
Kết quả có được là dùng công cu ̣ phân tích MSP430 tool chain
5.2.2 Kết quả thử nghiê ̣m về đo khoảng cách truyền nhâ ̣n và tỉ lê ̣ mất gói Để thử nghiê ̣m về khoảng cách, chúng tôi tiến hành cho sensor và node gởi gói report và thay đổi khoảng cách ở mỗi lần thử nghiê ̣m Trong thử nghiê ̣m này, chỉ đánh giá tỉ lê ̣ thành công của mô ̣t gói tin gởi đi Do , chúng tôi không thử nghiê ̣m với các ki ̣ch bản đã trình bày ở trên mà chỉ thử nghiê ̣m gởi mô ̣t gói tin UDP 90 byte dữ liê ̣u thông thường Hình 5-4 chỉ lược đồ sự tương quan giữa khoảng cách và tỉ lê ̣ rớt gói Nhâ ̣n thấy rằng, ở khoảng cách gần, tỉ lê ̣ gởi thành công cao Khi khoảng cách càng xa, tỉ lê ̣ rớt gói bắt đầu tăng nhanh
Hình 5-4 Tỉ lê ̣ mất gói khi gởi 1000 gói tin
5.2.3 Kết quả thử nghiê ̣m về năng lượng Để thử nghiê ̣m về năng lượng, chúng tôi dùng thiết bi ̣ oscilloscope để đo dòng điê ̣n khi gởi gói tin, khi nhâ ̣n gói tin và khi ở tra ̣ng thái idle Hiê ̣n ta ̣i, phòng thí nghiê ̣m chỉ có thiết bi ̣ oscilloscope dùng để đo điê ̣n thế nên không thể mắc trực tiếp oscilloscope đó cho viê ̣c đo dòng điê ̣n Vì vâ ̣y, chúng tôi mắc thêm điê ̣n trở như trong hình 5-5 để đo dòng điê ̣n tương đương cha ̣y qua board
Tỉ lệ mất gói/ khoảng cách
Tỉ lệ mât gói/ khoảng cách
Board chạy ứng d ng quản l chất lư ng nư c cho h nuôi tôm Oscilloscope
Hình 5-5 Cách đo dòng điê ̣n qua board dùng oscilloscope đo điê ̣n thế
Cường đô ̣ dòng điê ̣n của board khi truyền nhâ ̣n dữ liê ̣u được mô tả trong hình 5-6
Cường đô ̣ dòng điê ̣n lúc radio truyền là 150 mA
Cường đô ̣ dòng điê ̣n lúc radio nhâ ̣n là 30 mA
Cường đô ̣ dòng điê ̣n lúc radio ở tra ̣ng thái idle là 10 mA
5.2.3.2 Công suất Điê ̣n thế dùng trong board là 3.0 V Khi đó, ta tính được công suất của các tác vu ̣ như sau:
Công suất khi gởi mô ̣t gói tin: 450 mW
Công suất khi nhâ ̣n mô ̣t gói tin: 90 mW
Công suất khi ở tra ̣ng thái idle: 30 mW
42 Hình 5-6 Dòng điê ̣n trong lúc radio gởi, nhâ ̣n và ở tra ̣ng thái idle
5.2.3.3 Thời gian đáp ứng của chương trình
Thời gian đáp ứng của chương trình được mô tả từ hình 5-7 đến hình 5-13 và được tổng kết la ̣i thành bảng 5-3
Bảng 5-3 Thời gian đáp ứng cho các ki ̣ch bản
Trường hợp tốt nhất (giây) Trường hợp xấu nhất (giây)
43 Hình 5-7 Thời gian đáp ứng chương trình trong trường hợp tốt nhất của ki ̣ch bản 1
Hình 5-8 Thời gian đáp ứng chương trình trong trường hợp xấu nhất của ki ̣ch bản 1
44 Hình 5-9 Thời gian đáp ứng chương trình trong trường hợp tốt nhất của ki ̣ch bản 2
Hình 5-10 Thời gian đáp ứng chương trình trong trường hợp xấu nhất của ki ̣ch bản 2
45 Hình 5-11 Thời gian đáp ứng chương trình trong trường hợp tốt nhất của ki ̣ch bản 3
Hình 5-12 Thời gian đáp ứng chương trình trong trường hợp xấu nhất của ki ̣ch bản 3
46 Hình 5-13 Thời gian đáp ứng chương trình trong trường hợp tốt nhất của ki ̣ch bản 4
Hình 5-14 Thời gian đáp ứng chương trình trong trường hợp xấu nhất của ki ̣ch bản 4
Năng lượng tiêu thu ̣
Ta có công thức tính năng lượng tiêu thu ̣:
Năng lượng cơ bản chia thành 3 phần: phần gởi gói tin, phần nhâ ̣n gói tin và phần ở tra ̣ng thái chờ (idle)
Thời gian tương ứng với 3 phần của công suất: thời gian gởi yêu cầu, thời gian nhâ ̣n phản hồi và thời gian chờ (idle time)
Dựa vào công thức (1) để tính ra năng lượng khi gởi dữ liê ̣u từ sensor lên gateway cho mỗi ki ̣ch bản như trong bảng 5-4
Bảng 5-4 Năng lượng tiêu thu ̣ cho các ki ̣ch bản
Trường hợp tốt nhất (Joules) Trường hợp xấu nhất (Joules)
5.2.4 Kết qua ̉ triển khai thử nghiê ̣m bên ngoài
Chúng tôi tiến hành thử nghiê ̣m hê ̣ thống trên môi trường nuôi tôm thâ ̣t ta ̣i 2 công ty nuôi tôm sứ ở Phan Thiết và huyê ̣n Cần Giờ thành phố Hồ Chí Minh dựa theo mô hình được mô tả trong hình 5-15 Hê ̣ thống được triển khai với mô ̣t gateway và mô ̣t node cảm biến Node cảm biến có gắn 2 cảm biến pH và DO (đo đô ̣ hòa tan của oxy trong nước) Cứ mỗi 15 phút, sensor sẽ thu thâ ̣p các thông số về pH và DO và gởi về gateway Gateway có tích hợp module sim900 sẽ đưa dữ liê ̣u thu thập từ sensor lên internet thông qua ma ̣ng di đô ̣ng Người dùng có thể theo dõi các thông số điều kiê ̣n nước trên trang web hoă ̣c bằng ứng du ̣ng trên thiết bi ̣ di đô ̣ng android Các hình từ 5-16 đến 5-20 là các hình cài đă ̣t, triển khai hê ̣ thống ra môi trường thực tế
Web browser Gateway android Mobile network
Hình 5-15 Mô hình thử nghiê ̣m hê ̣ thống giám sát chất lượng nước
Hình 5-16 Node cảm biến chuẩn bi ̣ đóng hô ̣p
49 Hình 5-17 Node cảm biến đang thu thâ ̣p thông tin ta ̣i mô ̣t công ty ở Cần Giờ
Hình 5-18 Gateway trong lúc triển khai ta ̣i mô ̣t công ty ở Cần Giờ
50 Hình 5-19 Node cảm biến đang thu thâ ̣p thông tin ta ̣i mô ̣t công ty ở Bình Thuâ ̣n
Hình 5-20 Gateway được cài đă ̣t ta ̣i mô ̣t công ty ở Bình Thuâ ̣n
51 Dưới đây là đồ thi ̣ theo dõi 2 thông số oxy và pH được gởi về bởi gateway và được hiển thi ̣ từ trình duyê ̣t web
Hình 5-21 Đồ thi ̣ hiển thi ̣ nồng đô ̣ Oxy của node cảm biến 3
Hình 5-22 Đồ thi ̣ hiển thi ̣ pH của node cảm biến 3
Ta nhâ ̣n thấy rằng, thời gian đáp ứng trong trường hợp tốt nhất của 4 ki ̣ch bản tương đương nhau Năng lượng tiêu thu ̣ trong trường hợp tốt nhất của 4 ki ̣ch bản tương đương nhau Vì thời gian đáp ứng hay năng lượng tiêu thu ̣ đều phu ̣ thuô ̣c vào thời gian gởi yêu cầu, thời gian chờ giữa 2 lần thử la ̣i, và thời gian nhâ ̣n phản hồi, nên trong trườ ng hợp tốt nhất, khi mô ̣t client gởi yêu cầu đến gateway thì ngay lâ ̣p tức gateway sẽ phản hồi la ̣i Khi đó, thời gian chờ coi như là không có, thời gian gởi la ̣i yêu cầu coi như bằng 0 Vì vâ ̣y, thời gian đáp ứng của chương trình trong trường hợp tốt nhất của 4 ki ̣ch bản tương đương nhau Ngược la ̣i, thời gian đáp ứng chương trình trong trường hợp xấu nhất của ki ̣ch bản 1 lớn hơn trường hợp xấu nhất của ki ̣ch bản 4 là 4.25 lần Năng lượng tiêu thu ̣ trong trường hợp xấu nhất của ki ̣ch bản 1 lớn hơn trường hợp xấu nhất của ki ̣ch bản 4 là 1.26 lần Cả 2 đều phu ̣ thuô ̣c phần lớn vào thời gian giữa 2 lần gởi gói tin và số lần gởi la ̣i gói tin Số lần gởi la ̣i gói tin làm số lần chờ đợi tăng lên Thời gian chờ đợi giữa 2 lần gởi sẽ tăng gấp đôi mỗi khi gởi la ̣i mô ̣t yêu cầu Điều này hiển thi ̣ rõ trên các hình 5-6, 5-8, 5-10, 5-12
Dựa trên các kết quả đã trình bày về thời gian đáp ứng, năng lượng tiêu thụ của chương trình, chúng ta có thể thiết lập các thông số phù hợp nhất với yêu cầu của ứng dụng và các ràng buộc về tài nguyên trên hệ thống nhúng Điều này giúp tối ưu hóa năng lượng tiêu thụ, thời gian đáp ứng và tăng thời gian hoạt động của hệ thống.
Kết luâ ̣n
Kết luâ ̣n
Xuất phát từ những số liê ̣u thực tế là tỉ lê ̣ nuôi tôm thành công của nước ta còn thấp Một trong những nguyên nhân là hệ thống giám sát, cảnh báo về chất lượng nước chưa có, hoă ̣c nếu có cũng chỉ là những máy móc cần sự điều khiển thủ công của con người Do đó, viê ̣c quản lý, giám sát chất lượng nguồn nước hoàn toàn bi ̣ đô ̣ng, đô ̣ chính xác không cao và tốn nhiều công sức của người nuôi trồng Đề tài này thực hiê ̣n nhằm cung cấp mô ̣t hê ̣ thống giám sát chất lượng nước mô ̣t cách tự đô ̣ng, chính xác đến người dùng Nếu có những bất thường xảy ra, hê ̣ thống sẽ thông báo ki ̣p thời đến người dùng thông qua ma ̣ng điê ̣n thoa ̣i Ngoài ra, hê ̣ thống hiển thi ̣ ở da ̣ng đồ thi ̣ các thông số về điều kiê ̣n môi trường để người dùng có thể theo dõi xuyên suốt và ở bất cứ nơi nào có ma ̣ng intenet Đề tài “ Quản lý truyền nhận dữ liê ̣u trong nuôi trồng thủy sản dùng mạng cảm biến không dây ” đưa ra phương pháp áp du ̣ng chuẩn truyền nhâ ̣n dữ liê ̣u
(contrained application protocol-CoAP) dù ng trong ma ̣ng cảm biến không dây để quản lý chất lượng nước trong nuôi trồng thủy sản Đề tài cung cấp các giải pháp cho viê ̣c truyền nhâ ̣n dữ liê ̣u thu thâ ̣p từ các cảm biến về trung tâm và hiển thi ̣ cho người dùng đầu cuối Đề tài cũng tâ ̣p trung vào tối ưu năng lượng tiêu thu ̣ Chúng tôi phân tích và đánh giá thời gian đáp ứng cũng như năng lượng tiêu thu ̣ của hê ̣ thống Từ đó tìm ra những cải tiến về thời gian cũng như về năng lượng để hê ̣ thống hoa ̣t đô ̣ng được tốt hơn
Sau khi tiến hành hiê ̣n thực và triển khai thử nghiê ̣m hê ̣ thống ở công ty nuôi tôm ở huyê ̣n Cần Giờ, thành phố Hồ Chí Minh và ở huyê ̣n Lagi, tỉnh Bình Thuâ ̣n, hiê ̣n nay đề tài đã hoàn thành xong và có khả năng ứng du ̣ng vào thực tế Vì hê ̣ thống được thiết kế mô ̣t cách tổng quát, do đó, ngoài lĩnh vực quản lý chất lượng nướ c của hồ nuôi tôm, hê ̣ thống có thể dễ dàng áp du ̣ng qua các lĩnh vực khác như hê ̣ thống cảnh báo phát hiê ̣n cháy rừng, hê ̣ thống giám sát chất lượng các công trình cầu cống, hê ̣ thống nhà thông minh…
54 Bên ca ̣nh những ưu điểm của hê ̣ thống như dễ phát triển ứng du ̣ng, dễ dàng giao tiếp với các chuẩn khác bên ngoài, có thể quản lý về mức năng lượng cũng như thời gian đáp ứng, hê ̣ thống có những khuyết điểm của mình như chỉ giao tiếp theo kiểu one-to-one Do đó, khi muốn gởi đến nhiều đi ̣a chỉ phải gởi nhiều lần Điều này làm tăng năng lượng tiêu thu ̣ của hê ̣ thống Để khắc phu ̣c, hê ̣ thống cần phải cải tiến cơ chế gởi gói tin đến đi ̣a chỉ multicast nhằm mu ̣c đích giảm thiểu năng lượng.
Đi ̣nh hướng phát triển
Hiê ̣n ta ̣i hê ̣ thống chỉ cha ̣y với nguồn năng lượng là pin Trong quá trình cha ̣y, năng lượng sẽ giảm đi, do đó phải tiến hành thay thế nguồn năng lượng Điều này sẽ gây ra khó khăn và làm gián đoa ̣n sự hoa ̣t đô ̣ng của hê ̣ thống Để giải quyết vấn đề, chúng tôi sẽ tích hợp thêm hê ̣ thống năng lượng mă ̣t trời nhằm cung cấp năng lượng để duy trì lượng năng lượng tiêu hao theo thời gian Điều đó giúp hê ̣ thống có thể hoa ̣t đô ̣ng liên tu ̣c mà không cần phải thay nguồn pin Ngoài ra, chúng tôi còn hướng đến tích hợp hê ̣ thống camera GPS gắn lên các gateway hoă ̣c router để có thể xác đi ̣nh vi ̣ trí và quan sát hình ảnh thực tế của các hồ nuôi trồng thủy sản Vì các gateway và router thường được ở những nơi có nguồn điê ̣n nên sẽ không có vấn đề về năng lượng cho các webcam
Bên ca ̣nh đó hê ̣ cơ sở dữ liê ̣u cho hê ̣ thống cũng còn ở mức sơ sài Chủ yếu là viê ̣c đo ̣c và ghi trực tiếp vô Flash Điều đó gây ra những khó khăn cho viê ̣c phát triển và mở rô ̣ng hê ̣ thống Để giải quyết vấn đề đó thì hê ̣ thống sử du ̣ng hê ̣ quản tri ̣ cơ sở dữ liê ̣u cho hê ̣ thống nhúng như Antelop, SQlite, MySQL …
[1] "Vietnam Association of Seafood Exporters and Producers," [Online]
Available: http://www.seafood.vasep.com.vn
[2] Kazem Sohraby, Daniel Minoli and Taieb Znati, "Operating system for wireless sensor networks," in WIRELESS SENSOR NETWORKS - Technology, Protocols, and Applications, A John Wiley and Sons, 2007, pp 276-281
[3] M.O Farooq and T Kunz, "Operating Systems for Wireless Sensor Networks:
[4] "Msp430F5437A datasheet," [Online] Available: http://www.ti.com/product/msp430f5437A
[5] "wireless sensor network," [Online] Available: http://en.wikipedia.org/wiki/Wireless_sensor_network
[6] Kazem Sohraby, Daniel Minoli and Taieb Znati, "Introduction and Overview of Wireless Sensor Networks," in WIRELESS SENSOR NETWORKS - Technology, Protocols, and Applications, A John Wiley and Sons, 2007, pp 1-
[7] "Node cảm biến," [Online] Available: http://en.wikipedia.org/wiki/Sensor_node
[8] Kazem Sohraby, Daniel Minoli and Taieb Znati, "Basic Sensor Network Architectural Elements," in WIRELESS SENSOR NETWORKS - Technology, Protocols, and Applications, A John Wiley and Sons, 2007, pp 15-25
[9] "list of wireless node cảm biếns," [Online] Available: http://en.wikipedia.org/wiki/List_of_wireless_sensor_nodes
[10] "wireless products, proflex01-R2," [Online] Available: http://www.lsr.com/wireless-products/proflex01-r2
[11] "CC2520 Datasheet," [Online] Available: http://www.ti.com/lit/ds/swrs068/swrs068.pdf
56 http://www.ti.com/lit/ds/swrs070a/swrs070a.pdf
[13] "data sheet of ProFlex01-R2," [Online] Available: http://www.lsr.com/downloads/products/330-0098.pdf
[14] "Tiny OS home page," [Online] Available: http://www.tinyos.net/
[15] "Tiny OS," [Online] Available: http://en.wikipedia.org/wiki/TinyOS
[16] "Contiki OS home page," [Online] Available: http://www.contiki-os.org/
[17] Dunkels, A.; Gronvall, B.; Voigt, T., "Contiki - a lightweight and flexible operating system for tiny networked sensors," Local Computer Networks, 2004 29th Annual IEEE International Conference on, pp 455-462, Nov 2004
[18] Z Shelby and M Huttunen, "6LoWPAN: The Wireless Embedded," ISBN, p
[19] "Internet of things," [Online] Available: http://en.wikipedia.org/wiki/Internet_of_Things [Accessed Dec 2013]
[20] H Kopetz, "Internet of Things," in Real-Time Systems, Springer US, 2011, pp
[21] Rolf H Weber, Romana Weber, Internet of Things, Springer, 2010
[22] J W Hui and D E Culler, "IP is dead, long live IP for wireless sensor networks," in Proc 6th ACM Conf on Embedded network sensor systems (SenSys’08), 2008
[23] Z Shelby, "Embedded web services," Wireless Communications, IEEE, vol
[24] Z Shelby, K Hartke and C Bormann, " The Constrained Application Protocol (CoAP)," June 2014 [Online] Available: http://tools.ietf.org/html/rfc7252
[25] C.S Raghavendra, Krishna M Sivalingam, Taieb Znati, "Application layer porotocol for wireless sensor networks," in Wireless Sensor Networks,
[26] R Fielding, "Architectural Styles and the Design of Network-based Software Architectures," Ph.D dissertation, 2000
57 [27] Z Shelby; K Hartke and C Bormann, "Constrained Application Protocol
(CoAP)," [Online] Available: https://tools.ietf.org/html/draft-ietf-core-coap- 18 [Accessed Dec 2013]
[28] "Machine to machine," [Online] Available: http://en.wikipedia.org/wiki/Machine_to_machine [Accessed Dec 2013]
[29] M Kovatsch; S Duquennoy; A Dunkels, "A Low-Power CoAP for Contiki,"
Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Conference on, pp 855-860, Oct 2011
[30] F Osterlind, A Dunkels, J Eriksson, N Finne, and T Voigt, "Cross-level sensor network simulation with COOJA," in Proc 31st IEEE Conf on Local Computer Networks (LCN’06), p Nov, 2006
[31] J Eriksson, A Dunkels, N Finne, F Osterlind, and T Voigt, "MSPsim - – an extensible simulator for MSP430-equipped sensor boards," in Proc.European Conf on Wireless Sensor Networks (EWSN’07), 2007
Công tri ̀nh đã công bố
1 Tran Thanh Binh, Tran Ngoc Thinh, Bui Van Hieu, “Applying CoAP for sleepy devices in wireless water quality monitoring systems”, International Journal of Applied Engineering Research 2014, Renewable Energy and Green Technology International Conference, Kulawangsa Indonesia, Dec 2014.(accepted and published - to be present in Dec 2014)
2 Tran Thanh Binh, Bui Van Hieu, Tran Ngoc Thinh, Hiroshi Ishii, “Applying Constrained Application Protocol in data transmission for wireless water quality monitoring systems” Journal of Science and Technology (2014), Ho Chi Minh city, vol 52, pp 20-28, Oct 2014.