Dấu hiệu HMI không lên nguồn cần ghi lại ngay

HMI mất nguồn, chớp tắt, tối màn hình, liệt cảm ứng, mất giao tiếp PLC; trực tiếp khiến người vận hành không thể thao tác máy.

Checklist 8 bước xử lý HMI không lên nguồn cho SME

Thứ tự này giúp đội kỹ thuật xử lý HMI không lên nguồn theo dữ liệu, hạn chế thay sai linh kiện và tránh mất dấu nguyên nhân sau khi reset.

• Bước 1: Xác nhận lỗi xảy ra ở máy nào, ca nào và chế độ vận hành nào.
• Bước 2: Giữ nguyên log, alarm, trạng thái I/O và ảnh hiện trường trước khi reset.
• Bước 3: Đối chiếu pain point thực tế: HMI không lên nguồn, tối màn hình, liệt/loạn cảm ứng hoặc mất giao tiếp PLC làm người vận hành không thể nhập thông số hay chạy máy.
• Bước 4: Kiểm tra tín hiệu quan sát: HMI mất nguồn, chớp tắt, tối màn hình, liệt cảm ứng, mất giao tiếp PLC; trực tiếp khiến người vận hành không thể thao tác máy.
• Bước 5: Không lặp lại cách xử lý tạm: Tắt bật nguồn, kiểm tra 24V, vệ sinh giắc, thử gõ/chạm màn hình, tìm HMI cũ thay thử; nếu thay màn hình mới thường vướng không có project.
• Bước 6: Đo bằng dụng cụ phù hợp thay vì chỉ nhìn đèn báo hoặc cảm giác vận hành.
• Bước 7: Tính ảnh hưởng kinh doanh: Máy phải chạy tay hoặc dừng hẳn; nguy cơ mất recipe/thông số và phát sinh thêm chi phí nếu thay HMI mà không có chương trình.
• Bước 8: Chốt phương án dịch vụ: Gói phục hồi HMI: remote chẩn đoán 500k-1M; sửa/thay HMI + clone chương trình 2-8M; upsell backup toàn máy.

Bảng khoanh vùng nguyên nhân khi HMI không lên nguồn

Bảng này giúp chọn hướng kiểm tra đầu tiên khi sản xuất đang chờ máy chạy lại.

Không nên làm khi HMI không lên nguồn

Cách tự xử lý hiện tại thường là: Tắt bật nguồn, kiểm tra 24V, vệ sinh giắc, thử gõ/chạm màn hình, tìm HMI cũ thay thử; nếu thay màn hình mới thường vướng không có project. Những việc này có thể giúp máy chạy tạm nhưng dễ che mất…

Câu hỏi thường gặp

Dấu hiệu historian mất dữ liệu cần ghi lại ngay

Những tín hiệu ban đầu giúp phân biệt historian mất dữ liệu là lỗi thiết bị, lỗi logic, lỗi cấu hình hay lỗi thiếu dữ liệu bảo trì.

Checklist xử lý historian mất dữ liệu tại hiện trường

Thứ tự dưới đây giúp xử lý historian mất dữ liệu có kiểm soát và giảm rủi ro thay sai linh kiện hoặc che mất nguyên nhân gốc.

• Bước 1: Không chỉ nhìn tag live vì live value đúng không chứng minh có lịch sử.
• Bước 2: Kiểm tra provider mapping ở từng tag hoặc UDT instance critical.
• Bước 3: So historical deadband, storage mode và scan class/tag group.
• Bước 4: Test boolean đổi trạng thái nhanh, không chỉ test analog thay đổi chậm.
• Bước 5: Đọc store-and-forward, gateway log và lỗi database write.
• Bước 6: Kiểm tra timezone, partition, retention và quyền ghi DB.
• Bước 7: Chạy truy vấn mẫu trên dữ liệu mới trước khi cắt sang production.
• Bước 8: Lưu checklist go-live để lần migration sau không mất fault history.

Bảng khoanh vùng nguyên nhân khi historian mất dữ liệu

Bảng này giúp chọn điểm kiểm tra đầu tiên, tránh đi lan man khi sản xuất đang chờ máy chạy lại.

