Phát triển màn hình HMI: chuyển sang PC công nghiệp và FAT/SAT

Phát triển màn hình HMI nếu được xem xét trong bối cảnh chuyển từ touch panel tích hợp truyền thống sang PC công nghiệp, thì trọng tâm không nằm ở giao diện hiển thị mà ở phương thức triển khai, liên kết tag PLC, cảnh báo và log, runtime, bảo trì hệ điều hành, sao lưu, phân định trách nhiệm, và FAT/SAT. Đặc biệt với đội ngũ kỹ thuật sản xuất và mua sắm tại các nhà máy ở Thái Lan, nếu các điểm này không được làm rõ ngay từ giai đoạn RFP, gánh nặng bảo trì sau khi chạy máy rất dễ rơi vào tình trạng phụ thuộc nhà cung cấp.

Bài viết này tập trung vào việc đặc tả để triển khai, bảo trì và nghiệm thu, đồng thời so sánh giữa các lựa chọn: “nên dùng HMI/SCADA nền tảng PC công nghiệp”, “tiếp tục dùng panel tích hợp”, hay “thin client + máy chủ trung tâm” khi nâng cấp thiết bị hiện có hoặc đưa dây chuyền mới vào vận hành.

Lưu ý, các nội dung về thiết kế giao diện màn hình như chuyển trang, phối màu, biểu tượng, khả năng quan sát của operator, hay phân tầng chi phí không thuộc phạm vi bài này. Vui lòng tham khảo bài riêng về thiết kế màn hình HMI touch panel. Bài viết này chỉ tập trung vào kiến trúc triển khai và vận hành bảo trì.

Mục tiêu và phạm vi

Mục tiêu của bài viết

Mục tiêu của bài viết là giúp đội ngũ kỹ thuật sản xuất và mua sắm tại các nhà máy ở Thái Lan có thể chuyển trực tiếp các nội dung dưới đây vào thảo luận nội bộ hoặc RFP khi xem xét chuyển HMI sang PC công nghiệp:

• Làm rõ các trục so sánh để lựa chọn phương án
• Phân rã rõ phạm vi trách nhiệm cần giao cho nhà cung cấp
• Trực quan hóa những gì cần kiểm tra trong FAT/SAT
• Định nghĩa quy trình bảo trì, sao lưu, cập nhật kèm quản lý thay đổi
• Xây dựng cấu hình ít rủi ro đổ vỡ khi cải tạo sau này hoặc mở rộng đa ngôn ngữ

Phạm vi được đề cập trong bài

Bài viết đề cập các lĩnh vực sau:

• Triển khai HMI runtime chạy trên PC công nghiệp
• Mapping tag PLC
• Alarm, event, history, log
• Quyền người dùng, chuyển đổi ngôn ngữ, ghi nhận thao tác phục vụ truy vết
• Quản lý phiên bản OS, license, runtime
• Backup / restore
• Hành vi khi khôi phục sau mất điện, khi PLC offline
• Góc nhìn thử nghiệm FAT/SAT
• Đặc tả mua sắm, RFP, phân định trách nhiệm

Phạm vi không đề cập

• Lý thuyết UI/UX chung cho màn hình
• Lý thuyết DX mang tính trừu tượng
• Thiết kế coi HMI là chức năng an toàn

Điểm đặc biệt quan trọng là: HMI không phải là chức năng an toàn. Các chức năng liên quan đến dừng an toàn, interlock, SIL/PL phải được đảm bảo ở phía safety PLC hoặc mạch an toàn. HMI có thể là giao diện hiển thị trạng thái hoặc thao tác, nhưng không phải điều kiện để chức năng an toàn được xác lập.

Ngoài ra, ISA-101 là khung tham chiếu theo vòng đời cho thiết kế, triển khai và quản lý HMI, chứ không phải chứng nhận sản phẩm. ISA-101

Tương tự, IEC 62443-2-1 là tài liệu về chương trình an ninh phía asset owner, không có nghĩa là bảo đảm “chứng nhận” cho một sản phẩm cụ thể. IEC 62443-2-1

3 kiến trúc runtime

Phương thức triển khai HMI nên được xem xét từ góc độ phân bổ trách nhiệm vận hành và vị trí phát sinh lỗi. Dưới đây là 3 mô hình phổ biến trong sản xuất.

1. Panel PC tích hợp / panel HMI

Đây là cấu hình mà touch panel và runtime được tích hợp ngay trên thiết bị đầu cuối tại hiện trường.

Phù hợp khi

• Điều khiển khép kín cho máy đơn lẻ
• Muốn vận hành độc lập theo từng máy
• Muốn tách biệt mạng rõ ràng
• Tiêu chuẩn của nhà cung cấp đang thống nhất theo panel tích hợp

