Phân tích an toàn phần mềm (Software Safety Analysis)

1. Tổng quan

A. Định nghĩa và sự cần thiết

Phân tích an toàn phần mềm là hoạt động kỹ thuật có hệ thống nhằm nhận diện·phân tích·loại bỏ trước các mối nguy tiềm ẩn (Hazard) vốn có trong phần mềm xuyên suốt vòng đời phát triển để ngăn ngừa tai nạn (Accident), và là yêu cầu bắt buộc trong các hệ thống an toàn thiết yếu (Safety-Critical) như xe tự hành·thiết bị y tế·hàng không·đường sắt·điện hạt nhân, nơi lỗi dẫn thẳng đến thiệt hại về người và tài sản.

Bối cảnh căn bản khiến phân tích an toàn phần mềm trở thành một lĩnh vực kỹ thuật độc lập là phần mềm giờ đây đã vượt khỏi xử lý thông tin trên màn hình để trực tiếp điều khiển thế giới vật lý. Trước đây, khiếm khuyết phần mềm chỉ dừng ở lỗi hiển thị hay hỏng dữ liệu, nhưng ngày nay khiếm khuyết trong điều khiển phanh ô tô, cấp oxy của máy thở hay phần mềm điều khiển bay bằng tín hiệu điện (Fly-by-wire) của máy bay dẫn thẳng đến tai nạn và thương vong. Thực tế, khiếm khuyết điều kiện tranh chấp (Race Condition) trong phần mềm của máy xạ trị Therac-25 giai đoạn 1985~1987 đã chiếu lượng bức xạ gấp hàng trăm lần mức bình thường vào bệnh nhân, khiến ít nhất 3 người tử vong — một trường hợp điển hình vẫn còn là biểu tượng cho nguy cơ của phần mềm điều khiển thế giới vật lý.

Những rủi ro như vậy không thể kiểm soát đầy đủ chỉ bằng cách tiếp cận bị động (Reactive) — tạo ra khiếm khuyết trước rồi tìm bằng kiểm thử. Độ tin cậy mà hệ thống an toàn thiết yếu đòi hỏi thường ở mức xác suất xảy ra nguy hiểm 10⁻⁷~~10⁻⁹ mỗi giờ (tương ứng SIL 3~~4 của IEC 61508), đây là vùng mà chỉ với kiểm thử hữu hạn thì thậm chí không thể chứng minh về mặt thống kê. Do đó, bắt buộc phải song hành phân tích chủ động (Proactive) dự đoán và loại bỏ có hệ thống "điều gì có thể sai (What can go wrong)" ngay từ giai đoạn đầu thiết kế.

Các kỹ thuật phân tích được chia thành hai nhánh lớn theo hướng lập luận. Đó là kỹ thuật từ trên xuống (suy diễn, Deductive) xuất phát từ kết quả đáng lo ngại (tai nạn) rồi truy ngược nguyên nhân, và kỹ thuật từ dưới lên (quy nạp, Inductive) xuất phát từ nguyên nhân hỏng hóc của từng thành phần rồi xét xem nó dẫn đến kết quả gì. Bổ sung thêm là kỹ thuật dựa trên từ dẫn hướng (guideword) khám phá sự sai lệch so với ý đồ thiết kế bình thường, và kỹ thuật dựa trên lý thuyết hệ thống gần đây.

B. Hội tụ an toàn (Safety) và bảo mật (Security)

Theo truyền thống, phân tích an toàn xử lý hỏng hóc ngẫu nhiên·bất ngờ (Random Failure), còn phân tích bảo mật xử lý tấn công có chủ đích (Malicious Attack), là hai lĩnh vực riêng biệt. Tuy nhiên, khi điều khiển vật lý và kết nối mạng kết hợp như trong xe tự hành·thiết bị y tế thông minh·IoT công nghiệp, các tình huống mà trục trặc (Safety) và tấn công (Security) kết hợp gây ra một tai nạn ngày càng tăng. Ví dụ, tấn công thao túng ECU phanh từ xa rõ ràng là sự cố bảo mật, nhưng kết quả là tai nạn về người, tức là vấn đề an toàn. Vì vậy, các tiêu chuẩn mới như SAE J3061, ISO/SAE 21434 khuyến nghị thực hiện tích hợp phân tích an toàn với phân tích mối đe dọa bảo mật (TARA), và các khái niệm như "Safety of the Intended Functionality (SOTIF, ISO 21448)" xử lý cả rủi ro do giới hạn chức năng chứ không phải do trục trặc cũng đang lan rộng.

