.8 Cấu hình phần cứng Google colab cung cấp

Một phần của tài liệu Xây dựng hệ thống AI nhận diện và dự đoán sản lượng điện năng tiêu thụ bất thường của khách hàng (Trang 34)

1.5. Các giao thức và mơ hình

Với kiến trúc hướng dịch vụ, chúng tơi quyết định sử dụng Angular để phát triển trang web giao diện người dùng và Node JS để xây dựng các API để tương tác với dữ liệu lưu tại cơ sở dữ liệu tại Cơng ty. Ngồi ra tơi cũng sử dụng Google Colab để triển khai các chương trình huấn luyện trên đám mây. Tơi triển khai hệ thống của mình đến máy chủ của cơng ty TTHPC. Chúng tơi sẽ nĩi về những cơng nghệ này trong phần này, nhưng trước hết chúng tơi sẽ trình bày các lý thuyết cơ bản.

1.5.1. HTTP

Giao thức truyền siêu văn bản (HTTP) là một giao thức ứng dụng cho các hệ thống thơng tin phân tán, cộng tác và siêu phương tiện. Nĩ là một giao thức chung, khơng trạng thái, cĩ thể được sử dụng cho nhiều tác vụ ngồi việc sử dụng cho siêu văn bản, chẳng hạn như máy chủ định danh và hệ thống quản lý đối tượng phân tán, thơng qua việc mở rộng các phương thức yêu cầu, mã lỗi và tiêu đề của nĩ. HTTP là nền tảng của giao tiếp dữ liệu cho World Wide Web.

HTTP hoạt động như một giao thức phản hồi u cầu trong mơ hình tính tốn máy khách-máy chủ. Ví dụ: một trình duyệt web cĩ thể là máy khách và một ứng dụng chạy trên máy tính lưu trữ một trang web cĩ thể là máy chủ. Máy khách gửi một thơng báo yêu cầu HTTP đến máy chủ. Máy chủ, nơi cung cấp các tài nguyên như tệp HTML và nội dung khác, hoặc thực hiện các chức năng khác thay mặt máy khách, trả về một thơng báo phản hồi cho máy khách. Phản hồi chứa thơng tin trạng thái hồn thành về yêu cầu và cũng cĩ thể chứa nội dung được yêu cầu trong nội dung thư của nĩ.

HTTP được thiết kế để cho phép các phần tử mạng trung gian cải thiện hoặc cho phép giao tiếp giữa máy khách và máy chủ. Trình duyệt là một máy khách HTTP vì nĩ gửi các yêu cầu đến máy chủ HTTP (máy chủ Web), máy chủ này sau đĩ sẽ gửi phản hồi trở lại máy khách. Cổng tiêu chuẩn (và mặc định) cho các máy chủ HTTP để lắng nghe là 80, mặc dù chúng cĩ thể sử dụng bất kỳ cổng nào. Dịng yêu cầu cĩ ba phần, được phân tách bằng dấu cách: tên

phương thức, đường dẫn cục bộ của tài nguyên được yêu cầu và phiên bản HTTP đang được sử dụng.

HTTP xác định các phương thức để chỉ ra hành động mong muốn được thực hiện trên tài nguyên đã xác định. Tài nguyên này đại diện cho điều gì, cho dù là dữ liệu cĩ từ trước hay dữ liệu được tạo động, phụ thuộc vào việc triển khai của máy chủ. Thơng thường, tài nguyên tương ứng với một tệp hoặc đầu ra của tệp thực thi nằm trên máy chủ. Đặc tả HTTP / 1.0 xác định các phương thức GET, POST và HEAD và đặc tả HTTP / 1.1 đã thêm 5 phương thức mới: OPTIONS, PUT, DELETE, TRACE và CONNECT.