Ưu điểm

• Cấu hình dễ hiểu
• Dễ cắt phạm vi trách nhiệm theo từng máy
• Giảm phụ thuộc vào mạng và máy chủ

Điểm cần lưu ý

• Cần backup và quản lý phiên bản cho từng terminal
• Khi số lượng màn hình hoặc yêu cầu lưu dữ liệu tăng lên, quản lý cấu hình dễ trở nên phức tạp
• Khả năng thay thế khi đổi model thường phụ thuộc mạnh vào từng dòng thiết bị

2. Chạy cục bộ trên PC công nghiệp

HMI runtime chạy trên một PC công nghiệp lắp gần máy hoặc dây chuyền, kết nối với monitor hiện trường hoặc màn hình cảm ứng.

Phù hợp khi

• Muốn giám sát xuyên suốt nhiều PLC và thiết bị ngoại vi
• Số lượng màn hình, log, recipe, báo cáo ở mức tương đối nhiều
• Muốn tận dụng runtime hệ Windows và tính mở rộng
• Muốn chuẩn hóa phụ tùng bảo trì và vận hành lưu trữ

Ưu điểm

• Dễ tích hợp màn hình, log và các điểm kết nối
• Dễ thiết kế backup, thay ổ đĩa, triển khai image
• Linh hoạt hơn cho việc bổ sung chức năng trong tương lai

Điểm cần lưu ý

• Cần có quyết định rõ về bảo trì OS, license và patch
• Cần đánh giá kỹ độ phù hợp giữa phần cứng và môi trường hiện trường
• Nếu không làm rõ phân định trách nhiệm khi chạy thử, sẽ khó tách bạch lỗi phía PLC và lỗi phía HMI

3. Thin client / máy chủ trung tâm

Tại hiện trường chỉ dùng terminal mỏng hoặc client dạng trình duyệt, còn HMI runtime hoặc nền tảng visualization được tập trung về phía server. Ví dụ, mô hình workstation/client hoặc phân phối tập trung sẽ khác nhau tùy sản phẩm. Ignition Perspective Workstation

Phù hợp khi

• Muốn quản lý nhiều dây chuyền trên một nền tảng chung
• Muốn thống nhất backup tập trung và quản lý quyền
• Có kế hoạch tích hợp IT/OT hoặc triển khai đa địa điểm

Ưu điểm

• Dễ quản lý tập trung
• Khôi phục khi thay terminal thường đơn giản hơn
• Phù hợp triển khai đa terminal

Điểm cần lưu ý

• Mức phụ thuộc vào mạng và tính sẵn sàng của server tăng lên
• Phân định trách nhiệm giữa OT và IT dễ phức tạp hơn
• Nếu không định nghĩa trước yêu cầu vận hành cục bộ khi server dừng, vận hành thực tế tại hiện trường sẽ trở nên mơ hồ

Phương án tối ưu phụ thuộc vào cách đặt trách nhiệm cho thiết bị

Không có chuyện “PC công nghiệp luôn tốt hơn”. Trong quyết định mua sắm, nên chọn phương án có thể trả lời rõ các câu hỏi sau:

• Khi dây chuyền dừng, ai là người khôi phục tại hiện trường?
• PLC có thể tự vận hành độc lập không?
• Khi mất kết nối mạng có cần tiếp tục thao tác không?
• Cải tạo trong tương lai là theo từng máy hay trên toàn nhà máy?
• Chủ thể chính của backup là bộ phận thiết bị hay bộ phận IT?

Khảo sát hiện trường

Trước khi quyết định phương án triển khai, cần thu thập một số thông tin qua khảo sát thực địa. Điểm thường bị bỏ sót trên bàn giấy không phải là hiệu năng, mà là thực tế kết nối và tuyến bảo trì.

Các hạng mục tối thiểu cần xác nhận khi khảo sát hiện trường

Cấu hình điều khiển

• Hãng PLC, model CPU, firmware
• Giao thức truyền thông
• Số lượng tag hiện có, dư địa mở rộng sau này
• Nơi đang định nghĩa alarm hiện hữu (phía PLC, phía HMI, chỉ có trên giấy, v.v.)
• Nơi lưu recipe hoặc cài đặt theo mã hàng

Vận hành HMI

• Vị trí lắp terminal thao tác
• Ngôn ngữ cần dùng tại hiện trường
• Các cấp quyền và quy trình phê duyệt
• Cách xác nhận alarm theo từng ca
• Có hay không việc xuất báo cáo ngày hoặc CSV

