NHIỆM VỤ VÀ NỘI DUNG: - Xây dựng giao diện cấu hình gateway từ xa theo kiểu no-code - Thiết kế IoT gateway và lập trình vi điều khiển có chức năng tự động cấu hình và khởi tạo giao tiếp
CƠ SỞ LÝ THUYẾT
Giới thiệu máy ép phun nhựa
Máy ép nhựa (Injection Molding Machine), hay còn gọi là máy ép phun, máy ép keo, máy thành hình Chúng được sử dụng phổ biến trong các dây chuyền công nghệ ép phun Máy ép nhựa có tác dụng giữ khuôn đóng cố định trong quá trình đẩy nhựa nóng chảy bằng một áp lực phun vào lõi khuôn để điền đầy lòng khuôn và mở khuôn sau khi sản phẩm được làm nguội Sản phẩm sau đó sẽ được đẩy ra ngoài thông qua hệ thống lói
Hình 3.1 Máy ép phun nhựa (Nguồn: Haitian)
Máy ép nhựa bao gồm 2 thành phần chính: phần phun nhựa và kẹp khuôn Ngoài ra, cấu tạo của máy sẽ bao gồm thêm một số bộ phận khác: hệ thống làm nguội, hệ thống hỗ trợ, robot,…
Hình 3.2 Cấu tạo máy ép phun
Máy ép nhựa có nguyên lý hoạt động giống như một bơm tiêm Đầu tiên, nhựa sẽ được đưa vào phễu chứa Sau đó, chúng sẽ được hóa lỏng mỏi thanh gia nhiệt ở nhiệt độ thích hợp Tiếp theo, toàn bộ nhựa lỏng sẽ di chuyển lên phía trước nhờ trục vít Đồng thời, trục vít sẽ lùi về phía sau để tạo ra khoảng trống cho nhựa chảy vào phía trước đầu phun Nhờ áp lực đẩy của trục vít, nhựa nóng sẽ được bom và khuôn Cuối cùng, hệ thống làm mát sẽ làm nguội sản phẩm trước khi lấy sản phẩm ra ngoài
Hình 3.3 Nguyên lí hoạt động của máy ép phun
Trong đề tài, tôi thực hiện thu thập dữ liệu của dòng máy ép phun do hãng Haitian sản xuất
Sản phấm ép ra từ Máy ép phun bao gồm hai dòng sản phẩm chính là nắp bàn cầu và cụm cấp xả được thể hiện bên dưới
Hình 3.4 Sản phẩm nắp bàn cầu
Nắp bàn cầu gồm: 20 dòng nắp đế, 3 dòng pas, 3 dòng cột hơi, 7 dòng phụ kiện
Cụm cấp xả gồm: 3 dòng cụm cấp, 3 dòng cụm xả, 10 dòng cụm nhấn
Thực trạng nhà máy đang gặp phải những vấn đề cấp bách như sau:
- Hàng lỗi ép ra không được phát hiện và sửa chữa kịp thời, từ đó làm giảm sản lượng ép và kéo theo làm giảm hiệu suất sản xuất của nhà máy
- Công nhân cố ý thay đổi thông số máy ép, làm giảm chất lượng sản phẩm ép ra và ảnh hưởng đến uy tín của thương hiệu
- Xuất hiện tình trạng công nhân treo máy, nếu không phát hiện kịp thời sẽ làm hư hại Máy ép và ảnh hưởng đến hiệu suất sản xuất của nhà máy
- Không có công cụ để tự động dự báo các trường hợp bất thường Máy ép Khi máy ép hoạt động bất thường sẽ dễ dẫn đến hư hại khuôn ép, sản phẩm ép bị lỗi và hậu quả là buộc dừng sản xuất để sửa chữa, khiến thời gian chết nhà máy tăng cao
- Thông tin sản xuất của Máy ép và các sản phẩm ép đều được lưu trữ toàn bộ trên Excel Không có công cụ trực quan để phân tích, đánh giá kết quả sản xuất
- Báo cáo ép máy phụ thuộc khá lớn (có thể nói là phụ thuộc hoàn toàn) vào con người, khiến cho độ tin cậy của báo cáo là không cao Điều này dẫn đến kế hoạch ép và lệnh sản xuất bị đi theo lối mòn, không thể có phương án cải thiện để mang lại lợi ích cao cho nhà máy
Những vấn đề nói trên cơ bản xuất phát từ việc ban quản lí nhà máy không giám sát được thông tin ép máy theo thời gian thực tế Để giải quyết triệt để vấn đề này, từ đó giám sát hiệu suất làm việc của máy ép để tính toán và đưa ra lệnh sản xuất tối ưu chi phí và nhân công nhà máy, doanh nghiệp đã đề ra danh mục dữ liệu máy cần thu thập được yêu cầu trong bảng sau:
Bảng 3.1 Thông tin dữ liệu cần thu thập từ máy ép
Tuy nhiên trong quá trình khảo sát thực nghiệm tại nhà máy, các máy ép ở nhà máy lại có phiên bản khác nhau Đối với các máy đời mới, số lượng dữ liệu thu thập được sẽ đầy đủ giống như đã liệt kê Nhưng đối với các máy ép phiên bản đời cũ hơn, không hỗ trợ truyền thông thì sẽ thu thập dữ liệu ép thông qua các chân tín hiệu trên PLC Đây là điểm chưa hoàn chỉnh của đề tài này.
IoT gateway thu thập dữ liệu hiện trường
IoT Gateway là cầu nối giữa các loại công nghệ khác nhau về giao diện, giao thức hoặc các kiểu kết nối Tương tự như gateway (hoạt động như một cổng tổng hợp, xử lý và lọc ra tất cả dữ liệu), cổng IoT Gateway được cải tiến khả năng thực hiện các ứng dụng điện toán phức tạp Như đã giới thiệu ở phần trước, nhu cầu số hóa và tin học hóa dữ liệu sản xuất ở tầng hiện trường ở doanh nghiệp sản xuất là ngày càng lớn Một trong những phương án hữu hiệu giúp thu thập dữ liệu hiện trường theo thời gian thực và mang tính ổn định đó là sử dụng các IoT gateway Trong phạm vi đề tài, tôi sử dụng ESP32 đóng vai trò là IoT gateway giúp thu thập và truyền dữ liệu không dây theo thời gian thực về máy chủ
MCU ESP32 là một hệ thống dual-core với 2 CPU Xtensa LX6 sử dụng kiến trúc Harvard Tất cả bộ nhớ nhúng, bộ nhớ ngoài và các ngoại vi đều nằm trên đường data bus và intruction bus của CPU Hai CPU được đặt tên là “PRO_CPU” và “APP_CPU” (“protocol” và “application”), tuy nhiên với hầu hết các mục đích cả 2 CPU đều có thể hoán đổi cho nhau
Hình 3.6 Tính năng chip ESP32-S2 (Nguồn: Espressif)
ESP-IDF (Espressif-IoT Development Framework) là một môi trường phát triển các ứng dụng IoT chính thức của Espressif dành cho các dòng chip ESP32, ESP32-S và ESP32-C Nó cung cấp các công cụ và phần mềm dùng để phát triển ứng dụng (SDK) trên nền tảng ngôn ngữ C và C++
Hình 3.7 Tính năng của môi trường ESP-IDF (Nguồn: Espressif) Đề tài thực hiện lập trình chức năng cho IoT Board trên môi trường ESP-IDF sử dụng ngôn ngữ lập trình C.
Một số giao thức truyền thông trong công nghiệp
Giao thức truyền thông đóng vai trò như là “thông dịch viên”, giúp các thiết bị giao tiếp và trao đổi dữ liệu được với nhau Trong ngành công nghiệp tự động hóa, các giao thức truyền thông được sáng tạo ra nhằm kết nối dữ liệu máy móc đến các hệ thống sản xuất, cho thấy được hiệu quả sản xuất và tình trạng của máy Bên cạnh đó, người vận hành có thể giám sát dữ liệu máy một cách tự động bằng việc thu thập dữ liệu thiết bị thông qua các giao thức truyền thông
- Ethernet/IP: đây là chuẩn giao thức truyền thông được ứng dụng trong công nhiệp tự động hóa và IoT Etnernet/IP kế thừa 2 bộ tiêu chuẩn là Internet Protocol (IP) và IEE 802.3 để quy định tầng vận chuyển, tầng mạng, tầng liên kết dữ liệu và tầng vật lý
Hình 3.8 Biểu diễn của Ethernet/IP trong mô hình OSI 7 tầng
Phần IP của Ethernet/IP là viết tắt của Industrial Protocol, nó thích nghi hoặc chuyển đổi Common Industrial Protocol (CIP) để sử dụng trên nền Ethernet Vì vậy Ethernet/IP có thể thu thập và truyền bất kì tin hiệu I/O nào xuyên suốt đường mạng Quá trình này đã giúp dễ dàng thực hiện các chức năng tự động hóa mặc cho nhà máy có nhiều loại thiết bị khác nhau Trong các giải pháp ứng dụng IoT,
Ethernet/IP cho phép kết nối và thu thập dữ liệu từ cảm biến, bộ điều khiển đến các hệ thống điều khiển hòa vào trong cùng một mạng Đồng thời, các dữ liệu thu thập được có thể đẩy từ mạng lên các dịch vụ đám mây thông qua các thiết bị biên phù hợp [16]
- Modbus: đây là chuẩn giao tiếp được sử dụng rộng rãi trong công nghiệp cho tới ngày nay bởi vì là “ngôn ngữ” lâu đời và thông dụng để kết nối đến máy móc và thiết bị tự động hóa Modbus thường được sử dụng trong các hệ thống SCADA Không chỉ dừng lại ở mạng nối tiếp, Modbus ngày nay còn có thể giao tiếp trên nền Ethernet và TCP/IP [16]
- Factory Interface Network Service (FINS), là một giao thức mạng được sử dụng bởi các PLC Omron, qua các mạng vật lý khác nhau như Ethernet, Controller Link, DeviceNet và RS-232C Dịch vụ truyền thông FINS được phát triển bởi
Omron để cung cấp một cách nhất quán cho các PLC và máy tính trên các mạng khác nhau để giao tiếp
- Open Platform Communication - Unified Architecture (OPC-UA): giao thức sử dụng chủ yếu cho các chức năng điều khiển, tự động hóa công nghiệp, và thu thập dữ liệu trong các ứng dụng IoT Đây là một giao thức độc lập, không phụ thuộc vào nền tảng nào OPC-UA có tính mở rộng và bảo mật cao vì sử dụng tính năng trao đổi chứng chỉ và nhiều phương thức mã hóa điểm-điểm khác Trong các ứng dụng IoT, giao thức này cho phép người dùng kết nối điều khiển thiết bị tại biên hoặc trên đám mây [16] OPC UA ra đời đã khắc phục được những hạn chế của OPC, đồng thời còn được cung cấp những tính năng để đáp ứng cho những yêu cầu của cách mạng công nghiệp 4.0 Đến năm 2017, OPC UA được cập nhật thêm tính năng Publish – Subscribe để đáp ứng những yêu cầu của các hệ thống TSN (hệ thống đòi hỏi dữ liệu được truyền với độ trễ rất thấp), tăng tốc độ truyền nhận dữ liệu bằng cơ chế Publish và Subscribe
Những ưu điểm của OPC UA:
- OPC UA là chuẩn quốc tế IEC 62541
- OPC UA Server và Client có thể được lập trình và chạy trên nhiều hệ điều hành khác nhau, cũng như các nền tảng phần cứng khác nhau
- OPC UA Server và Client có thể được chạy trên các thiết bị trường như cảm biến và cơ cấu chấp hành Như vậy dữ liệu từ cảm biến, thiết bị chấp hành có thể được đưa thẳng lên Cloud mà không cần phải thông qua phần mềm trung gian
- Có tính bảo mật cao, sử dụng nhiều lớp bảo mật
Một trong những nhiệm vụ chính của đề tài là giải mã truyền thông OPC UA từ các PLC máy ép và truyền lên IoT Server Điểm khác biệt của đề tài chính là sử dụng các IoT Gateway đóng vai trò giải mã, lưu trữ và vận chuyển không dây dữ liệu theo thời gian thực
Hình 3.9 OPC-UA trong các ứng dụng IoT
Sparkplug MQTT
Giao thức OPC-UA ra đời cung cấp một ngôn ngữ chung trong công nghiệp giao tiếp giữa các thiết bị, máy móc và các ứng dụng phần mềm Tuy nhiên, bởi vì OPC-UA phức tạp và không phải lúc nào cũng dễ dàng tích hợp vào hệ thống, đặc biệt là đối với các hệ thống không được thiết kế ngay từ đầu cho việc liên kết và thu thập dữ liệu dùng OPC-UA, cần thiết phải tìm ra một giải pháp khác phù hợp hơn để thay thế [14] Mặt khác, sự ra đời của MQTT cùng với các đặc điểm mang tính cách mạng như giao tiếp giữa thiết bị tới cloud với độ trễ tối thiểu và thông lượng lớn, nhiều kỹ sư mong muốn một giải pháp đơn giản như MQTT để ứng dụng trong sản xuất nhưng cần phải thêm những quy định đặc thù của các ngành sản xuất như định nghĩa gói tin và thống nhất quy tắc truyền nhận giữa thiết bị và trung gian Bài toán được giải quyết với sự ra đời của giao thức Sparkplug, kế thừa từ MQTT với các bổ sung và điều chỉnh phù hợp hơn Trong đề tài này, tôi tập trung đi sâu vào giải mã giao thức Sparkplug B MQTT với thiết bị trường là máy ép nhựa (điều khiển bằng PLC S7-1200), thiết bị biên là ESP32 IoT custom board tự phát triển Sparkplug tập trung định nghĩa 3 thành phần chính [14]:
• Định nghĩa một MQTT Topic Namespace
• Định nghĩa quản lí trạng thái MQTT
• Định nghĩa gói tin MQTT
Gói tin Sparkplug MQTT tuân theo một cấu trúc chuẩn để đảm bảo tính nhất quán và hiệu quả trong việc trao đổi thông tin giữa các thiết bị IoT Một gói tin Sparkplug MQTT thường bao gồm các thành phần sau [14]:
• Topic: Đây là phần quy định vị trí hoặc địa chỉ của dữ liệu trong mạng IoT Topic xác định nơi mà dữ liệu sẽ được gửi hoặc nhận
• Namespace: Namespace xác định loại dữ liệu hoặc mục tiêu của gói tin, giúp phân loại thông tin một cách rõ ràng
• Payload: Payload là phần quan trọng chứa dữ liệu thực sự mà gói tin đang truyền tải Đây có thể là thông tin về trạng thái của thiết bị, dữ liệu cảm biến, hoặc bất kỳ thông tin nào cần được trao đổi
• Timestamp: Sparkplug MQTT thường bao gồm timestamp để xác định thời gian khi dữ liệu được tạo ra hoặc cập nhật Điều này hữu ích trong việc đồng bộ hóa dữ liệu trong mạng
• State: State cho biết trạng thái của thiết bị hoặc dữ liệu, chẳng hạn như trạng thái hoạt động hoặc ngừng hoạt động
• Metadata: Metadata có thể bao gồm các thông tin khác về dữ liệu như đơn vị đo lường, độ chính xác, hoặc thông tin mô tả
Tận dụng các ưu điểm nổi bật của giao thức Sparkplug MQTT trong môi trường công nghiệp, tôi đã thực hiện thành công việc giải mã và trao đổi các gói tin chứa dữ liệu theo cả hai chiều truyền và nhận Những gói tin này không chỉ đóng gói dữ liệu thu thập từ các thiết bị trường thành một tập tin thống nhất, mà còn chứa thông tin quan trọng về cấu hình, danh sách các thiết bị cần lấy dữ liệu, và loại giao thức cần sử dụng Mục tiêu chính của việc này là tạo ra khả năng cấu hình từ xa trên thiết bị điện toán biên để đáp ứng các yêu cầu đặc thù của mỗi doanh nghiệp Nhờ vào việc này, việc cập nhật dữ liệu máy móc trở nên nhanh chóng hơn, giúp các dữ liệu thu thập được cập nhật theo thời gian thực, tạo điều kiện để xử lý kịp thời trong trường hợp xảy ra sự cố ở lớp thiết bị trường
Hình 3.10 Mô tả cấu trúc, cơ sở hạ tầng của mô hình Sparkplug
IIoT Host đóng vai trò là ứng dụng trung tâm để quản lý và giám sát toàn bộ trạng thái của hệ thống Ứng dụng này tương tác trực tiếp tới MQTT Broker như là một MQTT Client Khác với kiến trúc hệ thống SCADA truyền thống, IIoT Host trong kiến trúc Sparkplug không chịu trách nhiệm thành lập hay duy trì kết nối tới các thiết bị một cách trực tiếp [14]
Edge of Network (EoN) nốt giữ vai trò cốt lõi trong hầu hết kiến trúc
Sparkplug Về cơ bản, EoN nốt được dùng để kết nối các thiết bị trường đến
Sparplug Các thiết bị trường giao tiếp với EoN nốt thông qua các giao thức truyền thông như OPC-UA, Modbus, hoặc các giao thức đặc thù của mỗi PLC EoN nốt chịu trách nhiệm quản lý chính trạng thái của nốt và trạng thái của thiết bị được kết nối tới nốt, cũng như nhận và truyền dữ liệu từ các thiết bị đến kiến trúc Sparkplug [14]
Các thiết bị trường là xương sống của công nghiệp tự động hóa Trong
Sparkplug, các thiết bị kết nối đến kiến trúc này thông qua EoN nốt Mặc dù hầu hết các thiết bị và cảm biến sử dụng các giao thức như Modbus, OPC-UA, và nhiều tiêu chuẩn hoặc giao thức đặc thù khác, nhiều nhà cung cấp ngày nay đã tích hợp thêm giao tiếp MQTT vào thiết bị và cảm biến Nếu các thiết bị có hỗ trợ sẵn MQTT và đã có thể liên kết với Sparkplug, chúng có thể tham gia trực tiếp vào hạ tầng
Sparkplug Trong trường hợp đó, thiết bị sẽ định nghĩa chính nó là một EoN nốt ở kiến trúc Sparkplug Nếu thiết bị chỉ hỗ trợ giao tiếp MQTT cơ bản thì vẫn cần phải thành lập một kết nối giữa EoN trung gian [14]
Các ứng dụng MQTT, hay gọi cách khác là các ứng dụng thứ cấp, là các thành phần tham gia vào mạng giao tiếp Sparkplug và có thể tạo và xử lý các gói tin MQTT, nhưng nó không phải là IIoT Host [14]
Với hầu hết các MQTT client như IIoT Host hoặc các ứng dụng IT đều phải đăng ký đến topic chứa nguồn thông tin mình muốn nhận Nhờ vào việc quy định cứng cấu trúc gói tin Sparkplug, mỗi MQTT client sẽ biết được kiểu thông tin và địa điểm chứa thông tin mình muốn nhận là ở đâu Việc các MQTT cilent đều có hiển thị trạng thái nên không xảy ra trường hợp mất thông tin ở bất kỳ thời điểm nào Mỗi kiểu gói tin sẽ biểu diễn cho một thông tin nhất định
Mỗi một MQTT client đều phải tuân thủ cấu trúc quy định gói tin Sparkplug
B Trong đó, topic namspace được định nghĩa như sau [14]: namespace/group_id/message_type/edge_node_id/[device_id]
Với: namespace là phần tử đầu tiên, quy định phiên bản Sparkplug (ví dụ spBv1.0) group_id là nhóm logic trong các nốt MQTT (ví dụ group_1) message_type là kiểu gói tin Sparkplus (ví dụ NCMD) edge_node_id đặc trưng cho một nốt (ví dụ N01)
Tiếp theo là định nghĩa kiểu gói tin Sparkplug B quy định sẵn các kiểu gói tin như sau:
3.4.1 Birth certificate/ Death certificate cho nốt và thiết bị:
Một gói tin BIRTH thông báo rằng MQTT client đang hoạt động Thiết bị và nốt phải cung cấp thông tin này đến toàn bộ hệ thống thông qua BIRTH topic Kiểu gói tin này được gửi đi ngay khi kết nối được thành lập Các EoN nốt thì gửi gói tin NBIRTH, còn các thiết bị thì gửi gói tin DBIRTH
Gói tin DEATH được sử dụng để thông báo trạng thái dừng hoạt động của một thiết bị hay một EoN nốt Nếu client mất kết nối, broker sẽ gửi gói tin đặc biệt đến DEATH topic tương ứng Phương thức này cho phép phát hiện trạng thái của client kể cả khi mất kết nối Các nốt thì gửi gói tin
NDEATH, còn các thiết bị thì gửi gói tin DDEATH
3.4.2 Gói tin DATA cho nốt và thiết bị:
Gói tin này được sử dụng để truyền tải một lượng dữ liệu và thông tin chi tiết của một thiết bị Chỉ khi có sự thay đổi của thông tin so với gói tin DATA cuối cùng hoặc khi có gói tin BIRTH thành lập thì dữ liệu mới được gửi đi (để đảm bảo không bị chậm trễ trên đường truyền mỗi khi có thiết lập lại) Kiến trúc publish/subscribe của MQTT đã loại bỏ đi việc thăm dò sự thay đổi bởi vì một khi có thay đổi, toàn bộ dữ liệu sẽ chủ động gửi đi đến những client nào có đăng kí đúng topic đó
3.4.3 Gói tin command cho nốt và thiết bị:
IoT Server
Sau khi đã có cơ sở hạ tầng cho việc thiết lập kết nối và truyền tải dữ liệu đến broker, cần thiết phải xây dựng một máy chủ (server) để chứa dữ liệu thu thập được Bên cạnh đó, server trong nghiên cứu này chính là nơi giao tiếp thường xuyên với broker nhằm xây dựng nên các ứng dụng thứ cấp về sau
Toàn bộ cấu trúc hạ tầng Sparkplug thực hiện trong nghiên cứu này được thể hiện bởi sơ đồ dưới đây
Hình 3.11 Tổng quan nền tảng No-code IIoT trong nghiên cứu
Nền tảng no-code IIoT được xây dựng để hướng tới mục tiêu không cần lập trình Người dùng chỉ cần nắm bắt các thao tác sử dụng cơ bản trên giao diện cấu hình, sau đó toàn bộ hệ thống sẽ được cập nhật và vận hành theo đúng yêu cầu mà người dùng đặt ra Bằng cách đó, nền tảng mang đến tính mở và tính ứng dụng cao ứng với nhiều yêu cầu đặc thù khác nhau
Giao diện cấu hình và quản lý là nơi xuất phát mọi hành động Người dùng thực hiện khai báo cho hệ thống các thông tin cần thiết: hệ thống sẽ bao gồm các nốt (node) gì, địa chỉ định danh của các nốt, danh sách dữ liệu cần lấy của nốt tương ứng, phương thức thu thập dữ liệu với thiết bị (device) là định danh các thẻ (tag) dữ liệu của thiết bị đó Sau khi cấu hình xong, giao diện gọi đến server thông qua phương thức HTTP, chỉ định server gửi đi một “tệp cấu hình” dưới dạng các gói tin Sparkplug để tiến hành cấu hình hệ thống các node tương ứng với cấu trúc mà người dùng đã thiết kế trước đó Ở chiều ngược lại, các dữ liệu thu thập được từ thiết bị sẽ được các EoN node gửi về và hiển thị lên giao diện này, giúp cho người dùng dễ dàng quản lí và giám sát được dữ liệu Dĩ nhiên, giao diện cấu hình và quản lí phải trang bị một số chức năng nhất định để phục vụ cho việc cấu hình và giám sát dữ liệu thu được
Từ IoT Server, một database sẽ được tạo ra tương ứng với số lượng và thành phần các node, device, tag đã cấu hình trên giao diện Sau đó, Server sẽ phát lệnh đến MQTT Broker các gói dữ liệu Sparkplug phục vụ cho việc cấu hình hệ thống bên dưới Đồng thời, Server cũng là nơi lưu trữ dữ liệu thu được từ broker thông qua các topic đã đăng kí để phục vụ cho việc truy xuất ở các ứng dụng thứ cấp khác
Từ các Node, dựa trên các “tệp hướng dẫn” nhận từ MQTT Broker sẽ thực hiện giải mã và xác định device mà mình kết nối Đồng thời xác định được các thông tin dữ liệu cần lấy và phương thức cần dùng đối với device đó Sau khi khởi tạo kết nối thành công, các Node sẽ gửi một Birth Certificate về Broker thông báo hệ thống đã kết nối thành công Ngược lại, trong quá trình khởi tạo kết nối nếu có gián đoạn hoặc lỗi xảy ra, các Node sẽ gửi Death Certificate về Broker Cơ chế gửi Birth/Deadth Certificate dựa trên giao thức Sparkplug
Các Device là các máy ép mục tiêu, các EoN thiết lập kết nối đến các máy ép này và thu thập dữ liệu từ chúng.
Support vector classifier (SVC)
SVC là một dạng triển khai cụ thể của Support vector machine (SVM), được thiết kế đặc biệt dành cho bài toán phân loại Các đặc trưng toán học đằng sau SVC được mô tả như sau:
Phương trình siêu phẳng (hyperplane equation): đối với bài toán phân loại nhị phân, mục tiêu là tìm ra một siêu phẳng phân tách dữ liệu thành hai lớp khác biệt
Về toán học, siêu phẳng đó được định nghĩa bởi phương trình:
Trong đó, w là vector trọng số vuông góc với siêu phẳng, x là điểm dữ liệu, và b là thành phần bias
Margin: đây là khoảng cách giữa siêu phẳng và điểm dữ liệu gần nhất của hai lớp Giá trị margin càng lớn thì độ tin cậy của kết quả phân loại càng cao Margin có thể được tính bằng cách xét khoảng cách giữa hai siêu phẳng song song nhau (mỗi siêu phẳng cho một lớp dữ liệu) Về mặt toán học, margin là nghịch đảo của chuẩn (norm) vector trọng số w
Support vector: là tập hợp các điểm dữ liệu gần siêu phẳng nhất Đây là những điểm dữ liệu giữ vai trò quyết định trong việc xác định vị trí siêu phẳng Các support vector góp phần tính toán và xác định margin
Soft margin: Trong dữ liệu thực tế, không phải lúc nào cũng tìm ra được một siêu phẳng tách biệt hoàn toàn hai lớp dữ liệu Khái niệm soft margin trong SVM cho phép phân loại sai bằng cách chấp nhận một (vài) điểm dữ liệu sẽ nằm sai phía so với margin hoặc thậm chí sai phía so với siêu phẳng
Hàm mục tiêu (Objective Function): Mục tiêu của SVM là tìm ra margin có giá trị lớn nhất đồng thời tối thiểu sai số khi phân lớp Điều này được giải quyết bằng cách giải bài toán tối ưu hóa, chính là tìm ra giá trị w và b thỏa mãn một số điều kiện nhất định nào đó Bài toán tối ưu hóa có thể được biểu diễn như sau:
Kernel trick: trong trường hợp không phân tách dữ liệu tuyến tính được, SVM sử dụng kỹ thuật tên là kernel trick nhằm biến đổi dữ liệu vào miền không gian đa chiều hơn ban đầu, nơi mà ở đó có thể tìm được một siêu phẳng phù hợp Kernel thường được sử dụng trong trường hợp này là radial basis funtion (RBF) kernel
Trong đề tài này, kỹ thuật phân loại SVC được sử dụng với RBF kernel để phân loại và dự đoán offline đối với chất lượng sản phẩm ép.
XÂY DỰNG PHẦN CỨNG VÀ PHẦN MỀM
Thiết kế và lập trình nhúng IoT board
Sau khi tham khảo các vi điều khiển ứng dụng trong công nghiệp, tôi chọn vi điều khiển ESP32 của Espressif Systems bởi các tính năng của chip rất thích hợp để làm gateway ứng với quy mô thực hiện của nghiên cứu này IoT board được thiết kế để phát huy thế mạnh của dòng chip ESP32-S Trên board nhúng có kết hợp với bộ vi xử lí ARM dòng F1 nhằm trang bị đầy đủ các tính năng cần thiết và khả năng tính toán mạnh mẽ để có thể đảm nhiệm vai trò là EoN nốt trong kiến trúc
Sparkplug đã đề cập ở chương trước
Hình 4.1 Sản phẩm IoT board tự thiết kế
Môi trường lập trình nhúng là ESP-IDF, ngôn ngữ lập trình C trên phần mềm Visual Studio Code ESP32 được lập trình trên hệ điều hành FreeRTOS dựa vào các ưu điểm của nó như hỗ trợ nhiều kiến trúc vi điều khiển khác nhau, kích thước nhỏ gọn (4.3 Kbytes sau khi biên dịch trên ARM7), được viết bằng ngôn ngữ C và có thể sử dụng, phát triển với nhiều trình biên dịch C khác nhau (GCC, OpenWatcom, Keil, IAR, Eclipse, …), cho phép không giới hạn các tác vụ chạy đồng thời, không hạn chế quyền ưu tiên thực thi, khả năng khai thác phần cứng Ngoài ra, nó cũng cho phép triển khai các cơ chế điều độ giữa các tiến trình như: queues, counting semaphore, mutexes
Trong khuôn khổ của đề tài, tôi sử dụng thư viện FreeRTOS được tích hợp sẵn trong ESP-IDF để chia chương trình thành các Task chính: Main task, App
Notifications task, Sparkplug task, GPIO task, MQTT Mess task
Hình 4.2 Tổng quan giải thuật lập trình nhúng Main task: đây là nơi đầu tiên hệ điều hành quét tới Nhiệm vụ ở đây là khởi tạo giao tiếp thẻ SD, đọc thời gian thực và mạng không dây và khởi động một lần toàn bộ các task trong chương trình
App Notifications task: là task nhận thông báo từ các hàm con khác khi có sự kiện xảy ra và thực thi các nhiệm vụ tương ứng
Sparkplug task: dùng để thiết lập kết nối Sparkplug đến broker và đăng kí đến các topic đã quy định sẵn Đồng thời, task này có nhiệm vụ giải mã gói tin nhận được để xác định cấu trúc hệ thống cần cấu hình
GPIO task: dùng để xử lý các sự kiện ngắt từ các chân digital input, qua đó xác định dữ liệu máy cần thu thập: chu kỳ ép, thời gian mở cửa, chế độ hoạt động và trạng thái máy Dữ liệu sau đó được đóng gói để gửi đi bằng Sparkplug MQTT, đồng thời lưu trữ lại vào thẻ nhớ Để gửi hoặc nhận được dữ liệu, bắt buộc gói tin với được thống nhất từ trước và phải tuân thủ theo cấu trúc gói tin của Sparkplug B Mô tả các gói tin quy ước được thể hiện ở bảng sau:
Bảng 4.1 Quy ước các gói dữ liệu Sparkplug
Kiểu gói tin Topic Nội dung
NBIRTH spBv1.0/Sparkplug B Devices/NCMD/{node_id}
"metrics" : [ { cccccccccccc"name" : "nodeId", cccccccccccc"timestamp" : 1702282909286, cccccccccccc"dataType" : "String", cccccccccccc"value" : “N01” cccccccccc}, { ccccccccc "name" : "nodeName", ccccccccccc"timestamp" : 1702282909291, ccccccccccc"dataType" : "String", ccccccccccc"value" : “Khu ep do choi” cccccccccc}, { ccccccccc "name" : "Device1", ccccccccccc"timestamp" : 1702282909301, ccccccccccc"dataType" : "String", ccccccccccc"value" : “DV01” ccccccccccc},{ ccccccccc"name" : "Device2", ccccccccccc"timestamp" : 1702282909301, ccccccccccc"dataType" : "String", ccccccccccc"value" : “DV02” ccccccccccc},{ ccccccccc} ], "seq" : 198 }
DBIRTH spBv1.0/Sparkplug B Devices/DCMD/Node 1/{device_id}
"metrics" : [ { cccccccccccc"name" : "deviceId", cccccccccccc"timestamp" : 1702282909286, cccccccccccc"dataType" : "String", cccccccccccc"value" : “DV01”
}, { ccccccccccc"name" : "deviceProtocol", ccccccccccccc"timestamp" : 1702282909291, ccccccccccccc"dataType" : "String”, ccccccccccccc"value" : “GPIO” ccccccccc}, { cccccccccccc "name" : "injectionTime", cccccccccccccc"timestamp" : 1702282909301, cccccccccccccc"dataType" : "float", cccccccccccccc"value" : 2.0 cccccccccc},{ ccccccccccc"name" : "doorOpen", ccccccccccccc"timestamp" : 1702282909301, ccccccccccccc"dataType" : "Bool", ccccccccccccc"value" : false cccccccccc},{ cccccccc} ], "seq" : 198 }
DDEATH spBv1.0/Sparkplug B Devices/NDEATH/{node_id}
Thiết kế và lập trình IoT Server
Như đã đề cập trên đây, nhu cầu cập nhật dữ liệu theo thời gian thực và xử lí một lượng thông tin dữ liệu lớn đòi hỏi phải có một kiến trúc xây dựng máy chủ phù hợp Vì thế, Domain Driven Design (DDD) đã được ứng dụng để xây dựng cấu trúc máy chủ Kiến trúc DDD và các thành phần cơ bản (entity, value type, aggregates, domain services) giúp nhóm nghiên cứu quy định chặt chẽ các mối quan hệ phức tạp giữa các thành phần trong hệ thống Ngôn ngữ lập trình được sử dụng là C#, lập trình trên môi trường phát triển Visual Studio Cùng với C# và kiến trúc DDD hệ thống máy chủ được xây dựng với kiến trúc như sau:
Hình 4.3 Kiến trúc máy chủ được xây dựng trong đề tài
Theo đó, hệ thống được chia thành bốn module như sau [18]:
Domain (Nghiệp vụ): Tại đây định nghĩa các nghiệp vụ (domain model) để biểu diễn các yếu tố trong hệ thống Ở nghiên cứu này, các nghiệp vụ này bao gồm Device (thiết bị máy ép), EoN Node (gateway), và Tag (biến dữ liệu) Chúng đã được mô tả bằng thuộc tính và phương thức tương ứng để mô tả trạng thái và hành vi Đồng thời, quy tắc đã được thiết lập để đảm bảo tính toàn vẹn của dữ liệu
Module nghiệp vụ này có vai trò như một bounded context giúp quản lý và cung cấp dữ liệu cho các phần khác
Infrastructure (Hạ tầng): Phần này chịu trách nhiệm xây dựng liên kết giữa các nghiệp vụ với cơ sở dữ liệu Entity Framework Core được sử dụng để ánh xạ các nghiệp vụ thành dạng bảng trong cơ sở dữ liệu SQL Server Repository Pattern được triển khai để trừu tượng hóa việc truy xuất và lưu trữ dữ liệu Module này có vai trò như một bounded context Data Persistence giúp duy trì và lưu trữ dữ liệu cho module Domain ở phía trên
Host (Máy chủ): Module này xử lý dữ liệu nhận được từ thiết bị thông qua giao thức Sparkplug Sparkplug được sử dụng để kết nối với MQTT broker và đăng ký theo dõi tin nhắn từ các topic liên quan đến thiết bị Sau khi nhận được tin nhắn, dữ liệu được chuyển đổi thành đối tượng Data và lưu trữ vào cơ sở dữ liệu thông qua Repository Module này được đóng gói và triển khai bằng Docker để tối ưu hiệu suất và khả năng mở rộng Containerization giúp cách ly ứng dụng và tài nguyên, đảm bảo xử lý tốc độ dữ liệu cao mà không ảnh hưởng đến hiệu suất
WebAPI: Phần này tạo ra các endpoint để cung cấp dữ liệu cho các ứng dụng khác Sử dụng ASP.NET Core Web API, các endpoint này được tạo ra và tuân thủ theo tiêu chuẩn RESTful, cho phép lọc dữ liệu dựa trên nhiều tiêu chí Ngoài ra, phần này cũng hỗ trợ gửi dữ liệu thời gian thực đến client thông qua SignalR Cụ thể, ở module Host đã phát triển một service nhằm kiểm tra khi có dữ liệu IIoT và gọi đến một hub trong module WebAPI Sau đó, client có thể cập nhật dữ liệu liên tục thông qua SignalR Module WebAPI cũng sử dụng ngôn ngữ chung bounded context để giao tiếp với 3 module phía trên.
Dự báo chất lượng sản phẩm ép
Việc dự đoán chất lượng sản phẩm mang lại một lợi ích to lớn giúp cho nhà máy tránh thất thoát nguyên vật liệu ép, tiết kiệm chi phí nhân công, tự động hóa dây chuyền và giảm thời gian kiểm tra sản phẩm Thật vậy, qua quá trình khảo sát thực tế tại nhà máy, tình trạng sản phẩm ép ra bị lỗi là khá thường xuyên Thậm chí, có lúc nhà máy bắt buộc phải tạm dừng sản xuất để khắc phục vấn đề Nhằm phát hiện sớm và nhanh chóng đưa ra cảnh báo sớm về chất lượng sản phẩm ép ra, tôi quyết định thực hiện nghiên cứu giải thuật dự báo chất lượng sản phẩm dựa trên dữ liệu ép máy
Qua việc phân tích và tham khảo ở [17], bài toán phân loại xác định ba loại chất lượng sản phẩm sau khi ép:
• NOK (filling) : khi sản phẩm cuối bị thiếu nhựa
• NOK (burr) : khi sản phẩm cuối bị thừa nhựa
Mô hình gán nhãn cho các lỗi lần lượt là 0, 1, 2 tương ứng với sản phẩm hoàn thiện (OK); sản phẩm lỗi filling (NOK filling); sản phẩm lỗi burr (NOK burr)
Do đó, bài toán thuộc dạng bài toán phân loại đa lớp: Multi-class
Về dữ liệu để huấn luyện, mô hình sử dụng tập dữ liệu ép máy lấy từ nhà máy sản xuất với các thông số tiêu chuẩn như sau:
Bảng 4.2 Thông số ép tiêu chuẩn
Loại dữ liệu Giá trị tiêu chuẩn
Thời gian ép (injection time) 130,4-137,5s Áp lực phun tối đa (maximum pressure) 230-240Mpa
Vị trí gối đệm (cushion value) 9,0-9,9mm
Thời gian phun (Plasticification time) 21,5-22,5s
Dữ liệu huấn luyện bao gồm 5333 mẫu (237 mẫu lỗi 1, 98 mẫu lỗi 2, 4998 mẫu đạt) Tỉ lệ lỗi trên tổng số mẫu đạt 6,23% Hình ảnh phân bố dữ liệu được mô tả ở hình bên
Hình 4.4 Phân bố dữ liệu tập huấn luyện
Nhận thấy dữ liệu huấn luyện được phân bố tương đối rõ ràng với ba lớp phân loại là 0,1,2 Tuy nhiên, vẫn có các điểm dữ liệu đan xen vào nhau dễ dẫn đến việc phân loại sai
Về tập dữ liệu test, có 878 mẫu (48 mẫu lỗi 1, 26 mẫu lỗi 2, 804 mẫu đạt) Tỉ lệ lỗi chiếm 8,4% trên tổng dữ liệu test Hình ảnh phân bố dữ liệu test được thể hiện ở hình bên
Hình 4.5 Phân bố dữ liệu test
Nhận thấy dữ liệu test có phân bố khá tương đồng với dữ liệu huấn luyện Thật vậy, đây là nguồn dữ liệu thu thập được từ máy ép thực tế Thời gian thu thập dữ liệu từ 23/07/2022 đến 13/08/2022.
PHÂN TÍCH VÀ ĐÁNH GIÁ KẾT QUẢ
Sản phẩm phần cứng
Về phần cứng, thiết kế và thi công hoàn thiện một bo mạch vi điều khiển dùng ESP32, kết hợp chip ARM F1 Bo mạch đóng vai trò làm EoN node trong kiến trúc hạ tầng Sparkplug
Hình 5.1 Sản phẩm IoT board
Thiết kế một vali demo bao gồm 3 PLC mô phỏng hoạt động của máy ép, một màn hình để sử dụng giao diện cấu hình và quản lý, một sản phẩm IoT board và một IPC được thể hiện như hình
Hình 5.2 Sản phẩm vali demo
Sản phẩm phần mềm
Về phần mềm, xây dựng được một ứng dụng dùng để cấu hình hạ tầng mạng Sparkplug Đồng thời lập trình thiết kế một số tiện ích như xuất bảng biểu, vẽ biểu đồ dữ liệu theo thời gian và dashboard thể hiện dữ liệu tổng quát
Hình 5.3 Màn hình khởi tạo Node, Device và Tag
Hình 5.4 Danh sách các Node, Device và Tag sau khi khởi tạo thành công
Hình 5.5 Đồ thị dữ liệu thu thập được từ EoN Node
Hình 5.6 Truy xuất dữ liệu thu thập từ EoN Node
Sản phẩm dự báo
Kết quả huấn luyện được viết bằng ngôn ngữ Python và thử nghiệm bằng bốn phương pháp phân lớp khác nhau là Decision Tree Classifier, Support Vector Classifier, Gaussian Classifier và Artificial Neural Network alist = [
('DecisionClassi', DecisionTreeClassifier(max_depth = 20, ccp_alpha=0.01)),
('SVC', SVC(C00, kernel = 'rbf', gamma = 0.01)),
('ANN', MLPClassifier( hidden_layer_sizes=(300,), activation='logistic',solver = 'lbfgs', random_state = 1700)) ]
Phương pháp đánh giá dùng Root Mean Square Error (RMSE) được sử dụng nhằm đánh giá xem độ sai lệch giữa các điểm dữ liệu dự đoán so với thực tế for a , b in alist: rmse = np.mean(np.sqrt(-cross_val_score(b, X, y, cv=5, scoring="neg_mean_squared_error"))) print(f"RMSE: {round(rmse, 4)} ({a})")
Kết quả RMSE trả về của 4 phương pháp như sau: 0.3162 (DecisionClassic), 0.2429 (SVC), 0.2558 (Gauss)
Trong trường hợp này, phương pháp SVC cho kết quả RMSE nhỏ nhất và bằng 0,2429
Sau khi xác nhận phương pháp SVC cho kết quả tốt nhất, tiếp theo phải tìm ra kernel phù hợp để huấn luyện mô hình Đề tài sử dụng kỹ thuật GridSearch giúp tìm kiếm tham số phù hợp cho mô hình có một bộ dữ liệu cụ thể from sklearn.model_selection import GridSearchCV
# defining parameter range param_grid = {'C': [1500, 1550, 1600, 1700, 1750, 1800],
'kernel': ['rbf','linear'] } grid = GridSearchCV(SVC(), param_grid, refit = True, verbose = 3, error_score='raise')
# fitting the model for grid search grid.fit(X, y)
Kết quả trả về bộ thông số phù hợp ứng với C00 mẫu, gamma=0.01 và kernel được chọn là RBF
Cuối cùng, khi ứng dụng phương pháp phân loại đã chọn Kết quả phân loại trên tập test chính xác với tỉ lệ khá cao là 98,975% model_svc = SVC(C00, kernel = 'rbf', gamma = 0.01, probability=True) model_svc.fit(X, y) y_pre = model_svc.predict(X_test) print(accuracy_score(y_test, y_pre)) cf_svc = confusion_matrix(y_test, y_pre) Để đánh giá kết quả phân loại, đề tài sử dụng các công cụ đánh giá là confusion matrix và các chỉ số như accuracy, precision, recall, và điểm F1 from sklearn.metrics import classification_report scores = [] scores.append([accuracy_score(y_test, y_pre), precision_score(y_test, y_pre, average ='weighted'), recall_score(y_test, y_pre, average = 'weighted'), f1_score(y_test, y_pre, average = 'weighted')]) print(scores)
''' -''' pd.set_option('display.max_rows', None) result = pd.DataFrame(scores, columns=["Accuracy","Precision","Recall", "F1"]) target_names = ['OK', 'NOK_FILLING', 'NOK_BURR'] print(classification_report(y_test, y_pre, target_names=target_names, digits=4))
Hình 5.7 Kết quả confusion matrix của tập test
Bảng 5.1 Đánh giá kết quả dự đoán
- Accuracy khi test model là 0.9897 cho thấy về tổng quan mô hình đoán tương đối chính xác về các class OK , NOK_BURR, NOK_FILLING
- Precision (Chính xác): Precision có giá trị 0.9899, tức là 98.99% trong số những dự đoán positive của mô hình là chính xác Điều này thể hiện khả năng của mô hình trong việc tránh tạo ra những dự đoán positive sai (False Positives)
- Recall (Độ nhớ): Recall có giá trị 0.9897, tức là mô hình có khả năng bắt kịp 98.97% những trường hợp thực tế positive Điều này là một chỉ số tích cực, đặc biệt quan trọng khi muốn đảm bảo không bỏ sót các trường hợp positive
- F1-Score: F1-Score có giá trị 0.9897, là sự kết hợp giữa precision và recall Đối với mọi bài toán phân loại, một giá trị F1-Score cao như vậy thường được coi là một mô hình có hiệu suất tốt và cân bằng giữa việc giữ chính xác và đảm bảo độ nhớ F1-Score cao cũng cho thấy mô hình làm việc ổn với dữ liệu không cân bằng (cụ thể dữ liệu test, số label 1, 2 chỉ chiếm 8.4% tổng dữ liệu)