Không nên làm khi historian mất dữ liệu

Các thao tác quen tay có thể làm máy chạy tạm nhưng khiến nguyên nhân thật khó chứng minh hơn ở lần sự cố kế tiếp.

Câu hỏi thường gặp

Dấu hiệu alarm không gửi email cần ghi lại ngay

Những tín hiệu ban đầu giúp phân biệt alarm không gửi email là lỗi thiết bị, lỗi logic, lỗi cấu hình hay lỗi thiếu dữ liệu bảo trì.

Checklist xử lý alarm không gửi email tại hiện trường

Thứ tự dưới đây giúp xử lý alarm không gửi email có kiểm soát và giảm rủi ro thay sai linh kiện hoặc che mất nguyên nhân gốc.

• Bước 1: Ghi alarm ID, priority, timestamp active và trạng thái acknowledge.
• Bước 2: Kiểm tra pipeline có được gán đúng vào alarm source không.
• Bước 3: Xem rule filter có loại mất alarm vì area, priority hoặc tag path không.
• Bước 4: Kiểm tra roster, lịch trực, email, số điện thoại và escalation delay.
• Bước 5: Đọc log SMTP/API để biết lỗi auth, rate limit, DNS hoặc timeout.
• Bước 6: Test bằng alarm giả lập, không chờ lỗi production thật.
• Bước 7: Xác nhận người nhận thực tế nhận được mail/SMS/callout.
• Bước 8: Ghi kết quả test định kỳ vào checklist vận hành SCADA.

Bảng khoanh vùng nguyên nhân khi alarm không gửi email

Bảng này giúp chọn điểm kiểm tra đầu tiên, tránh đi lan man khi sản xuất đang chờ máy chạy lại.

Không nên làm khi alarm không gửi email

Các thao tác quen tay có thể làm máy chạy tạm nhưng khiến nguyên nhân thật khó chứng minh hơn ở lần sự cố kế tiếp.

Câu hỏi thường gặp

Dấu hiệu Ignition Gateway tự restart cần ghi lại ngay

Những tín hiệu ban đầu giúp phân biệt Ignition Gateway tự restart là lỗi thiết bị, lỗi logic, lỗi cấu hình hay lỗi thiếu dữ liệu bảo trì.

Checklist xử lý Ignition Gateway tự restart tại hiện trường

Thứ tự dưới đây giúp xử lý Ignition Gateway tự restart có kiểm soát và giảm rủi ro thay sai linh kiện hoặc che mất nguyên nhân gốc.

• Bước 1: Lấy gateway log quanh thời điểm restart, không chỉ xem dashboard hiện tại.
• Bước 2: Kiểm tra wrapper/service log để biết process tự thoát hay bị kill.
• Bước 3: Đọc OS event log, journalctl hoặc dmesg nếu chạy Linux.
• Bước 4: Theo dõi heap JVM, garbage collection, thread count và memory native.
• Bước 5: Kiểm tra module mới, script gateway, transaction DB và tag subscription.
• Bước 6: So restart với backup job, antivirus, update OS hoặc service supervision.
• Bước 7: Bật cảnh báo khi gateway memory hoặc uptime bất thường.
• Bước 8: Ghi timeline 6-30 giờ để tìm pattern thay vì đo một thời điểm.

Bảng khoanh vùng nguyên nhân khi Ignition Gateway tự restart

Bảng này giúp chọn điểm kiểm tra đầu tiên, tránh đi lan man khi sản xuất đang chờ máy chạy lại.

Không nên làm khi Ignition Gateway tự restart

Các thao tác quen tay có thể làm máy chạy tạm nhưng khiến nguyên nhân thật khó chứng minh hơn ở lần sự cố kế tiếp.

Câu hỏi thường gặp

Dấu hiệu Historian bị đứng trend liên quan store-and-forward

Các dấu hiệu sau cho thấy Historian bị đứng trend không phải do widget hiển thị mà do pipeline ghi dữ liệu đang nghẽn hoặc lỗi.

Checklist xử lý Historian bị đứng trend

Đi đúng thứ tự sẽ giúp cứu dữ liệu khi Historian bị đứng trend trước khi backlog đầy hoặc bị purge ngoài ý muốn.