Hạ tầng

• Chất lượng nguồn điện, có sụt áp chớp nhoáng hay không
• Có cần UPS hay không
• Topology mạng, VLAN, đơn vị quản lý
• Có cho phép kết nối bảo trì từ xa hay không
• Nhiệt độ hiện trường, bụi, rung, tích nhiệt trong tủ điện

Tổ chức bảo trì

• Bộ phận nào tại nhà máy Thái Lan xử lý bước đầu
• Phạm vi tham gia của IT trụ sở
• Phạm vi onsite support của nhà cung cấp
• Chính sách lưu kho phụ tùng thay thế
• Người phê duyệt khi sửa đổi phần mềm

Những điểm dễ bị bỏ sót tại nhà máy ở Thái Lan

• Câu alarm có nhất quán giữa tiếng Anh, tiếng Nhật và tiếng Thái hay không
• Có giả định rằng ca đêm sẽ tự đăng nhập OS hoặc khởi động lại service hay không
• Sau khi có điện lại, hệ thống tự phục hồi hay dừng ở màn hình xác nhận
• Bộ phận bảo trì tại chỗ có được kỳ vọng tự restore backup hay không
• Bộ phận quản trị mạng nhà máy có quản lý terminal OT như tài sản PC thông thường hay không

Bảng yêu cầu

Khi chuyển yêu cầu thành đặc tả, nên tránh viết thành câu mô tả mơ hồ gửi cho nhà cung cấp. Hiệu quả hơn là lập bảng theo hạng mục yêu cầu, mục đích, cách xác minh và chủ thể trách nhiệm.

Ví dụ bảng yêu cầu

Những cách diễn đạt mơ hồ cần tránh trong đặc tả

• “Sử dụng OS mới nhất”
• “Thực hiện các biện pháp bảo mật phù hợp”
• “Backup đầy đủ cần thiết”
• “Hiển thị tốc độ cao”
• “Có thể mở rộng trong tương lai”

Các cụm từ này thuận tiện lúc chốt đơn hàng nhưng rất dễ gây tranh cãi khi FAT/SAT hoặc bảo trì. Thay vào đó, phải viết đến mức ai xác minh cái gì, bằng cách nào.

PLC tag và alarm

Trong HMI nền tảng PC công nghiệp, lỗi phát sinh nhiều nhất thường không nằm ở giao diện, mà ở sai lệch ý nghĩa tag và sự mơ hồ trong vận hành alarm.

Những điều cần quyết định trong thiết kế tag PLC

Nguồn chịu trách nhiệm của tag

Trước hết cần làm rõ: “ai định nghĩa ý nghĩa của giá trị này?”

• Tag do phía PLC định nghĩa gốc
• Tag được HMI dẫn xuất để hiển thị
• Tag mà HMI xử lý giá trị tính toán, chuyển chuỗi, đổi đơn vị
• Tag đến từ master dùng chung cho thiết bị

Nếu điểm này mơ hồ, khi PLC thay đổi, HMI có thể vẫn giữ ý nghĩa cũ và gây sự cố.

Quy tắc đặt tên và mapping

Bảng mapping tag nên tối thiểu có các cột sau:

Xử lý malformed/stale tag

Trong vận hành thực tế, ngoài mất truyền thông đơn thuần, còn thường gặp vấn đề sai định dạng hoặc giữ lại giá trị cũ.

1. malformed tag

• Không khớp kiểu dữ liệu
• Giá trị tương đương NULL ngoài dự kiến
• Chuỗi vượt quá độ dài cho phép
• Định dạng ngày giờ bị lỗi

2. stale tag

• Sau khi PLC dừng, HMI vẫn tiếp tục hiển thị giá trị cuối cùng
• Trước khi truyền thông kết nối lại, giá trị cũ lại trông như giá trị mới
• Không thấy thời điểm cập nhật nên operator hiểu nhầm là tình trạng hiện tại

Vì vậy, trong RFP nên đưa vào:

• Cách hiển thị quality bit của truyền thông
• Cách xử lý thời điểm cập nhật cuối cùng
• Quy tắc hiển thị khi giá trị đã cũ
• Điều kiện cấm ghi khi có bất thường
• Hành vi màn hình khi PLC offline

Yêu cầu triển khai khi PLC offline

Ngay cả khi PLC offline, vẫn nên thiết kế sao cho ứng dụng HMI không bị sập mà có thể thể hiện:

• Đang mất truyền thông
• Thời điểm cập nhật thành công cuối cùng
• Trạng thái không cho ghi
• Cấm ACK hoặc giới hạn ACK
• Local log sẽ tiếp tục hay dừng lại

