STPA (System Theoretic Process Analysis) — So sánh với FMEA·HAZOP

1. Tổng quan

A. Khái niệm và bối cảnh

STPA là kỹ thuật phân tích mối nguy (Hazard Analysis) dựa trên lý thuyết hệ thống, coi tai nạn không phải là 'hỏng hóc linh kiện' mà là 'hành động điều khiển không phù hợp vi phạm ràng buộc an toàn (Unsafe Control Action)', và rút ra mối nguy theo hướng từ trên xuống (Top-down) từ cấu trúc điều khiển của hệ thống. Kỹ thuật này bắt rễ từ STAMP (System-Theoretic Accident Model and Processes), mô hình nhân quả tai nạn do Nancy Leveson của MIT đề xuất.

Lý do căn bản STPA ra đời là vì 'tai nạn hiện đại phát sinh từ vấn đề tương tác·điều khiển nhiều hơn là hỏng hóc linh kiện'. Để hiểu bối cảnh này, trước hết phải xem các giả định mà phân tích an toàn truyền thống dựa vào. Các kỹ thuật cổ điển như FMEA·HAZOP đặt câu hỏi 'nếu linh kiện này hỏng thì chuyện gì xảy ra'. Bên dưới là giả định của lý thuyết độ tin cậy (Reliability Theory): nếu từng linh kiện bình thường thì hệ thống cũng an toàn. Giả định này hợp lý trong thời đại lấy máy móc làm trung tâm, khi hỏng hóc linh kiện là nguyên nhân chi phối của tai nạn.

Tuy nhiên trong các hệ thống phức tạp nơi phần mềm điều khiển tích hợp nhiều thành phần như xe tự hành·hàng không·thiết bị y tế·hạt nhân, giả định này sụp đổ. Dù mọi linh kiện hoạt động bình thường đúng quy cách, tai nạn vẫn xảy ra do tương tác sai giữa các linh kiện hoặc lệnh điều khiển không phù hợp với tình huống. Ví dụ, dù cảm biến và bộ điều khiển đều đã qua mọi thử nghiệm riêng lẻ, nếu bộ điều khiển đưa ra lệnh không phù hợp do nhận thức sai tình huống (lỗi Process Model) thì tai nạn vẫn xảy ra. Phần mềm không 'hỏng' về mặt vật lý — nó hoạt động đúng như thiết kế, chỉ là hành vi được thiết kế đó nguy hiểm trong một ngữ cảnh cụ thể. Do đó không thể giải thích rủi ro phần mềm bằng 'tỷ lệ hỏng hóc'.

STPA chuyển đổi góc nhìn ở điểm này. Nó định nghĩa lại an toàn không phải là 'trạng thái linh kiện không hỏng' mà là 'trạng thái hệ thống được điều khiển để liên tục thỏa mãn ràng buộc an toàn (Safety Constraint)', và coi tai nạn là kết quả của việc điều khiển đó thất bại. Tức là xử lý an toàn như một bài toán điều khiển (Control Problem). Nhờ sự chuyển đổi này, STPA phát hiện không chỉ hỏng hóc linh kiện mà cả những mối nguy mà kỹ thuật truyền thống bỏ lỡ như yêu cầu thiếu sót, lỗi nhận thức tình huống của bộ điều khiển, lỗi tương tác giữa con người và tự động hóa.

B. Đặc trưng và hạn chế của FMEA·HAZOP

FMEA và HAZOP là các kỹ thuật đã qua kiểm chứng lâu dài nhưng có hạn chế chung. FMEA (Failure Mode and Effects Analysis) liệt kê các dạng hỏng hóc (Failure Mode) của từng linh kiện và phân tích ảnh hưởng theo hướng từ dưới lên (Bottom-up), xếp thứ tự ưu tiên bằng RPN (Risk Priority Number) là tích của mức nghiêm trọng·mức phát sinh·mức phát hiện. HAZOP (Hazard and Operability Study) áp các từ hướng dẫn (guideword) như 'No', 'More', 'Less' vào biến quy trình để tìm có hệ thống các sai lệch (Deviation) khỏi ý đồ thiết kế.

