3. QUÁ TRÌNH THỰC HIỆN
3.5. Triển khai hệ thống giám sát
3.5.1. Xây dựng hệ thống giám sát
- Từ quá trình thực hiện suy luận AI để giải quyết các bài toán của trạm biến áp đã trình bày ở các phần trên, cơng việc tiếp theo ta cần thực hiện là xây dựng một hệ thống giám sát hồn chỉnh với các mục tiêu chính như sau:
+ Quản lý được các thiết bị Edge Devices và Camera trong TBA. + Thiết lập và điều chỉnh các thông số cần thiết để để các Edge Device có thể hoạt động tốt trong các điều kiện khác nhau.
+ Giám sát được các báo động mà mô hình Deep Learning phát hiện được về các bài tốn đã đề ra để kịp thời giải quyết sự cố.
Hình 3.30. Sơ đồ tồn bộ hệ thống giám sát của trạm biến áp
- Với các mục tiêu trên, đề tài luận văn đề xuất một hệ thống giám sát vận hành dựa trên các services hoạt động độc lập dựa vào Docker Container [32]. Chi tiết về hệ thống giám sát được thể hiện ở Hình 3.30 được chia thành hai nhóm chính là các services hoạt động tại Server và các services hoạt động tại Edge Devices.
3.5.2.!Server
- Nhóm services ở Server được chạy trên các Docker Container với chức năng và chi tiết hoạt động của các services như sau:
Cơ sở dữ liệu (Database Service)
- Để có thể quản lý được các ED, Cameras, AI Models và các cài đặt mà người dùng gán cho các camera thì chúng ta cần phải có một service Database làm nơi lưu trữ cũng như truy xuất thông tin.
- Để chạy được một Database Service, ta sử dụng PostgreSQL [33] – một hệ thống quản trị cơ sở dữ liệu được sử dụng phổ biến hiện nay. PostgreSQL có hỗ trợ sẵn một Docker Image để người dùng có thể dễ dàng sử dụng mà khơng cần gặp khó
- Để xây dựng cơ sở dữ liệu cho Hệ thống giám sát, ta cần xác định các đối tượng của hệ thống mà ở đây 3 đối tượng chính của hệ thống là Edge Devices, Cameras và Models (AI Models).
Hình 3.31. Sơ đồ liên kết các bảng trong Database
- Ở Hình 3.31, lấy trọng tâm là 3 đối tượng đã nêu ta xây dựng mối quan hệ của các bảng dữ liệu (gắn với thông tin của 3 đối tượng) với nhau. Các bảng dữ liệu trung gian của các đối tượng là EdgeHasCameras, EdgeHasModels.
- Để phục vụ cho bài toàn xác định người trong vùng nguy hiểm, ta cần xây dựng thêm bảng Areas chứa các thông tin của vùng tương ứng với mỗi Camera trong Edge Device.
- Vì mỗi camera có thể tồn tại ở nhiều Edge Device khác nhau và có các vùng nguy hiểm (Areas) khác nhau tuỳ vào cài đặt của người giám sát, do đó dữ liệu tại bảng Area không nên kết nối với bảng Cameras mà phải kết nối đến bảng EdgeHasCameras để phản ánh cụ thể đây là vùng nguy hiểm của camera A trong thiết
- Để có thể tuỳ chỉnh các thông số hoạt động của Edge Device, ta cần thêm một bảng lưu thông số của từng ED, do đó ta có thêm bảng DsConfigs với mỗi dịng dữ liệu trong bảng này chứa thơng số của duy nhất một ED tương ứng. Do đó ta cần phải liên kết bảng EdgeDevice và bảng DsConfigs thông qua bảng EdgeHasConfigs.
API Service
- API Service là một dịch vụ chạy ngầm dưới hệ thống giám sát có nhiệm vụ thực thi các yêu cầu từ người dùng thông qua giao diện (GUI) để truy xuất dữ liệu từ Database và để gửi các lệnh điều khiển xuống Edge Devices.
- Trong sơ đồ chi tiết hệ thống giám sát được giới thiệu ở phần 3.5.1 ta có thể thấy, chỉ có duy nhất API Service mới có quyền truy cập vào Database. Việc làm này nhằm tránh bị xung đột dữ liệu xảy ra khi có quá nhiều service chạy độc lập đều có thể thay đổi dữ liệu trong Database. Chính vì vậy, các service khác chỉ có thể cập nhập và truy xuất dữ liệu thơng qua API Service.
- Trong hệ thống giám sát mà luận văn xây dựng, GUI Service sẽ gọi vào API Service để thực hiện các tác vụ như tạo, thêm, sửa hoặc xoá các đối tượng (Edge Device, Camera, Model, …).
- Ngoài các chức năng cơ bản như trên, các tác vụ khác như lưu dữ liệu vùng nguy hiểm (Areas), điều chỉnh thông số của ED, thêm camera vào ED hay cập nhập trạng thái của Edge Device đều được thực thi tại API Service khi nhận được yêu cầu từ GUI.
- Chi tiết các API trong hệ thống giám sát được thể hiện ở bảng sau với địa chỉ của API Service {api} = ‘http://127.0.0.1:8002’
Bảng 3.5. Danh sách các API cho đối tượng Edge Device
Bảng 3.6. Danh sách các API cho đối tượng Camera, Model và Area
RabbitMQ
- RabbitMQ [34] là một Message Broker dùng để phục vụ như cầu giao tiếp giữa các ứng dụng với nhau. Trong hệ thống giám sát này, ta dùng RabbitMQ như là phần mềm trung gian giúp quản lý các gói tin (message) được gửi giữa các services trong nội bộ Server với nhau.
- Một nhiệm vụ quan trọng nữa của RabbitMQ trong hệ thống này là được dùng như một gateway hứng các gói tin gửi từ Edge Device về Server để cho các services có nhiệm vụ truy xuất và xử lý.
Hình 3.32. Sơ đồ giao tiếp Server-Edge Device qua RabbitMQ!
- Hình 3.32 cho ta cái nhìn trực quan hơn về nhiệm vụ của RabbitMQ trong hệ thống giám sát của chúng ta.
- Tại Server: khi được khởi chạy, nhiệm vụ đầu tiên của Notify Service là kết nối với RabbitMQ để tạo ra các Queue quan trọng có tên là Status, Notify và Registry. - Status Queue có nhiệm vụ nhận tất cả các message liên quan đến sự thay đội trạng thái của ED được gửi từ các Edge Devices lên Server. Để cho Notify Service truy cập vào và xử lý.
-Notify Queue có nhiệm vụ nhận tất cả các message liên quan đến báo động mà ED gửi đến Server.
mà Server muốn gửi đến cho ED đó. Queue ed_{id} được khởi tạo khi Edge Device đó gửi message đầu tiên lên cho Server để khai báo sự tồn tại của mình với Server.
- Ngồi ra, RabbitMQ có một exchange hoạt động với cơ chế gọi là “fanout” dùng để gửi một gói tin đến nhiều queue khác nhau nếu queue đó có liên kết với exchange trên. Ở đây, hệ thống giám sát sử dụng “ha.all_eds” là một exchange hoạt động với cơ chế “fanout”, liên kết với tất cả các ed_{id} queue để phụ vụ cho nhu cầu điều khiển đồng loạt nhiều thiết bị ED hoặc nếu cần cập nhập phần mềm đồng loạt cho các thiết bị.
Hình 3.33. Sơ đồ chi tiết nội dung message giao tiếp giữa Server-Edge Device
- Quá trình giao tiếp giữa Server và Edge Device (Hình 3.33) diễn ra như sau: + Tại ED sẽ có 3 Services chính sẽ được mơ tả chức năng chi tiết ở phần sau. Tuy nhiên về mặt truyền nhận dữ liệu Server-ED ta có thể tạm hiểu Master Service là nơi nhận các lệnh điều khiển từ Server và thực thi các lệnh đó tại ED.
+ Do đó, tuỳ vào lệnh mà sẽ có một loại “action” khác nhau được gửi đi như “add_cam”, “add_model”, “update_config”, … Tương ứng với mỗi lệnh sẽ có
+ Sau khi thực thi các lệnh, Master Service sẽ trả kết quả thực thi về Server tại Status Queue, do đó message trả về sẽ có thêm một field chỉ trạng thái của lệnh đã thực thi “status”=”success”/”fail”.
+ DeepStream Service là nơi thực thi các tác vụ chính của Edge Device mà hệ thống giám sát yêu cầu bao gồm cả việc xử lý AI. Do đó, DeepStream sẽ gửi kết quả suy luận và cảnh báo về cho Server tại Notify Queue bao gồm dữ liệu ảnh nên message gửi về có thêm field “image” chứa ảnh cảnh báo và “cam_id” cho ta biết cảnh báo đó xảy ra ở camera nào.
+ Ngồi ra, để phản hồi lại cho Server các trạng thái của camera trong quá trình thực thi, DeepStream trả trạng thái kết nối với camera là “connected”/”disconnected” về Status Queue và thông tin tốc độ xử lý cũng như tốc độ xử lý về Notify Queue với field “metric”.
Notify Service
- Notify Service là một worker có nhiệm vụ xử lý các message phản hồi trạng thái từ các Edge Device gửi về từ Server trước khi thực thi trong hệ thống.
- Khi một lệnh điều khiển một Edge Device được thực thi, API Service sẽ chuyển lệnh điều khiển đó thành một gói tin phù hợp với định dang đã quy ước trước đó và gửi đến ed_{id} queue của Edge Device tương ứng.
- Edge Device nhận được gói tin và thực thi hành động sau đó gửi lại kết quả thực thi là hành động ví dụ: action=”add_cam” với status=“success”/”fail” về cho Server qua Status Queue.
- Nhiệm vụ chính của Notify Service là nhận các message này và cập nhập trạng thái vào cơ sở dữ liệu hoặc gửi về GUI cho người dùng quan sát.
GUI
- GUI (Graphical User Interface) là một giao diện giúp người giám sát hệ thống có thể dễ dàng hơn trong việc điều khiển các Edge Devices từ xa, cài đặt các thông số cho ED, theo dõi và giám sát hoạt động của toàn bộ hệ thống giám sát cũng như
- GUI Service được xây dựng trên thư viện Tkinter của Python và chạy độc lập với tất cả các services khác trong hệ thống nhờ vào Docker Container, tên container của GUI Service trong hệ thống là monitor.
- Khi khởi động giao diện, GUI Service sẽ thiết lập 2 kết nối:
+ Kết nối đến API Service và thực hiện các API trong danh sách được giới thiệu ở phần trên nhằm truy xuất dữ liệu hệ thống, truy cập thông tin các thiết bị cũng như thay đổi dữ liệu nếu người dùng thay đổi trên GUI.
+ Kết nối đến RabbitMQ Service và lấy message từ Notify Queue để nhận các cảnh báo từ các Edge Devices gửi về và hiển thị lên giao diện cho người dùng quan sát.
- Chi tiết về giao diện điều khiển ta có 3 trang cơ bản như sau
Hình 3.34. Trang Login của hệ thống giám sát
- Mục đích của Login Page là để tạo tính năng đăng nhập nhằm bảo mật cho hệ thống giám sát. Tuy nhiên đây chỉ là chức năng phụ và không cần thiết trong đề tài luận văn thế nên ta chỉ tạo Login Page với mục đích tượng trưng.
Hình 3.35. Trang MainPage của hệ thống giám sát
- Main Page cho ta cái nhìn tổng quan về hệ thống giám sát, có chức năng hiển thị số lượng các Edge Devices, Cameras, Models đang thực thi trong hệ thống.
+ Hiển thị chi tiết các thông tin của từng thiết bị.
+ Dựa vào số Edge Devices, số Camera và Models có sẵn trong hệ thống, ta có thể cài đặt để gán Camera vào ED, thêm Model vào ED từ MainPage.
+ Quy định như sau: một Camera có thể được thêm vào nhiều Edge Devices khác nhau, tuy nhiên không được thêm nhiều hơn một Camera vào cùng một ED. Số lượng Camera tối đa là 4, số lượng Model tối đa là 1 trong một ED. Chỉ có thể thêm Camera khi đã thêm Model vào ED đó.
Hình 3.36. Trang ViewPage của hệ thống giám sát
+ ViewPage là giao diện giúp ta quan sát một cách chi tiết nhất về trạng thái hoạt động của một Edge Device. Với hai chức năng chính là xem trực tiếp camera muốn giám sát và hiển thị các báo động cũng như thông số hoạt động của Camera từ ED đang giám sát gửi về.
+ Ngoài ra, ViewPage còn là giao diện để chúng ta điều chỉnh các thông số cho ED, vẽ các vùng làm việc nguy hiểm hoặc vùng cho phép làm việc để phục vụ cho bài toán phát hiện người khi vào vùng nguy hiểm.