Cần tránh tình trạng “không thấy PLC = HMI bị treo”. Cách tiếp cận chung về runtime và cấu hình visualization cũng được tài liệu hãng mô tả theo vòng đời tag và hiển thị. Siemens Engineering Guideline Siemens WinCC Unified Visualizing Processes

Những điều cần quyết định trong thiết kế alarm

Bài viết này không bàn về thiết kế giao diện alarm mà về cách triển khai và vận hành alarm.

Nguồn định nghĩa alarm

• Điều kiện được đánh giá trong PLC rồi gửi trạng thái sang HMI
• Ngưỡng được đánh giá ở phía HMI
• Điều kiện được gom và đánh giá ở server cấp trên

Không phải cách nào cũng như nhau; cần quyết định đâu là chủ thể phán định đúng/sai cuối cùng. Với alarm quan trọng liên quan đến dừng thiết bị, thông thường đánh giá ở phía PLC sẽ rõ trách nhiệm hơn. Ngược lại, alarm phụ để hiển thị hoặc event phục vụ phân tích bảo trì vẫn có thể đặt ở phía HMI.

Trách nhiệm ACK

Với xác nhận alarm, tối thiểu cần định nghĩa:

• Ai có thể ACK
• ACK là cục bộ trên terminal hay dùng chung cho tất cả terminal
• Có cho ACK khi nguyên nhân chưa được xử lý xong hay không
• Sau khi phục hồi thì tự xóa hay lưu lịch sử
• Cần lưu lại thao tác nào trong log

Quyền hạn và khả năng truy vết

• Operator chỉ được xem
• Tổ trưởng được ACK
• Engineer có thể suppress / disable
• Chỉ admin mới được thay đổi cài đặt

Việc tách role như vậy cần được định nghĩa bằng quyền thao tác và bản ghi, không chỉ bằng cách hiển thị trên màn hình.

Chọn phần cứng PC và hệ điều hành

Khi chuyển sang PC công nghiệp, điều quan trọng không phải là “chọn PC hiệu năng cao”, mà là phù hợp với điều kiện hiện trường và cách phục hồi.

Cách tiếp cận khi chọn phần cứng

Điều kiện lắp trong tủ / ngoài tủ

• Vị trí lắp đặt
• Thông gió trong tủ
• Khoảng cách đến nguồn nhiệt
• Có thể bảo trì lọc gió hay không
• Tuyến đi dây
• Mức độ gần nguồn rung

Lưu trữ

• Có dùng SSD hay không
• Phương thức backup image
• Quy trình thay thế
• Tính tương thích với máy dự phòng

SSD hiện được dùng phổ biến trong công nghiệp, nhưng vẫn cần xác nhận ảnh hưởng của nhiệt phát sinh, ghi liên tục, và môi trường nhiệt trong tủ điện. Vì vậy trong đặc tả không chỉ nên ghi có dùng SSD hay không, mà còn phải ghi cả cách xác minh vận hành trong trạng thái tích nhiệt.

UPS

Việc có cần UPS hay không không nên chỉ nhìn như biện pháp chống mất điện, mà nên tách theo các mục tiêu:

• Muốn tránh hỏng OS khi mất điện chớp nhoáng
• Muốn đóng log đúng cách
• Điều khiển vẫn do PLC tiếp tục, chỉ cần bảo vệ phần HMI
• Cần làm rõ quan hệ với trình tự dừng an toàn

Nói cách khác, UPS không phải câu chuyện “có / không”, mà là xác định muốn bảo vệ cái gì khi mất nguồn.

Những điều cần quyết định khi chọn OS

• Edition của OS
• Ai giữ quyền local administrator
• Có cho phép auto login hay không
• Thành phần nào tự khởi động
• Cách đồng bộ thời gian
• Giới hạn sử dụng USB
• Cách xử lý event log
• Ai là người quyết định áp dụng patch

Cập nhật OS không đồng nghĩa “càng mới càng an toàn”. Trong môi trường OT, nguyên tắc là đánh giá dưới cơ chế quản lý thay đổi rồi mới quyết định có áp dụng hay không. Cách tổ chức theo chương trình quản lý an ninh của asset owner có thể tham chiếu IEC 62443-2-1. IEC 62443-2-1

Cách xử lý các điểm riêng theo model

Nếu cần ghi model của hãng sản xuất, phải nêu rõ đó là thông tin đặc thù theo model.

Ví dụ, thông số và điều kiện lắp đặt của fanless industrial PC là khác nhau theo từng model. Thông tin của Beckhoff C6525-0060 chỉ áp dụng cho model đó. Beckhoff C6525-0060

