Series Từ số hóa đến AI #34: Khi nào cần lấy dữ liệu tự động từ máy móc, PLC, SCADA hoặc IoT?

Trả lời nhanh: Không bắt buộc phải kết nối PLC, SCADA hoặc IoT mới làm dashboard và AI. Nhà máy nên lấy dữ liệu tự động khi dữ liệu cần nhanh, liên tục, chính xác, khối lượng lớn hoặc khó quan sát bằng tay, và khi đã biết quyết định nào sẽ thay đổi nhờ dữ liệu đó. Những dữ liệu như nguyên nhân, hành động và xác nhận hiện trường vẫn thường cần con người.

Nhiều dự án bắt đầu bằng câu hỏi “nên mua cảm biến gì?” thay vì “cần biết điều gì để cải thiện vận hành?”. Kết quả có thể là một lượng lớn tag và dữ liệu lịch sử nhưng không có người dùng, KPI hoặc workflow phản ứng.

Kết nối máy rất có giá trị, nhưng phải đi sau use case và kiến trúc dữ liệu phù hợp.

Từ số hóa đến AI - Sổ tay chuẩn bị cho nhà máy

I. PLC, SCADA và IoT khác nhau ở mức nào?

  • PLC điều khiển máy/quy trình và đọc tín hiệu tại thiết bị.
  • SCADA/HMI giám sát, hiển thị và lưu một số dữ liệu điều khiển/quá trình.
  • IoT/IIoT thường bổ sung kết nối, gateway, cảm biến và nền tảng để thu thập/chia sẻ dữ liệu rộng hơn.
  • MES/CMMS/dashboard/AI sử dụng dữ liệu cho quản lý sản xuất, bảo trì, phân tích và quyết định.

Ranh giới thực tế có thể khác tùy kiến trúc. Nhà quản lý không cần tập trung vào tên công nghệ trước; cần hiểu dữ liệu nào có sẵn, tần suất, chất lượng, quyền truy cập và mục đích dùng.

II. Năm trường hợp nên ưu tiên lấy tự động

1. Dữ liệu có tần suất cao

Tốc độ, cycle time, nhiệt độ, áp suất, dòng điện hoặc rung động có thể thay đổi liên tục. Nhập tay không thể phản ánh đủ.

2. Cần phản ứng nhanh

Nếu máy dừng và trưởng ca cần biết trong vài phút, trạng thái tự động giúp giảm độ trễ. Con người có thể xác nhận nguyên nhân sau.

3. Nhập tay dễ sai hoặc gây tải lớn

Đếm sản lượng, giờ chạy và năng lượng lặp lại nhiều lần nên được tự động nếu tín hiệu đáng tin.

4. Sự kiện khó quan sát

Micro-stop, dao động thông số hoặc bất thường ngắn có thể bị bỏ qua nếu chỉ ghi cuối ca.

5. Dữ liệu ảnh hưởng trực tiếp đến kiểm soát/rủi ro

Một số điều kiện quá trình, môi trường hoặc thiết bị critical cần log tự động để truy xuất và cảnh báo theo yêu cầu vận hành.

III. Khi nào nhập thủ công vẫn phù hợp?

  • Nguyên nhân dừng máy cần judgment.
  • Triệu chứng và bối cảnh sự cố.
  • Disposition chất lượng.
  • Lý do thay đổi kế hoạch.
  • Xác nhận hoàn thành checklist.
  • Hành động xử lý và kết quả chạy thử.
  • Các sự kiện tần suất thấp, chi phí tự động hóa không hợp lý.

Tự động hóa mọi trường có thể tạo dữ liệu thiếu ý nghĩa. Một mô hình hiệu quả thường là máy ghi sự kiện - người xác nhận ngữ cảnh.

IV. Ma trận quyết định tự động hay thủ công

Tiêu chí Nghiêng về tự động Nghiêng về thủ công/xác nhận
Tần suất Liên tục/nhiều lần mỗi phút Hiếm, theo sự kiện
Độ trễ Cần phản ứng giây/phút Có thể cuối ca/ngày
Tính khách quan Tín hiệu đo rõ Cần judgment/nguyên nhân
Khối lượng Rất lớn Ít bản ghi
Rủi ro sai Nhập tay dễ sai, ảnh hưởng lớn Có thể kiểm tra trực tiếp
Chi phí kết nối Có sẵn PLC/tag/gateway Cần retrofit phức tạp
Quyết định Có workflow dùng ngay Chưa rõ ai sẽ dùng

Chỉ nên đầu tư khi có nhiều yếu tố nghiêng về tự động và giá trị đủ rõ.

V. Ví dụ 1: Dữ liệu dừng máy

