Blog

2026.09.20

Triển khai Safety PLC: RFP, thẩm định và bằng chứng FAT/SAT

Triển khai Safety PLC: RFP, thẩm định và bằng chứng FAT/SAT

Sai lầm nguy hiểm nhất khi triển khai Safety PLC là cho rằng mua một bộ điều khiển đã được chứng nhận đồng nghĩa với việc an toàn của toàn bộ máy đã được chứng minh. Safety PLC là một cấu phần quan trọng, nhưng luận cứ ở cấp máy phải dựa trên chuỗi bằng chứng nối liền mối nguy, chức năng an toàn, PLr hoặc SIL cần đạt, kiến trúc và phần mềm, verification, validation và kết quả FAT/SAT có thể tái lập. Bài viết này hướng dẫn nhà máy tại Thái Lan và ASEAN mua chuỗi bằng chứng đó như một sản phẩm kỹ thuật, thay vì mua phần cứng trước rồi phát hiện thiếu hồ sơ khi nghiệm thu.

Kết luận nhanh: hãy mua chuỗi bằng chứng của chức năng an toàn

Kết quả hợp đồng phải bao gồm: nhận diện mối nguy; định nghĩa chức năng an toàn; xác lập mục tiêu bằng phương pháp được công bố; thiết kế và tích hợp sensor, logic, actuator; verification thiết kế; validation chức năng đã lắp; và lưu bằng chứng để một người có năng lực khác có thể kiểm tra lại.

Vì vậy, sản phẩm bàn giao không chỉ là source code. Nó phải liên kết risk assessment, Safety Requirement Specification (SRS), cause-and-effect matrix, sơ đồ điện, đánh giá kiến trúc, đặc tả phần mềm, baseline tham số, hồ sơ verification, kế hoạch validation, biên bản FAT/SAT, residual risk và hướng dẫn bảo trì.

Nếu trình tự này bị đứt, ngay cả safety CPU mạnh, đầu vào hai kênh và safety drive cũng không trả lời được đang kiểm soát mối nguy nào, phải đạt trạng thái gì và trong bao lâu. Khi chuỗi bằng chứng rõ ràng, bên mua có thể so sánh nhà cung cấp không chỉ theo giá, số điểm I/O và network, mà còn theo mức đáp ứng yêu cầu, khả năng chẩn đoán, change control, tính dễ kiểm thử và khả năng cập nhật bằng chứng trong bảo trì.

Triển khai Safety PLC: RFP, thẩm định và bằng chứng FAT/SAT - figure 1

Thông báo chứng nhận ngày 17/9/2026 có ý nghĩa gì

Ngày 17 tháng 9 năm 2026, Mitsubishi Electric công bố safety programmable controller MELSEC iQ-R đã nhận EU type-examination certificate theo EU Machinery Regulation. Thông cáo cho biết sản phẩm có thể kết hợp điều khiển thông thường và điều khiển an toàn, đồng thời mô tả các biện pháp cybersecurity. Các cụm như “one of the first” và “first for its FA business” cần được dẫn rõ là tuyên bố của Mitsubishi Electric, không phải xếp hạng độc lập.

Tín hiệu đáng chú ý không phải là một sản phẩm có thể tự hoàn tất conformity. Bản consolidated hiện hành của Regulation (EU) 2023/1230 áp dụng từ 20 tháng 1 năm 2027; tài liệu của European Commission cũng nhấn mạnh cyber-safety khi phần mềm và safety control system liên quan đến compliance. Vì thế, bên mua phải thiết kế evidence, access control và change control ngay từ lúc chọn cấu phần. Không nên dùng mốc 14 tháng 1 còn xuất hiện ở cách trình bày cũ của initial text.

Chứng nhận giúp giảm bất định về phạm vi, điều kiện và giới hạn công bố của cấu phần. Nó không tự tìm mối nguy bị bỏ sót, chọn PLr, sửa wiring, chứng minh stopping distance, ngăn guard bị vô hiệu, kiểm tham số hay quản lý thay đổi khi bảo trì. Những việc đó vẫn thuộc cấp máy và ứng dụng.