Điều rút ra không phải là “fanless thì dùng ở đâu cũng ổn”, mà là phải xác nhận mức phù hợp môi trường cho từng model ứng viên.

Các hạng mục kiểm tra về môi trường, nhiệt và nguồn điện

Trong RFP và thử nghiệm, nên ghi rõ:

• Vị trí đo nhiệt độ trong tủ
• Cách xác minh nhiệt độ CPU / storage dưới tải
• Hành vi của runtime khi UPS chuyển nguồn
• Kiểm tra phản hồi màn hình sau khi chạy liên tục thời gian dài
• Xác minh trình tự phục hồi từ mất nguồn đến có điện lại
• Xác minh quy trình restore sau khi thay SSD

Bảo mật và vòng đời

Bảo mật HMI không được quyết định chỉ bởi việc sản phẩm có hay không có “chứng nhận”. Điều quan trọng tại hiện trường là ai được thay đổi, cập nhật khi nào, và rollback bằng cách nào.

Định nghĩa bảo mật qua vận hành

IEC 62443-2-1 đề cập chương trình an ninh phía asset owner. IEC 62443-2-1

Ngoài ra, các khuyến nghị cho ICS của CISA cũng nhấn mạnh các điểm mang tính vận hành như kiểm kê tài sản, phân tách mạng, quản lý thay đổi, sao lưu và chuẩn bị phục hồi. CISA ICS Recommended Practices

Những nội dung vận hành cần định nghĩa cho HMI / PC công nghiệp

Quản lý account

• Cách xử lý account dùng chung
• Ai lưu giữ mật khẩu admin
• Thời hạn hiệu lực của account bảo trì do vendor dùng
• Quy trình cắt quyền khi nhân sự nghỉ việc hoặc chuyển vị trí

Quản lý thay đổi

• Ai đề xuất áp dụng OS patch
• Môi trường kiểm chứng cho cập nhật runtime
• Ai phê duyệt sửa lỗi khẩn cấp
• Quy trình rollback

Backup

• System image
• File project HMI
• Recipe / file cấu hình
• Thông tin license
• Dữ liệu log / history

Đây không phải là cùng một loại backup. Về thực tế nên tách theo mục tiêu phục hồi.

Tránh arbitrary updates

Sai lầm thường gặp tại nhà máy là nhân sự bảo trì hoặc IT cập nhật với thiện ý nhưng làm mất đồng bộ runtime hoặc driver.

Vì vậy trong đặc tả không nên chỉ viết “cấm cập nhật tùy ý”, mà nên viết rõ: chỉ cho phép cập nhật theo quy trình quản lý thay đổi.

Quản lý vòng đời

• Chính sách chuyển đổi khi OS hết hỗ trợ
• Thời gian cố định phiên bản runtime
• Điều kiện cấp lại license
• Quy trình áp image cho máy thay thế
• Quy trình thay sang model kế nhiệm

Vòng đời không kết thúc khi bàn giao thiết bị. Với HMI chạy trên PC công nghiệp, cập nhật phần cứng, OS, runtime và thay đổi PLC thường đến vào các thời điểm khác nhau, nên cần xác định trước ai ra quyết định cải tiến, khi có trigger nào.

Kế hoạch chuyển đổi

Khi chuyển từ panel tích hợp sang PC công nghiệp, không thể chỉ dừng ở việc chuyển màn hình. Kế hoạch chuyển đổi phải được nhìn theo 4 lớp: kết nối, chức năng, bảo trì, và duy trì vận hành.

Các bước chuyển đổi theo giai đoạn

1. Rà soát tài sản hiện tại

• Danh sách màn hình hiện có
• Danh sách tag đang dùng
• Danh sách alarm
• Recipe / mục cài đặt
• Quyền người dùng
• Tài nguyên ngôn ngữ
• Phương thức backup

2. Làm rõ các điểm không tương thích

• Khác biệt driver truyền thông
• Khác biệt kiểu tag
• Khác biệt đặc tả lịch sử alarm
• Khác biệt font và hiển thị đa ngôn ngữ
• Khác biệt định dạng file recipe
• Khác biệt mô hình license

3. Kiểm chứng song song

• Kiểm tra trước chỉ riêng kết nối PLC
• Kiểm tra trước chỉ các alarm chính
• Kiểm tra trước chỉ khôi phục sau mất điện
• Kiểm tra trước chỉ nơi lưu log

4. Quyết định phương án chuyển đổi

• Chuyển đổi đồng loạt
• Chuyển đổi theo từng máy
• Chuyển đổi trong thời gian dừng dây chuyền
• Chuyển đổi có giai đoạn chạy song song với HMI cũ

