Phát triển màn hình HMI cho nhà máy Thái Lan: RFP và FAT/SAT

Khi một nhà máy tại Thái Lan thuê ngoài phát triển màn hình HMI, yêu cầu báo giá chỉ dựa trên số màn hình và số tag PLC có thể làm cho giá trông dễ so sánh, nhưng không tạo ra tiêu chí hoàn thành tương đương. Một HMI có thể vận hành phải giúp người dùng nhận biết đúng trạng thái thiết bị, chỉ cho phép thao tác đúng quyền, hướng dẫn phản ứng khi bất thường, hiển thị rõ bằng mọi ngôn ngữ yêu cầu và khôi phục được từ bản sao lưu đã kiểm chứng. Các kết quả đó cần nằm trong cùng một phạm vi nghiệm thu.

Bài viết này chuyển phạm vi trên thành yêu cầu thực tế cho quản lý nhà máy, kỹ sư sản xuất, bảo trì và điều khiển, bộ phận mua hàng cũng như người phê duyệt ở trụ sở Nhật Bản. Nội dung gồm ranh giới phát triển HMI, ma trận RFP, sản phẩm bàn giao, cách so sánh nhà cung cấp trung lập, phép thử FAT/SAT và mô hình khối lượng công việc minh bạch. Đây không phải bảng xếp hạng thương hiệu. Tính năng thay đổi theo model, license, phiên bản phần mềm, giao thức, phần cứng và môi trường triển khai; phải xác minh tương thích chính xác trước khi mua.

Phát triển màn hình HMI công nghiệp thực sự gồm những gì

HMI là Human-Machine Interface, điểm giao tiếp nơi con người nhìn trạng thái thiết bị, ra quyết định và phát lệnh được phép. Vì vậy, phát triển HMI không chỉ là vẽ nút. Phạm vi còn gồm mô hình trạng thái, phân cấp màn hình, ranh giới dữ liệu với PLC, cảnh báo, vai trò người dùng, ngôn ngữ, lịch sử, recipe, sao lưu, kiểm soát thay đổi, đào tạo và nghiệm thu.

Hướng dẫn này xem công việc HMI là vòng đời của giao diện vận hành, từ thiết kế, triển khai, vận hành, thay đổi đến khôi phục—không phải một tập hợp màn hình. Vì thế, bên mua nên quy định ai cần quyết định điều gì, trong kịch bản nào, dùng dữ liệu nào, với quyền nào và kiểm chứng kết quả ra sao—không chỉ hỏi nhà thầu sẽ vẽ bao nhiêu màn hình. Đây là khung mua sắm thực tiễn, không thay thế tiêu chuẩn áp dụng.

Vì sao báo giá theo số màn hình dễ thất bại

Hai dự án cùng có 20 màn hình có thể cần khối lượng rất khác. Một dự án chỉ hiển thị trạng thái; dự án khác có thay recipe, audit trail, ba ngôn ngữ, xem từ xa, trend, phân quyền và khôi phục. Số màn hình không cho biết dự án có bao gồm:

• chỉ vận hành bình thường hay cả chuyển mã, chế độ tay, bảo trì và phục hồi bất thường;
• hai trạng thái chạy/dừng hay cả khởi động, chờ, interlock, lỗi và xác nhận phục hồi;
• chỉ hiện nội dung cảnh báo hay cả mức ưu tiên, nguyên nhân, hậu quả, hành động, quyền xác nhận và lịch sử;
• chủ sở hữu thuật ngữ đa ngôn ngữ, font, nhập liệu, độ dài chuỗi và phê duyệt;
• định nghĩa tag, scale, chất lượng, chu kỳ cập nhật và cách hiển thị dữ liệu cũ;
• source file, quy trình build, license, quản lý phiên bản và thử nghiệm restore.

Giá thấp trên một màn hình không đồng nghĩa tổng chi phí thấp. Phạm vi bị bỏ quên thường quay lại dưới dạng phát sinh, chậm chạy máy, thao tác sai hoặc project không thể khôi phục.