PLC thông thường và functional safety PLC khác nhau ở đâu

PLC thông thường cũng có thể tắt output. Safety PLC được thiết kế và đánh giá để thực hiện safety-related function với integrity, diagnostic behavior, fault reaction, giới hạn phát triển và điều kiện sử dụng có tài liệu.

Nội dungĐiều khiển thông thườngĐiều khiển liên quan đến an toàn
Mục tiêuTrình tự, chất lượng, tốc độ, năng suấtGiảm rủi ro bằng chức năng an toàn đã định nghĩa
Khi có lỗiAlarm và khôi phục thường do vận hành quyết địnhDiagnosis, fault reaction và safe state là bằng chứng thiết kế
I/O và mạngI/O, network thông thườngSafety I/O và safety communication phù hợp
Phần mềmChủ yếu chứng minh chức năng chạyCấu trúc kiểm được, review và traceability
Nghiệm thuTrình tự chạy đúng có thể được coi là đạtCần negative, fault, timing, reset và recovery test
Hồ sơProgram, I/O list, hướng dẫnEvidence liên kết từ hazard đến validation

Ngay cả khi normal control và safety control dùng chung rack hoặc engineering environment, quyền hạn, lifecycle và evidence vẫn phải được kiểm soát. Thay đổi tốc độ trong logic thường trở thành thay đổi safety nếu ảnh hưởng stopping time hoặc protective distance.

Trang sản phẩm có thể ghi khả năng đến SIL 3 hoặc PL e, nhưng đó không phải integrity đạt được của mọi chức năng trên máy. Kết quả phụ thuộc toàn chuỗi input, wiring, logic, communication, output, actuator, diagnosis, common-cause measure, software, test interval và điều kiện dùng.

Cấu phần được chứng nhận không đồng nghĩa máy phù hợp

“Dừng robot khi light curtain bị che” chưa phải safety function có thể kiểm thử. Đặc tả cần có người và mode gặp rủi ro, trigger, actuator bị điều khiển, safe state, tổng response-time budget, điều kiện reset/restart, mục tiêu PLr/SIL và lý do, điều kiện lắp đặt, phương pháp verification và evidence validation trên máy thật.

Manual safety I/O của Mitsubishi cũng nêu sự phân biệt quan trọng: chứng nhận sản phẩm không bảo đảm không có malfunction hay failure; nhà thiết kế thiết bị vẫn phải risk assessment và chọn SIL/PL cần thiết. Trong bối cảnh module được dẫn, cấu hình SIL 3 / Category 4 / PL e cần double wiring. Không được khái quát yêu cầu này cho mọi Safety PLC; phải ghi đúng model, revision manual, circuit example và constraint.

Từ ISO 12100 đến đặc tả chức năng an toàn

ISO 12100:2010 đưa ra phương pháp risk assessment và risk reduction cho máy. Tại thời điểm nghiên cứu, bản 2010 vẫn là bản hiện hành và đang được sửa đổi. RFP phải ghi edition và cách xử lý nếu bản mới xuất hiện trong dự án.

Hãy định nghĩa giới hạn máy cho production, setup, cleaning, jam clearing, teaching, maintenance, recovery và decommissioning. Nhận diện hazard theo task và mode: kẹp, cắt, cuốn, văng, điện, nhiệt, áp suất, trọng lực và unexpected start. Ưu tiên inherently safe design và guard trước khi phụ thuộc safety-related control.

Sau đó gán ID cho từng safety function. Ghi hazard, input, logic, output, safe state, maximum response time, reset, mode, PLr/SIL, exclusion và test method. “Dừng an toàn” là chưa đủ; phải nói rõ năng lượng, chuyển động và áp suất nào cần đạt trạng thái nào trong bao lâu.

1. Xác định giới hạn của máy

Không chỉ xét sản xuất tự động; hãy bao gồm setup, cleaning, jam removal, teaching, maintenance, recovery và decommissioning. Ghi ai có thể tiếp cận trong từng mode, kể cả contractor và người vận hành tạm thời. Ở site đa ngôn ngữ, xác định bảng thuật ngữ và quy tắc tag vật lý ngay tại đây.