2. Tổng quan các kỹ thuật phân tích an toàn

flowchart TB
  S["Phân tích an toàn phần mềm"] --> D["Từ trên xuống·suy diễn<br/>(kết quả→nguyên nhân)"]
  S --> U["Từ dưới lên·quy nạp<br/>(nguyên nhân→kết quả)"]
  S --> G["Dựa trên sai lệch<br/>(ý đồ thiết kế→sai lệch)"]
  S --> T["Dựa trên lý thuyết hệ thống<br/>(cấu trúc điều khiển→điều khiển không an toàn)"]
  D --> FTA["FTA<br/>Fault Tree Analysis"]
  U --> FMEA["FMEA / FMECA<br/>Phân tích dạng hỏng·tác động"]
  G --> HAZOP["HAZOP<br/>Phân tích sai lệch theo từ dẫn hướng"]
  T --> STPA["STPA / STAMP<br/>Phân tích quy trình theo lý thuyết hệ thống"]
  style S fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style STPA fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px

Như hình trên, các kỹ thuật phân tích an toàn phần mềm được phân nhóm theo logic tiếp cận thành từ trên xuống·từ dưới lên·dựa trên sai lệch·dựa trên lý thuyết hệ thống. Bốn nhóm này không cạnh tranh nhau mà phải được hiểu là các công cụ bổ trợ lẫn nhau, soi rọi rủi ro từ các góc độ khác nhau. Bởi rủi ro mà một kỹ thuật bỏ sót sẽ được kỹ thuật khác nắm bắt. Dưới đây lần lượt giải thích nguyên lý, quy trình và bối cảnh áp dụng của từng kỹ thuật.

A. FTA (Fault Tree Analysis, phân tích cây sự cố)

FTA là kỹ thuật phân tích suy diễn xuất phát từ một sự kiện đỉnh (Top Event, tai nạn cấp cao nhất) đáng lo ngại, triển khai từ trên xuống các nguyên nhân bằng cổng logic (AND·OR·cổng ức chế, v.v.) để truy vết đến nguyên nhân gốc rễ.

Luồng tư duy của FTA là đặt câu hỏi "để tai nạn này xảy ra, những sự kiện cấp dưới nào phải kết hợp với nhau theo tổ hợp logic nào". Đặt tai nạn cấp cao nhất làm gốc, trải nguyên nhân xuống dưới như các cành cây, và lại phân rã mỗi sự kiện trung gian thành các nguyên nhân cấp dưới. Cổng AND biểu thị sự kiện cấp trên chỉ xảy ra khi mọi sự kiện cấp dưới cùng đồng thời xảy ra (hiệu quả của thiết kế dư thừa·phòng thủ nhiều lớp), còn cổng OR biểu thị chỉ cần một sự kiện xảy ra là sự kiện cấp trên xảy ra (tính dễ tổn thương của điểm hỏng đơn lẻ).

Điểm mạnh lớn nhất của FTA là làm lộ rõ trực quan các đường dẫn mà nhiều nguyên nhân đan xen phức tạp gây ra tai nạn. Đặc biệt, nếu gán xác suất xảy ra cho từng sự kiện cơ bản (Basic Event), có thể dùng đại số Boole để tìm tập cắt tối thiểu (Minimal Cut Set) và tính định lượng xác suất xảy ra của tai nạn cấp cao nhất. Ví dụ, trong hệ thống điều khiển máy bay, tai nạn "cả ba máy tính điều khiển bay dự phòng ba lớp đều hỏng" là tổ hợp AND của ba lần hỏng, nên nếu xác suất hỏng riêng lẻ là 10⁻³ thì về lý thuyết giảm xuống mức 10⁻⁹ — FTA đưa ra căn cứ định lượng theo cách như vậy.

Tuy nhiên, FTA giới hạn đối tượng phân tích ở một tai nạn cụ thể (Top Event), nên có hạn chế là các loại tai nạn mà người phân tích chưa hình dung tới sẽ không bao giờ xuất hiện trên cây. Ngoài ra, với đối tượng có trạng thái·thời điểm·tương tác phức tạp như phần mềm, ý nghĩa của "xác suất" trở nên mơ hồ, nên thường được dùng để nắm bắt định tính cấu trúc nguyên nhân hơn là phân tích định lượng.

B. FMEA / FMECA (Phân tích dạng hỏng và tác động)