Với các URL và phương thức, máy khách cĩ thể khởi tạo các yêu cầu tới máy chủ. Đổi lại, máy chủ phản hồi bằng mã trạng thái và thơng báo. Mã trạng thái rất quan trọng và cho máy khách biết cách diễn giải phản hồi của máy chủ. Thơng số HTTP xác định các phạm vi số nhất định cho các loại phản hồi cụ thể: 1xx: Tin nhắn thơng tin. Lớp mã này được giới thiệu trong HTTP / 1.1 và hồn tồn là tạm thời.

2xx: Thành cơng. Loại mã trạng thái này cho biết rằng yêu cầu của khách hàng đã được nhận, hiểu và chấp nhận thành cơng. Mã phổ biến nhất là 200 OK.

3xx: Chuyển hướng. Điều này yêu cầu khách hàng thực hiện thêm hành động. Trường hợp sử dụng phổ biến nhất là chuyển đến một URL khác để tìm nạp tài nguyên.

4xx: Lỗi máy khách. Các mã này được sử dụng khi máy chủ cho rằng máy khách bị lỗi, do yêu cầu tài nguyên khơng hợp lệ hoặc đưa ra yêu cầu khơng hợp lệ. Mã phổ biến nhất trong lớp này là 404 Not Found, nĩ chỉ ra rằng tài nguyên khơng hợp lệ và khơng tồn tại trên máy chủ.

5xx: Lỗi Máy chủ. Loại mã này được sử dụng để chỉ ra lỗi máy chủ trong khi xử lý yêu cầu. Mã lỗi phổ biến nhất là Lỗi máy chủ nội bộ 500.

1.5.2. Định dạng JSON

JSON hoặc JavaScript Object Notation là một định dạng trao đổi dữ liệu văn bản thuần túy. Nĩ dựa trên một tập hợp con của phiên bản thứ ba của tiêu chuẩn ECMA-262. JSON được sử dụng như một cơ chế để tuần tự hĩa cấu trúc dữ liệu thành chuỗi. Các chuỗi này thường được gửi qua các mạng, được ghi để xuất tệp hoặc được sử dụng để gỡ lỗi.

Về mặt ngữ pháp, JSON rất giống với cú pháp theo nghĩa đen của đối tượng JavaScript. Danh sách sau đây mơ tả các quy tắc để tạo chuỗi JSON:

− Các đối tượng JSON bắt đầu bằng dấu ngoặc nhọn mở ‘{‘ và kết thúc bằng dấu ngoặc nhọn đĩng ‘}”.

− Giữa các dấu ngoặc nhọn là khơng hoặc nhiều cặp khĩa / giá trị được gọi là thành viên.

− Các thành viên được phân tách bằng dấu phẩy.

− Khĩa và giá trị của mỗi phần tử được phân tách bằng dấu hai chấm.

− Khĩa là chuỗi và phải được bao quanh bởi dấu ngoặc kép.

− Định dạng của giá trị phụ thuộc vào kiểu dữ liệu.