Hạn chế của cả hai kỹ thuật bắt nguồn từ việc đơn vị phân tích là 'linh kiện (hoặc biến quy trình)'. Vì tách từng linh kiện ra xem, các lỗi tương tác·điều khiển xảy ra dù mọi linh kiện đều bình thường về cấu trúc không lọt vào tầm nhìn. Đây chính xác là điểm STPA muốn bổ khuyết.

Về lịch sử, hạn chế này đã lộ ra trong các tai nạn lớn thực tế. Các phân tích tích lũy cho thấy phần lớn tai nạn của hệ thống do phần mềm điều khiển không bắt nguồn từ hỏng hóc vật lý của linh kiện riêng lẻ mà từ sự không đầy đủ của yêu cầu, hiểu lầm giữa người vận hành và tự động hóa, lệnh điều khiển không phù hợp tình huống. Với khung FMEA·HAZOP khó trả lời câu hỏi 'mọi linh kiện đều đạt quy cách, sao vẫn xảy ra tai nạn', và chính khoảng trống này đã sinh ra nhu cầu về kỹ thuật phân tích mới dựa trên lý thuyết hệ thống.

2. Mô hình tai nạn STAMP và vị trí của STPA

Để hiểu đúng STPA, trước hết phải xem lý thuyết nền tảng của nó là STAMP. STAMP xem hệ thống là cấu trúc điều khiển phân tầng, trong đó tầng trên áp đặt ràng buộc an toàn và kiểm soát tầng dưới. Dưới đây là sơ đồ cấu trúc tổng thể thể hiện quan hệ giữa vòng điều khiển của STAMP và ràng buộc an toàn mà STPA xử lý.

flowchart TB
  subgraph CL["Vòng điều khiển (Control Loop)"]
    CT["Bộ điều khiển (Controller)<br/>+ mô hình quy trình"]
    AC["Cơ cấu chấp hành (Actuator)"]
    CP["Đối tượng được điều khiển (Controlled Process)"]
    SE["Cảm biến (Sensor)"]
    CT -->|lệnh điều khiển| AC --> CP
    CP -->|đo trạng thái| SE -->|phản hồi| CT
  end
  SC["Ràng buộc an toàn (Safety Constraint)"] -.áp đặt.-> CT
  CP -.khi vi phạm.-> HZ["Mối nguy (Hazard) → Tổn thất (Loss)"]
  style CT fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style HZ fill:#fde8e8,stroke:#d64545,stroke-width:2px

Khái niệm cốt lõi của STAMP gồm ba điểm. Thứ nhất, cấu trúc điều khiển (Control Structure) — hệ thống được biểu diễn thành tầng bậc các vòng điều khiển gồm bộ điều khiển·cơ cấu chấp hành·đối tượng được điều khiển·cảm biến. Thứ hai, mô hình quy trình (Process Model) — bộ điều khiển có mô hình nội bộ về trạng thái của đối tượng được điều khiển và ra lệnh dựa trên đó; nếu mô hình này lệch với thực tế (ví dụ: phán đoán sai máy bay đang ở trạng thái hạ cánh) thì lệnh không phù hợp sẽ được đưa ra. Thứ ba, ràng buộc an toàn — điều kiện hệ thống phải tuân thủ để ngăn tai nạn, và STPA truy vết khi nào ràng buộc này bị vi phạm. Thấu hiểu của STAMP là phần lớn tai nạn của hệ thống tập trung phần mềm được giải thích bằng 'lỗi mô hình quy trình', điều mà mô hình hỏng hóc linh kiện không nắm bắt được.

3. Phương pháp phân tích 4 bước của STPA

STPA theo quy trình từ trên xuống, xuất phát từ việc định nghĩa tổn thất và thu hẹp dần đến kịch bản nguyên nhân cụ thể. Dưới đây là sơ đồ quy trình chi tiết.

flowchart LR
  A["1. Định nghĩa phạm vi phân tích<br/>(tổn thất·mối nguy·ràng buộc an toàn)"] --> B["2. Mô hình hóa cấu trúc điều khiển"]
  B --> C["3. Rút ra hành động điều khiển không an toàn (UCA)"]
  C --> D["4. Phân tích kịch bản·nguyên nhân gây UCA"]
  D --> E["Yêu cầu an toàn·cải tiến thiết kế"]
  style C fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