FMEA là kỹ thuật phân tích từ dưới lên·quy nạp liệt kê đầy đủ các dạng hỏng (Failure Mode) của từng phần tử cấu thành hệ thống và đánh giá tác động (Effect) cùng nguyên nhân, và xác định thứ tự ứng phó bằng chỉ số ưu tiên rủi ro (RPN, Risk Priority Number) là tích của mức nghiêm trọng·tần suất xảy ra·khả năng phát hiện.

FMEA tiếp cận theo hướng ngược lại hoàn toàn với FTA. Xuất phát không phải từ tai nạn mà từ hỏng hóc ở đơn vị linh kiện·mô-đun·chức năng, kiểm tra từng mục dưới dạng bảng "nếu phần tử này hỏng theo cách này thì tác động gì lan truyền đến toàn hệ thống". Với mỗi dạng hỏng, đánh giá mức nghiêm trọng (Severity, 1~~10), tần suất xảy ra (Occurrence, 1~~10), khả năng phát hiện (Detection, 1~10) rồi nhân ba giá trị để tính RPN (tối đa 1000). Nguồn lực ứng phó như cải tiến thiết kế·tăng cường phát hiện được ưu tiên dành cho các hỏng hóc có RPN cao.

Phần mở rộng tăng cường đánh giá mức độ nguy hiểm (Criticality) cho FMEA là FMECA (Failure Mode, Effects and Criticality Analysis), và trong ngành ô tô, bản sửa đổi do AIAG-VDA công bố năm 2019 đã đưa vào mức ưu tiên hành động (AP, Action Priority) thay cho RPN để khắc phục giới hạn của thói quen phán đoán chỉ bằng tích các con số. Điều này phản ánh nhận thức thực tiễn rằng dù RPN cùng giá trị, hỏng hóc có mức nghiêm trọng cao vẫn nguy hiểm hơn hỏng hóc có khả năng phát hiện kém.

Điểm mạnh của FMEA nằm ở tính bao quát quét hết từng phần tử và tính hướng phòng ngừa, nhưng vì xử lý từng hỏng hóc một cách độc lập nên có giới hạn là khó nắm bắt hỏng hóc phức hợp phát sinh do nhiều phần tử đồng thời·tương tác. Đây chính là lý do cần bổ trợ lẫn nhau với FTA (truy vết nguyên nhân phức hợp) hay STPA (phân tích tương tác).

C. HAZOP (Hazard and Operability Analysis, phân tích mối nguy và khả năng vận hành)

HAZOP là kỹ thuật phân tích định tính áp các từ dẫn hướng (No·More·Less·Reverse·Part of·As well as, v.v.) vào ý đồ thiết kế (Design Intent) để rút ra một cách có hệ thống các sai lệch (Deviation) khỏi trạng thái bình thường cùng các mối nguy·vấn đề vận hành do chúng gây ra.

HAZOP ban đầu xuất phát từ ngành công nghiệp quy trình hóa chất của Anh (ICI) vào thập niên 1960, sau đó được mở rộng sang phân tích rủi ro phần mềm·vận hành hệ thống. Cốt lõi là sau khi nêu rõ "ý đồ thiết kế bình thường", kết hợp từ dẫn hướng với từng tham số (lưu lượng·áp suất·dữ liệu·thời điểm, v.v.) để buộc phải tạo ra các kịch bản sai lệch như "nếu không có lưu lượng (No Flow)", "nếu dữ liệu đến quá nhiều (More)", "nếu tín hiệu bị đảo ngược (Reverse)". Nhờ vậy, việc khai thác rủi ro không bỏ sót mà không chỉ phụ thuộc vào trí tưởng tượng của người phân tích.

Đặc điểm của HAZOP là kiểm tra không chỉ an toàn (Safety) mà cả khả năng vận hành (Operability), và được tiến hành dưới dạng hội thảo có cấu trúc với sự tham gia của chuyên gia đa lĩnh vực như quy trình·đo lường·điều khiển·vận hành. Nhờ tính chất cộng tác này, cả những rủi ro ở cấp độ tổ chức·vận hành mà cá nhân dễ bỏ sót cũng được làm lộ ra. Tuy nhiên, vì lấy cuộc họp làm trung tâm nên tốn thời gian·chi phí, và với hệ thống quy mô lớn thì khối lượng phân tích trở nên đồ sộ do bùng nổ tổ hợp.

3. So sánh các kỹ thuật

