1. Trang chủ
  2. » Tất cả

Báo cáo BTL IOT Giám sát lượng nước toàn thành phố

21 1 0

Đ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

Báo cáo BTL IOT Giám sát lượng nước toàn thành phố​ A. ĐẶT VẤN ĐỀ I. Thực trạng hiện nay Hiện nay, vấn đề quản lý nước trong thành phố gặp khá nhiều khó khăn vì phải thực hiện thủ công, ghi chép bằng tay. Ghi chép lượng nước hàng tháng thủ công dẫn đến việc trực hóa thống kê và sao lưu có nhiều bất cập và gần như là không thể đối với dữ liệu lớn. Đặc biệt, khả năng truy vết lịch sử sử dụng nước theo năm để dự đoán lượng nước trong tương lai hay phục vụ nghiên cứu gần như là nhiệm vụ bất khả thi. Hơn nữa, nó còn tốn kém chi phí nguồn lực. Ví dụ: Báo cáo kết quả giám sát thực hiện luật Thủ đô, UB Pháp luật của Quốc hội cho biết, năm 2020, dân số Hà Nội khoảng 10.5 triệu người. Trung bình 4 ngườihộ. Vậy chúng ta có 2.625.000 hộ. Hàng tháng sẽ có 2.625.000 bản ghi tiền điện (số lượng bản ghi sẽ nhiều và gia tăng sẽ rất nhanh). Giả sử mỗi nhân viên chịu trách nhiệm ghi 1.000 bản ghi mỗi tháng, ta sẽ có 2.625 nhân viên. Mức lương cơ bản mỗi nhân viên giả sử là 4 triệutháng, vậy mỗi tháng ta sẽ mất 10,5 tỉtháng để trả lương (một con số lớn). Và với số lượng 2.625.000 bản ghi tháng thì việc sao lưu và thống kê đã là cả 1 bài toán về công sức và việc ghi chép phải cực kì tỉ mỉ vì dễ dẫn đến sai xót với số lượng bản ghi lớn như vậy. II. Đề xuất ý tưởng Từ những khó khăn và nhược điểm của hệ thống hiện nay, nhóm chúng em đã nghiên cứu, bàn bạc và đi đến thống nhất đưa ra một hệ thống tự động, IOT có thể khắc phục toàn bộ những khó khăn trên. Giảm bớt công sức con người với độ chính xác cao, ổn định. Hơn nữa, nó có khả năng mở rộng với quy mô. Đặc biệt có hệ thống web, app an toàn, bảo mật, dễ sử dụng để dễ dàng quản lý và theo dõi. Các thành phần chức năng của hệ thống: • Hiển thị lượng nước từng hộ gia đình theo giờ, tháng, năm • Kiểm soát từng gia đình • Kiểm soát lượng nước toàn thành phố theo tháng, năm • Lưu lại lịch sử các năm để truy vết dữ liệu • Trực quan hóa dữ liệu bằng biểu đồ để phân tích, dự báo lượng nước trong tương lai.