A. Bước 1 — Định nghĩa phạm vi phân tích. Trước tiên định nghĩa tổn thất (Loss) mà hệ thống tuyệt đối không được gặp (ví dụ: thương vong, thất bại nhiệm vụ, hư hại tài sản), và nhận diện mối nguy (Hazard) ở cấp hệ thống dẫn tới tổn thất đó (ví dụ: 'xe tự hành không duy trì được khoảng cách an toàn tối thiểu với xe phía trước'). Tiếp theo đảo ngược từng mối nguy để rút ra ràng buộc an toàn mà hệ thống phải tuân thủ. Bước này quan trọng vì nó đặt điểm chuẩn của phân tích không phải ở 'linh kiện' mà ở 'tổn thất được tổ chức·các bên liên quan thống nhất', khiến mọi phân tích sau đó được căn chỉnh theo kết quả thực sự cần ngăn chặn.

B. Bước 2 — Mô hình hóa cấu trúc điều khiển. Mô hình hóa hệ thống thành vòng điều khiển bộ điều khiển-cơ cấu chấp hành-đối tượng được điều khiển-cảm biến. Ở đây không chỉ bộ điều khiển phần mềm mà cả người lái, kiểm soát viên, thậm chí tổ chức quản lý cấp trên cũng có thể được đưa vào như bên điều khiển. Việc đặt con người và tự động hóa chung trong một cấu trúc điều khiển là điểm mạnh của STPA, giúp xử lý tự nhiên lỗi tương tác người-tự động hóa (Human-Automation Interaction). Với mỗi quan hệ điều khiển, ghi rõ lệnh điều khiển nào được gửi và phản hồi nào quay lại.

C. Bước 3 — Rút ra hành động điều khiển không an toàn (UCA). Với mỗi lệnh điều khiển, xem xét có hệ thống theo bốn loại xem trong ngữ cảnh nào nó vi phạm ràng buộc an toàn. Bốn loại này là công cụ cốt lõi của STPA.

D. Bước 4 — Phân tích kịch bản·nguyên nhân. Với mỗi UCA rút ra, đào sâu 'vì sao điều khiển như vậy xảy ra'. Nguyên nhân chia thành hai nhánh lớn — lỗi mô hình quy trình bên trong bộ điều khiển (nhận thức tình huống sai, khuyết tật thuật toán, yêu cầu thiếu sót) và vấn đề của đường điều khiển (lệnh không được truyền, phản hồi bị trễ·mất, lỗi cảm biến). Các kịch bản rút ra như vậy dẫn thẳng tới yêu cầu an toàn và phương án cải tiến thiết kế. Ví dụ, kịch bản 'độ trễ phản hồi cảm biến gây phanh muộn' được cụ thể hóa thành yêu cầu 'bảo đảm trần độ trễ phản hồi trong vòng T ms'.

Điểm khác biệt quyết định của 4 bước này so với kỹ thuật truyền thống là 'điểm kết thúc của phân tích'. Trong khi FMEA dừng ở chỉ số định lượng là xác suất hỏng theo linh kiện và RPN, STPA đi qua kịch bản cụ thể gây ra từng UCA để quy về thẳng yêu cầu an toàn có thể kiểm chứng. Tức sản phẩm của STPA không phải 'linh kiện nào nguy hiểm' mà là 'hệ thống phải tuân thủ ràng buộc nào trong điều kiện nào', và điều này dẫn tự nhiên tới giai đoạn thiết kế·kiểm chứng, giúp kiểm soát an toàn ở mức yêu cầu. Trong trường hợp xe tự hành thực tế, nếu 'lỗi nhận thức phân loại nhầm xe đang dừng thành cảnh nền' được rút ra như kịch bản nguyên nhân của việc không cung cấp lệnh phanh (UCA ①), nó được phản ánh thành yêu cầu 'trong tình huống cụ thể, nếu độ tin cậy nhận thức dưới ngưỡng thì dừng an toàn'.

4. So sánh với kỹ thuật truyền thống và hàm ý thực tiễn