2. Nhận diện mối nguy và tình huống nguy hiểm

Mô tả theo task và mode, không dùng nhãn rộng như “có robot.” Xét nghiền, cắt, cuốn, văng, điện, nhiệt, áp suất, trọng lực và khởi động ngoài dự kiến. Bao gồm teaching tốc độ thấp, áp suất còn dư và chuyển động theo quán tính sau khi mở guard.

3. Ưu tiên thiết kế an toàn vốn có và guard

Safety PLC không mặc nhiên là biện pháp đầu tiên. Hãy giảm lực nguy hiểm, loại khe kẹp, chuyển service point ra khỏi hazard zone và dùng fixed guard khi khả thi. Sau đó mới phân bổ interlock, light curtain, safe-speed monitoring và safety-related control.

4. Viết từng safety function theo một cách hiểu duy nhất

Gán ID và định nghĩa input, logic, output, safe state, maximum response time, reset, mode, hazard, PLr/SIL, exclusion và test method. Thay “dừng an toàn” bằng trạng thái cụ thể của năng lượng, chuyển động hoặc áp suất.

5. Ghi residual risk và thông tin sử dụng

Không đẩy rủi ro tùy tiện sang procedure, training hoặc PPE. Ghi vì sao rủi ro còn lại, ai kiểm soát và thay đổi nào kích hoạt đánh giá lại. Thông tin vận hành phải phù hợp với trạng thái máy đã được thẩm định.

Chọn ISO 13849-1 hay IEC 62061 theo một phương pháp nhất quán

ISO 13849-1:2023 bao quát thiết kế và tích hợp safety-related parts of control systems, kể cả software. Tiêu chuẩn không tự chọn safety function hay PLr cho ứng dụng và không trực tiếp quy định security measure. ISO 13849-2:2012 đề cập validation bằng phân tích và thử nghiệm safety function, category và performance level. Bản 2012 là bản hiện hành tại thời điểm nghiên cứu, đồng thời đang được sửa đổi.

Phiên bản hợp nhất hiện hành là IEC 62061:2021+AMD1:2024+AMD2:2026 CSV. Phiên bản này bao quát thiết kế, tích hợp và validation safety-related control system, nhấn mạnh kỷ luật lifecycle như functional-safety planning, configuration management, parametrisation, periodic testing và mức độc lập phù hợp của verification/validation. Amendment 1 được phát hành năm 2024 và Amendment 2 ngày 20 tháng 3 năm 2026; RFP phải ghi bản hợp nhất này hoặc chính xác edition và amendment áp dụng.

Điểm quyết địnhTheo ISO 13849Theo IEC 62061
Mục tiêuPLr có lập luận từ rủi roSIL requirement có lập luận từ rủi ro
Bằng chứngSRP/CS, data, architecture, software, validationsafety plan, subsystem, integration, lifecycle evidence
Công cụSISTEMA có thể hỗ trợ đánh giá có cấu trúcDùng công cụ calculation/lifecycle phù hợp
Lỗi cần tránhSao chép PL e từ nhãn cấu phầnSao chép SIL capability từ nhãn cấu phần
Yêu cầu chungEvidence toàn chức năng trên máy thậtEvidence toàn chức năng trên máy thật

Không quản lý dự án hỗn hợp bằng bảng quy đổi PL/SIL một-một đơn giản. Hãy nêu phương pháp cho từng function, boundary giữa các phương pháp, cấu phần dùng chung, giả định và trách nhiệm phê duyệt. SISTEMA có thể hỗ trợ ISO 13849, nhưng output chỉ tốt khi input data, block boundary và operating assumption đúng.

Triển khai Safety PLC: RFP, thẩm định và bằng chứng FAT/SAT - figure 2

12 yêu cầu bắt buộc trong RFP Safety PLC

1. Phạm vi và ranh giới trách nhiệm

Xác định máy, line, mode, giới hạn sửa đổi và interface với thiết bị hiện hữu. Yêu cầu RACI cho risk assessment, safety specification, panel, field wiring, PLC software, drive parameter, test, document và training.