Đặt truy vết từ yêu cầu đến thử nghiệm ở trung tâm RFP

Tài liệu quan trọng nhất của hoạt động mua HMI là chuỗi truy vết:

Kịch bản vận hành → trạng thái thiết bị → đối tượng màn hình → tag PLC → quyền → cảnh báo/hành động → bằng chứng FAT/SAT

Ví dụ với kịch bản “phục hồi sau kẹt băng tải”, hãy liên kết tag phát hiện kẹt, cách hiển thị trạng thái, lý do dừng, điều kiện reset, lệnh chỉ dành cho bảo trì, cảnh báo liên quan và phép thử phục hồi dưới cùng một Requirement ID. Khi điều kiện đổi, nhóm dự án tìm được phạm vi ảnh hưởng. Khi nghiệm thu, bên mua thấy rõ yêu cầu nào đã có bằng chứng.

Ma trận phạm vi HMI dành cho bên mua

RFP hiệu quả phân biệt thông tin nhà máy cung cấp, phần thiết kế nhà tích hợp chịu trách nhiệm và tài liệu hai bên cùng phê duyệt. Có thể dùng ma trận sau làm checklist đầu dự án.

Xác định trạng thái trước khi chọn màu

Một HMI tốt giúp người vận hành hiểu máy đang ở trạng thái nào, vì sao và hành động nào được phép tiếp theo. Hãy xác định sản xuất, chờ, dừng, lỗi, chuẩn bị khởi động, chờ interlock, can thiệp tay, lỗi truyền thông và dữ liệu cũ nếu phù hợp với kịch bản thực tế.

Màu đơn lẻ dễ gây nhầm dưới ánh sáng phản chiếu, chất lượng màn hình khác nhau, khác biệt nhận biết màu và nhiều cảnh báo cạnh tranh. Cần kết hợp màu với hình dạng, nhãn, vị trí và animation được kiểm soát. Giữ trạng thái bình thường yên tĩnh về mặt thị giác, chỉ nhấn mạnh điều kiện cần hành động, rồi ghi quy tắc vào HMI philosophy và style guide.

Thiết kế HMI công nghiệp phải tính đến găng tay và nguy cơ bấm nhầm

Khu vực sản xuất ở Thái Lan có thể có găng tay, nhiệt, bụi, chói sáng, thao tác khi đứng và nhiều ngôn ngữ. Mục chạm quá nhỏ, lệnh nguy hiểm đặt sát nhau hay điều kiện bị giấu dưới vùng cuộn có thể vượt qua review trên bàn nhưng thất bại tại hiện trường. Hãy quy định kích thước và khoảng cách, cách xác nhận, hold-to-act hoặc phê duyệt hai bước khi phù hợp, và ranh giới giữa lệnh HMI với nút vật lý.

HMI không tự thân là một chức năng an toàn. Logic và validation liên quan an toàn phải nằm trong safety system phù hợp và được người đủ năng lực xem xét. HMI có thể truyền đạt trạng thái an toàn nhưng không thay thế mạch an toàn.

Thiết kế cảnh báo HMI để dẫn đến hành động

Danh sách cảnh báo không thể chỉ là danh sách message từ PLC. Cần phân công rõ trách nhiệm đối với sự cần thiết, mức ưu tiên, phản ứng mong đợi, triển khai, kiểm thử, giám sát vận hành, thay đổi và lịch sử. Hướng dẫn này chuyển chuỗi trách nhiệm đó thành yêu cầu RFP và kiểm thử nghiệm thu.

Mỗi cảnh báo tối thiểu cần có:

• ID duy nhất, điều kiện phát sinh và trở về, delay và deadband;
• mức ưu tiên và cơ sở của mức đó;
• hành động mong đợi từ người vận hành;
• nguyên nhân có thể và vị trí kiểm tra;
• hậu quả nếu không hành động;
• vai trò được acknowledgement và bản ghi xác nhận;
• quy tắc shelving, suppression, maintenance mode;
• bước FAT/SAT cho phát sinh, xác nhận, trở về và lịch sử.