Ví dụ: {“name": "xuanthien", "age": 26, "city": "thành phố Huế"} là một đối tượng JSON. Các khĩa của nĩ là tên, tuổi và thành phố. Giá trị tương ứng của nĩ là xuanthien, 26 và thành phố Huế.

JSON hỗ trợ nhiều kiểu dữ liệu gốc của JavaScript. Cụ thể, JSON hỗ trợ số, chuỗi, Boolean, mảng, đối tượng và null. Vì định dạng JSON chỉ là văn bản nên nĩ cĩ thể dễ dàng được gửi đến và đi từ máy chủ và được sử dụng làm định dạng dữ liệu bởi bất kỳ ngơn ngữ lập trình nào.

1.5.3. Chuyển giao trạng thái đại diện (REST)

Chuyển giao trạng thái đại diện (REST) xác định một tập hợp các nguyên tắc kiến trúc mà bạn cĩ thể thiết kế các dịch vụ Web tập trung vào tài nguyên của hệ thống, bao gồm:

Client - Server

Điều này về cơ bản tách các mối quan tâm về giao diện người dùng khỏi mối quan tâm về lưu trữ dữ liệu. Cĩ nghĩa là ứng dụng máy khách và ứng dụng máy chủ phải cĩ khả năng phát triển riêng biệt mà khơng phụ thuộc vào nhau. Khách hàng chỉ nên biết URI tài nguyên và đĩ là tất cả. Điều này về cơ bản cho phép ứng dụng khách trên nhiều nền tảng và ứng dụng máy chủ cĩ thể mở rộng.

Máy chủ sẽ khơng lưu trữ bất cứ điều gì về ứng dụng khách yêu cầu HTTP mới nhất được thực hiện. Nĩ sẽ coi mỗi và mọi yêu cầu là mới. Mỗi yêu cầu từ máy khách đến máy chủ phải chứa tất cả thơng tin cần thiết để hiểu được yêu cầu và khơng thể tận dụng bất kỳ ngữ cảnh được lưu trữ nào trên máy chủ. Khơng cĩ phiên, khơng cĩ lịch sử. Bất kỳ trạng thái phiên nào đều do khách hàng nắm giữ.

Lý do cho điều này về cơ bản là khi số lượng máy khách tăng lên, máy chủ sẽ khơng thể theo dõi tất cả các máy khách đang giao tiếp với nĩ, điều này sẽ mất rất nhiều thời gian. Vì vậy, điều này về cơ bản là cần thiết để đảm bảo quy mơ của hệ thống. Nhưng về cơ bản điều này làm cho hệ thống REST thiếu một số chức năng cơ bản như đăng nhập, đăng xuất. Để xác thực và ủy quyền máy khách, máy chủ kiểm tra thơng tin đăng nhập của từng yêu cầu, do đĩ máy khách cần lưu trữ thơng tin đăng nhập và gửi chúng trong mỗi yêu cầu.

Hình 1.10 Stateless

Uniform interface

Bằng cách áp dụng nguyên tắc chung của kỹ thuật phần mềm cho giao diện thành phần, kiến trúc hệ thống tổng thể được đơn giản hĩa và khả năng hiển thị của các tương tác được cải thiện. Để cĩ được một giao diện thống nhất, cần cĩ nhiều ràng buộc kiến trúc để hướng dẫn hành vi của các thành phần. REST được định nghĩa bởi bốn ràng buộc giao diện: xác định tài nguyên; thao túng các nguồn lực thơng qua các đại diện; thơng điệp tự mơ tả; và, siêu phương tiện như động cơ của trạng thái ứng dụng.

Cacheable

Như trên WWW, máy khách cĩ thể lưu vào bộ nhớ cache các phản hồi. Do đĩ, các phản hồi phải tự xác định một cách rõ ràng hoặc rõ ràng là cĩ thể lưu vào bộ nhớ cache hoặc khơng, để ngăn máy khách sử dụng lại dữ liệu cũ hoặc

khơng phù hợp để phản hồi các yêu cầu khác. Bộ nhớ đệm được quản lý tốt sẽ loại bỏ một phần hoặc hồn tồn một số tương tác giữa máy khách và máy chủ, cải thiện hơn nữa khả năng mở rộng và hiệu suất.

Layered system

Thơng thường, một máy khách khơng thể biết liệu nĩ được kết nối trực tiếp với máy chủ cuối hay với một bên trung gian trên đường đi. Máy chủ trung gian cĩ thể cải thiện khả năng mở rộng hệ thống bằng cách cho phép cân bằng tải và bằng cách cung cấp bộ nhớ đệm dùng chung. Họ cũng cĩ thể thực thi các chính sách bảo mật.

Code on demand (optional)

Hầu hết thời gian, bạn sẽ gửi các biểu diễn tĩnh của tài nguyên dưới dạng XML hoặc JSON. Nhưng khi cần, bạn cĩ thể tự do trả lại mã thực thi để hỗ trợ một phần của ứng dụng. Nĩ được phép để làm mà khơng bị ngăn cản bởi các chính sách nào.

1.5.4. REST API

API web là giao diện lập trình ứng dụng cho máy chủ web hoặc máy khách web.

Hình 0.11 REST API

API cĩ sẵn ở cả phía máy chủ và phía máy khách, giúp lập trình Web dễ dàng hơn, cho phép các lập trình viên xây dựng ứng dụng web trên giao diện cấp cao.

API web phía máy chủ là giao diện lập trình bao gồm một hoặc nhiều điểm cuối được hiển thị cơng khai với hệ thống thơng báo yêu cầu-phản hồi đã xác định, thường được thể hiện bằng JSON hoặc XML, được hiển thị qua web - phổ biến nhất là dựa trên HTTP máy chủ web. API web phía máy khách là một giao diện cĩ lập trình để mở rộng chức năng trong trình duyệt web hoặc máy khách HTTP khác.

API REST là một API tuân theo các ràng buộc của REST. Nĩ cho thấy URI giống cấu trúc thư mục, chuyển XML, JSON hoặc cả hai. Các thành phần chính của giao thức chuẩn trong API REST được sử dụng để cung cấp các hành động CRUD (Create, Read, Update, Delete) cho các tài nguyên.

Bảng 1.1 Bảng quan hệ giữa SQL và HTTP

Operation SQL HTTP

Create INSERT POST

Read SELECT GET

Update UPDATE PUT/PATCH

Delete DELETE DELETE

Trong thực tế, một API REST khơng được cĩ đầy đủ 6 ràng buộc của REST. Nhưng nếu một API REST đáp ứng tất cả các ràng buộc của REST, nĩ được gọi là API RESTful.

1.5.5. Mơ hình MVC

Mẫu MVC đã được nhiều nhà phát triển báo trước là một mẫu hữu ích cho việc tái sử dụng mã đối tượng và một mẫu cho phép họ giảm đáng kể thời gian phát triển ứng dụng với giao diện người dùng.

Hình 1.12 Kiến trúc MVC

Mơ hình model-view-controller đề xuất ba thành phần hoặc đối tượng chính được sử dụng trong phát triển phần mềm:

− Model, đại diện cho cấu trúc cơ bản, logic của dữ liệu trong một ứng dụng phần mềm và lớp cấp cao liên kết với nĩ. Mơ hình đối tượng này khơng chứa bất kỳ thơng tin nào về giao diện người dùng.

− View, là một tập hợp các lớp đại diện cho các phần tử trong giao diện người dùng (tất cả những thứ mà người dùng cĩ thể nhìn thấy và phản hồi trên màn hình, chẳng hạn như các nút, hộp hiển thị, v.v.).

− Controller, đại diện cho các lớp kết nối mơ hình và khung nhìn và được sử dụng để giao tiếp giữa các lớp trong mơ hình và khung nhìn.

CHƯƠNG 2: ỨNG DỤNG THUẬT TỐN RANDOM FOREST VÀO BÀI TỐN

2.1. Thu thập dữ liệu

2.1.1 Quy trình thu thập dữ liệu từ hệ thống CMIS

Hệ thống thơng tin quản lý khách hàng dùng điện (CMIS) được EVN đưa vào sử dụng nhằm khai thác cĩ chức năng truy vấn sản lượng điện năng của khách hàng. Từ đĩ, các đơn vị cĩ thể xây dựng các chương trình ứng dụng để phát triển cho đơn vị nhằm tăng năng suất lao động và nâng cao SXKD tại Cơng ty.

Hệ thống CMIS được xây dựng và phát triển trên nền tản Oracle nên việc truy vấn vào cần được bảo đảm an tồn thơng tin để bảo vệ dữ liệu. Mọi truy vấn đến CSDL cần được xác thực và được cấp quyền riêng biệt. Nhằm đảm bảo hệ thống thơng tin luơn ổn định và liên tục. CMIS luơn đảm bảo chỉ cho phép chạy trên nền tảng mạng nội bộ của Điện lực.

Hệ thống AI dự đốn sản lượng điện tiêu thụ của khách hàng dựa trên sản lượng điện tiêu thụ theo tháng (kWh) của khách hàng đĩ. Do đĩ, tơi sẽ thu thập dữ liệu theo số liệu sản lượng điện trên hĩa đơn tiền điện tháng của khách hàng. Hệ thống thu thập dữ liệu sẽ thoạt động với tần suất 01 lần/01 tháng (kỳ hĩa đơn tiền điện của khách hàng) và sẽ thu thập tồn bộ các khách hàng sử dụng điện đã đăng ký mua điện trên địa bàn miền Trung. Vì vậy, tương ứng với mỗi năm, một khách hàng sẽ cĩ 12 trường dữ liệu theo hĩa đơn thanh tốn tiền điện từng tháng của khách hàng đĩ.

Ví dụ: khách hàng PC03BB0101051 cĩ sản lượng điện sử dụng qua từng tháng theo đơn vị tính kWh từ tháng 1 đến tháng 12 trong năm 2021 là: 603, 633, 554, 588, 693, 845, 882, 1136, 1050, 901, 662, 618 (12 trường dữ liệu tương ứng 12 tháng). Vậy 1 đối tượng sẽ cĩ tối thiểu 14 trường dữ liệu bao gồm (Mã khách hàng, năm sử dụng và 12 dữ liệu sản lượng điện theo hĩa đơn của 12 tháng).

Hình 2.1 Sản lượng điện tiêu thụ 12 tháng năm 2021 của khách hàng PC03BB0101051

2.1.2 Quy trình thu thập dữ liệu các khách hàng trộm cắp điện

Đầu tiên, ta sẽ tổng hợp lại danh sách các khách hàng ăn trộm điện và dữ liệu sản lượng điện của họ đã sử dụng qua từng tháng trong năm vi phạm. Để tập dữ liệu huấn luyện được lớn và đa dạng, tơi sẽ sử dụng dữ liệu của khách hàng đã vi phạm ăn trộm điện thuộc quyền quản lý của Tổng cơng ty Điện lực miền Trung (hơn 1.000 khách hàng đã cĩ hành vi ăn trộm điện từ năm 2018- 2021 đã được các Cơng ty Điện lực quản lý phát hiện và xử lý biên bản truy thu).

Dưới đây là 6 khách hàng trộm cắp điện năm 2019 thuộc Điện lực Nam Sơng Hương – TTHPC. Bằng khả năng nghiệp vụ, sau khi phát hiện khách hàng trộm cắp điện thì sẽ phân tích để chọn ra tháng cĩ sản lượng vi phạm.

Bảng 2.1 06 khách hàng trộm cắp điện năm 2019 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 125 159 131 177 185 185 78 169 205 204 168 142 285 133 276 321 354 242 138 180 157 159 152 101 221 208 242 373 492 820 764 829 769 638 609 511 138 144 116 124 123 204 339 263 169 142 186 152 996 573 923 1188 1296 2045 1910 1352 1747 1891 1833 1757 241 249 249 292 252 260 246 360 429 345 335 323 603 633 554 588 693 845 882 1136 1050 901 662 618 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 PC03BB0101051

Hình 2.2 Biểu đồ sản lượng trong năm 2019 06 khách hàng trộm cắp điện

2.1.3 Xử lý dữ liệu khách hàng gây nhiễu

Ngày nay, hành vi trộm cắp điện của các khách hàng ngày một tinh vi. Một số trường hợp ăn trộm điện nhưng sản lượng điện từng tháng khơng tăng hoặc giảm mạnh. Điều này làm các cán bộ giám sát phải giám sát nhiều yếu tố. Nhất thời cần bổ sung thêm dữ liệu điện từng ngày để kiểm tra tình hình sử

Một phần của tài liệu Xây dựng hệ thống AI nhận diện và dự đoán sản lượng điện năng tiêu thụ bất thường của khách hàng (Trang 34)