Khác biệt giữa các kỹ thuật không chỉ dừng ở chỗ "hướng khác nhau", mà dẫn tới hàm ý thực tiễn nắm bắt tốt loại rủi ro nào và bỏ sót điều gì. FTA xử lý tốt cấu trúc nguyên nhân và xác suất của tai nạn cụ thể nhưng yếu với tai nạn chưa hình dung, FMEA vượt trội về tính bao quát theo phần tử nhưng yếu với hỏng hóc do tương tác, còn HAZOP mạnh trong khai thác sai lệch vận hành nhưng chi phí lớn. Do đó, phải kết hợp phù hợp với tính chất của hệ thống và giai đoạn phát triển.

Phân loại	FTA	FMEA / FMECA	HAZOP	STPA
Hướng	Từ trên xuống (suy diễn)	Từ dưới lên (quy nạp)	Phân tích sai lệch	Lý thuyết hệ thống (từ trên xuống)
Điểm xuất phát	Tai nạn (Top Event)	Hỏng hóc thành phần	Ý đồ thiết kế	Cấu trúc điều khiển
Công cụ cốt lõi	Cổng logic·xác suất·tập cắt	Ưu tiên RPN / AP	Từ dẫn hướng	Hành động điều khiển không an toàn (UCA)
Điểm mạnh	Đường dẫn tai nạn·xác suất định lượng	Phòng ngừa theo phần tử·tính bao quát	Khai thác sai lệch vận hành·cộng tác	Tương tác·SW/yếu tố con người
Giới hạn	Bỏ sót tai nạn chưa hình dung	Yếu với hỏng hóc phức hợp·tương tác	Tốn thời gian·chi phí	Thiếu đánh giá rủi ro định lượng
Đối tượng phù hợp	Độ tin cậy HW·dự phòng	Hệ thống theo đơn vị linh kiện·chức năng	Hệ thống quy trình·vận hành	Hệ thống thâm dụng phần mềm

Điểm đáng chú ý là trong khi FTA·FMEA truyền thống xem "hỏng hóc của thành phần" là nguyên nhân tai nạn, thì STPA sẽ được giải thích ở phần sau xử lý cả "trường hợp không phần tử nào hỏng nhưng tương tác lại không an toàn". Phần mềm không có hỏng hóc vật lý như mài mòn·vỡ hỏng, và phần lớn tai nạn bắt nguồn từ lỗi yêu cầu hoặc tương tác sai giữa các thành phần, nên hệ thống càng thâm dụng phần mềm thì tầm quan trọng của kỹ thuật dựa trên lý thuyết hệ thống càng lớn.

4. Quy trình phân tích và liên kết tiêu chuẩn

flowchart LR
  A["1.Nhận diện mối nguy<br/>(lập danh mục Hazard)"] --> B["2.Phân tích rủi ro<br/>(FTA·FMEA·HAZOP·STPA)"]
  B --> C["3.Đánh giá rủi ro<br/>(mức nghiêm trọng·xác suất·SIL/ASIL)"]
  C --> D["4.Rút ra yêu cầu an toàn<br/>(Safety Requirement)"]
  D --> E["5.Phản ánh vào thiết kế·kiểm chứng<br/>(V&V·hồ sơ an toàn)"]
  E --> F["6.Quản lý vận hành·thay đổi<br/>(phân tích lại liên tục)"]
  F -. Phản hồi .-> A
  style C fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Phân tích an toàn không phải hoạt động một lần mà được thực hiện như quy trình tuần hoàn nhận diện mối nguy → phân tích → đánh giá → rút ra yêu cầu an toàn → phản ánh vào thiết kế·kiểm chứng → quản lý vận hành·thay đổi như hình trên. Đặc biệt, đánh giá rủi ro ở bước 3 liên kết trực tiếp với cấp toàn vẹn của các tiêu chuẩn an toàn chức năng.

IEC 61508, tiêu chuẩn cơ bản cho toàn ngành, định nghĩa mức yêu cầu giảm rủi ro là SIL (Safety Integrity Level) 14, cấp càng cao thì mức độ nghiêm ngặt phát triển và kiểm chứng yêu cầu càng được tăng cường. ISO 26262, tiêu chuẩn phái sinh cho lĩnh vực ô tô, khác IEC 61508 — vốn xác định SIL chỉ bằng một xác suất nguy hiểm — ở chỗ xác định cấp ASIL (AD, chức năng không liên quan an toàn là QM) bằng cách kết hợp ba yếu tố mức nghiêm trọng (S)·tần suất phơi nhiễm (E)·khả năng kiểm soát (C) thông qua phân tích mối nguy và đánh giá rủi ro (HARA). Ví dụ, chức năng như mất khả năng phanh có mức nghiêm trọng·phơi nhiễm·không thể kiểm soát đều cao sẽ được xếp vào cấp cao nhất ASIL D, đòi hỏi phát triển·kiểm chứng nghiêm ngặt nhất như kiểm chứng hình thức·độ phủ MC/DC.

