Một hệ thống thu thập dữ liệu thực tế sản xuất cho nhà máy tại Thái Lan chưa hoàn thành chỉ vì đã đọc được PLC và hiển thị con số. Hệ thống phải tránh ghi nhận hai lần khi dữ liệu được gửi lại, phân biệt nhập muộn với sự kiện thời gian thực, ngăn kết quả kiểm tra chưa duyệt đi vào ERP và lưu toàn bộ lịch sử sửa. Bài viết chuyển “tính đúng của bản ghi” và “trách nhiệm xác nhận” thành yêu cầu RFP, PoC, FAT và SAT có thể nghiệm thu.
Hệ thống thu thập dữ liệu thực tế sản xuất phải chứng minh nhiều hơn khả năng hiển thị
Đưa tín hiệu máy lên dashboard có thể làm khá nhanh, nhưng số nhìn thấy chưa chắc là production actual. Một bit completion chuyển trạng thái có thể là một sản phẩm tốt, chạy không tải, khuôn nhiều cavity, chạy thử hoặc sản phẩm còn chờ kiểm. Khi mạng phục hồi và gửi lại cùng message, cộng theo số lần nhận sẽ làm sản lượng tăng sai.
Bản ghi dùng cho kế hoạch, tồn kho, giá thành hoặc cam kết giao hàng phải trả lời được: việc gì đã xảy ra ở site, line, thiết bị, operation, order, item và lot nào; xảy ra, được nhận và được xác nhận khi nào; đến từ raw record và rule version nào; gửi lại có chỉ được tính một lần không; đang provisional, confirmed, posted hay cancelled; ai sửa, vì sao và giá trị trước/sau là gì.
Khả năng nhìn thấy tiến độ công đoạn là đầu ra của nền tảng này. Nếu nền tảng yếu, hiện trường vẫn giữ giấy hoặc Excel song song và xem hệ thống là số tham khảo. Vì vậy, cần xác định event identity, state transition, deduplication và quyền sửa trước khi chọn biểu đồ.
Thiết kế thu thập kết quả sản xuất theo 5 trạng thái
Không biến mọi dữ liệu đến thành “đã ghi sổ”. Hãy tách:
- Raw — giá trị PLC, sensor, barcode scan hoặc operator input vừa thu nhận.
- Event — diễn giải nghiệp vụ như bắt đầu operation, hoàn tất một lần hoặc kiểm tra NG.
- Provisional — đã gắn order, item, lot, operator và unit nhưng chưa chấp nhận.
- Confirmed — người có thẩm quyền hoặc quy tắc đã duyệt xác nhận là thực tế chính thức.
- Posted — ERP/tồn kho/giá thành đã phản hồi và đối soát.
Giữ raw evidence để có thể xử lý lại khi sửa mapping logic, đồng thời thống nhất retention, capacity, access và privacy. Không nên overwrite bản ghi confirmed; hãy thêm cancellation event và correction event để giữ giá trị gốc, lý do và người sửa. Nếu đã post ERP, việc sửa phải gồm reverse/repost phía ERP, không chỉ đổi màn hình MES.
Tách raw signal khỏi business event
Bit, register hoặc counter PLC mô tả trạng thái điều khiển; production event mô tả ý nghĩa nghiệp vụ. Mapping phải xử lý pulse, debounce, PLC restart, multi-cavity, trial, dry cycle, quality state và counter reset/rollover.
Đính kèm event-definition table trong RFP với source, trigger, debounce, quantity rule, work-order mapping, quality state, event-ID rule, error handling và owner của từng event. Câu trả lời “hỗ trợ OPC UA” chưa đủ.
OPC UA PubSub có thể phân phối dữ liệu chu kỳ và event, đồng thời tách publisher khỏi subscriber. Tuy nhiên, DataSetMessage nào là kết quả của order nào vẫn là hợp đồng ở tầng ứng dụng. Hãy đánh giá connectivity và tính hợp lệ của production record như hai tiêu chí riêng.
Phân vai PLC, người vận hành, kiểm tra và barcode
PLC ghi nhận điểm phát sinh khách quan
PLC phù hợp với cycle start/end, trạng thái thiết bị, counter và alarm nhưng không phải lúc nào cũng biết work order hợp lệ, defect reason hoặc final quality. Tránh nhồi toàn bộ business master vào control logic. PLC tạo source event; edge/MES kết hợp nó với work-order assignment có thời hạn hiệu lực. Nếu không kết hợp được, đưa vào exception queue thay vì bỏ. Khi sửa sau đó, vẫn giữ event ID và timestamp gốc.
Người vận hành bổ sung ý nghĩa và ngoại lệ
Setup complete, downtime reason, rework reason và disposal reason thường cần con người. Nên dùng reason code được kiểm soát và lựa chọn theo context thay vì free text. Code là master key, còn nhãn hiển thị có thể bằng Thái, Anh và Nhật.
Tách thời điểm chọn khỏi thời điểm gửi. Terminal offline phải giữ durable queue và hiển thị khác nhau giữa local saved, sent, received, confirmed. Tài khoản dùng chung làm mất trách nhiệm sửa; nên dùng named identity hoặc quy trình theo tổ được phê duyệt và có phân tách nhiệm vụ.
Kết quả kiểm tra không nên ghi đè số lượng sản xuất
Một thiết kế ghi completion ở provisional rồi phân bổ thành good, reject, hold, rework sau kiểm tra. Thiết kế khác dùng inspection pass làm good-output event. Cả hai có thể đúng; lỗi là overwrite tất cả trong một counter.
Định nghĩa quy tắc nhất quán giữa completed, inspected, accepted, rejected, held và reworked, cùng sampling, retest version và quality approval. Nếu tồn kho hoặc quality lot đã post, correction workflow phải cập nhật hệ thống đích.
Barcode xác định đối tượng rồi mới xác thực
Barcode có thể nhận diện order, item, lot, serial, container hoặc operator, nhưng đọc được không có nghĩa là hợp lệ. Cần kiểm routing sequence, expiry, prior use, duplicate, item match và equipment eligibility. Mỗi scan có event ID riêng; chỉ debounce theo thời gian không phân biệt được double scan lỗi với hai thao tác hợp lệ.
Xác định ranh giới MES–ERP bằng quyền xác nhận
ISA-95 cung cấp ngôn ngữ chung cho physical process, sensing/control, manufacturing operations management và enterprise function, nhưng không ép mọi nhà máy dùng cùng topology. Hãy xác định system of record và quyền confirm cho từng nhóm dữ liệu.
| Dữ liệu | Chủ sở hữu điển hình | Trách nhiệm phía thu thập |
|---|---|---|
| item, routing, order | ERP hoặc production master đã duyệt | nhận version/validity, không tạo master song song |
| equipment, tag, edge mapping | OT/MES | quản lý version của source và transformation rule |
| raw/event/provisional | edge/MES | giữ identity, state và exception evidence |
| confirmed execution | MES/production management | áp dụng role và approval rule |
| inventory/accounting posting | ERP | trả target document ID và kết quả |
SAP Production Order Confirmation API là một ví dụ có thời gian bắt đầu/kết thúc, yield, scrap, rework, variance reason và final confirmation type. Đây không phải chuẩn chung cho mọi ERP, nhưng cho thấy production actual không chỉ là quantity.
Quyết định ERP posting bắt đầu ở confirmed, supervisor approval hay shift close. Khi ERP timeout, không đánh dấu Posted chỉ vì đã gửi request. Giữ posting request ID, target response ID, result code và chỉ chuyển trạng thái sau reconciliation.
Tham khảo 4 trục đánh giá khi so sánh MES để đánh giá sản phẩm và hướng dẫn RFP thuê ngoài phát triển hệ thống khi có custom integration hoặc software.
Tách event_time, received_at và confirmed_at
Một timestamp không giải thích được mất kết nối, nhập muộn hay chờ duyệt. Tối thiểu cần:
- event_time — lúc sự kiện xảy ra tại hiện trường;
- received_at — lúc edge, broker hoặc MES ghi nhận đã nhận;
- confirmed_at — lúc nghiệp vụ chấp nhận là actual chính thức.
GS1 EPCIS cũng phân biệt eventTime của sự kiện thực với recordTime của repository. Dù không dùng EPCIS, cách tách này vẫn hữu ích. Lưu timezone offset, clock source và clock status khi vận hành giữa Thái Lan, Nhật Bản và Việt Nam.
Khi clock thiết bị lệch, event_time có thể muộn hơn received_at. Định nghĩa clock skew cho phép, cách sync, loss-of-sync flag và correction rule. Giữ timestamp gốc, thêm corrected_event_time và lý do. Dashboard phải nêu rõ thời gian nào dùng cho biểu đồ: event time cho phát sinh hiện trường, received time cho pipeline latency và confirmed time cho chốt số.
Xử lý gửi lại, trùng lặp và đảo thứ tự bằng business ID
MQTT 5.0 QoS 1 là at-least-once nên có thể trùng. DUP flag không nhận diện application message. QoS 2 tăng bảo đảm ở transport nhưng không tự ngăn database transaction hoặc ERP posting trùng sau application retry.
Gán source_event_id không tái sử dụng dài hạn, ví dụ site-line-PLC boot ID-sequence hoặc UUID, rồi enforce unique key. Cùng ID và cùng payload là duplicate được ghi nhận nhưng không cộng lần hai. Cùng ID mà payload khác là critical exception, không được overwrite.
Áp dụng idempotency ở mọi boundary: device→edge theo event ID; edge→MES giữ event ID và attempt; MES state dùng expected version; MES→ERP dùng posting request ID ổn định sau timeout; lưu ERP document ID để đối soát.
Event có thể đến đảo thứ tự, chẳng hạn completion trước start hoặc inspection trước production completion. Định nghĩa reorder window, prerequisite hold, timeout và exception queue. Thứ tự insert vào database không phải thứ tự sản xuất.
Thiết kế offline recovery thành quy trình vận hành
Nhà máy tại Thái Lan có thể mất factory LAN, Wi-Fi, VPN, cloud, điện hoặc edge runtime. “Chạy offline” phải nói rõ dữ liệu giữ ở đâu, bao lâu, ưu tiên nào và xử lý ra sao khi storage đầy.
AWS IoT Greengrass Stream Manager là ví dụ chính thức hỗ trợ intermittent connectivity, persistence, retention và export priority. Bất kể sản phẩm, hãy yêu cầu:
- durable queue sống qua edge restart;
- append-only journal có sequence, checksum và source event ID;
- ưu tiên production event khác diagnostic data;
- giám sát buffer usage, oldest unsent và dead-letter;
- backlog drain có kiểm soát, không làm nghẽn event hiện tại;
- safe state khi disk đầy, corrupt, mất clock hoặc certificate hết hạn;
- encryption, key, access và maintenance control cho dữ liệu local.
Khi offline, UI phải phân biệt local saved, received và confirmed. Sau phục hồi phải đối soát gap, duplicate và số ERP posting; “đã gửi hết message” chưa đủ.
Đưa event data contract vào RFP
RFP cần sample event schema, không chỉ screen list và machine count.
| Nhóm | Field tối thiểu |
|---|---|
| Identity | source_event_id, site, line, equipment, event_type, schema_version |
| Context | work_order, operation, item, lot/serial, shift, operator/role |
| Value | quantity, unit, quality_state, reason_code, raw reference |
| Time | event_time, timezone, received_at, confirmed_at, clock status |
| State | raw, event, provisional, confirmed, posted, cancelled, state version |
| Audit | creator, confirmer, changer, reason, before/after, rule version |
| Delivery | sequence, attempt, checksum, posting request ID, response ID |
Định nghĩa compatibility khi thêm field, đổi mandatory hoặc triển khai nhiều version. Tách PLC tag mapping khỏi canonical event schema để thay đổi control không lan tới mọi consumer.
Yêu cầu security phải nêu device identity, certificate rotation, least privilege, port/route, remote maintenance, log access, restore test, vulnerability response và thu hồi quyền, chứ không chỉ “mã hóa.”
Dùng PoC 30/60/90 ngày để chứng minh tính đúng
Khung 30/60/90 ngày là đề xuất ra quyết định, không phải thời hạn chuẩn bắt buộc.
Ngày 30: khóa định nghĩa
Chọn một operation, thống nhất event definition, ID, clock, state transition, exception và owner. Thu sample normal, setup, trial, rework, hold, PLC restart và work-order change. Duyệt manual truth set trước demo.
Ngày 60: tạo bằng chứng failure
Tiêm network loss, edge restart, duplicate, out-of-order, ERP timeout, clock skew và master mismatch. Ví dụ 10.000 event, outage hai giờ, gửi lại ba lần và lệch ±5 phút chỉ là test mẫu; phải thay bằng peak, buffer và SLA thực tế.
Đo collection completeness, duplicate posting, unreconciled record, confirmation lead time, exception effort, recovery time và audit gap. Xem maximum và failure case, không chỉ average.
Ngày 90: nghiệm thu vận hành
Operator phải xử lý exception bằng tiếng Thái, supervisor phải confirm, IT/OT phải đi từ alert tới nguyên nhân và ERP user phải reverse/repost. Nhận operating procedure, access matrix, backup/restore evidence, certificate renewal, support escalation và known limitation rồi quyết định scale, revise hay stop.
FAT/SAT phải bao phủ normal, failure và recovery
FAT chứng minh schema, deduplication, state, authorization, audit và interface trong môi trường nhà cung cấp. SAT lặp lại với PLC, network, shift, operator và ERP/MES thật.
Kiểm normal event; counter reset và biên ngày/ca/lot; lỗi LAN, broker, DB, edge, ERP; lost ack và conflicting duplicate; clock drift/timezone; unauthorized confirmation; backlog drain/dead-letter replay; peak load và full disk.
Mỗi test case cần precondition, input, expected event/state, evidence, actual, tester, date và defect ID. Ảnh “pass” không đủ; phải trace cùng event ID từ raw qua MES tới ERP document.
So sánh TCO bao gồm exception và thay đổi
Dùng cùng công thức:
TCO tháng = license + edge/kết nối + cloud/database + support + lao động xử lý exception + thay đổi phân bổ + training/audit
Không tự tạo giá thị trường hay phần trăm hiệu quả. Yêu cầu nhà cung cấp báo theo cùng giả định: thêm một máy, mười tag, event type mới, đổi ERP field, trực đêm, hỗ trợ tiếng Thái, spare edge, certificate rotation, patch và restore test.
Tỷ lệ tự động cao nhưng nhiều order mismatch hoặc clock error có thể làm tăng việc. Theo dõi số lượng và tuổi exception, manual correction ratio, recurrence và root cause, không chỉ automation percentage.
Sai lầm thường gặp và cách sửa
- Dùng PLC counter làm good output: tách raw completion khỏi quality-confirmed quantity.
- Chỉ lưu arrival time: lưu event, received, confirmed.
- Nghĩ MQTT QoS giải quyết ghi trùng: thêm event identity và idempotency.
- Chỉ ping khi test outage: test buffer, replay, order, gap và ERP reconciliation.
- Overwrite sau confirmed: dùng cancellation/correction event.
- Để MES và ERP cùng là master: chỉ định owner theo field và state.
- Kết thúc PoC ở demo một máy: inject failure và kiểm vận hành đa ngôn ngữ.
- Bỏ exception labor khỏi TCO: gồm support, renewal, patch và recovery.
FAQ: Thu thập kết quả sản xuất và hiển thị tiến độ
Hệ thống thu thập dữ liệu thực tế sản xuất là gì?
Đó là hệ thống biến bản ghi PLC, operator, inspection và barcode thành actual gắn order/operation, rồi kiểm soát provisional, confirmation, ERP posting và correction. Event identity, state, authorization và audit giúp nó khác data logger.
Có thể tự động hóa toàn bộ kết quả chỉ bằng PLC không?
PLC tốt cho cycle và status khách quan, nhưng reason, rework, hold và order exception cần operator hoặc context cấp trên. Hãy kết hợp nguồn bằng confirmation rule rõ ràng.
Vì sao tách event time và confirmation time?
Mất mạng, nhập muộn và chờ duyệt làm hai thời điểm khác nhau. Không tách thì không giải thích được progress, shift close và audit.
Dashboard tiến độ có cần deduplication không?
Có. Gửi lại có thể làm progress vượt 100% và dự báo hoàn tất sai.
MQTT QoS 2 có bảo đảm ERP chỉ post một lần không?
Không. QoS xử lý transport; database commit, service retry và ERP posting vẫn cần application event ID và idempotent processing.
PoC, FAT và SAT khác nhau thế nào?
PoC chứng minh định nghĩa và cách làm trong phạm vi nhỏ. FAT chứng minh chức năng/failure tại nhà cung cấp. SAT lặp lại trong nhà máy thật với người dùng thật.
Đã có MES thì có nên rà soát lại việc thu thập kết quả sản xuất không?
Có. Doanh nghiệp có thể tăng cường hợp đồng sự kiện tại edge, ID, timestamp, xử lý ngoại lệ và đối soát ERP mà không phải thay đổi màn hình MES hiện có. Hãy bắt đầu bằng cách phân loại dữ liệu thiếu, dữ liệu trùng, nhập muộn và các lần sửa trong log hiện tại, rồi chỉ điều chỉnh phần cần thiết.
Kết luận: một actual đúng phải có đường đi giải thích được
Mục tiêu không phải thu mọi thứ tự động. Mục tiêu là nối raw signal, business event, provisional, confirmation và ERP posting bằng ID bền vững, rồi giải thích được con số sau outage, retransmission hoặc correction. Hãy đưa owner, ba timestamp, audit và recovery reconciliation vào RFP và acceptance test.
TOMAS TECH có thể hỗ trợ nhà máy tại Thái Lan xác định event contract cho một operation, ranh giới PLC/operator/inspection, RFP, PoC 30/60/90 ngày và bằng chứng FAT/SAT. Có thể trao đổi ngay từ giai đoạn trước chọn sản phẩm qua trang liên hệ.