Khác biệt của ba kỹ thuật rốt cuộc nằm ở 'đơn vị phân tích và mô hình tai nạn'. FMEA·HAZOP lấy linh kiện·quy trình làm đơn vị và đứng trên lý thuyết độ tin cậy, còn STPA lấy cấu trúc điều khiển làm đơn vị và đứng trên lý thuyết hệ thống.

Nối lý do khác biệt tới hàm ý thực tiễn thì như sau. FMEA định lượng tốt độ tin cậy linh kiện vì dữ liệu xác suất gọi là tỷ lệ hỏng tồn tại theo đơn vị linh kiện, và chính vì thế nó yếu trước lỗi logic phần mềm không biểu diễn được bằng xác suất. Ngược lại STPA mạnh trước lỗi SW·tương tác vì lấy đối tượng phân tích là 'tính phù hợp của hành động điều khiển' chứ không phải 'hỏng hóc', và cái giá phải trả là không trực tiếp tính ra chỉ số định lượng như xác suất hỏng theo linh kiện. Do đó trong thực tế không đặt hai thứ đối lập — trong chứng nhận hệ thống an toàn thiết yếu, dùng STPA để phát hiện mối nguy điều khiển·tương tác và lập yêu cầu an toàn, dùng FMEA để đánh giá định lượng hỏng hóc linh kiện phần cứng, và song hành hai thứ bổ trợ nhau là cách tiếp cận đã định hình.

5. Chuyên sâu: xu hướng áp dụng tiêu chuẩn·ngành

A. Ô tô — xe tự hành và SOTIF. Trong khi tiêu chuẩn an toàn chức năng ISO 26262 xử lý 'mối nguy do hỏng hóc linh kiện (trục trặc)', vấn đề mới của xe tự hành là 'mối nguy phát sinh từ giới hạn của chức năng dự định hoặc nhận thức sai dù không có hỏng hóc'. Tiêu chuẩn xử lý vấn đề này là ISO 21448 (SOTIF, Safety Of The Intended Functionality), và ở đây STPA được dùng rộng rãi như kỹ thuật phát hiện mối nguy dựa trên kịch bản. Bởi STPA nắm bắt tốt quá trình lỗi nhận thức tình huống sinh ra điều khiển không phù hợp trong vòng điều khiển nối từ cảm biến·nhận thức·phán đoán·điều khiển.

B. Hàng không·vũ trụ·quốc phòng. Trong lĩnh vực hàng không vũ trụ Mỹ, STPA·STAMP đã được áp dụng thực tế cho phân tích an toàn của các hệ thống quy mô lớn, và các sổ tay cùng trường hợp liên quan đã được công bố. Vì có thể xử lý trong một mô hình cấu trúc điều khiển đan xen nhiều tự động hóa và con người (phi công·kiểm soát viên), nó thể hiện điểm mạnh trong phân tích·phòng ngừa tai nạn bắt nguồn từ tương tác người-tự động hóa. Đặc biệt trong hệ thống phức tạp có nhiều tổ chức·tầng bậc tham gia, việc có thể đưa cả tầng quản lý·quản lý nhà nước cấp trên vào cấu trúc điều khiển để phân tích được đánh giá là hữu ích trong các miền mà yếu tố tổ chức tác động lớn tới tai nạn như hàng không·quốc phòng.

C. Mở rộng sang bảo mật (STPA-Sec) và hướng ra đề dự kiến. Gần đây, phần mở rộng STPA-Sec phân tích không chỉ an toàn (Safety) mà cả mối đe dọa bảo mật (Security) theo cùng góc nhìn cấu trúc điều khiển cũng được thảo luận. Về chiến lược bài làm từ góc độ Kỹ sư chuyên nghiệp (Professional Engineer), ① trình bày rõ sự chuyển đổi mô hình tai nạn 'hỏng hóc linh kiện vs điều khiển·tương tác', ② giải thích mối liên kết khái niệm STAMP–mô hình quy trình–ràng buộc an toàn và 4 loại UCA bằng trường hợp cụ thể (phanh xe tự hành v.v.), ③ mở rộng tới sự bổ trợ với FMEA·HAZOP, liên kết tiêu chuẩn như ISO 26262/21448 và lợi ích áp dụng từ đầu thiết kế thì có thể thể hiện chiều sâu chuyên sâu.