Ngoài ra, các tiêu chuẩn theo miền như hàng không (DO-178C), thiết bị y tế (IEC 62304), đường sắt (EN 50128/50657) đều yêu cầu phân tích an toàn và quy trình phát triển tương ứng. Như vậy, kỹ thuật phân tích là phương tiện hỗ trợ có căn cứ cho cấp toàn vẹn mà tiêu chuẩn yêu cầu, nên phải được lập kế hoạch tích hợp với tiêu chuẩn ngay từ đầu quá trình phát triển.

Đặc biệt, cấp toàn vẹn không chỉ là một nhãn mà hoạt động như "núm điều chỉnh" quyết định cường độ của toàn bộ quá trình phát triển về sau. Cấp càng cao thì các hoạt động kiểm chứng được yêu cầu — phân tích tĩnh, tiêu chí độ phủ, nhóm kiểm chứng độc lập (Independent V&V), phạm vi áp dụng phương pháp hình thức — được tăng cường từng bước, và mọi căn cứ này được đan kết thành một hồ sơ an toàn (Safety Case), trở thành hệ thống lập luận thuyết phục cơ quan chứng nhận. Do đó, kết quả của phân tích an toàn không kết thúc tại chính nó, mà chỉ được công nhận giá trị khi liên kết với từng sản phẩm đầu ra của yêu cầu·thiết kế·hiện thực·kiểm thử bằng khả năng truy vết hai chiều (Bidirectional Traceability).

5. Chuyên sâu — Phân tích dựa trên lý thuyết hệ thống (STPA/STAMP) và xu hướng mới

Các kỹ thuật truyền thống (FTA·FMEA) dựa trên mô hình tai nạn "chuỗi hỏng hóc (Chain of Events)". Tuy nhiên, phần đáng kể các tai nạn xảy ra trong hệ thống thâm dụng phần mềm hiện đại bắt nguồn từ tương tác giữa các thành phần và khiếm khuyết của chính yêu cầu dù không linh kiện nào hỏng. Xuất phát từ nhận thức này là mô hình tai nạn STAMP (System-Theoretic Accident Model and Processes) do giáo sư Nancy Leveson của MIT đề xuất và kỹ thuật phân tích dựa trên nó là STPA (System-Theoretic Process Analysis).

STPA mô hình hóa hệ thống thành cấu trúc điều khiển phân cấp (Control Structure) gồm "bộ điều khiển (Controller)–hành động điều khiển (Control Action)–quy trình bị điều khiển–phản hồi", và rút ra các hành động điều khiển không an toàn (UCA, Unsafe Control Action) có thể phát sinh trong cấu trúc này. UCA được hệ thống hóa thành bốn loại: (1) không thực hiện điều khiển cần thiết, (2) thực hiện điều khiển không an toàn, (3) điều khiển sai thời điểm·thứ tự, (4) duy trì quá lâu/quá ngắn. Sau đó phân tích các kịch bản nguyên nhân (Loss Scenario) làm phát sinh từng UCA để rút ra yêu cầu an toàn.

Điểm mạnh của STPA là có thể xử lý trong một khung duy nhất cả lỗi logic phần mềm, sự không đầy đủ của yêu cầu và yếu tố con người (Human Factor). Việc áp dụng đang tăng nhanh trong các lĩnh vực xe tự hành·hàng không·quốc phòng, và STPA-Sec — phần mở rộng xử lý đồng thời an toàn và bảo mật — cùng CAST (Causal Analysis based on STAMP) dùng để phân tích sau tai nạn cũng được sử dụng. Tuy nhiên, STPA tự thân không cung cấp đánh giá rủi ro định lượng (tính xác suất) mà phần lớn tiêu chuẩn an toàn quốc tế yêu cầu, nên trong thực tế khuyến nghị cách tiếp cận lai: dùng STPA khai thác kịch bản và dùng FMEA·FTA bổ sung đánh giá định lượng. Về hướng ra đề dự kiến, các chủ đề có khả năng cao gồm "khác biệt mô hình tai nạn giữa FTA/FMEA và STPA", "liên kết xe tự hành·SOTIF với phân tích an toàn", "phân tích tích hợp Safety-Security".