Nếu chỉ cần ghi một thay đổi trạng thái, hãy dùng event. Nếu chỉ cung cấp thông tin không cần phản ứng, hãy dùng message. Chỉ dành alarm cho điều kiện đòi hỏi hành động kịp thời; nếu không, cảnh báo quan trọng sẽ chìm trong alarm flood. Alarm master nên được quản lý tách khỏi graphic và lưu lý do thay đổi cùng người phê duyệt.

HMI đa ngôn ngữ cho trụ sở Nhật và người vận hành Thái

Localization không phải thay chuỗi vào phút cuối. Nhãn tiếng Nhật ngắn có thể dài hơn nhiều trong tiếng Thái hay tiếng Anh và tràn khỏi nút, bảng, trend hay popup. Cần thử tổ hợp nguyên âm và dấu thanh tiếng Thái, dấu tiếng Việt và từ ghép dài tiếng Anh bằng chính runtime và font sẽ triển khai.

Glossary được kiểm soát phải gán một thuật ngữ đã duyệt cho mỗi máy, trạng thái và lệnh. Người sử dụng thiết bị tại hiện trường phải tham gia duyệt, không chỉ người dịch ở trụ sở. Hồ sơ bàn giao cần chỉ rõ người duyệt bản dịch, quy trình đổi, ngôn ngữ fallback, cách import/export string và cách đưa chuỗi sửa đổi trở lại source control.

Nghiệm thu đa ngôn ngữ cần gồm:

1. mở mọi màn hình bằng mọi ngôn ngữ, ghi nhận tràn chữ, chồng lấp và key chưa dịch;
2. kiểm tra cấu tạo ký tự Thái và Việt, cùng xử lý search/input nếu có;
3. xác minh ngôn ngữ trong alarm history, trend, recipe, audit log và file PDF/CSV;
4. chuyển ngôn ngữ khi đang vận hành mà không làm hỏng trạng thái hay giá trị nhập dở;
5. đồng bộ thay đổi glossary qua màn hình, hướng dẫn và học liệu trong cùng quản lý phiên bản.

Làm rõ quyền sở hữu PLC, tag và dữ liệu

HMI và PLC liên kết chặt, nhưng ranh giới trách nhiệm mơ hồ sẽ làm quá trình phân tích lỗi bế tắc. Tag dictionary cần có tên logic, địa chỉ PLC, kiểu dữ liệu, đơn vị, scale, chiều đọc/ghi, chu kỳ cập nhật, chất lượng, chủ sở hữu và các màn hình sử dụng. Phân biệt giá trị HMI tính, interlock PLC đảm bảo và recipe đến từ hệ thống cấp trên.

Nếu có sửa PLC, hãy xem source control, online change, rollback, kiểm tra I/O và ảnh hưởng lên máy hiện hữu như một phạm vi riêng. Tham khảo hướng dẫn thuê ngoài phát triển chương trình PLC tại Thái Lan và với thiết bị cũ, kết hợp hướng dẫn thay thế và retrofit PLC để lập kế hoạch tương thích và thời gian dừng.

Khi mất truyền thông, giá trị tốt gần nhất không được trông như giá trị hiện tại. Phải phân biệt stale, bad-quality và disconnected, đồng thời quy định lúc nào khóa lệnh. Đây là yêu cầu bảo vệ quyết định vận hành, không phải lựa chọn thẩm mỹ.

Danh mục sản phẩm bàn giao phát triển HMI

Ghi rõ định dạng, ngôn ngữ, nguồn có thể sửa và người phê duyệt trong phạm vi mua. Chỉ nhận PDF hiếm khi đủ cho thay đổi tương lai.

So sánh nhà cung cấp theo RFP, không theo xếp hạng thương hiệu