Những điểm dễ thất bại khi chuyển đổi

Mang nguyên tag cũ sang

Có những tag ở HMI cũ vẫn “đủ dùng”, nhưng khi gom vào nền tảng PC có thể xung đột hoặc trùng lặp. Khi chuyển đổi, nên chuẩn hóa lại từ điển tag một lần để thuận lợi cho các bước sau.

Chỉ dịch nội dung alarm là xong

Với đa ngôn ngữ, không chỉ câu hiển thị mà cả mô tả quyền thao tác, thông báo phục hồi, ngữ cảnh mã lỗi cũng phải được kiểm tra.

Để test backup đến cuối cùng

Điều quan trọng nhất nhưng thường bị để lại sau là hỏng thì có khôi phục được không. Trong kế hoạch chuyển đổi, nên chốt chính sách phục hồi trước cả kiểm tra chức năng.

Cách tiếp cận liên quan đến triển khai phần mềm

Nếu không nhìn HMI như một khối tách biệt mà xem cùng với liên kết PLC, triển khai trên PC, xử lý dữ liệu và khả năng bảo trì của toàn bộ phần mềm thiết bị, việc tổ chức yêu cầu sẽ dễ hơn. Có thể tham khảo thêm bài viết liên quan về phát triển phần mềm máy móc.

Phân định trách nhiệm với nhà cung cấp

Trong mua sắm, điều quan trọng nhất không hẳn là chọn vendor nào, mà là cách viết phân định trách nhiệm. Nếu phần này mơ hồ, khi chạy thử sẽ dễ xảy ra tình trạng đùn đẩy giữa “lỗi PLC”, “lỗi HMI”, “lỗi mạng”.

Mẫu phân định trách nhiệm khuyến nghị

Nhà cung cấp HMI

• Xây dựng HMI runtime
• Triển khai màn hình
• Mapping tag
• Cấu hình alarm và history
• Triển khai quyền người dùng
• Tài liệu backup / restore
• Chuẩn bị tài liệu thực hiện FAT

Nhà cung cấp PLC hoặc bộ phận điều khiển

• Định nghĩa biến PLC
• Logic đánh giá alarm
• Điều kiện cho phép ghi
• Xác nhận kết nối truyền thông
• Đảm bảo an toàn khi PLC dừng

Chủ sở hữu thiết bị

• Phê duyệt cấu trúc quyền
• Phê duyệt nội dung ngôn ngữ
• Quyết định yêu cầu giữ log
• Quyết định chính sách áp dụng patch
• Chứng kiến SAT và quyết định nghiệm thu

Phụ trách hạ tầng IT/OT

• Thiết kế IP
• Có/không cho join domain
• Đồng bộ thời gian
• Chính sách kết nối từ xa
• Bảo trì server / storage

Những điểm cần ghi thành văn bản trong phân định trách nhiệm

• Trách nhiệm hiển thị HMI khi PLC offline
• Phạm vi tác động khi mất mạng
• Ai là đầu mối phân tích ban đầu khi OS lỗi
• Trách nhiệm khôi phục cấu hình khi mất license
• Trách nhiệm phê duyệt lỗi dịch thuật
• Đầu mối sửa lỗi được phát hiện trong FAT

Hồ sơ bàn giao tài liệu

Trong điều kiện nghiệm thu, tối thiểu nên có:

• Sơ đồ cấu hình hệ thống
• Bảng mapping tag
• Danh sách alarm
• Danh sách user role
• Hướng dẫn backup
• Hướng dẫn restore
• Danh sách phiên bản
• Thông tin lưu giữ license
• Biên bản FAT
• Biên bản SAT
• Điều kiện bàn giao source / project

Mẫu RFP

Dưới đây là ví dụ các mục RFP mà bộ phận mua sắm có thể dùng trực tiếp. Có thể phát hành dưới dạng bảng nếu cần.

1. Tổng quan dự án

• Tên thiết bị mục tiêu
• Lắp mới / nâng cấp / di dời
• Điều kiện vận hành
• Thời gian cho phép dừng để chuyển đổi
• Ngôn ngữ sử dụng

2. Phạm vi đề xuất

• HMI runtime
• PC công nghiệp hoặc panel
• Cấu hình truyền thông
• Triển khai màn hình
• Alarm / log
• Quản lý người dùng
• FAT/SAT
• Đào tạo
• Bảo trì

3. Nội dung bắt buộc trong hồ sơ đề xuất

• Kiến trúc thực thi
• Cấu hình phần cứng
• Cấu hình OS
• Tên sản phẩm runtime / phiên bản
• Hình thức license
• Phương thức kết nối PLC
• Phương thức backup
• Phương thức phục hồi
• Giả định mạng
• Phân định trách nhiệm