6. Những điểm cần xem xét và hàm ý

Hãy dùng song song các kỹ thuật một cách bổ trợ lẫn nhau. Kỹ thuật đơn lẻ chắc chắn có điểm mù. Phân tích đường dẫn và xác suất của tai nạn cụ thể bằng FTA, hỏng hóc theo phần tử bằng FMEA, sai lệch vận hành bằng HAZOP, khiếm khuyết tương tác·yêu cầu bằng STPA thì có thể khai thác rủi ro toàn diện từ các góc độ khác nhau. Từ góc độ Kỹ sư chuyên nghiệp (Professional Engineer), năng lực cốt lõi là thiết kế "dùng gì, khi nào, theo tổ hợp nào" phù hợp với tính chất hệ thống (tập trung HW vs thâm dụng SW).
Hãy áp dụng từ giai đoạn đầu phát triển để tối thiểu hóa chi phí. Chi phí sửa khiếm khuyết tăng theo cấp số nhân khi đi từ giai đoạn yêu cầu·thiết kế đến giai đoạn vận hành (thường là quy tắc 1:10:100). Rủi ro được phát hiện·loại bỏ ở giai đoạn thiết kế càng sớm thì càng đạt hiệu quả lớn với chi phí nhỏ, nên cần chiến lược Shift-Left tích hợp phân tích an toàn từ phía trái của mô hình V (yêu cầu·thiết kế).
Hãy liên kết nhất quán với các tiêu chuẩn an toàn chức năng. ISO 26262 (ô tô)·IEC 61508 (đa dụng)·IEC 62304 (y tế)·DO-178C (hàng không) yêu cầu kỹ thuật phân tích và mức kiểm chứng tương ứng với từng cấp toàn vẹn (ASIL·SIL). Kết quả phân tích cuối cùng được cấu trúc thành hồ sơ an toàn (Safety Case) để dùng cho chứng nhận·kiểm toán, nên việc lập tài liệu có khả năng truy vết (Traceability) phải được quản lý cùng như một sự đánh đổi.
Hãy xử lý tích hợp an toàn (Safety) và bảo mật (Security). Trong hệ thống kết nối·tự hành, tấn công dẫn thẳng đến tai nạn an toàn. Xu hướng đang tiến hóa theo hướng liên kết với ISO/SAE 21434 (an ninh mạng ô tô), ISO 21448 (SOTIF) để thực hiện tích hợp phân tích mối đe dọa (TARA) với phân tích an toàn.
Hãy vận hành phân tích như một hoạt động liên tục. Hệ thống được thay đổi·cập nhật và rủi ro cũng thay đổi theo. Trong thời đại mà hành vi thay đổi sau khi triển khai như OTA (cập nhật qua mạng không dây)·đưa vào chức năng dựa trên AI, cần có cơ chế phân tích lại liên tục (Continuous Safety Assurance) liên động với quản lý thay đổi (Change Management).

Tài liệu tham khảo

itemis, "Functional Safety: ISO 26262, IEC 61508, ASIL, Safety Case" — https://www.itemis.com/en/compliance-intelligence/functional-safety/
Wikipedia, "Automotive Safety Integrity Level(ASIL)" — https://en.wikipedia.org/wiki/Automotive_safety_integrity_level
UL Solutions, "Understanding STAMP, STPA, and CAST: Safety Engineering" — https://www.ul.com/sis/blog/introduction-to-stamp-stpa-and-cast
Software Quality Journal, "Comparison of the FMEA and STPA safety analysis methods" — https://dl.acm.org/doi/10.1007/s11219-017-9396-0

Tóm tắt một câu: Phân tích an toàn phần mềm phòng ngừa trước rủi ro của hệ thống an toàn thiết yếu ngay từ đầu giai đoạn thiết kế, dùng song song một cách bổ trợ FTA (đường dẫn tai nạn·xác suất từ trên xuống)·FMEA (hỏng hóc phần tử từ dưới lên·RPN)·HAZOP (sai lệch theo từ dẫn hướng)·STPA (lý thuyết hệ thống·tương tác), và tích hợp với các tiêu chuẩn an toàn chức năng như ISO 26262·IEC 61508 cùng bảo mật (TARA) để chứng minh bằng hồ sơ an toàn.