2. Luật, tiêu chuẩn và edition áp dụng

Ghi quốc gia đích, nơi lắp và chuẩn khách hàng. Khi liên quan, nêu ISO 12100, ISO 13849-1:2023, ISO 13849-2:2012 và IEC 62061:2021+AMD1:2024+AMD2:2026 CSV. Tránh lời hứa mơ hồ tự động đáp ứng mọi edition tương lai.

3. Phương pháp risk assessment và người tham gia

Quy định workshop, biểu mẫu, người duyệt và cách xử lý residual risk. Yêu cầu mechanical, electrical, controls, production, maintenance, EHS và operator thật tham gia, không chấp nhận đánh giá bàn giấy chỉ do supplier làm.

4. Safety Requirement Specification

Gán ID cho mọi safety function và định nghĩa hazard, input, logic, output, safe state, response time, reset, mode, PLr/SIL và test method. Khi requirement đổi, phải truy được thiết kế và test cần review.

5. Kiến trúc phần cứng

Chia chain thành sensor, safety I/O, CPU, communication, contactor, safety drive và pneumatic/hydraulic output. Yêu cầu model, firmware, certification scope, operating constraint, component data, common-cause measure, diagnosis và proof-test interval.

6. Quy tắc thiết kế phần mềm

Định nghĩa permitted safety block, naming, state transition, reset, muting, bypass, stopping, restart, error handling, code review, static check và test coverage. Xác nhận standard logic không thể âm thầm thay safety parameter.

7. Kiểm soát tham số và engineering tool

Nhận diện safety-drive speed, stop-monitoring time, sensor distance, filter và discrepancy time. Nêu ai được đổi, phê duyệt thế nào, backup gì và test nào phải chạy sau restore.

8. Cybersecurity và remote maintenance

Quy định engineering workstation, user identity, least privilege, multifactor access khi phù hợp, remote window, activity log, protected backup, malware control và end-of-support. Đường truy cập có thể đổi safety logic hoặc parameter phải nằm trong safety impact assessment.

9. Kế hoạch verification

Phân công requirement review, circuit review, calculation, I/O test, software unit test, interface test, fault injection và stopping-time measurement. Đảm bảo mức độc lập để tác giả không phải người duy nhất quyết định nghiệm thu.

10. Validation và FAT/SAT

Với mỗi safety-function ID, yêu cầu normal, fault, boundary, recovery, power-loss, communication-loss, open-circuit, short-circuit, discrepancy và restart case. Case phụ thuộc site chưa xong ở FAT phải chuyển rõ sang SAT.

11. Định dạng evidence và traceability

Liên kết requirement ID, drawing number, PLC version, parameter baseline, test case, instrument, người thực hiện, thời gian, result, deviation, correction và retest. Một ảnh, chữ ký hoặc dấu tick riêng lẻ là chưa đủ.

12. Handover, thay đổi và bảo trì

Đưa editable source, compiled backup, licence, credential transfer, BOM, spare, obsolescence notice, training, periodic proof test, restore drill, change request và revalidation trigger vào hợp đồng.

Quản lý software, parameter và change như một deliverable safety

Protective distance có thể phụ thuộc response của sensor, PLC filter, network update, drive reaction và thời gian dừng cơ khí. Thay đổi một yếu tố có thể làm kết quả cũ mất hiệu lực. Change request phải ghi reason, asset và safety-function ID, source/checksum trước-sau, firmware/library, parameter/drawing, safety impact, regression scope, approval, rollback và kết quả tại hiện trường.

Đổi một giây thành 1,5 giây không phải “chỉ là giá trị” nếu liên quan monitoring hoặc stopping. Online edit, forcing và bypass phải có permission, expiry, visible indication và audit. Remote access từ OEM nước ngoài cần time-bound, gắn với cá nhân và kết thúc bằng version check cùng test đã định.

