Cách biến chẩn đoán PLC và SCADA thành hoạt động bảo trì đáng tin cậy mà không làm gián đoạn điều khiển.
Tín hiệu đã tồn tại bên trong lớp điều khiển
PLC thường vẫn tiếp tục chạy trong khi tình trạng của nó suy giảm. Trước tiên, hãy xem lịch sử chẩn đoán, không chỉ xem màn hình mô phỏng. Các gián đoạn liên lạc tăng dần. Một mô-đun I/O từ xa báo lỗi không liên tục. Ở lớp SCADA, các lần mất kết nối lặp lại trước khi có bất kỳ sự cố dừng sản xuất nào. Đây là những cảnh báo sớm, không phải nhiễu. Các bộ điều khiển hiện đại vốn đã cung cấp dữ liệu này. Không phải lúc nào bạn cũng cần một mạng lưới cảm biến mới. Phần khó là xác định đích sử dụng hữu ích cho từng tín hiệu. Đích đó là một hồ sơ bảo trì gắn với một tài sản thực tế.
Bước 1 — Thu thập các trạng thái tình trạng thực tế của bộ điều khiển
Logic dự đoán phải sử dụng các tín hiệu mà thiết bị thực sự hỗ trợ. Đừng cho rằng mọi PLC đều cung cấp cùng một loại dữ liệu tình trạng. Trên hệ thống Allen-Bradley ControlLogix (chẳng hạn như Bộ xử lý Allen-Bradley ControlLogix) hoặc CompactLogix, hãy theo dõi các bộ đếm lỗi cổng EtherNet/IP trên những card truyền thông như Mô-đun truyền thông 1756 ControlLogix. Theo dõi số lần lỗi có thể khắc phục theo từng trạm từ xa. Trên bộ điều khiển Woodward có thể truy cập qua Modbus TCP (các hệ thống giám sát sử dụng mô-đun I/O Woodward), hãy đọc định kỳ các thanh ghi yêu cầu bảo trì và giới hạn tuổi thọ. Một số thiết bị báo trực tiếp lỗi nội bộ hoặc nguồn cấp bất thường.
-
Bước 1 — Liệt kê mọi chẩn đoán mà thiết bị mục tiêu thực sự cung cấp.
-
Bước 2 — Theo dõi xu hướng của các bộ đếm hằng tuần, vì tần suất cho thấy sự suy giảm rõ hơn một sự kiện đơn lẻ.
-
Bước 3 — Chỉ phát cảnh báo khi độ dốc tăng hoặc tình trạng kéo dài, không phải chỉ vì một dao động nhất thời.
-
Bước 4 — Liên kết mỗi bộ đếm với một tài sản đã gắn thẻ, không bao giờ liên kết với một rack chung chung.
Bước 2 — Đừng biến mọi cảnh báo thành một phiếu công việc
SCADA thu hút sự chú ý của người vận hành. Bộ phận bảo trì quyết định ai sẽ trực tiếp sửa chữa. Nhầm lẫn hai việc này sẽ chôn vùi sự suy giảm thực sự dưới hàng loạt phiếu không cần thiết. Cảnh báo nhiệt độ cao có thể chỉ là hành vi bình thường của quá trình sản xuất. Một lần mất kết nối ngắn có thể tự khôi phục. Vì vậy, hãy xác minh tình trạng trước khi tạo công việc. Sự lặp lại đáng tin cậy hơn một sự kiện đơn lẻ. Thời lượng thường quan trọng hơn mức độ nghiêm trọng đỉnh điểm. Một xu hướng trôi dần xuống dưới giới hạn cảnh báo vẫn có thể đáng để kiểm tra. Ngoài ra, hãy tách việc xác nhận khỏi việc hoàn tất. Người vận hành xác nhận rằng lỗi đã được nhìn thấy. Điều đó không chứng minh thiết bị đã được sửa.
-
Bước 1 — Thêm quy tắc yêu cầu lặp lại ba lần trong bảy ngày mới kích hoạt công việc.
-
Bước 2 — Đính kèm ngữ cảnh: tài sản, xu hướng và các lần sửa chữa trước đó.
-
Bước 3 — Chỉ đóng phiếu sau khi công việc đã hoàn tất và được ghi nhận.
Lịch sử sửa chữa giúp mô hình chính xác hơn
Dữ liệu historian cho thấy những gì xảy ra trước một lỗi. Lịch sử bảo trì cho thấy những gì xảy ra sau khi có người kiểm tra. Giả sử lỗi truyền thông liên tục tạo ra các phiếu công việc. Lần nào kỹ thuật viên cũng không phát hiện hỏng hóc phần cứng. Có khả năng ngưỡng kích hoạt quá nhạy. Tuy nhiên, nếu cùng một sự kiện luôn kết thúc bằng việc thay một đầu nối, hãy tin vào mẫu hình đó. Nó đáng được chú ý sớm hơn. Công việc đã hoàn tất giúp phân biệt triệu chứng với nguyên nhân. Một lỗi I/O ảo có thể bắt nguồn từ một thiết bị hiện trường bị mất nguồn. Thay mô-đun sẽ sửa nhầm tài sản. Ghi chú hoàn tất lưu lại nguyên nhân thực sự cho ca làm việc tiếp theo.
Tích hợp mà không tạo thêm rủi ro
CMMS không được trở thành một ứng dụng khách có quyền đặc biệt trên hệ thống điều khiển. Hãy đưa dữ liệu chẩn đoán ra ngoài thông qua một lớp dữ liệu. Lấy xu hướng từ SCADA hoặc historian. Sử dụng OPC UA chỉ đọc cho thông tin tình trạng và chẩn đoán được chuẩn hóa. Sau đó, một dịch vụ tích hợp sẽ chuyển các sự kiện đã được xác minh đến nền tảng bảo trì thông qua API. Cách này giữ lưu lượng bảo trì tránh xa logic nhạy cảm về thời gian. Các phép tính dự đoán không cần chạy bên trong bộ điều khiển. Ngoài ra, hãy bảo vệ mạng. Ứng dụng bảo trì hiếm khi cần ghi vào bộ nhớ PLC. Giới hạn ứng dụng ở quyền truy cập chỉ đọc. Tuân thủ quy trình kiểm soát thay đổi của nhà máy trước khi bất kỳ liên kết tự động nào kết nối với môi trường sản xuất. Cuối cùng, hãy đồng bộ đồng hồ. Một sự kiện SCADA được ghi dấu thời gian lệch vài phút so với bản ghi CMMS sẽ phá hỏng việc tái dựng lỗi.
Kết luận & khuyến nghị hành động
Bảo trì dự đoán đề cao sự kiên nhẫn và luồng dữ liệu sạch, không phải các bảng điều khiển cầu kỳ. Trước tiên, chỉ thu thập những trạng thái tình trạng mà thiết bị thực sự cung cấp. Tiếp theo, xác minh tình trạng dựa trên sự lặp lại và thời lượng trước khi tạo phiếu. Ngoài ra, hãy để lịch sử sửa chữa đã được xác minh điều chỉnh các điều kiện kích hoạt theo thời gian. Tuy nhiên, không bao giờ để CMMS ghi vào logic điều khiển hoặc bỏ qua quy trình kiểm soát thay đổi. Vì vậy, hãy xây dựng một đường dẫn chỉ đọc qua historian và OPC UA với thời gian được đồng bộ. Cuối cùng, hãy xem chính hạ tầng điều khiển là thiết bị cần bảo trì. Hãy bắt đầu với một liên kết EtherNet/IP quan trọng trong tuần này. Kiểm chứng toàn bộ vòng lặp từ đầu đến cuối trước khi mở rộng ra toàn nhà máy.
Tác giả: Sun Yifei là kỹ sư tự động hóa công nghiệp với hơn 10 năm kinh nghiệm về PLC, DCS và các hệ thống điều khiển.