Thông tin chính thức của Mitsubishi Electric GOT3000, Rockwell Automation FactoryTalk Optix và Siemens WinCC Unified cho thấy những ví dụ như hiển thị độ phân giải cao, đồ họa đa ngôn ngữ, alarm, quản lý phiên bản, OPC UA, web client, triển khai tập trung và kết nối dữ liệu PLC. Đây là ví dụ, không phải yêu cầu phổ quát hay cam kết cho mọi model. Hãy xác minh model, license, version, protocol và runtime mục tiêu.

Trong buổi demo, hãy yêu cầu xem mất truyền thông, lệnh bị từ chối, chuỗi tiếng Thái dài, tải alarm và khôi phục—không chỉ màn hình tổng quan đẹp ở trạng thái bình thường.

Đưa truy cập từ xa và an ninh mạng vào RFP ngay từ đầu

Nếu HMI kết nối mạng nhà máy, historian, web client, cloud hoặc hỗ trợ từ xa, phạm vi đã chạm ranh giới IT/OT. Nguồn thực hành khuyến nghị ICS công khai của CISA đề cập defense in depth, quản lý bản vá, ứng phó sự cố, ngôn ngữ mua sắm an toàn và truy cập từ xa an toàn. RFP tối thiểu cần quy định:

• tài khoản định danh và vai trò, bao gồm cách kiểm soát tài khoản quản trị dùng chung;
• phê duyệt remote access, giới hạn thời gian, MFA và bản ghi phiên;
• chiều truyền thông và port được phép giữa HMI, PLC, historian và hệ thống trên;
• quy trình USB/file transfer, kiểm tra mã độc và application allow-list;
• trách nhiệm patch và môi trường thử của OS, runtime, project;
• mã hóa, vị trí, thời gian giữ và chủ sở hữu phục hồi backup;
• liên lạc sự cố, bảo toàn bằng chứng, cô lập và phục hồi.

Cho phép remote control hay chỉ remote viewing không chỉ là quyết định tiện lợi. Cần xem xét hazard, thiết kế an toàn, người xác nhận tại chỗ, độ trễ, hành vi khi ngắt và phê duyệt đủ năng lực.

Phép thử nghiệm thu FAT/SAT cho HMI

FAT xác minh thiết kế trong môi trường phát triển hoặc trước giao hàng. SAT xác minh giải pháp tích hợp với PLC, mạng, thiết bị, tài khoản và điều kiện vận hành thực tế. Phải thống nhất ranh giới, test data, simulator, người chứng kiến, định dạng bằng chứng và quy tắc retest trước khi trao hợp đồng.

Đưa phục hồi bất thường vào tiêu chí đạt chính thức

Demo vận hành bình thường không bộc lộ điểm yếu. Phải kiểm tra đánh dấu stale data, hành vi restart, recipe dở dang, lịch sử acknowledgement và phục hồi không gây tự động khởi động thiếu an toàn. Mọi phép thử phải theo đánh giá rủi ro và phương pháp đã duyệt.

Backup không đạt chỉ vì có file. Trên workstation hay máy ảo sạch, hãy khôi phục phần mềm, license, cài đặt truyền thông và project, rồi tái hiện startup, edit, build và download khi an toàn. Không để phục hồi phụ thuộc vào trí nhớ của một kỹ sư.

Để tích hợp bằng chứng PLC, HMI, I/O và máy, tham khảo thiết kế điều khiển trình tự và FAT và dùng cùng Requirement ID xuyên suốt.

Mô hình khối lượng giả định minh bạch, không phải giá thị trường

Không có giá thị trường phổ quát cho phát triển HMI. Khối lượng thay đổi theo tag, kịch bản, rationalization cảnh báo, ngôn ngữ, runtime, giao tiếp PLC, recipe, báo cáo, FAT/SAT, đào tạo, tài liệu và bàn giao source. Phép tính sau là giả định lập kế hoạch, không phải báo giá thị trường hay báo giá TOMAS TECH.

Giả định một dây chuyền mới, 12 màn hình chính, 8 popup, 300 tag PLC, 60 cảnh báo, ba ngôn ngữ, chưa có style guide, một FAT và một SAT.