Kỷ luật này không chỉ dành cho máy xuất sang EU. Ngay cả khi không xuất khẩu, tiêu chuẩn nội bộ của tập đoàn toàn cầu, điều kiện bảo hiểm, phòng ngừa tai nạn và khả năng khôi phục đáng tin cậy sau thay đổi đều đòi hỏi nhà máy giải thích đã thay đổi gì, chức năng an toàn nào bị ảnh hưởng và bằng chứng nào cho phép đưa máy trở lại vận hành.

Kế hoạch thiết kế và nghiệm thu 90 ngày có giới hạn

Đây là ví dụ lập kế hoạch của TOMAS TECH, không phải thời hạn theo tiêu chuẩn hay bảo đảm cho mọi máy.

Giai đoạnGói công việcEvidence để chuyển bước
Ngày 1–15Limits, hazard, document, standard, interfaceHazard register và candidate function được duyệt
Ngày 16–30SRS, target method, response budget, RFPMỗi function có ID, target, test concept
Ngày 31–55Circuit, I/O, PLC, drive, HMI, diagnosis, change controlThiết kế được review và baseline
Ngày 56–70Calculation, verification, unit/interface test, fault injection, FATĐóng major deviation, ghi SAT carryover
Ngày 71–85Installation, wiring check, stopping-time test, SAT, recoveryChứng minh function và restart tại site
Ngày 86–90Correction, retest, training, handover, approvalEvidence ledger hoàn tất, chuyển ownership

Những nội dung phải kiểm tại FAT

FAT phải vượt qua expected operation. Trước hết xác nhận build khớp design baseline, rồi mô phỏng channel open, discrepancy, short được phát hiện, communication loss, output fault, E-stop giữ, reset conflict, power cycle và unexpected-restart prevention. Đọc lại safety-drive setting và so với approved list. Hạng mục phụ thuộc site phải được ghi “not tested” và liên kết SAT case; không để chữ “FAT đạt” che các mục chuyển tiếp.

Những nội dung phải kiểm tại SAT

SAT kiểm wiring, load, speed, inertia, guard distance, ánh sáng, liên động máy trước-sau và operating practice thực tế. Nếu vị trí light curtain, phản xạ sàn, work nhô ra hoặc đường bypass khác FAT, phải kiểm lại. Với E-stop, cần kiểm vùng bị dừng, residual pressure/gravity, manual reset, không tự restart, hiển thị và recovery authority.

Triển khai Safety PLC: RFP, thẩm định và bằng chứng FAT/SAT - figure 3

Đưa negative test vào điều kiện FAT/SAT

FunctionFault hoặc boundaryEvidence cần có
Light curtainChe tia, channel fault, reset khi còn che, tiếp cận gần nhấtOutput transition, measured stop, restart prevention, log
Guard doorOpen, discrepancy, locking fault, yêu cầu unlock sớmSafe state, diagnosis, unlock condition, recovery
E-stopTừng nút, contact fault, release, nhiều yêu cầu đồng thờiStop scope, latch, manual reset, không restart
Safety driveCommand, communication loss, parameter mismatchMeasured stop, feedback, so sánh approved setting
Safety networkCable loss, node loss, delay, reconnectionFault reaction, diagnostic time, recovery condition
Power/recoveryBrownout, total loss, CPU replacement, restoreSafe startup, version match, retest record

Ghi calibration, speed, load, software version và điều kiện môi trường. Video chỉ là evidence hỗ trợ, không thay test ID, expected result, measurement và approval. Case fail phải có deviation ID, containment, cause, correction, impact, regression và reapproval.

Duy trì evidence ledger từ hazard đến kết quả hiện trường

Giữ đường dẫn không đứt:

Hazard ID → biện pháp giảm rủi ro → Safety Function ID → PLr/SIL → circuit/component → PLC block/parameter → calculation → verification → FAT/SAT → result → correction → approval

Nhóm trong sổ bằng chứngNội dung tối thiểu cần giữ
RequirementID, hazard, mode, safe state, response time, target và rationale
Designdrawing, component model, certificate, constraint, calculation, software version
ImplementationI/O, PLC block, drive setting, HMI và access permission
Testcase ID, precondition, action, expected/actual, instrument, evidence link
Deviationseverity, containment, cause, correction, impact và retest
Handoverapproval, residual risk, training, periodic test và change ownership