4. Yêu cầu chức năng

• Số lượng và phân loại màn hình
• Cách ước tính số điểm tag
• Cách định nghĩa alarm
• Cách lưu history
• Có/không cần xuất CSV/PDF…
• Chuyển đổi đa ngôn ngữ
• Quyền người dùng
• Hành vi khi PLC offline
• Khôi phục sau mất điện
• Quy tắc hiển thị malformed/stale tag

5. Yêu cầu về bảo mật và vận hành

• Cơ chế account
• Quyền local administrator
• Chính sách sử dụng USB
• Quy trình áp dụng patch
• Quản lý thay đổi
• Có/không yêu cầu audit log
• Tần suất backup và trách nhiệm quy trình

6. Kết quả bàn giao

• Sơ đồ cấu hình
• Bảng I/O và tag
• Bảng alarm
• Danh sách màn hình
• Định nghĩa quyền
• Bảng phiên bản
• Hướng dẫn backup / restore
• Quy trình và biên bản FAT/SAT
• Tài liệu đào tạo

7. Mẫu phản hồi của nhà cung cấp

Để dễ so sánh, nên thống nhất định dạng thay vì để mô tả tự do.

Ma trận thử nghiệm FAT/SAT

FAT/SAT không chỉ là kiểm tra xem màn hình có hiển thị hay không. Cần xác nhận bằng phương pháp đo được về vận hành, bất thường, phục hồi, quyền và bảo trì.

Những góc nhìn cần xác nhận trong FAT

FAT được thực hiện trước khi xuất xưởng, tại môi trường của vendor hoặc môi trường dựng tạm. Nếu có thể thì dùng PLC thật; nếu khó thì tái hiện bằng simulator hoặc force value.

Những góc nhìn cần xác nhận trong SAT

SAT được thực hiện sau khi lắp đặt tại hiện trường, với đấu nối thực, mạng thực và quyền vận hành thực. Các điểm FAT không nhìn ra như đồng bộ thời gian, chuyển nguồn UPS, hiển thị ngôn ngữ, luồng thao tác tại hiện trường cũng phải được xác nhận.

Ví dụ ma trận FAT/SAT

Cách viết tiêu chí nghiệm thu

Không nhất thiết phải đóng đinh các giá trị số cố định ngay trong nội dung bài. Thay vào đó, điều kiện nghiệm thu cho từng bài test có thể viết như sau:

• Phù hợp với đặc tả đã nêu trong RFP
• Không mâu thuẫn với bảng tag, bảng alarm, định nghĩa quyền
• Hiển thị khi bất thường tuân theo quy tắc đã được người dùng chấp thuận
• Có tính tái lập theo quy trình backup / restore
• Không cản trở vận hành liên tục trong môi trường thực tế tại nhà máy

Chi phí và kiểm soát thay đổi

Khi chuyển sang PC công nghiệp, chỉ nhìn báo giá ban đầu thì chưa đủ để đánh giá phù hợp hay không. Chênh lệch chi phí thường xuất hiện ở chi phí thay đổi và chi phí bảo trì, nhiều hơn là chỉ ở chi phí đầu tư ban đầu.

Cách nhìn cấu trúc chi phí

Vì số tiền khác nhau tùy dự án, ở đây chỉ sắp xếp theo hạng mục.

Chi phí đầu tư ban đầu

• Bản thân PC công nghiệp
• Monitor / màn hình cảm ứng
• License HMI runtime
• Driver truyền thông hoặc option
• Công thiết kế và triển khai
• Công FAT/SAT
• Công chạy thử tại hiện trường

Chi phí liên quan đến bảo trì

• Máy dự phòng
• Xử lý cấp lại license
• Thiết bị / phương tiện lưu backup
• Hợp đồng bảo trì onsite
• Thử nghiệm lại khi cải tạo
• Đánh giá cập nhật OS
• Cập nhật bản dịch

Chi phí thay đổi trong tương lai

• Thêm tag PLC
• Thêm màn hình
• Thay đổi role quyền
• Thay đổi cách lưu log
• Tích hợp lên server
• Chuyển sang PC kế nhiệm

Thực tế triển khai change control

Quản lý thay đổi không chỉ dành cho doanh nghiệp lớn. Chỉ cần tối thiểu lập bảng vận hành cho các nội dung sau, hiện trường đã ổn định hơn nhiều.

Những câu hỏi cần kiểm tra khi so sánh báo giá