• Bước 1: Ghi thời điểm Historian bị đứng trend bắt đầu, tag nào bị ảnh hưởng, và realtime tag có còn đổi hay không để tách lỗi hiển thị khỏi lỗi logging.
• Bước 2: Kiểm store-and-forward hoặc queue tương đương: số bản ghi backlog, số record trong quarantine và tốc độ flush hiện tại.
• Bước 3: Đọc log lỗi transaction ghi database, đặc biệt duplicate key, timestamp conflict, deadlock, timeout hoặc mất kết nối ODBC/JDBC.
• Bước 4: Kiểm dung lượng đĩa của queue local, đường dẫn store-and-forward và tình trạng ghi file; nếu queue đầy hoặc quyền ghi lỗi, Historian bị đứng trend sẽ kéo dài dù database đã hồi.
• Bước 5: So clock giữa SCADA server, historian node và database server; lệch thời gian hoặc timezone sai có thể tạo bản ghi trùng hoặc vào sai partition.
• Bước 6: Kiểm bảng đích và index database: khoá chính, unique constraint, partition policy và tốc độ commit thực tế dưới tải hiện tại.
• Bước 7: Chỉ retry, requeue hoặc clear quarantine sau khi hiểu rõ nguyên nhân; nếu không, Historian bị đứng trend có thể mất thêm dữ liệu hoặc lặp lỗi duplicate-key liên tục.
• Bước 8: Xác nhận trend đã chạy lại, backlog đang giảm thật và dữ liệu mới được ghi xuống database trước khi coi sự cố Historian bị đứng trend là đã xong.

Bảng khoanh vùng khi Historian bị đứng trend

Bảng này giúp biết nên tập trung vào queue, transaction, database hay đồng bộ thời gian trước.

Không nên làm khi Historian bị đứng trend

Historian bị đứng trend thường còn cứu được dữ liệu nếu xử lý đúng thứ tự. Làm sai sớm sẽ chuyển lỗi nghẽn thành lỗi mất dữ liệu thật.

Câu hỏi thường gặp

Dấu hiệu SCADA bị chậm dần có khả năng liên quan memory leak

Một số dấu hiệu sau thường xuất hiện trước khi SCADA bị chậm dần tới mức gateway phải restart hoặc client gần như không thao tác được.

Checklist kiểm tra khi SCADA bị chậm dần

Đi đúng thứ tự sẽ giúp biết SCADA bị chậm dần do leak, query, client session hay do database phía sau.

• Bước 1: Ghi thời điểm SCADA bắt đầu chậm, thời điểm restart gần nhất và khoảng thời gian từ lúc restart đến lúc hệ xuống hiệu năng rõ rệt.
• Bước 2: Theo dõi RAM hệ điều hành, heap ứng dụng, garbage collection pause và thread count theo thời gian thay vì chỉ chụp một ảnh tức thời.
• Bước 3: Kiểm tra số client/session, tab dashboard, Vision/Perspective session hoặc remote desktop đang mở; nhiều phiên treo có thể làm SCADA bị chậm dần dù server chưa full CPU.
• Bước 4: Đọc log slow query, lịch sử trend, báo cáo định kỳ và script timer vì query lịch sử nặng hoặc polling dày cũng khiến SCADA bị chậm dần rất giống memory leak.
• Bước 5: So thay đổi gần nhất: update module, sửa tag event script, thêm historian path, thêm dashboard hoặc thay retention database.
• Bước 6: Tách bài test ứng dụng khỏi database: nếu stop query nặng mà SCADA bị chậm dần vẫn tiếp tục, nghi leak ứng dụng; nếu hiệu năng phục hồi ngay, ưu tiên khoanh database hoặc historian.
• Bước 7: Chỉ restart sau khi đã lấy đủ heap usage, log lỗi và số session để lần chậm sau còn có dữ liệu so sánh, không phải quay lại đoán từ đầu.

Bảng khoanh vùng khi SCADA bị chậm dần

Bảng này giúp phân biệt SCADA bị chậm dần do memory leak, query nặng, session client hay hạ tầng lưu trữ.

Không nên làm khi SCADA bị chậm dần