Tên file “final2” không phải configuration management. Cần approved baseline, checksum, release note, protected backup và restore test. Khi thay CPU, I/O, sensor, contactor hay drive “tương đương”, phải so certificate scope, diagnosis, response time, firmware và condition, rồi thực hiện regression test cần thiết.

Bảy kiểu thất bại thường gặp

1. Sao chép PL e hoặc SIL 3 của sản phẩm vào tuyên bố cho toàn máy

Khả năng của sản phẩm không phải performance đạt được của toàn chức năng. Hãy đánh giá sensor, wiring, logic, output, dừng cơ khí và proof-test interval như một chain.

2. Giao toàn bộ risk assessment cho supplier

Nhà máy hiểu công việc cleaning, jam clearing và recovery thật. Production, maintenance và EHS phải kết hợp hiểu biết này với năng lực thiết kế của supplier.

3. Dùng bảng đổi PL/SIL thay cho kỹ thuật

Khái niệm, giả định và phương pháp đánh giá không giống nhau. Công bố phương pháp cho từng function và review interface có chủ đích.

4. Nhận source PLC nhưng không nhận safety-drive setting

Nếu safe speed hoặc stopping function phụ thuộc drive, parameter set, permission, backup, revision và test evidence của drive là safety deliverable.

5. Kết thúc FAT bằng demo normal operation

Không có open, short, communication-loss, reset và power-recovery test thì chưa có evidence về fault reaction. Hãy đưa negative test vào hợp đồng.

6. Thêm remote maintenance như một tiện ích

Ai được đổi safety code hoặc parameter, từ terminal nào và trong window nào là quyết định safety lifecycle. Phải có approval và audit trong đường truy cập.

7. Chỉ test hẹp sau một thay đổi

Thay timer có thể ảnh hưởng protective distance. Xác định function bị tác động và regression scope trước khi làm, rồi duyệt evidence ledger đã cập nhật.

Điều kiện triển khai tại Thái Lan và ASEAN

Giữ một Safety ID qua mọi ngôn ngữ

Hướng dẫn vận hành có thể dùng tiếng Thái, Anh, Nhật hoặc Việt, nhưng safety-function ID, I/O tag, drawing và test ID phải giữ nguyên qua các bản dịch. Tách giải thích đã dịch khỏi technical identifier và xác nhận người vận hành hiểu nội dung, không chỉ kiểm ngữ pháp.

Quản lý remote maintenance như cửa vào cho safety change

Remote support từ OEM phải có plant approval, time limit, personal account, activity log, backup trước việc, version check sau việc và retest đã định. Cần procedure khi mất kết nối để không để lại trạng thái trung gian nguy hiểm.

Không duyệt phụ tùng “tương đương” chỉ từ specification

Khi dùng linh kiện thay thế trong khu vực, phải so chính xác certificate scope, condition, diagnosis, response time, terminal và firmware. Danh sách spare nên ghi revision được phép và test sau thay.

Không tách tủ điều khiển khỏi field wiring

Tủ đúng không bù được hư hại chung của cáp hiện trường, protective distance thiếu hoặc switch dễ bị defeat. Hợp đồng phải gom panel, field device, mechanical guard và site validation trong cùng safety-function boundary.

Thiết kế điều khiển phải đi cùng bảo vệ vật lý. Xem hướng dẫn hàng rào an toàn robot và ISO 10218 và hướng dẫn thuê ngoài lập trình PLC. Với máy xuất sang EU, kết nối dự án với hướng dẫn EU Machinery Regulation 2027 cho doanh nghiệp Thái Lan.

Checklist Go/No-Go trước khi ký hợp đồng

