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.
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:
- PLC/SCADA ghi trạng thái run/stop và timestamp.
- MES/production tracking tạo sự kiện dừng.
- Người vận hành/trưởng ca chọn nhóm nguyên nhân.
- Nếu lỗi thiết bị, sự kiện liên kết CMMS/work order.
- 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:
- Nguồn: PLC, sensor, SCADA, máy đếm.
- Edge/gateway: đọc giao thức, lọc và buffer khi cần.
- Integration/data layer: chuẩn hóa tag, timestamp, asset ID và lưu trữ.
- Context layer: gắn lệnh, sản phẩm, ca, trạng thái và work order.
- Ứng dụng: dashboard, MES, CMMS, analytics, AI.
- 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
- Liệt kê 10 quyết định hoặc KPI đang bị hạn chế bởi dữ liệu.
- Xác định trường nào hiện nhập tay và lỗi/độ trễ ra sao.
- Kiểm tra PLC/SCADA đã có tín hiệu nào.
- Chấm ma trận giá trị - khả thi - rủi ro.
- Chọn 5-20 tag hoặc một nhóm máy cho pilot.
- Thiết kế workflow xác nhận và hành động.
- Đo độ đầy đủ, độ trễ, sai lệch và hiệu quả.
- 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.
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.