Con số 56 người-ngày chỉ là giả định. Điều cần so sánh là mỗi nhà thầu bao gồm công việc gì, đầu vào nào bên mua chịu trách nhiệm, và retest hay thời gian chờ hiện trường được tính ra sao. Chuyển báo giá “20 màn hình” thành các gói trên sẽ làm rõ khác biệt.

Khi có thay đổi, đánh giá theo Requirement ID và màn hình, tag, ngôn ngữ, alarm, tài liệu, retest bị ảnh hưởng. Sửa nhãn và đổi state transition hay permission không phải cùng một loại công việc.

Rủi ro dự án đặc thù tại nhà máy Thái Lan

Phê duyệt ba bên: trụ sở, hiện trường Thái và nhà tích hợp

Khi trụ sở định chính sách, nhà máy Thái nghiệm thu và nhà tích hợp thực hiện, phê duyệt mơ hồ gây chậm. Gán người soạn, người review và người duyệt cho từng gate: yêu cầu, glossary, prototype, alarm, FAT và SAT. Ví dụ trụ sở sở hữu chính sách máy, operator sở hữu usability, controls sở hữu ranh giới PLC, IT sở hữu mạng và tài khoản.

Thời gian dừng hạn chế cho thử nghiệm thật

Dây chuyền hiện hữu không thể tự do tạo mọi lỗi. Hãy thống nhất cửa sổ dừng, phép thử bằng simulator thay thế, rủi ro còn lại của test chưa thực hiện và điều kiện retest sau đó. Online change phải có backup, review khác biệt, rollback và phê duyệt hiện trường.

Rủi ro license và tài khoản bảo trì

Project có thể chạy trên PC nhà phát triển nhưng thiếu runtime, driver, web client, historian hay language license tại nhà máy. Ghi mã sản phẩm, số lượng, chủ hợp đồng, kỳ gia hạn, khả năng offline và chuyển sang thiết bị thay thế trong build/version manifest. Không để recovery phụ thuộc duy nhất vào tài khoản cá nhân của nhân viên nhà thầu.

Diễn giải điều kiện về BOI Thái Lan

Investment Promotion Guide hiện hành của BOI Thái Lan liệt kê các hoạt động liên quan máy móc hoặc thiết bị tự động hóa có thiết kế kỹ thuật, tích hợp hệ thống tự động hóa và cấu hình hệ thống điều khiển. Điều này không có nghĩa dự án HMI riêng lẻ tự động đủ điều kiện. Pháp nhân, hoạt động, thiết bị, thời điểm nộp và dữ kiện khác cần được xác minh từng trường hợp với BOI hoặc cố vấn thích hợp.

Trình tự thực hiện dự án HMI

1. Quan sát công việc và xác định kịch bản: gồm ca sản xuất, chuyển mã, vệ sinh, bảo trì và phục hồi.
2. Phê duyệt HMI philosophy: thống nhất state, hierarchy, màu, component, lệnh, alarm và ngôn ngữ bằng mẫu.
3. Tạo traceability và prototype: nối requirement, tag, permission, alarm, test trước khi triển khai toàn bộ.
4. Triển khai lặp: bắt đầu từ component dùng lại và kịch bản đại diện, review với người dùng ngôn ngữ hiện trường.
5. Thực hiện FAT: mô phỏng normal, abnormal, communication, permission, language và recovery.
6. Thực hiện SAT: dùng PLC, I/O, mạng, tài khoản và điều kiện hiện trường thật.
7. Đào tạo và bàn giao: tách operator, bảo trì, quản trị, change control; trình diễn restore.
8. Quản lý thay đổi: lưu Requirement ID, version, lý do, phê duyệt và bằng chứng retest sau chạy máy.

FAQ về phát triển màn hình HMI

Phát triển màn hình HMI có chỉ là thiết kế bố cục touch panel không?

Không. Bố cục chỉ là một phần. Phạm vi đầy đủ gồm kịch bản vận hành, trạng thái, tag PLC, quyền, cảnh báo, ngôn ngữ, lịch sử, remote access, backup, FAT/SAT, đào tạo và source có thể chỉnh sửa.