Một thiết kế theo lớp:

  1. PLC/SCADA ghi trạng thái run/stop và timestamp.
  2. MES/production tracking tạo sự kiện dừng.
  3. Người vận hành/trưởng ca chọn nhóm nguyên nhân.
  4. Nếu lỗi thiết bị, sự kiện liên kết CMMS/work order.
  5. Dashboard tổng hợp downtime và action.

Nếu chưa kết nối máy, nhà máy vẫn có thể ghi start/end bằng app. Kết nối tự động nên được ưu tiên khi sự kiện nhiều, dừng ngắn bị bỏ sót hoặc độ trễ nhập tay làm giảm giá trị.

VI. Ví dụ 2: OEE và sản lượng

Dữ liệu tự động hữu ích cho:

  • Run/stop.
  • Đếm sản lượng.
  • Cycle time/tốc độ.
  • Alarm hoặc trạng thái máy.

Dữ liệu cần nghiệp vụ xác nhận:

  • Planned production time.
  • Lệnh và sản phẩm đang chạy.
  • Nguyên nhân dừng.
  • Good/reject/rework nếu máy không phân biệt đáng tin.
  • Lý do thay đổi tốc độ chuẩn.

OEE không chỉ là bài toán kết nối PLC; định nghĩa kế hoạch, chất lượng và mã nguyên nhân vẫn quyết định độ tin cậy.

VII. Ví dụ 3: Năng lượng

Nếu mục tiêu là giảm tổng hóa đơn, dữ liệu công tơ tổng có thể chỉ cho biết xu hướng. Muốn biết tổn thất ở đâu, cần đo theo khu vực, dây chuyền hoặc thiết bị, đồng thời liên kết với giờ chạy, sản lượng và sản phẩm.

Trước khi lắp thêm meter, hãy xác định:

  • Cấp đo nào dẫn đến hành động?
  • Ai chịu trách nhiệm khi tiêu thụ bất thường?
  • Baseline theo sản lượng hay thời gian?
  • Tần suất cập nhật cần bao nhiêu?
  • Hệ thống hiện có đã có tag nào?

VIII. Ví dụ 4: Condition monitoring và dự báo hỏng

Các tín hiệu như rung, nhiệt độ, dòng điện hoặc dầu có thể hỗ trợ phát hiện bất thường. Nhưng cần:

  • Failure mode cụ thể cần giám sát.
  • Vị trí và tần suất đo phù hợp.
  • Baseline trạng thái bình thường.
  • Lịch sử bảo trì và xác nhận failure.
  • Quy trình phản ứng khi cảnh báo.
  • Người chịu trách nhiệm đánh giá.

Không nên gắn cảm biến cho mọi máy chỉ vì mục tiêu “predictive maintenance”. Bắt đầu với thiết bị critical và failure mode có tín hiệu đo được.

IX. Kiến trúc dữ liệu tối thiểu

Một luồng phổ biến:

  1. Nguồn: PLC, sensor, SCADA, máy đếm.
  2. Edge/gateway: đọc giao thức, lọc và buffer khi cần.
  3. Integration/data layer: chuẩn hóa tag, timestamp, asset ID và lưu trữ.
  4. Context layer: gắn lệnh, sản phẩm, ca, trạng thái và work order.
  5. Ứng dụng: dashboard, MES, CMMS, analytics, AI.
  6. Governance: phân quyền, log, backup, retention và monitoring.

Giá trị lớn nằm ở context layer. Một tag DB12.DBD4 hoặc Temp_01 chưa đủ cho người quản lý nếu không biết thuộc máy nào, đơn vị gì và điều kiện vận hành nào.

X. Những yêu cầu kỹ thuật dễ bị bỏ qua

Đồng bộ thời gian

PLC, gateway, server và hệ thống nghiệp vụ cần timestamp có thể đối chiếu. Sai vài phút có thể làm timeline sự cố sai.

Chất lượng tín hiệu

Cần kiểm tra missing, spike, stuck value, scaling và đơn vị. Dữ liệu tự động không mặc nhiên đúng.

Tag và asset mapping

Mỗi tag cần liên kết với asset, signal type, unit, sampling, owner và trạng thái sử dụng.

Buffer và mất kết nối

Xác định dữ liệu có được lưu tạm khi mất mạng và cách đồng bộ lại. Tránh dữ liệu trùng hoặc khoảng trống không được đánh dấu.

Bảo mật OT

Kết nối phải tuân theo phân vùng mạng, quyền tối thiểu và quy trình change management. Không nên cho ứng dụng phân tích ghi ngược vào PLC nếu không có thiết kế an toàn rõ.

XI. Chi phí thực sự của kết nối máy