• File project có nằm trong phạm vi bàn giao không?
• Điều kiện di chuyển license là gì?
• Ai thực hiện phục hồi lên máy thay thế?
• Sau SAT, thay đổi nhỏ được bao gồm tối đa bao nhiêu lần?
• Đơn giá phát sinh khi thêm tag được tính như thế nào?

FAQ (5 câu hỏi chính xác)

Q1. Chuyển từ panel tích hợp sang PC công nghiệp thì có luôn dễ bảo trì hơn không?

Không hẳn. Việc dùng PC giúp tổ chức backup và mở rộng dễ hơn, nhưng đồng thời làm tăng khối lượng quản lý OS, license và cập nhật. Chỉ khi xác định rõ bộ phận bảo trì hiện trường làm đến đâu, IT/OT tham gia như thế nào, thì tính bảo trì mới thực sự được cải thiện.

Q2. Có vấn đề gì nếu đặt nút dừng an toàn hoặc trạng thái nhả an toàn ở phía HMI?

HMI có thể được dùng như giao diện hiển thị hoặc nhập lệnh, nhưng không nên đặt chủ thể xác lập chức năng an toàn ở HMI. Điều kiện tiên quyết là safety PLC hoặc mạch an toàn phải tự đảm bảo độc lập. HMI không phải là chức năng an toàn.

Q3. Tự động cập nhật OS định kỳ, không dừng hệ thống, có phải luôn an toàn hơn không?

Trong OT không thể kết luận như vậy một cách đồng loạt. Cần quyết định áp dụng trên cơ sở quản lý thay đổi, đánh giá ảnh hưởng, thử nghiệm, quy trình thực hiện và rollback. IEC 62443-2-1 CISA ICS Recommended Practices

Q4. FAT nên kiểm tra đến mức nào để SAT nhẹ hơn?

Tối thiểu, nên xử lý xong từ FAT các mục: mapping tag, phát alarm và ACK, quyền người dùng, backup / restore, khôi phục sau mất điện, và hành vi khi PLC offline. Nếu để đến SAT mới kiểm tra, thời gian dừng tại hiện trường sẽ bị dùng để tìm các lỗi cơ bản.

Q5. Với hỗ trợ tiếng Thái, tiếng Anh và tiếng Nhật, chỉ cần bàn giao bảng dịch là đủ chưa?

Chưa đủ. Không chỉ câu alarm, mà cả nhãn nút, hộp thoại xác nhận, đơn vị, định dạng ngày tháng, lỗi thiếu ký tự, xuống dòng, khả năng tìm kiếm, và cả hiển thị trong log thao tác cũng nên nằm trong phạm vi QA. Test chuyển ngôn ngữ nên được thực hiện không chỉ ở FAT mà cả SAT.

Tổng kết và CTA

Điều thực sự quan trọng khi chuyển HMI sang PC công nghiệp không phải là hình thức của màn hình, mà là kiến trúc hệ thống, quản lý ý nghĩa tag PLC, vận hành alarm, OS/license, backup/restore, quản lý thay đổi, phân định trách nhiệm, và khả năng kiểm chứng bằng FAT/SAT. Panel tích hợp, PC công nghiệp, và thin client / server trung tâm đều có bối cảnh phù hợp riêng; không có một phương án đúng trong mọi trường hợp. Từ góc độ kỹ thuật sản xuất và mua sắm, yếu tố quyết định thành công không chỉ là so sánh phương án, mà là có thể chuyển thành đặc tả rõ ràng câu hỏi “khi sự cố xảy ra, ai sẽ khôi phục cái gì và bằng cách nào” hay không. Đặc biệt tại các nhà máy ở Thái Lan, nếu chốt sớm các điều kiện về đa ngôn ngữ, tổ chức bảo trì tại chỗ, khôi phục sau mất điện, trách nhiệm mạng và ranh giới với vendor, thì sẽ giảm đáng kể tình trạng phụ thuộc cá nhân sau khi đưa vào vận hành.

Nếu doanh nghiệp của bạn đang nâng cấp thiết bị hoặc triển khai mới và muốn cùng xây dựng RFP cho HMI/PC công nghiệp, lựa chọn nhà cung cấp, làm rõ phân định trách nhiệm, cũng như cụ thể hóa các điểm kiểm tra FAT/SAT ngay từ giai đoạn phác thảo yêu cầu, vui lòng liên hệ: https://tomastc.com/vn/contact/

Nguồn tham khảo

• ISA-101 Standards
• Siemens WinCC Unified Engineering Guideline
• Siemens WinCC Unified Visualizing Processes
• Ignition Perspective Workstation
• Beckhoff C6525-0060
• IEC 62443-2-1
• CISA ICS Recommended Practices