Khi cân nhắc triển khai AI phát hiện âm thanh bất thường trong nhà máy, điều đầu tiên cần quyết định không phải là tên mô hình. Thay vào đó, cần xác định rõ: “Thiết bị nào, ở trạng thái vận hành nào, sẽ thu nhận sự thay đổi âm thanh nào, ai sẽ xác nhận và xác nhận điều gì”. Âm thanh của máy móc thay đổi theo tốc độ quay, vật liệu gia công, thiết bị xung quanh, hướng micro, thậm chí cả việc đóng/mở cửa. Chỉ đơn giản ghi âm và đưa vào AI sẽ không tạo ra cảnh báo mà hiện trường có thể xử lý. Bài viết này dành cho các quản lý triển khai giám sát âm thanh cho động cơ, băng tải, quạt, hộp giảm tốc… tại nhà máy Thái Lan, trình bày toàn bộ quy trình từ đo đạc, RFP, FAT đến SAT như một thiết kế liền mạch. Không phải là tổng quan về chẩn đoán cavitation cho bơm hay bảo trì dự đoán chung, mà tập trung vào các quyết định triển khai khi sử dụng âm thanh truyền qua không khí.
Kết luận: Thiết kế đồng thời “sự khác biệt âm thanh” và “hành động tại hiện trường” khi phát hiện âm thanh bất thường
AI phát hiện âm thanh bất thường có thể cảnh báo khi âm thanh vận hành lệch khỏi trạng thái được xem là bình thường. Tuy nhiên, chỉ dựa vào sự lệch này không thể khẳng định chắc chắn vị trí hỏng hóc, tuổi thọ còn lại hay có cần dừng máy hay không. Thách thức của DCASE về phát hiện âm thanh bất thường cũng tập trung vào thực tế khó bao quát dữ liệu bất thường và “domain shift” do thay đổi trạng thái vận hành, tiếng ồn môi trường. Do đó, yêu cầu đặt hàng không nên chỉ gói gọn trong “độ chính xác AI”, mà cần tách biệt: thiết bị/trạng thái vận hành mục tiêu, vị trí lắp micro, phạm vi thu âm bình thường, nơi nhận thông báo, quy trình xác nhận, điều kiện nghiệm thu. ISO 17359 đưa ra quy trình chung xây dựng chương trình giám sát tình trạng thiết bị, nhấn mạnh việc coi đo đạc và quyết định bảo trì là một vận hành thống nhất.
Trong thực tế, không nên nhắm tới toàn bộ thiết bị ngay từ đầu. Hãy chọn một máy móc có thể dẫn tới dừng hoặc lỗi, lập bảng liệt kê âm thanh có thể quan sát, hồ sơ bảo trì xác nhận được, hành động mà nhân viên có thể thực hiện. Dựa vào đó, tiến hành ghi âm nhỏ, để con người đánh giá liệu sự thay đổi âm thanh có đáng cảnh báo hay không. Ghi lại điều kiện lắp đặt và ngưỡng dùng để kiểm chứng, xác nhận dữ liệu và giao diện tại FAT, kiểm tra thiết bị thực tế và ca làm việc tại SAT. Khi thiết bị hoặc quy trình thay đổi, định nghĩa “bình thường” cũng cần cập nhật. Đây là khung xương cho triển khai.
Thiết bị phù hợp và không phù hợp với AI phát hiện âm thanh bất thường trong nhà máy
Các thiết bị quay, quạt, băng tải, hộp giảm tốc, cơ cấu khí nén, cơ cấu vận chuyển tiếp xúc theo chu kỳ – nơi âm thanh phát ra ngoài – là ứng viên phù hợp. Nếu các hiện tượng như ma sát, va chạm, rò rỉ khí, lỏng lẻo… thể hiện rõ trong dải tần nghe được hoặc dải đo, việc dùng micro không tiếp xúc có ý nghĩa. Tuy nhiên, phát ra âm thanh và khả năng xác định chắc chắn lỗi là hai việc khác nhau. Ở dây chuyền có nhiều nguồn âm gần nhau, máy bên cạnh có thể át tiếng. Nếu có vỏ che hoặc hộp cách âm, âm lượng thay đổi mạnh theo vị trí micro. Nếu thay đổi bên trong thiết bị khó truyền ra âm thanh trong không khí, có thể nên dùng cảm biến rung, dòng điện, nhiệt độ…
Khi khảo sát hiện trường ban đầu, hãy liệt kê cho từng thiết bị: “chế độ lỗi/bất thường”, “dự kiến thay đổi âm thanh”, “âm chuẩn có thể lấy tại hiện trường”, “tiếng ồn nền”, “cách xác nhận sau khi phát hiện”. Ví dụ, nếu nhắm tới tiếng tiếp xúc dẫn hướng băng tải, cần thu âm cả các lô sản phẩm khác nhau, khởi động/dừng, máy bên cạnh hoạt động. Ngay cả khi nghe thấy tiếng nghi ngờ lệch băng, hiện trường phải kiểm tra theo quy trình an toàn, kiểm tra lực căng, căn chỉnh mới có thể kết luận. Không giả định AI sẽ tự động quyết định dừng an toàn hoặc thay thế interlock.
Cũng cần nêu rõ các trường hợp không phù hợp. Nếu không có người nhận cảnh báo, dây chuyền tạm thời có nguồn ồn thay đổi liên tục, thiết bị kín gần như không lọt âm, hoặc không ghi lại thời điểm sự kiện bảo trì, cần chuẩn bị vận hành hoặc nền tảng dữ liệu trước khi PoC. Trước khi khẳng định có thể phát hiện bất thường bằng âm thanh, hãy kiểm tra liệu con người có phân biệt được trong cùng điều kiện, hoặc có thể quan sát sự khác biệt trên dạng sóng/tần số không. Việc sàng lọc trước này hợp lý hơn so với lắp micro cho toàn bộ thiết bị rồi mới giảm cảnh báo.
Quyết định “điều gì là bình thường” trước khi lắp đặt
Âm thanh bình thường không chỉ có một loại. Nếu trộn lẫn các trạng thái như chạy không tải, khởi động, vận hành ổn định, thay đổi tốc độ, chuyển đổi sản phẩm, vệ sinh, dừng ngắn, khởi động thiết bị lân cận vào cùng “bình thường”, mô hình sẽ mất khả năng phân biệt các khác biệt thực sự cần thiết. Ngược lại, nếu chia quá nhỏ, sẽ thiếu mẫu học cho từng điều kiện. Trước tiên, hãy liệt kê các chế độ vận hành, tốc độ, mã sản phẩm, ca làm việc… có thể lấy từ PLC/MES, ưu tiên ghi lại các điều kiện ảnh hưởng lớn tới âm thanh. Nếu không lấy được, lập kế hoạch đối chiếu với nhật ký công việc hoặc lệnh sản xuất.
Mô tả nhiệm vụ DCASE 2024 nêu rõ: mẫu âm thanh bất thường hiếm và đa dạng, cần xét đến thay đổi trạng thái vận hành và tiếng ồn môi trường. Trong PoC nhà máy, có thể cân nhắc phương pháp “chỉ học âm thanh bình thường, phát hiện lệch”. Tuy nhiên, không quyết định thời gian lấy mẫu bình thường chỉ dựa vào số ngày cố định, mà dựa vào việc bao quát điều kiện vận hành. Ghi lại đã lấy được các ca làm việc, sản phẩm chính, dải tốc độ, chuyển đổi, thiết bị lân cận chưa. Không mặc định mọi khoảng thời gian không ghi nhận bất thường là “bình thường”, mà kiểm tra nguy cơ lẫn lộn qua nhật ký bảo trì và phỏng vấn nhân viên.
Định nghĩa “bình thường” cần có ngày cập nhật và người phê duyệt. Khi thay thế linh kiện mòn, di chuyển vị trí lắp, thay vỏ che, đổi model, cập nhật phần mềm, thay micro… điều kiện âm thanh thay đổi dù cùng tên thiết bị. So sánh với chuẩn cũ, nếu cần thì lập chuẩn mới. Không xóa dữ liệu cũ, đảm bảo có thể truy vết cảnh báo đã phát sinh với mô hình và điều kiện lắp nào. Điều này không chỉ giúp cải tiến mô hình mà còn hữu ích khi điều tra nguyên nhân báo sai hoặc giải trình kết quả nghiệm thu.
Bố trí micro: Xác nhận nguồn âm, tiếng ồn nền, thao tác bảo trì trên một sơ đồ
Chỉ dựa vào thông số kỹ thuật micro không thể quyết định âm thanh thu được tại hiện trường. Cần kiểm tra khoảng cách, hướng tới bộ phận mục tiêu, che chắn bởi vỏ/cabin, phản xạ từ sàn/tường, thiết bị lân cận, điều hòa, khí nén, lối đi của nhân viên. Chọn 2-3 vị trí ứng viên, ghi âm so sánh trong cùng điều kiện vận hành. Nếu lắp cố định, cần xem xét vệ sinh, nước, phoi, nhiệt, rung, đi dây, khả năng thay thế khi bảo trì. Không chọn vị trí khó tiếp cận trong sản xuất chỉ vì dễ ghi âm.
Tài liệu kỹ thuật đo tiếng ồn của OSHA giải thích: thân người đo và thiết bị xung quanh có thể che âm, hướng micro ảnh hưởng tới đo đạc. Dù tài liệu này dùng cho đo phơi nhiễm tiếng ồn lao động, không phải tiêu chuẩn nghiệm thu phát hiện bất thường thiết bị, nhưng lưu ý vật lý “vị trí và hướng làm thay đổi âm thanh” rất hữu ích. Ghi chú vị trí, độ cao, góc trên gá cố định, chụp ảnh, để so sánh sau khi di dời. Nếu thay đổi hướng micro trong thử nghiệm, không thể tách biệt ảnh hưởng do mô hình và do lắp đặt.
Khi nhiều nguồn âm gần nhau như động cơ, hộp giảm tốc, mặt băng tải, không nên cố xác định nguyên nhân chỉ với một micro. Nếu cần, tách micro, so sánh khi dừng dây chuyền, khi chỉ thiết bị lân cận hoạt động. Có thể đặt micro tham chiếu giám sát tiếng nền, nhưng cần kiểm tra giá trị thực tế trong PoC do phải thêm dây và đồng bộ. Nếu âm thanh bất thường mục tiêu bị lẫn trong nền, thay đổi loại cảm biến có thể phù hợp hơn là tăng số micro.
Dữ liệu ghi âm phải gắn với “trạng thái thiết bị tại thời điểm đó”
Đơn vị lưu trữ không chỉ là file âm thanh. Cần liên kết ID thiết bị, ID micro, vị trí/hướng lắp, thời gian và múi giờ, chế độ vận hành, mã sản phẩm hoặc điều kiện công việc, phiên bản mô hình, điểm cảnh báo, kết quả bảo trì. Việc lưu toàn bộ âm thanh dài hạn hay không tùy vào mục đích và quy định nội bộ. Có thể chỉ cần đặc trưng và clip ngắn xác nhận cho âm thanh bình thường. Thiết kế phạm vi lưu trữ, quyền truy cập, thời gian giữ dựa trên căn cứ cảnh báo, học lại sau này, khả năng có tiếng người. Không biến giám sát âm thanh thành “ghi âm mọi thứ”.
Nếu thời gian suy luận và thời gian PLC/MES lệch nhau, sẽ gán nhầm thay đổi âm thanh với sự kiện dừng máy. Đưa đồng bộ thời gian thiết bị thu thập, lưu cục bộ khi mất kết nối, gửi lại sau khi phục hồi, phát hiện file hỏng vào RFP. Cách liên kết dữ liệu sản xuất tùy thiết bị và hệ thống cấp trên. Đặc tả OPC UA cho máy công cụ của OPC Foundation chỉ ra giao diện chung trao đổi thông tin giám sát với MES, SCADA, ERP, phân tích. Tuy nhiên, không mặc định thiết bị hiện tại đã triển khai mô hình thông tin này, cần xác nhận tag và chất lượng thời gian thực tế.
Tại nhà máy Thái Lan, có thể lẫn lộn nhật ký vận hành tiếng Nhật, Thái, Anh. Chỉ dịch tên phân loại không đồng nhất vận hành. Màn hình xác nhận cảnh báo cần hiển thị ID thiết bị, thời gian, trạng thái vận hành, clip âm thanh gần nhất, lựa chọn kết quả xác nhận của nhân viên với ý nghĩa chung. Khi chuyển sang lệnh công việc hoặc ticket bảo trì, giữ tham chiếu tới âm gốc và kết quả xác nhận của con người. Phân biệt rõ “phát hiện thay đổi âm thanh” và “đã xác nhận nguyên nhân”, không để văn bản sinh từ âm thanh tự động lan truyền.
Suy luận tại Edge hay Cloud: Quyết định xử lý cần thiết khi mất kết nối trước
Suy luận tại thiết bị Edge cho phép xử lý âm thanh gần thiết bị, chỉ gửi sự kiện ngắn hoặc đặc trưng lên hệ thống trên. Có thể thiết kế tiếp tục phát hiện cục bộ khi mạng không ổn định. Tuy nhiên, cần vận hành tại hiện trường: môi trường lắp đặt, nguồn điện, nhiệt, cập nhật, thay thế khi hỏng, phân phối mô hình, thu hồi log. Xử lý Cloud dễ quản lý phân tích chéo, mô hình, nhưng phải quyết định băng thông truyền âm thanh, độ trễ, mất kết nối, nơi lưu và quyền truy cập. Không có lựa chọn nào luôn ưu việt.
Quyết định dựa trên thời gian đáp ứng cảnh báo và cách xử lý dữ liệu. Cảnh báo chỉ cần xác nhận trong lần kiểm tra tiếp theo khác với cảnh báo cần xác nhận ngay trong quá trình sản xuất. Thiết kế cũng khác giữa nơi có thể lọt tiếng nói nhân viên vào ghi âm và phòng máy kín chỉ có tiếng máy. Trong RFP, ghi rõ “khi mất mạng, xử lý nào tiếp tục, sự kiện nào gửi lại sau, hiển thị thế nào trên màn hình”. Nếu chọn Edge, không tự động cập nhật lên thiết bị, cần quản lý phiên bản và quy trình rollback.
Trong PoC ban đầu, thay vì chọn mô hình nặng trước, hãy xác lập điều kiện thu âm và đơn vị cảnh báo con người có thể xác nhận. Có nhiều phương pháp: spectrogram, đặc trưng, embedding, lỗi tái tạo… và DCASE cũng có nhiều nghiên cứu. Không thể lấy thứ hạng benchmark làm tỷ lệ phát hiện trên dây chuyền của mình, vì máy móc, tiếng nền, vị trí micro, chi phí báo sai khác nhau. Khi chọn, hãy trình bày kết quả so sánh trên dữ liệu thực tế và khả năng cải thiện, thay vì chỉ tên mô hình.
Đánh giá báo sai và bỏ sót như thế nào?
Chỉ số “độ chính xác 99%” không đủ để nghiệm thu giám sát thiết bị. Nếu phần lớn dữ liệu là bình thường, hệ thống luôn trả lời “bình thường” cũng có vẻ đúng cao. Cần đo: đã phát hiện bao nhiêu sự kiện bất thường định nghĩa, thời gian từ cảnh báo tới xác nhận hiện trường, số lần gọi nhầm khi vận hành bình thường, có thể review nguyên nhân cảnh báo không. Ghi rõ mẫu số và thời gian quan sát. Nếu ít mẫu bất thường, không cam kết tỷ lệ phát hiện là con số chắc chắn, mà tách biệt phạm vi đã kiểm chứng và chưa kiểm chứng.
Báo sai không chỉ tính số lần/ngày mà còn phân tầng theo thiết bị, chế độ vận hành, ca làm việc, mã sản phẩm. Nếu cảnh báo nhiều chỉ khi chuyển đổi, có thể tách chế độ đó thành nhóm bình thường riêng hoặc giảm giám sát. Tuy nhiên, nếu giảm quá mức sẽ bỏ sót cảnh báo cần thiết. Nếu chia cảnh báo thành “thông báo”, “cần xác nhận”, “cần xác nhận khẩn cấp”, cần quy định căn cứ, nơi nhận, thời gian chờ tối đa cho từng cấp. Ngưỡng quá thấp không xét tải hiện trường sẽ khiến cảnh báo bị bỏ qua.
Bỏ sót không thể xác định chỉ bằng cách phát lại mọi trường hợp dừng máy trong quá khứ. Trường hợp không còn âm thanh trước khi hỏng, điều kiện thay đổi sau sửa chữa, hoặc trước khi lắp micro không thể so sánh. Không tạo lỗi nguy hiểm chỉ để thử nghiệm. Ghi rõ kết quả cho từng trường hợp: thực tế đã ghi âm, âm mô phỏng được hiện trường phê duyệt, điều kiện thử nghiệm an toàn do hãng thiết bị cho phép. Nếu không phát hiện được âm thanh bất thường, cần quyết định cách giám sát hiện tại như kiểm tra định kỳ, đo rung sẽ bổ sung ra sao.
Đưa xác nhận của con người vào quy trình cảnh báo
Nhân viên nhận cảnh báo AI cần xem thiết bị, thời điểm phát sinh âm thanh, trạng thái vận hành, âm thanh bình thường để so sánh, lịch sử bảo trì gần nhất. Chỉ hiển thị điểm số màu đỏ không giúp điều tra. Ở bước xác nhận đầu tiên, kiểm tra trạng thái thiết bị và các chỉ số khác từ vị trí an toàn. Kiểm tra thực tế hoặc mở vỏ che phải tuân thủ quy trình an toàn nhà máy. Nếu nguyên nhân thay đổi âm thanh là điều kiện vận hành, ghi nhận là “thay đổi điều kiện bình thường”; nếu nghi ngờ lỗi cơ khí, ghi “cần kiểm tra”; nếu chưa xác định, ghi “tạm giữ” và lý do.
Khi đưa kết quả sau cảnh báo vào cải tiến mô hình, không nhầm lẫn giữa “cảnh báo sai” và “chưa xác định nguyên nhân tại hiện trường”. Trường hợp đầu có thể do ngưỡng hoặc dữ liệu học, trường hợp sau có thể cần thêm cảm biến hoặc hồ sơ bảo trì. Liên kết linh kiện thay thế, kết quả kiểm tra, thời gian dừng, ảnh hưởng chất lượng vào ticket bảo trì, đánh giá hiệu quả cảnh báo trong review tháng sau. Khối lượng gán nhãn của con người cũng tính vào chi phí PoC. Nếu số cảnh báo tăng mà quyết định bảo trì không nhanh hơn, cần xem lại thiết kế.
Tùy độ dài dây chuyền, mức độ quan trọng thiết bị, nơi nhận cảnh báo có thể là bảo trì, sản xuất, chất lượng hoặc nhiều bên. Theo RACI, phân rõ nhận cảnh báo, xác nhận lần đầu, quyết định dừng, xác định nguyên nhân, phê duyệt thay đổi mô hình. Đặc biệt, “ai quyết định dừng thiết bị” không phải là mục trong màn hình cấu hình của nhà cung cấp AI, mà do quy trình an toàn, chất lượng, sản xuất của hiện trường quyết định, AI chỉ cung cấp thông tin hỗ trợ. ISO 13374-1 đưa ra hướng dẫn chung về xử lý, truyền, hiển thị thông tin giám sát tình trạng, nhưng thiết kế quyền thực tế là trách nhiệm của từng nhà máy.
Thiết kế PoC từ một thiết bị, một mục tiêu phát hiện
Trước khi bắt đầu PoC, hãy viết một dòng về thiết bị và chế độ bất thường mục tiêu. Không thể đánh giá với “phát hiện âm thanh lạ bất kỳ”. Ví dụ: “Phát hiện thay đổi âm thanh nghi ngờ tiếp xúc dẫn hướng băng tải trong vận hành ổn định, để nhân viên bảo trì xác nhận trong ngày”, xác định rõ điều kiện quan sát và hành động. Nếu chưa chắc xác định được tên lỗi, thử nghiệm dưới dạng “thông báo bất thường”. Kiểm tra hồ sơ bảo trì và phỏng vấn nhân viên xem có trường hợp quá khứ để so sánh không.
Quy trình PoC gồm: đo hiện trường, so sánh vị trí, lấy mẫu bình thường, mô hình/rule ban đầu, review cảnh báo tại hiện trường, cải tiến, nghiệm thu. Mỗi bước lưu lại bằng chứng khác nhau: sơ đồ và ghi âm cho so sánh vị trí, bảng điều kiện vận hành cho lấy mẫu bình thường, dữ liệu đánh giá cố định cho so sánh mô hình, lịch sử xác nhận cảnh báo cho review hiện trường. Ghi trước thời gian đánh giá, ngưỡng dự kiến, không thay đổi điều kiện đánh giá sau khi xem kết quả. Phân biệt giai đoạn cải tiến dựa trên dữ liệu và giai đoạn đóng băng để nghiệm thu.
Chi phí PoC không chỉ gồm micro và thiết bị. Bao gồm cả gá lắp, đi dây, chống bụi/nước, thời gian dừng để lắp, liên kết PLC/MES, lưu âm thanh, review hiện trường, cập nhật mô hình, đào tạo, bảo trì. Trong báo giá, tách chi phí ban đầu và chi phí duy trì, ghi rõ thời gian làm việc phía nhà máy. Phân biệt phần có thể dùng chung khi tăng thiết bị và phần tăng theo từng máy. Lợi ích phát hiện sớm chỉ tính toán sau khi biết số lần dừng/quá khứ và khả năng xử lý sau xác nhận. Không đặt sẵn tỷ lệ giảm hoặc thời gian thu hồi vốn không có căn cứ.
Các yêu cầu cần ghi trong RFP
Trong RFP, thay vì “trọn bộ AI phát hiện âm thanh bất thường”, hãy định nghĩa đầu vào/ra từ đo đạc đến quyết định. Liệt kê tên máy, bộ phận mục tiêu, bất thường mục tiêu, chế độ vận hành, tiếng ồn nền, vị trí lắp, thời gian thông báo cần thiết, người dùng dự kiến, hệ thống bảo trì hiện có. Yêu cầu nhà cung cấp đề xuất vị trí micro ứng viên, lý do, phương pháp ghi âm so sánh. Đưa vào điều kiện lấy mẫu âm thanh, đồng bộ, xử lý khi thiếu dữ liệu, phạm vi lưu ghi âm, luồng dữ liệu local/cloud, cài đặt lại khi thay thiết bị. Vừa giữ tự do thiết kế, vừa chỉ định sản phẩm có thể đánh giá.
Phần AI cần ghi: định nghĩa âm thanh bình thường, xử lý điều kiện vận hành, cài đặt ngưỡng, quản lý phiên bản mô hình, điều kiện học lại, hiển thị căn cứ cảnh báo. Nếu tự động hiển thị tên âm thanh bất thường, yêu cầu dữ liệu học/kiểm chứng cho phân loại đó. Với bất thường chưa biết, ưu tiên giữ trạng thái chờ và luồng xác nhận hơn là dự đoán tên. Chỉ số đánh giá quyết định theo phạm vi dữ liệu đúng thực tế. Nếu không có âm thanh lỗi quá khứ, không thể yêu cầu cam kết “tỷ lệ phát hiện mọi lỗi” trong hợp đồng.
Phần vận hành gồm: nơi gửi cảnh báo, màn hình xác nhận, tạo ticket bảo trì, trách nhiệm phản hồi, quyền hạn, đào tạo, log, xử lý sự cố. Nếu nhà máy có quy định về biên mạng hoặc kết nối ngoài, cần xác nhận trước với bộ phận CNTT. Quyết định trách nhiệm bảo trì thiết bị và mô hình. Nếu không rõ ai chịu trách nhiệm vệ sinh micro, kiểm tra góc lắp, cập nhật thiết bị, dung lượng log, thay thiết bị, đánh giá lại sau khi cải tạo dây chuyền, sẽ dễ bỏ sót suy giảm hiệu suất sau khi vận hành. Bảng so sánh báo giá không chỉ ghi tên chức năng mà còn phạm vi vận hành này.
Bảng thông tin tối thiểu đính kèm RFP
| Hạng mục | Nội dung nhà máy cung cấp | Nội dung nhà cung cấp trả lời |
|---|---|---|
| Thiết bị & bất thường | ID thiết bị, bộ phận mục tiêu, hiện tượng nghi ngờ, hồ sơ bảo trì | Khả năng quan sát âm thanh, đề xuất cảm biến thay thế |
| Điều kiện vận hành | Tốc độ, mã sản phẩm, ca làm việc, khởi động/dừng, thiết bị lân cận | Phân tầng âm thanh bình thường, kế hoạch lấy mẫu |
| Điều kiện lắp đặt | Vị trí ứng viên, hạn chế an toàn, nguồn điện, mạng | Bản vẽ lắp, đặc tính chịu môi trường, kế hoạch ghi âm so sánh |
| Cảnh báo | Người phụ trách, thời gian phản hồi, quy trình bảo trì | Nội dung hiển thị, thông báo, xử lý khi thiếu dữ liệu |
| Nghiệm thu | Âm thanh bất thường có sẵn, thời gian quan sát được | Quy trình FAT/SAT, bằng chứng, phạm vi chưa kiểm chứng |
Phân biệt kiểm tra gì tại FAT và SAT
FAT là kiểm tra chức năng với dữ liệu âm thanh và cấu hình đã thống nhất trước khi lắp đặt tại nhà máy. Kiểm tra nhập file ghi âm, nhận diện chế độ vận hành, xuất điểm bất thường và cảnh báo, hiển thị màn hình, ghi nhận phiên bản mô hình, quyền hạn, thiếu dữ liệu và gửi lại, nơi nhận thông báo, log sự cố. Nếu có mẫu bất thường, phát lại; nếu không, ghi rõ “chưa thử bất thường này”. Âm mô phỏng hoặc dữ liệu tổng hợp hữu ích cho kiểm tra kết nối, nhưng không chứng minh hiệu suất phát hiện tại hiện trường. Tài liệu nghiệm thu cần ghi nguồn và quyền sử dụng dữ liệu thử nghiệm.
SAT là kiểm tra tại nhà máy thực tế: vị trí micro cố định, tiếng ồn nền hiện trường, nhiều điều kiện vận hành, chất lượng kết nối, quy trình thao tác giữa các ca. Trước khi bắt đầu, đóng băng vị trí và phiên bản mô hình, nếu thay đổi phải ghi lại. Kiểm tra xem có cảnh báo liên tục trong các sự kiện thường nhật không, luồng xác nhận từ cảnh báo tới nhân viên, phục hồi sau khi dừng thiết bị hoặc mất mạng. Nếu phát hiện báo sai trong SAT mà chỉ tăng ngưỡng để xóa ngay, sẽ không biết có tăng bỏ sót không. Ghi lại lý do và đánh giá trước/sau khi thay đổi.
Đánh giá đạt FAT/SAT không dựa vào một chỉ số “độ chính xác”, mà theo bảng kiểm thử đã thống nhất. Mỗi thử nghiệm ghi điều kiện, đầu vào, kết quả kỳ vọng, kết quả thực tế, bằng chứng, người đánh giá, mục chưa giải quyết. Nếu thiếu mẫu âm thanh bất thường, nghiệm thu có điều kiện, xác định thời điểm đánh giá lại sau khi thu thập thêm, chỉ định người chịu trách nhiệm. Không tự động coi cập nhật mô hình sau nghiệm thu là đạt, cần quy định quản lý thay đổi và phạm vi thử lại trong hợp đồng. Chỉ khi làm rõ như vậy mới chuyển được từ PoC sang vận hành thực tế.
Hãy ghi rõ điều kiện phải đánh giá lại sau nghiệm thu trong kế hoạch thử nghiệm. Di dời máy, thay động cơ hoặc hộp giảm tốc, thêm vỏ cách âm, tháo rồi lắp lại giá micro, hoặc đổi vật liệu và dải tốc độ của sản phẩm đều có thể thay đổi đường truyền âm hay âm thanh bình thường. Điều này không có nghĩa phải huấn luyện lại mọi mô hình sau mỗi thay đổi. Trước tiên, đối chiếu bản vẽ lắp đặt và điều kiện vận hành, rồi ghi âm đường cơ sở mới trong điều kiện tương ứng. Nếu khác biệt nhỏ, ghi lý do có thể tiếp tục giám sát; nếu khác biệt đáng kể, chuyển ngưỡng cảnh báo và mô hình cho người có thẩm quyền phê duyệt đánh giá lại. Đừng chỉ nhìn số lượng cảnh báo. Cần xem cả loại sự kiện mà nhân viên bảo trì đã xác nhận để phân biệt cải thiện thật với nguy cơ bỏ sót tăng lên. Hợp đồng ban đầu nên quy định quyền sở hữu dữ liệu cần cho lần đánh giá lại, định dạng bàn giao mô hình và cấu hình, đầu mối nhà cung cấp và phạm vi nhà máy được tự điều chỉnh. Lưu quyết định cùng lịch sử thay đổi cấu hình theo một mã thiết bị để người phụ trách mới truy vết được.
Vận hành tại nhà máy Thái Lan: Kết nối bảo trì thiết bị và ngôn ngữ hiện trường
Tại nhà máy Thái Lan có liên quan tới trụ sở Nhật, sản xuất địa phương, nhà thầu bảo trì, việc giải thích cảnh báo vượt qua rào cản ngôn ngữ. Thông báo nên ngắn gọn, gồm ID thiết bị, thời gian, nguồn âm mục tiêu, hành động đầu tiên tại hiện trường là mục cố định. Dùng cùng ID sự kiện cho báo cáo kỹ thuật tiếng Nhật và lệnh công việc tiếng Thái. Không ra lệnh dừng chỉ dựa vào từ “bất thường” đã dịch. Thống nhất tên thiết bị, linh kiện hiện trường, để đối chiếu với hồ sơ bảo trì.
Trước khi triển khai, kiểm tra vị trí micro và nhân viên, khả năng lọt tiếng nói, quy định ghi âm của nhà máy. Giới hạn mục đích vào giám sát thiết bị, không dùng cho đánh giá cá nhân, ghi rõ phạm vi vận hành. Kiểm tra quy định nội bộ và pháp luật liên quan tới xử lý âm thanh. Nếu truyền lên cloud, cần thống nhất nơi lưu, đối tác, quyền truy cập, cách xóa với bộ phận CNTT. Giá trị hệ thống không nằm ở việc ghi âm lâu, mà ở khả năng truy vết thay đổi âm thanh cần thiết và kết quả xác nhận.
Khi liên kết với thiết bị hiện có, không cần đưa âm thanh vào PLC. Thiết bị xử lý âm thanh tạo sự kiện, nhận trạng thái vận hành từ PLC/MES, chuyển kết quả xác nhận tới hệ thống bảo trì. Đặc tả OPC UA cho giám sát máy móc là tài liệu tham khảo cho thiết kế trao đổi dữ liệu, nhưng cần xác nhận thiết bị thực tế có hỗ trợ không. Nếu bắt đầu từ thông tin công đoạn nhập tay, cần lưu lại đã liên kết âm thanh thời điểm nào với trạng thái vận hành nào. Ưu tiên không để mất ngữ cảnh cần thiết cho quyết định hiện trường hơn là cách liên kết.
Năm sai lầm cần tránh khi triển khai AI phát hiện âm thanh bất thường
Thứ nhất, không ghi lại vị trí micro. Nếu điều kiện ghi âm ban đầu và thực tế khác nhau, so sánh mô hình mất ý nghĩa. Thứ hai, trộn lẫn các chế độ vận hành khác nhau vào cùng âm thanh bình thường. Dễ nhận nhầm âm thanh khởi động là lỗi, mất niềm tin hiện trường. Thứ ba, lấy thành tích benchmark làm giá trị đảm bảo cho dây chuyền của mình. DCASE hữu ích cho nghiên cứu, nhưng thiết bị và môi trường khác nhau. Thứ tư, không quyết định thao tác sau cảnh báo. Dù tăng thông báo cũng không dẫn tới kiểm tra/sửa chữa. Thứ năm, cập nhật mô hình và thiết bị mà không quản lý thay đổi. Dù thay đổi góc lắp, linh kiện, tốc độ vẫn dùng chuẩn cũ.
Những điều này có thể phòng tránh mà không cần kỹ thuật AI cao siêu. Điều quan trọng là nhất quán các tài liệu quản lý thông thường: sơ đồ lắp đặt, bảng điều kiện vận hành, bảng review cảnh báo, bảng kiểm thử FAT/SAT, lịch sử thay đổi. Để tìm hiểu thêm về giám sát tình trạng thiết bị nói chung, xem Cách chọn lĩnh vực áp dụng AI phát hiện bất thường. Về phân tích các cảnh báo đã ghi trong PLC, xem Triển khai AI phân tích cảnh báo thiết bị. Bài viết này tập trung vào điều kiện triển khai khi đo âm thanh từ micro.
FAQ: Những câu hỏi thường gặp trước khi triển khai AI phát hiện âm thanh bất thường trong nhà máy
AI phát hiện âm thanh bất thường có xác định được nguyên nhân hỏng hóc không?
Có trường hợp có thể ước đoán nguyên nhân, nhưng chỉ phát hiện thay đổi âm thanh không đủ để xác định nguyên nhân. Ví dụ, cùng tiếng kim loại có thể do tiếp xúc, vật rơi, thiết bị lân cận, thay đổi điều kiện vận hành. Để hiển thị tên nguyên nhân cần dữ liệu học và kiểm chứng thực tế. Giai đoạn đầu nên định nghĩa là “thông báo âm thanh khác thường, hiện trường xác nhận kết hợp thông tin khác” sẽ dễ nghiệm thu hơn.
Nếu đã có cảm biến rung thì có cần micro không?
Tùy hiện tượng muốn đo. Cảm biến rung dễ bắt chuyển động cơ khí của vỏ, ổ trục; micro có thể quan sát rò khí, tiếp xúc, tương tác sản phẩm-máy từ xa. Không phải lúc nào hai loại cũng phản ứng cùng lúc với cùng lỗi. Nếu tín hiệu hiện có đủ, không cần thêm micro. Nếu có trường hợp thực tế tiếng lạ xuất hiện trước, nên làm PoC so sánh. Kiểm chứng xem cảm biến bổ sung có tăng thông tin không.
Không có ghi âm âm thanh bất thường thì có làm AI được không?
Có thể cân nhắc phương pháp chỉ phát hiện ngoại lệ từ âm thanh bình thường. DCASE cũng có nghiên cứu chỉ dùng âm bình thường. Tuy nhiên, không có ví dụ bất thường thực tế thì không đánh giá được hiệu quả với lỗi quan trọng. Không khẳng định hết loại bất thường, ưu tiên bao quát điều kiện bình thường và review cảnh báo. Sau vận hành, tích lũy kết quả bảo trì, cập nhật hiệu suất theo từng loại bất thường.
Cần bao nhiêu micro, đặt ở đâu?
Không thể quyết định đồng loạt chỉ dựa vào kích thước thiết bị, tiếng ồn nền. Vẽ sơ đồ nguồn âm mục tiêu và xung quanh, ghi âm so sánh tại các vị trí ứng viên. Xem xét cả vỏ che, phản xạ, vệ sinh, đi dây, thao tác thay thế. Chỉ tăng số micro hoặc đổi cảm biến khi không thể tách âm mục tiêu bằng một micro. Thay vì cố định số lượng trước để báo giá, nên đưa so sánh vị trí vào kết quả PoC.
Ước tính chi phí và thời gian thu hồi vốn AI phát hiện âm thanh bất thường như thế nào?
Tách riêng micro, lắp đặt, thiết bị, truyền thông, lưu trữ dữ liệu, phát triển mô hình, liên kết hệ thống hiện có, review cảnh báo, bảo trì. Chi phí thay đổi theo số thiết bị, độ khó lắp đặt, dữ liệu hiện có, thời gian phản hồi cần thiết. Thời gian thu hồi vốn tính từ số lần dừng/mất chất lượng quá khứ và phạm vi thực tế có thể tránh sau khi phát hiện. Không áp dụng tỷ lệ giảm của nhà máy khác. Trong RFP đầu tiên, so sánh tổng giá, gánh nặng vận hành và phạm vi chưa kiểm chứng.
Chỉ FAT có đủ nghiệm thu vận hành thực tế không?
FAT kiểm tra chức năng, luồng dữ liệu, đầu vào mô phỏng, nhưng tiếng ồn nền thực tế, nhiều ca làm việc, vị trí micro cố định, kết nối, thao tác hiện trường phải kiểm tra tại SAT. Nếu ít ví dụ bất thường, ngay cả SAT cũng không chứng minh được toàn bộ hiệu suất. Xác định nghiệm thu có điều kiện, thời điểm đánh giá bổ sung, thử lại khi thay đổi mô hình hoặc điều kiện thiết bị.
Tổng kết
Triển khai AI phát hiện âm thanh bất thường trong nhà máy không chỉ là lắp micro lên máy, mà là dự án đo âm thanh mục tiêu, quản lý điều kiện bình thường, kết nối cảnh báo AI với quyết định bảo trì của con người. Tập trung vào một bất thường, cố định vị trí, ghi âm so sánh, liên kết chế độ vận hành và âm thanh, làm rõ cảnh báo sai và phạm vi chưa kiểm chứng. Yêu cầu vận hành và luồng dữ liệu trong RFP, nghiệm thu tách biệt FAT và SAT. Như vậy, có thể phân biệt rõ điều đã kiểm chứng trong PoC và điều có thể cam kết khi vận hành thực tế.
Nếu bạn đang ở giai đoạn sắp xếp thiết bị mục tiêu hoặc vị trí micro tại nhà máy Thái Lan, hãy liên hệ với TOMAS TECH. Dù chưa có nhiều ghi âm bất thường, chúng tôi có thể hỗ trợ từ lập kế hoạch đo, review hiện trường, RFP và điều kiện nghiệm thu.
Tham khảo
- DCASE 2024 Task 2: Phát hiện âm thanh bất thường không giám sát lần đầu cho giám sát tình trạng máy móc — Giải thích về học âm thanh bình thường, bất thường chưa biết, domain shift do điều kiện vận hành và tiếng ồn nền.
- Mô tả và thảo luận DCASE 2024 Task 2 — Bài báo về thiết lập nhiệm vụ và kết quả nghiên cứu.
- ISO 17359:2018 — Hướng dẫn chung về chương trình giám sát tình trạng thiết bị.
- ISO 13374-1:2003 — Hướng dẫn chung về xử lý, truyền, hiển thị thông tin giám sát tình trạng.
- OPC UA for Machine Tools, Part 1 — Đặc tả trao đổi thông tin giám sát máy móc với hệ thống cấp trên.
- OSHA Technical Manual, Section III, Chapter 5 — Lưu ý về vị trí, hướng, che chắn micro khi đo tiếng ồn. Tài liệu đo phơi nhiễm tiếng ồn lao động, không quy định giá trị nghiệm thu phát hiện bất thường thiết bị.