Chỉ chuyển từ báo giá sang hợp đồng khi nhóm trả lời được cả 12 điểm bằng evidence:

  • Đã định nghĩa máy, mode, boundary và user.
  • Đã cấu trúc hazard và biện pháp giảm rủi ro theo phương pháp ISO 12100.
  • Mỗi function có ID, input, logic, output, safe state và response time.
  • Rationale và phương pháp PLr hoặc SIL được ghi theo từng function.
  • Block và trách nhiệm rõ từ sensor đến actuator.
  • Đã kiểm certificate scope, manual, condition và constraint của sản phẩm.
  • PLC code, drive, safety I/O và parameter dùng chung change control.
  • Đã thiết kế remote connection, account, log, backup và restore.
  • Đã phân công vai trò, independence và approval cho verification/validation.
  • FAT/SAT có cả normal test và negative test.
  • Evidence ledger truy từ requirement ID đến kết quả cuối.
  • Hợp đồng có periodic test, replacement, change và revalidation.

FAQ: Safety PLC, PLr, validation và FAT/SAT

Safety PLC là gì?

Đó là controller được thiết kế và đánh giá cho safety-related control function với diagnosis, fault reaction, development constraint và condition. Nó không tự chọn target hay chứng minh toàn máy.

Có thể chọn PLr từ nhãn PL e của sản phẩm không?

Không. PLr đến từ risk assessment của ứng dụng. Performance đạt được còn phụ thuộc architecture, data, diagnosis, common-cause measure, software và proof test.

Có thể quy đổi trực tiếp SIL và PL không?

Không nên quyết định bằng quy đổi một-một đơn giản. Hãy áp dụng nhất quán phương pháp đã chọn và ghi interface nếu dùng hỗn hợp.

ISO 13849-2:2012 còn hiện hành không?

Tại thời điểm nghiên cứu, đây là bản hiện hành và revision đang được thực hiện. Hợp đồng cần ghi edition và cách xử lý khi có bản mới.

RFP Safety PLC nên yêu cầu gì đầu tiên?

Machine scope, risk assessment, SRS và responsibility matrix trước khi so sánh hardware.

FAT khác SAT trong thực tế như thế nào?

FAT kiểm baseline, panel, code, simulated I/O và fault response; SAT kiểm wiring, load, stopping time, guard geometry, machine interface và operation tại site.

PLC được chứng nhận có thể bỏ validation không?

Không. Validation cấp máy xác nhận function đã chọn, tích hợp và lắp đặt thực sự đạt risk reduction dự kiến.

Dự án Safety PLC có thể hoàn thành trong 90 ngày không?

Kế hoạch 90 ngày là ví dụ giới hạn cho một máy hoặc representative cell, không bảo đảm rollout toàn nhà máy. Thời gian phụ thuộc scope, chất lượng tài liệu, shutdown access và yêu cầu pháp lý.

Có phải test lại mọi safety function sau remote maintenance không?

Dùng impact assessment có ghi chép để xác định phạm vi. Thay safety logic, parameter, firmware, shared library hoặc communication condition cần regression test cho các function bị ảnh hưởng và revalidation khi cần. Ngay cả session “view only,” hãy dùng version và access log xác nhận không có thay đổi trái phép.

Tổng kết: ký hợp đồng cho evidence, không chỉ cho số chứng nhận

Triển khai Safety PLC thành công khi hazard, safety function, PLr/SIL, circuit, software, parameter, verification, validation và FAT/SAT tạo thành một chuỗi evidence có kiểm soát. Thông báo chứng nhận tháng 9/2026 mở rộng lựa chọn cấu phần, nhưng bên mua vẫn phải phân biệt “cấu phần được chứng nhận” với “máy có bằng chứng đầy đủ.”

TOMAS TECH có thể hỗ trợ safety-function inventory, RFP response matrix, ranh giới PLC/tủ điện, FAT/SAT case và evidence ledger ngay cả khi chưa chọn hãng. Để bắt đầu với một máy tại nhà máy Thái Lan hoặc dự án cùng OEM nước ngoài, vui lòng dùng trang liên hệ.

Tài liệu tham khảo

Lưu ý: kế hoạch 90 ngày, danh sách RFP, test case và evidence ledger là mẫu lập kế hoạch của TOMAS TECH, không thay tiêu chuẩn hay tư vấn pháp lý. Cần điều chỉnh theo máy, điều kiện dùng, quốc gia đích, khách hàng và edition đã ký.