Ngoài cảm biến/gateway còn có:

  • Khảo sát và đọc giao thức.
  • Tủ điện, nguồn, mạng và lắp đặt.
  • License hoặc connector.
  • Chuẩn hóa tag và mapping.
  • Lưu trữ dữ liệu lịch sử.
  • Bảo mật, backup và monitoring.
  • Bảo trì cảm biến/kết nối.
  • Tích hợp MES/CMMS/ERP.
  • Nhân lực phân tích và phản ứng.

Vì vậy, ROI phải gắn với use case: giảm thời gian nhập, phát hiện dừng, giảm năng lượng, condition monitoring hoặc truy xuất.

XII. Hạ tầng AI có cần rất mạnh không?

Nhiều use case ban đầu như dashboard, tóm tắt báo cáo, phân tích lịch sử hoặc AI Copilot không cần GPU tại nhà máy. Có thể dùng cloud server hoặc dịch vụ AI phù hợp, với yêu cầu bảo mật và kết nối rõ.

Bài toán hình ảnh thời gian thực, mô hình lớn chạy tại edge hoặc dữ liệu tốc độ cao có thể cần hạ tầng khác. Hãy sizing theo use case, số tag, sampling, retention, số người dùng và latency; không đầu tư server lớn trước khi chứng minh giá trị.

XIII. Quy trình chọn điểm tự động hóa

  1. Liệt kê 10 quyết định hoặc KPI đang bị hạn chế bởi dữ liệu.
  2. Xác định trường nào hiện nhập tay và lỗi/độ trễ ra sao.
  3. Kiểm tra PLC/SCADA đã có tín hiệu nào.
  4. Chấm ma trận giá trị - khả thi - rủi ro.
  5. Chọn 5-20 tag hoặc một nhóm máy cho pilot.
  6. Thiết kế workflow xác nhận và hành động.
  7. Đo độ đầy đủ, độ trễ, sai lệch và hiệu quả.
  8. Mở rộng theo failure mode hoặc dây chuyền.

XIV. KPI cho pilot kết nối máy

KPI Ý nghĩa
Tỷ lệ dữ liệu sẵn có Độ ổn định kết nối
Độ trễ từ sự kiện đến dashboard Khả năng phản ứng
Sai lệch so với đối chiếu Chất lượng tín hiệu
Tỷ lệ event được xác nhận nguyên nhân Kết nối máy-người
Giờ nhập liệu thủ công giảm Hiệu quả hành chính
Số cảnh báo hữu ích Chất lượng use case
Downtime/năng lượng/chỉ số mục tiêu Kết quả vận hành

XV. Những sai lầm thường gặp

  • Mua cảm biến trước khi có use case.
  • Thu mọi tag nhưng không có data dictionary.
  • Cho rằng dữ liệu tự động luôn chính xác.
  • Bỏ qua timestamp và asset mapping.
  • Không thiết kế bước con người xác nhận.
  • Cảnh báo không có owner hoặc workflow.
  • Kết nối trực tiếp OT-IT thiếu kiểm soát bảo mật.
  • Lưu dữ liệu tần suất quá cao không có nhu cầu.
  • Đánh giá thành công bằng số tag thay vì quyết định cải thiện.

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

Không có PLC/SCADA có làm AI Copilot được không?

Có. AI Copilot có thể bắt đầu từ manual, SOP, checklist và lịch sử bảo trì. Nó không nhất thiết cần dữ liệu máy.

Nên lấy toàn bộ tag có sẵn không?

Không. Chọn tag liên quan đến use case và failure mode. Thu quá nhiều làm tăng chi phí và khó quản trị.

Dữ liệu dừng máy nên tự động hoàn toàn không?

Start/stop có thể tự động, nhưng nguyên nhân và hành động thường cần người xác nhận. Tự động phân loại có thể hỗ trợ sau khi có dữ liệu đủ tốt.

Có thể dùng cloud cho dữ liệu máy không?

Có thể nếu kiến trúc, băng thông, latency, bảo mật, retention và yêu cầu vận hành phù hợp. Một số dữ liệu/điều khiển có thể cần xử lý tại edge hoặc nội bộ.

Bài viết được biên tập từ ebook “Từ số hóa đến AI - Sổ tay chuẩn bị cho nhà máy”, Vietsoft, 06/2026.

Nhà máy của bạn đã sẵn sàng cho AI?

Hãy bắt đầu bằng việc đánh giá nhanh mức sẵn sàng AI của nhà máy hoặc tải E-book “Từ Số Hóa Đến AI” để tham khảo cách xây dựng lộ trình Smart Factory phù hợp.

Bắt đầu đánh giá AI Readiness Tải E-book: Từ Số Hóa Đến AI