SCADA bị chậm dần rất dễ bị chữa cháy bằng restart, nhưng cách đó chỉ xóa triệu chứng và xóa luôn dữ liệu cần để sửa gốc.

Câu hỏi thường gặp

Dấu hiệu SCADA HMI chậm lỗi query cần ghi lại trước khi reset

Nhiều sự cố kiểu SCADA HMI chậm lỗi query chỉ hiện ra trong vài giây hoặc ở đúng một điều kiện tải.

Checklist SCADA HMI chậm lỗi query tại hiện trường

Đi theo checklist này giúp tránh thay linh kiện hoặc chỉnh logic mù khi gặp SCADA HMI chậm lỗi query.

• Bước 1: Ghi thời điểm HMI bắt đầu chậm, lỗi query xuất hiện ở màn nào và có lan sang lịch sử hay alarm không.
• Bước 2: Kiểm tra connection pool, số session mở, timeout và query chậm trước khi chỉ reboot dịch vụ SCADA.
• Bước 3: Tách màn hình, báo cáo hoặc trend nào đang gọi dữ liệu nặng nhất trong giờ cao điểm.
• Bước 4: So tài nguyên máy chủ, disk latency và tình trạng database với thời điểm hệ hoạt động bình thường.
• Bước 5: Kiểm tra thay đổi gần nhất ở query, historian, report hoặc dashboard trước khi lỗi bùng lên.
• Bước 6: Không tăng pool hoặc restart định kỳ thay cho việc khoanh đúng truy vấn gây nghẽn.
• Bước 7: Bổ sung cảnh báo pool gần cạn, query chậm và dashboard nặng để bắt lỗi sớm hơn.
• Bước 8: Lưu danh sách query, index và thời điểm fail để tối ưu triệt để thay vì chữa cháy.

Bảng khoanh vùng SCADA HMI chậm lỗi query

Bảng này giúp chọn hướng kiểm tra nhanh hơn khi SCADA HMI chậm lỗi query làm máy dừng hoặc vận hành không ổn.

Sai lầm hay gặp khi xử lý SCADA HMI chậm lỗi query

Áp lực khôi phục sản xuất dễ làm đội hiện trường bỏ qua dữ liệu gốc và kéo dài thời gian xử lý.

Câu hỏi thường gặp

Dấu hiệu SCADA redundancy mất event cần ghi lại trước khi reset

Nhiều sự cố kiểu SCADA redundancy mất event chỉ hiện ra trong vài giây hoặc ở đúng một điều kiện tải.

Checklist SCADA redundancy mất event tại hiện trường

Đi theo checklist này giúp tránh thay linh kiện hoặc chỉnh logic mù khi gặp SCADA redundancy mất event.

• Bước 1: Xác nhận mất event xảy ra đúng lúc failover, ở loại sự kiện nào và mức độ mất có lặp lại không.
• Bước 2: Kiểm tra buffer sự kiện ở PLC, gateway và SCADA để biết dữ liệu có nơi giữ trung gian hay không.
• Bước 3: So cấu hình đồng bộ redundancy, store-forward và event queue giữa hai node SCADA.
• Bước 4: Test failover có kiểm soát với tín hiệu tốc độ cao để đo khoảng trống dữ liệu thực tế.
• Bước 5: Kiểm tra độ trễ mạng, time sync và cơ chế flush queue khi node chính chuyển sang dự phòng.
• Bước 6: Không giả định redundancy là đủ nếu event critical không được buffer ở lớp thấp hơn.
• Bước 7: Bổ sung test case failover cho tín hiệu tốc độ cao trong FAT hoặc SAT.
• Bước 8: Lưu biểu đồ mất event và thời gian chuyển hệ để làm chuẩn thiết kế cho lần sau.

Bảng khoanh vùng SCADA redundancy mất event

Bảng này giúp chọn hướng kiểm tra nhanh hơn khi SCADA redundancy mất event làm máy dừng hoặc vận hành không ổn.

Sai lầm hay gặp khi xử lý SCADA redundancy mất event

Áp lực khôi phục sản xuất dễ làm đội hiện trường bỏ qua dữ liệu gốc và kéo dài thời gian xử lý.

Câu hỏi thường gặp