6. Các điểm cần xem xét và hàm ý

Từ góc độ Kỹ sư chuyên nghiệp, STPA không nên được tiếp cận như vấn đề hơn kém giữa các kỹ thuật riêng lẻ, mà như vấn đề cấu thành chiến lược phân tích mối nguy thế nào cho phù hợp với độ phức tạp của hệ thống·mức yêu cầu an toàn·hệ thống chứng nhận hiện có. Dưới đây là các tiêu chí phán đoán để lập chiến lược đó.

1. Nguyên tắc là khai thác bổ trợ. STPA không phải kỹ thuật thay thế FMEA·HAZOP mà là thứ bổ trợ, cùng phân tích hỏng hóc linh kiện (FMEA) và lỗi điều khiển·tương tác (STPA) để phát hiện mối nguy một cách bao quát. Trong chứng nhận hệ thống an toàn thiết yếu, chiến lược song hành hai dòng kỹ thuật để lấp điểm mù của nhau là phù hợp.

2. Thiết yếu với hệ thống tập trung phần mềm·tự hành. Trong các hệ thống mà SW điều khiển phức tạp và tương tác với con người như xe tự hành·hàng không·thiết bị y tế, các mối nguy không giải thích được chỉ bằng hỏng hóc linh kiện (lỗi mô hình quy trình, yêu cầu thiếu sót, tương tác người-tự động hóa) chiếm ưu thế, nên góc nhìn điều khiển của STPA rất mạnh.

3. Áp dụng từ đầu thiết kế là hiệu quả về chi phí. STPA mô hình hóa cấu trúc điều khiển, nên nếu áp dụng ở giai đoạn thiết kế yêu cầu·kiến trúc thì có thể phản ánh ngay UCA và kịch bản phát hiện được thành yêu cầu an toàn để phòng ngừa mối nguy tận gốc. Xét việc lỗi phát hiện càng muộn trong phát triển thì chi phí sửa càng tăng vọt, hiệu quả kinh tế của áp dụng sớm là lớn.

4. Thiết kế sự nhất quán với tiêu chuẩn·định lượng hóa. STPA mạnh trong việc 'phát hiện' mối nguy nhưng không trực tiếp tính ra chỉ số định lượng như xác suất hỏng theo linh kiện. Do đó phải căn chỉnh với hệ thống tiêu chuẩn như ISO 26262 (an toàn chức năng)·ISO 21448 (SOTIF), và cấu thành hồ sơ an toàn tích hợp (Safety Case) bổ khuyết căn cứ định lượng cần thiết bằng FMEA·phân tích độ tin cậy định lượng.

5. Bảo đảm năng lực áp dụng và công cụ là then chốt. STPA đòi hỏi chuyển đổi góc nhìn và hiểu biết lý thuyết hệ thống, nên việc đào tạo người phân tích, đường cong học tập của nhóm và công cụ hỗ trợ mô hình hóa cấu trúc điều khiển·quản lý UCA quyết định thành bại của việc lan tỏa. Phải lập kế hoạch đồng thời nội tại hóa phương pháp luận ở cấp tổ chức và hỗ trợ công cụ thì mới có hiệu quả thực tế.

Tài liệu tham khảo

• Nancy Leveson, Engineering a Safer World (STAMP/STPA) — https://mitpress.mit.edu/9780262533690/engineering-a-safer-world/
• MIT PSAS, STPA Handbook — http://psas.scripts.mit.edu/home/materials/
• Tổng quan ISO 21448 (SOTIF) — https://www.iso.org/standard/77490.html

Tóm tắt một câu: STPA là kỹ thuật phân tích mối nguy dựa trên lý thuyết hệ thống (STAMP) coi tai nạn là điều khiển không phù hợp (vi phạm ràng buộc an toàn) chứ không phải hỏng hóc linh kiện, rút ra 4 loại UCA từ trên xuống trong cấu trúc điều khiển để phát hiện lỗi tương tác·SW·con người mà FMEA·HAZOP bỏ lỡ, và được dùng bổ trợ với kỹ thuật truyền thống trong các hệ thống phức tạp·an toàn thiết yếu như xe tự hành·hàng không.