A ĐẶT VẤN ĐỀ I Thực trạng Hiện nay, vấn đề quản lý nước thành phố gặp nhiều khó khăn phải thực thủ cơng, ghi chép tay Ghi chép lượng nước hàng tháng thủ cơng dẫn đến việc trực hóa thống kê lưu có nhiều bất cập gần liệu lớn Đặc biệt, khả truy vết lịch sử sử dụng nước theo năm để dự đoán lượng nước tương lai hay phục vụ nghiên cứu gần nhiệm vụ bất khả thi Hơn nữa, cịn tốn chi phí nguồn lực Ví dụ: Báo cáo kết giám sát thực luật Thủ đô, UB Pháp luật Quốc hội cho biết, năm 2020, dân số Hà Nội khoảng 10.5 triệu người Trung bình người/hộ Vậy có 2.625.000 hộ Hàng tháng có 2.625.000 ghi tiền điện (số lượng ghi nhiều gia tăng nhanh) Giả sử nhân viên chịu trách nhiệm ghi 1.000 ghi tháng, ta có 2.625 nhân viên Mức lương nhân viên giả sử triệu/tháng, tháng ta 10,5 tỉ/tháng để trả lương (một số lớn) Và với số lượng 2.625.000 ghi/ tháng việc lưu thống kê tốn cơng sức việc ghi chép phải tỉ mỉ dễ dẫn đến sai xót với số lượng ghi lớn II Đề xuất ý tưởng Từ khó khăn nhược điểm hệ thống nay, nhóm chúng em nghiên cứu, bàn bạc đến thống đưa hệ thống tự động, IOT khắc phục tồn khó khăn Giảm bớt cơng sức người với độ xác cao, ổn định Hơn nữa, có khả mở rộng với quy mơ Đặc biệt có hệ thống web, app an tồn, bảo mật, dễ sử dụng để dễ dàng quản lý theo dõi Các thành phần chức hệ thống:      Hiển thị lượng nước hộ gia đình theo giờ, tháng, năm Kiểm sốt gia đình Kiểm sốt lượng nước tồn thành phố theo tháng, năm Lưu lại lịch sử năm để truy vết liệu Trực quan hóa liệu biểu đồ để phân tích, dự báo lượng nước tương lai B THIẾT KẾ HỆ THỐNG I Sơ đồ thiết kế tổng quan Hệ thống bao gồm phần chính:     Device sensor MQTT Broker Server Client Giao tiếp Device sensor, Server MQTT Broker giao thức MQTT Protocol II Phân tích chi tiết thành phần hệ thống Các device, sensor Mỗi thiết bị gắn vi xử lý ESP32, sensor đo lưu lượng nước gắn vào chân tương ứng ESP32 Từ ta thu thập liệu lượng nước sử dụng Thiết bị kết nối mạng 24/7 thông qua wifi, ESP32 liên tục thu thập liệu gửi lên Server qua topic giao thức MQTT Về sensor đo lượng nước YF-S201 DN15:  Có chân, đó: o Màu đỏ cho Vcc o Màu đen cho GND o Màu vàng cho đầu xung  Công thức tính tốn cảm biến lưu lượng nước: lít nước chảy, cảm biến tạo 450 xung  Mỗi xung có 1/450 lít nước chảy  V_ total= N * 1/450 lít với N số xung phát Mà V_total= Q(L/s) * t Trong t thời gian nước chảy qua, Q(L/s) tổng thể tích chất lỏng chảy qua đơn vị thời gian      Q(L/s)*t=N*1/450 N/t=450*Q(L/s) F=450*Q(L/s) = 7.5*Q (L/s) V_total=Q(L/s) * t (second) * 60 V_total= F/7.5*t/60 Mà F = Xung/s  V_total=Xung / (7.5*60) a Sơ đồ giao tiếp esp32 server Đầu tiên, thiết bị gửi id kèm theo password lên server để đăng ký tham gia vào hệ thống Server gửi lại cho thiết bị token để sử dụng khoảng thời gian Mỗi thiết bị gửi liệu ,server kiểm tra tính hợp lệ token (thời hạn sử dụng) Nếu token hết hạn, thiết bị gửi yêu cầu lấy token lên cho server Thiết bị liên tục thu thập liệu từ sensor Và sau khoảng thời gian (1 tiếng), gửi liệu lượng nước truy cập lên cho server Gói tin gửi lên có id, token liệu Thiết bị sau đăng ký tham gia vào hệ thống phải liên tục gửi gói tin keep alive lên server để server biết hoạt động (1 phút gửi lần) Nếu thời gian cho phép mà server khơng nhận gói tin keep alive từ thiết bị, server coi thiết bị ngừng hoạt động khơng nhận gói tin collect data b Các task cần thực esp32  Task thu thập liệu lượng nước Thực nhiệm vụ đo lưu lượng nước từ sensor  Task keep_alive Thực gửi gói tin keepAlive lên cho server, để server nhận biết thiết bị động  Task gửi liệu Sau tiếng thiết bị gửi liệu đo từ sensor lên cho server lưu trữ vào database  Task get token: Thực lấy token để thiết bị gửi gói tin lên cho server hoạt Server Triển khai hai service HTTP serivce Mqtt Serivce  HTTP serivce: cung cấp số API  Đăng ký  Đăng nhập  Thêm device  Quản lý user  Quản lý device  Lấy liệu sensor   Mqtt Serivce  Subscribe: iot/authentication, iot/collectdata, iot/getTokenCollectData, iot/keepAlive  Publish:iot/authentication_result_{id_device}, iot/getTokenCollectData_result_{id_device} Database Admin User Hệ thống có tác nhân chính, người dùng (chính người sử dụng nước hộ gia đình), hai admin (người quản trị nước thành phố) Admin có đầy đủ chức : thêm xóa sửa user, thêm thiết bị cho user, phân quyền user, xem tổng lượng nước thành phố theo năm theo tháng user User đăng nhập web app xem chi tiết thơng tin thiết bị (video có demo) III Các công nghệ sử dụng Mqtt a Tổng quan MQTT MQTT (Message Queing Telemetry Transport) thiết kế hai kỹ sư Andy Stanford-Clark Arlen Nipper vào năm 1999 Nó giao thức truyền thơng điệp theo mơ hình publish/subsribe, thiết kế đơn giản, sử dụng băng thơng thấp, độ tin cậy cao, có khả hoạt động điều kiện đường truyền thiếu ổn định Vì phù hợp cho ứng dụng M2M IoT MQTT hoạt động theo mơ hình Client (Publisher/Subscriber) – Server (Broker) b Kiến trúc chế hoạt động MQTT       Thành phần MQTT Client (Publisher/Subscriber), Server (Broker), Sessions , Subscriptions Topics MQTT Client (Publisher/Subscriber): Clients subscribe nhiều topics để gửi nhận thông điệp từ topic tương ứng MQTT Server (Broker): Broker nhận thông tin subscribe (Subscriptions) từ client, nhận thông điệp, chuyển thông điệp đến Subscriber tương ứng dựa Subscriptions từ client Topic: Có thể coi Topic hàng đợi thơng điệp, có sẵn khuôn mẫu dành cho Subscriber Publisher Một cách logic topic cho phép Client trao đổi thơng tin với ngữ nghĩa định nghĩa sẵn Ví dụ: Dữ liệu cảm biến nhiệt độ tòa nhà Session: Một session định nghĩa kết nối từ client đến server Tất giao tiếp client server phần session Subscription: Không giống session, subscription mặt logic kết nối từ client đến topic Khi subscribe topic, Client nhận/gửi thơng điệp (message) với topic c Quality of Service -QoS QoS thỏa thuận bên gửi bên nhận việc đảm bảo phân phối message Có cấp độ QoS MQTT publish/subscribe    QoS0 Broker/Client gửi liệu lần, trình gửi xác nhận giao thức TCP/IP QoS1 Phía server nhận message xác định message PUBACK Nếu có lỗi, hay message xác nhận không nhận sau khoảng thời gian định gửi lại message thiết lập bit DUP tron header message Vì message gửi tới server lần Nếu client không nhận message PUBACK khoảng thời gian định nghĩa có lỗi xảy client gửi lại message PUBLISH với DUP thiết lập Khi nhận message lặp lại từ phía client, server publish message đến subscriber gửi message PUBACK khác QoS2: Message bị lặp lại không chuyển đến ứng dụng Đây mức độ cao phân phối message, message lặp lại không chấp nhận Khi QoS = 2, message có message ID phần header Nếu có lỗi sau khoảng thời gian, luồng protocol thực lại kết message xác nhận cuối PUBLISH PUBREL Vì đảm bảo message đến subscriber lần Spring mvc Spring framework tảng mã nguồn mở phổ biến để xây dựng ứng dụng Những tính cốt lõi Spring sử dụng để phát ứng dụng Java Destop, ứng dụng mobile, Java Web cách đơn giản Trong tập lớn sử dụng Spring framework để xây dựng ứng dụng phía server, cung cấp chế thuận tiện để triển khai dịnh vụ chức hệ thống Flow Spring MVC framework      Bất kỳ request tới ứng dụng web gửi tới Front Controller(Dispatcher servlet) Dispatcher servlet sử dụng Handler Mapping để biết controller xử lý rquest Thực thi logic xác định controller trả đối tượng ModelAndView Dựa giá trị ModelAndView, Dispatcher servlet gửi yêu cầu đến View Resolver, View Resolver tìm kiếm dựa config file view mà Controller trả Cuối Dispatcher servlet tìm kiếm đến file view View Resolver xác định trước gửi kết cho người dùng Triển khai theo mơ hình front-end back-end riêng Client gửi request tới server qua API sử dụng RestController để xử lý trả liệu JSON Spring triển khai gói dịch vụ Nó phục vụ luồng khác máy chủ Bao gồm HTTP service(Cung cấp API cho front-end) Mqtt service(đăng ký topic xử lý message) Vue.js Vue.js framework linh động dùng để xây dựng giao diện người dùng (user interfaces) Khác với framework nguyên khối (monolithic), Vue thiết kế từ đầu theo hướng cho phép khuyến khích việc phát triển ứng dụng theo bước Khi phát triển lớp giao diện (view layer), người dùng cần dùng thư viện lõi (core library) Vue, vốn dễ học tích hợp với thư viện dự án có sẵn Cùng lúc đó, kết hợp với kĩ thuật đại SFC (single file components) thư viện hỗ trợ, Vue đáp ứng dễ dàng nhu cầu xây dựng ứng dụng trang (SPA - Single-Page Applications) với độ phức tạp cao nhiều MySQL MySQL hệ thống quản lý sở liệu quan hệ mã nguồn mở (RDBMS) dựa ngơn ngữ truy vấn có cấu trúc ( SQL) phát triển, phân phối hỗ trợ tập đoàn Oracle MySQL chạy hầu hết tất tảng, bao gồm Linux , UNIX Windows MySQL thường kết hợp với ứng dụng web Apache Tomcat Apache Tomcat web server HTTP phát triển Apache Software Foundation, hỗ trợ mạnh cho ứng dụng Java thay website tĩnh Do đó, chạy nhiều Java chuyên biệt Java Servlet, JavaServer Pages (JSP), Java EL, WebSocket Bạn hồn tồn sử dụng Apache Tomcat với nhiều ngơn ngữ lập trình khác PHP, Python, Perl,… Nhờ giúp đỡ module Apache phù hợp, chẳng hạn mod_php, mod_python, mod_perl,… React Native React Native framework công ty công nghệ tiếng Facebook phát triển nhằm mục đích giải tốn hiệu Hybrid tốn chi phí mà phải viết nhiều loại ngôn ngữ native cho tảng di động Ở hệ thống này, chúng em triển khai ứng dụng Android chủ yếu cung cấp cho người dùng theo dõi lượng nước theo chu kỳ thời gian (1 tiếng/lần) real-time (khi ấn vào refresh) Từ để giám sát lượng nước, phát bất thường, tính tốn số tiền gian lận (nếu có) bên cung cấp nước C TRIỂN KHAI (DEMO) I Demo thành phần chức hệ thống Demo IOT - Hê thống cấp nước thông minh cho thành phố II Server: Minh họa code Client: https://github.com/tvdinh1008/SpringIOT ESP32  TaskCollectData  Task gửi liệu o Trước liệu, thiết bị cần active hệ thống: o Sau kiểu tra xem token cịn hạn khơng, cịn gửi dũ liệu  Task GetToken KeepAlive III Kết quả, hình ảnh sản phẩm Admin Admin Trang chủ : Chỉ có Admin có chức thêm người dùng, thêm thiết bị cho người dùng (có phân quyền cho user) Sau tạo tài khoản cho user, admin thêm thiết bị gắn với user Sau tạo thiết bị thành cơng server create token để active thiết bị Admin theo dõi tổng user thiết bị user Admin xem lượng nước thiết bị user theo năm theo tháng: Theo năm: (có thể select chọn năm, video có demo) Hệ thống có đầy đủ chức thêm xóa sửa user, device, profile (có video demo): b 2 User D TEAMWORK – CƠNG VIỆC NHĨM Họ tên Phan Thành Đạt MSSV 20173001 Hoàng Văn Chương 20172984 Trần Văn Định 20173017 Chử Việt Hồng 20173135 Cơng việc Thuyết trình, viết báo cáo, tìm hiểu phần cứng sensor, viết app điện thoại, bảo mật hệ thống, thiết kế hệ thống Làm slide, viết báo cáo, viết web hiển thị, thiết kế sở liệu, thiết kế hệ thống Làm slide, viết báo cáo, tìm hiểu phần cứng ESP32, viết Server, thiết kế sở liệu, thiết kế hệ thống Làm slide, viết báo cáo, tìm hiểu ESP32, code ESP 32, thiết kế sở liệu, thiết kế hệ thống ... người sử dụng nước hộ gia đình), hai admin (người quản trị nước thành phố) Admin có đầy đủ chức : thêm xóa sửa user, thêm thiết bị cho user, phân quyền user, xem tổng lượng nước thành phố theo năm... dùng theo dõi lượng nước theo chu kỳ thời gian (1 tiếng/lần) real-time (khi ấn vào refresh) Từ để giám sát lượng nước, phát bất thường, tính tốn số tiền gian lận (nếu có) bên cung cấp nước C TRIỂN... sensor   Mqtt Serivce  Subscribe: iot/ authentication, iot/ collectdata, iot/ getTokenCollectData, iot/ keepAlive  Publish :iot/ authentication_result_{id_device}, iot/ getTokenCollectData_result_{id_device}

Ngày đăng: 02/03/2023, 01:24

Xem thêm:

w