Có thể so sánh chi phí phát triển HMI theo giá mỗi màn hình không?

Không đáng tin nếu dùng riêng. Hành vi tag, dynamic object, recipe, báo cáo, alarm, localization, quyền, truyền thông, test và tài liệu có thể làm cùng số màn hình cần nỗ lực khác nhau. Hãy so sánh work package, giả định, ngoại lệ, retest và hỗ trợ hiện trường.

Thiết kế HMI công nghiệp nên bắt đầu từ đâu?

Hãy xác định người dùng, kịch bản vận hành, trạng thái thiết bị, lệnh được phép và hành động bất thường trước màu hay widget. Sau đó mới thiết kế hierarchy, navigation, reusable object và visual rule.

Sản phẩm bàn giao thiết kế cảnh báo HMI cần có gì?

Yêu cầu alarm master với cơ sở ưu tiên, nguyên nhân, hậu quả, phản ứng người vận hành, quyền acknowledgement, suppression rule, history, bước FAT/SAT và change record. Cần rationalization xem từng alarm có thực sự cần hành động hay không.

Có nên thuê cùng một công ty phát triển PLC và HMI?

Một công ty có thể đơn giản hóa quyền sở hữu nhưng không bắt buộc. Nếu tách nhà cung cấp, hãy quy định state model, tag dictionary, cause-and-effect, version control, integration test và quyền xử lý sự cố trong RFP.

Khi hỗ trợ chạy máy, FAT hay SAT quan trọng hơn?

Cần cả hai. FAT phát hiện lỗi thiết kế khi còn dễ sửa; SAT xác minh máy, mạng, tài khoản và người vận hành thật. Chỉ SAT sẽ dồn lỗi vào thời gian dừng; chỉ FAT sẽ bỏ lỡ khác biệt tích hợp hiện trường.

HMI có thể dùng như chức năng an toàn không?

HMI có thể hỗ trợ nhận biết nhưng không thay safety system phù hợp. Logic, mạch, chức năng dừng và validation liên quan an toàn phải được người đủ năng lực review theo tiêu chuẩn áp dụng và đánh giá rủi ro.

Nhận source file có nghĩa bàn giao hoàn tất chưa?

Chưa. Bên mua còn cần phần mềm và phiên bản, license, driver, cài đặt truyền thông, hướng dẫn build, checksum, backup và clean restore đã trình diễn. Kỹ sư bên mua nên tự mở, build và thực hiện một thay đổi nhỏ có kiểm soát.

Kết luận: nghiệm thu giao diện vận hành, không phải một bộ màn hình

Chất lượng phát triển màn hình HMI không thể đo bằng vẻ ngoài hay số lượng màn hình. Hãy truy vết kịch bản qua trạng thái, đối tượng màn hình, tag PLC, quyền, cảnh báo, ngôn ngữ, phục hồi và bằng chứng thử nghiệm. Chứng minh hành vi bất thường, localization, mất truyền thông, restart và clean backup restore trong FAT/SAT. RFP cũng phải định nghĩa sản phẩm bàn giao, ranh giới trách nhiệm, phiên bản, license, sở hữu source và quản lý thay đổi để mọi nhà thầu được so sánh trên cùng cơ sở.

Nếu đang lên kế hoạch HMI cho nhà máy tại Thái Lan, bạn có thể trao đổi ngay cả khi screen inventory và tag list chưa hoàn chỉnh. TOMAS TECH có thể hỗ trợ cấu trúc kịch bản hiện trường, ranh giới RFP và tiêu chí FAT/SAT. Hãy gửi loại thiết bị, PLC hiện hữu, ngôn ngữ cần dùng và thời điểm dự kiến chạy máy qua trang liên hệ tiếng Việt.

Nguồn tham khảo chính

• Mitsubishi Electric GOT3000
• Rockwell Automation FactoryTalk Optix
• Siemens WinCC Unified for Industrial Edge
• CISA ICS Recommended Practices
• Thailand BOI Investment Promotion Guide