SIL4 đối với hệ thống liên khóa máy tính (CBI): Tại sao đạt được lại khó đến vậy?

Computer-Based Interlocking (hệ thống liên khóa máy tính, CBI) ngày càng thay thế hoặc tích hợp sâu với relay interlocking (liên khóa rơ-le) truyền thống trong các dự án đường sắt. Về bản chất, logic interlocking không phải điều gì quá bí ẩn: đó là tập hợp các quy tắc xác định khi nào một route (tuyến đường chạy tàu) được phép thiết lập, khi nào một signal (tín hiệu) được phép mở, và khi nào một point (ghi) được phép chuyển động. Bất kỳ kỹ sư tín hiệu nào có kinh nghiệm cũng có thể mô tả những quy tắc này trên giấy trong vài giờ.

Nhưng có một khoảng cách rất lớn giữa ba khái niệm tưởng như gần nhau: CBI chạy được, CBI an toàn, và CBI đạt SIL4 (Safety Integrity Level 4 — Mức toàn vẹn an toàn cấp 4). Một hệ thống có thể chạy đúng logic trong hàng nghìn lần test, được vận hành thử nghiệm suôn sẻ, và vẫn còn cách rất xa việc được công nhận là SIL4.

Câu hỏi trung tâm của bài viết này là:

Nếu một hệ thống CBI có thể thực hiện đúng logic interlocking, tại sao để đạt SIL4 lại khó đến vậy?

Câu trả lời ngắn gọn: SIL4 là bài toán chứng minh an toàn (proving safety), không chỉ là bài toán phát triển phần mềm hay phần cứng. Phần còn lại của bài sẽ bóc tách vì sao điều đó lại đúng, và những lớp công việc nào nằm giữa một CBI “chạy được” và một CBI “SIL4”.

CBI là gì và SIL4 có ý nghĩa gì đối với một hệ thống liên khóa?

CBI thực hiện công việc gì?

CBI thay thế logic relay bằng xử lý logic trên nền tảng máy tính. Nó xử lý các chức năng cốt lõi của một hệ thống liên khóa: route setting (thiết lập đường chạy), locking (khóa tuyến), release (giải phóng tuyến), signal control (điều khiển tín hiệu), và point control (điều khiển ghi). CBI giao tiếp với các thiết bị ngoài hiện trường – track circuit hoặc axle counter (mạch điện đường ray hoặc bộ đếm trục để phát hiện chiếm dụng đường ray), point machine (máy quay ghi), signal head (đèn tín hiệu) – thông qua các giao diện vào/ra hoặc mạng truyền thông.

SIL4 thực sự yêu cầu điều gì?

Một sai lầm phổ biến là hiểu SIL4 đơn giản là “một hệ thống rất an toàn”, hoặc tệ hơn, quy gọn nó về một con số xác suất duy nhất. Thực tế, SIL4 là mức toàn vẹn an toàn cao nhất trong bốn cấp SIL được sử dụng cho các hệ thống thuộc phạm vi áp dụng. Việc chứng minh SIL4 không chỉ dựa trên các chỉ tiêu xác suất đối với dangerous failure (lỗi nguy hiểm) — như Probability of Failure per Hour (PFH) hay Tolerable Hazard Rate (THR) — mà còn phụ thuộc vào các biện pháp kiểm soát systematic failure (lỗi hệ thống), quy trình phát triển, verification & validation, và toàn bộ bằng chứng an toàn xuyên suốt vòng đời hệ thống. Nói cách khác, “xác suất thấp” không đồng nghĩa với “đạt SIL4” — đặc biệt với software, nơi lỗi gần như luôn mang bản chất systematic chứ không phải random.

Cần phân biệt rõ ba khái niệm hay bị gộp lẫn:

• Functional performance (hiệu năng chức năng): hệ thống có làm đúng việc nó được thiết kế để làm hay không, trong điều kiện hoạt động bình thường.
• Safety performance (hiệu năng an toàn): hệ thống có ngăn được các trạng thái nguy hiểm hay không, kể cả khi có lỗi.
• Safety integrity (toàn vẹn an toàn): mức độ tin cậy — được chứng minh bằng bằng chứng định lượng và định tính — rằng safety performance sẽ được duy trì trong suốt vòng đời hệ thống.

SIL4 nằm ở lớp thứ ba. Một hệ thống có functional performance hoàn hảo vẫn có thể chưa đạt SIL4, vì SIL4 đòi hỏi bằng chứng có hệ thống, không chỉ đòi hỏi kết quả đúng.

Câu hỏi quan trọng nhất

CBI không chỉ phải làm đúng khi mọi thứ hoạt động bình thường; nó phải được thiết kế và chứng minh để không tạo ra trạng thái nguy hiểm khi xảy ra các lỗi có liên quan. Đây là nền tảng chi phối toàn bộ phần còn lại của bài viết.

Logic interlocking không phải phần khó nhất

Một CBI phải xử lý những gì?

Danh sách chức năng của một CBI khá dài nhưng quen thuộc với bất kỳ kỹ sư signalling nào: route selection (chọn tuyến), route setting (thiết lập tuyến), route locking (khóa tuyến), approach locking (khóa tiếp cận), route release (giải phóng tuyến), flank protection (bảo vệ sườn), overlap (đoạn dự phòng vượt quá tín hiệu), point detection (phát hiện vị trí ghi), track occupancy (chiếm dụng đường ray), signal control (điều khiển tín hiệu), conflicting route prevention (ngăn xung đột tuyến), và xử lý abnormal/failure conditions (điều kiện bất thường/lỗi).

Những logic này có thể lập trình được

Toàn bộ tập hợp quy tắc trên hoàn toàn có thể mô hình hóa, xây dựng thành thuật toán, viết thành software, mô phỏng, và test. Đây là phần mà hầu hết kỹ sư phần mềm có kinh nghiệm đều có thể làm được trong một khoảng thời gian hợp lý.

Nhưng đây mới là vấn đề

Viết được logic không có nghĩa là chứng minh được logic đó an toàn. Đây là điểm mấu chốt tạo ra khoảng cách giữa một CBI “chạy được” và một CBI SIL4. Từ đây dẫn ra một chuỗi yêu cầu bắt buộc:

Correct requirement (yêu cầu đúng) → Correct design (thiết kế đúng) → Correct implementation (triển khai đúng) → Correct verification (kiểm chứng đúng) → Correct validation (xác nhận đúng) → Safety evidence (bằng chứng an toàn).

Chỉ cần một mắt xích trong chuỗi này lỏng lẻo, toàn bộ safety case (hồ sơ luận chứng an toàn) sẽ bị đặt câu hỏi.

SIL4 không phải là một bài kiểm tra cuối dự án

Hiểu nhầm phổ biến

Nhiều đội phát triển hình dung quy trình SIL4 theo kiểu: Develop (phát triển) → Test (kiểm thử) → Pass (đạt) → SIL4. Đây là cách nghĩ dẫn đến thất bại gần như chắc chắn khi đối mặt với independent assessment (đánh giá độc lập).

Thực tế

Safety phải được xây dựng ngay từ đầu vòng đời dự án (lifecycle), theo trình tự:

Hazard Identification (Nhận diện mối nguy) → Safety Requirements (Yêu cầu an toàn) → System Architecture (Kiến trúc hệ thống) → Hardware/Software Design (Thiết kế phần cứng/phần mềm) → Implementation (Triển khai) → Verification (Kiểm chứng) → Validation (Xác nhận) → Safety Case (Hồ sơ an toàn) → Independent Assessment (Đánh giá độc lập).

Tại sao điều này quan trọng?

Một lỗi xuất hiện ngay từ bước requirement (yêu cầu) sẽ kéo theo hiệu ứng domino: Requirement error (lỗi yêu cầu) → Design error (lỗi thiết kế) → Software error (lỗi phần mềm) → Test không phát hiện được → Safety Case yếu. Càng phát hiện muộn, chi phí sửa càng lớn — và trong nhiều trường hợp, lỗi ở tầng requirement gần như không thể sửa triệt để chỉ bằng cách vá ở tầng code.

Thông điệp chính: SIL4 không phải một “đích đến” ở cuối dự án. Nó là một yêu cầu chi phối cách hệ thống được phát triển ngay từ ngày đầu tiên.

Bài toán cốt lõi: CBI phải kiểm soát trạng thái nguy hiểm

Khi mọi thứ bình thường

Trong điều kiện lý tưởng — có route request (yêu cầu tuyến), track clear (đường ray trống), points correctly detected (ghi được phát hiện đúng vị trí), không có conflicting route (tuyến xung đột), có flank protection và overlap khả dụng — route được thiết lập. Đây là kịch bản mà hầu hết các bài demo hay trình diễn sản phẩm tập trung vào, và cũng là kịch bản dễ đạt nhất.

Nhưng SIL4 hỏi câu khác

SIL4 không chỉ đặt câu hỏi hệ thống có làm đúng trong điều kiện bình thường hay không — functional correctness (tính đúng đắn về chức năng) vẫn là điều kiện tiên quyết, một CBI sai ngay ở normal operation thì không còn gì để bàn tiếp. Nhưng SIL4 còn đặt ra câu hỏi khó hơn nhiều: hệ thống sẽ phản ứng thế nào khi các lỗi và điều kiện bất thường xảy ra? Ví dụ: input sai, mất point detection, thông tin track circuit/axle counter bất thường, output bị lỗi, mất communication, memory error (lỗi bộ nhớ), processor failure (lỗi bộ xử lý), data inconsistency (dữ liệu không nhất quán), module failure (lỗi module).

Nguyên tắc Fail-safe

Nguyên tắc fail-safe (an toàn khi có lỗi) thường bị hiểu sai thành “hệ thống không bao giờ được lỗi”. Cách hiểu đúng là: khi lỗi xảy ra, hệ thống phải được thiết kế sao cho lỗi không dẫn tới trạng thái nguy hiểm, hoặc lỗi được phát hiện và hệ thống chuyển về trạng thái an toàn theo thiết kế (thường là restrictive state — trạng thái hạn chế, ví dụ tín hiệu về stop). Đây là khác biệt căn bản giữa tư duy “làm cho đúng” và tư duy “làm cho an toàn”.

Hardware CBI SIL4: Redundancy không đồng nghĩa với SIL4

Dual CPU không tự động tạo ra SIL4

Một hiểu nhầm rất phổ biến: có CPU A và CPU B chạy song song thì mặc nhiên đạt SIL4. Thực tế, 2 × CPU không tự động bằng SIL4.

Những câu hỏi phải trả lời

Redundancy (dự phòng) chỉ có giá trị khi trả lời được một loạt câu hỏi: Hai kênh (channel) có thực sự độc lập không? Có nguy cơ common cause failure — CCF (lỗi nguyên nhân chung, ví dụ cả hai kênh cùng lỗi vì cùng một nguyên nhân như nhiễu điện từ hoặc lỗi thiết kế chung) không? Làm thế nào để phát hiện output sai? Nếu hai kênh disagree (không khớp kết quả) thì hệ thống phản ứng ra sao? Cơ chế failure detection (phát hiện lỗi) hoạt động thế nào? Diagnostic coverage (độ phủ chẩn đoán) đạt bao nhiêu phần trăm? Fault reaction time (thời gian phản ứng khi có lỗi) là bao lâu? Có dangerous undetected failure (lỗi nguy hiểm không được phát hiện) nào còn sót lại không?

Từ architecture đến safety analysis

Để trả lời những câu hỏi trên, kiến trúc phần cứng phải được đánh giá thông qua các công cụ phân tích an toàn chuẩn: FMEA (Failure Mode and Effects Analysis — Phân tích dạng lỗi và ảnh hưởng), FTA (Fault Tree Analysis — Phân tích cây lỗi), failure rate (tỷ lệ lỗi), diagnostic coverage, common cause failure, independence (tính độc lập), và fault detection.

Thông điệp chính: Redundancy giúp tăng khả năng chịu lỗi, nhưng chỉ khi toàn bộ kiến trúc và cơ chế phát hiện lỗi được chứng minh phù hợp với mục tiêu safety — không phải chỉ vì có “hai bộ” phần cứng.

Software: Bức tường lớn nhất của CBI SIL4

Software safety khác software thông thường

Phát triển software cho CBI SIL4 không chỉ hỏi “Software có chạy đúng không?” mà hỏi một câu khó hơn nhiều: “Có bằng chứng nào cho thấy software không tạo ra dangerous behaviour (hành vi nguy hiểm) trong phạm vi đã xác định?” Đây là sự khác biệt giữa kiểm thử chức năng thông thường và safety-critical software engineering.

Các nguồn systematic error

Phần lớn lỗi trong software an toàn không đến từ “bug ngẫu nhiên” mà từ systematic error (lỗi hệ thống, có nguồn gốc từ quá trình phát triển): incorrect requirement (yêu cầu sai), ambiguous requirement (yêu cầu mơ hồ), design error, algorithm error, coding error, interface error, data error, configuration error, và change management error (lỗi trong quản lý thay đổi).

Requirements Traceability

Một trong những công cụ then chốt để kiểm soát các lỗi trên là requirements traceability (khả năng truy xuất nguồn gốc yêu cầu), thể hiện qua chuỗi:

Safety Requirement → System Requirement → Software Requirement → Design → Source Code → Test Case → Test Result.

Câu hỏi quan trọng

Câu hỏi mà bất kỳ safety assessor nào cũng sẽ đặt ra: Có thể truy xuất một yêu cầu safety từ lúc nó được xác định cho đến khi có bằng chứng chứng minh nó đã được verify/validate hay không? Nếu không trả lời được, dù software chạy đúng 100% trong test, nó vẫn chưa có đủ evidence để được công nhận SIL4. Đây chính là điểm phân định giữa một coding project thông thường và một safety-critical engineering project.

CBI SIL4 không chỉ là câu chuyện của phần mềm

Một CBI là một hệ thống gồm nhiều lớp: application software (phần mềm ứng dụng) → interlocking platform (nền tảng liên khóa) → processor/hardware (bộ xử lý/phần cứng) → I/O (vào/ra) → communication (truyền thông) → field interface (giao diện hiện trường) → signalling equipment (thiết bị tín hiệu).

Một safety function chỉ thực sự an toàn khi toàn bộ chain (chuỗi) liên quan đến safety function đó được xem xét đầy đủ. Ví dụ, software có thể tính toán đúng route, nhưng nếu interface hoặc output stage (tầng xuất tín hiệu ra thiết bị) có khả năng tạo ra trạng thái nguy hiểm, thì không thể chỉ nhìn vào source code (mã nguồn) rồi kết luận hệ thống an toàn.

Đây là lý do vì sao safety của CBI phải được xem xét ở cấp system (hệ thống), chứ không thể đánh giá chỉ bằng chất lượng của phần mềm — dù phần mềm thường là nơi tốn nhiều công sức nhất trong quá trình phát triển.

Test 10.000 lần vẫn chưa chắc chứng minh được SIL4

Functional test

Chạy hàng loạt functional test — Route A PASS, Route B PASS, Point reverse PASS, Signal clear PASS — mang lại cảm giác an tâm, nhưng đây mới chỉ là phần dễ nhất của bức tranh.

Nhưng còn abnormal conditions

Phần khó và tốn công hơn nhiều nằm ở test cho abnormal conditions (điều kiện bất thường): missing input, invalid input, communication loss, point detection failure, track occupancy anomaly, module failure, memory failure, power failure, data corruption. Đây là nơi phần lớn dangerous failure ẩn náu.

Quan trọng nhất: Test phải có nguồn gốc

Test case không nên xuất phát từ việc “kỹ sư nghĩ ra”. Nó phải xuất phát từ một chuỗi có thể truy xuất: Hazard/Requirement → Test Objective → Test Case → Result → Evidence. Nếu một test case không truy được về một hazard hay requirement cụ thể, giá trị làm bằng chứng an toàn của nó gần như bằng không, dù nó vẫn hữu ích để bắt bug thông thường.

Coverage không chỉ là “bao nhiêu test case”

Coverage (độ phủ) cần được nhìn ở nhiều lớp: requirements coverage, functional coverage, structural coverage (độ phủ cấu trúc mã nguồn), boundary conditions (điều kiện biên), và fault scenarios (kịch bản lỗi).

Thông điệp chính: Nhiều test không đồng nghĩa với đủ bằng chứng safety. Một bộ 10.000 test case không có traceability rõ ràng có giá trị thấp hơn nhiều so với 500 test case được thiết kế trực tiếp từ hazard analysis.

Safety Case: “Cuốn sách” chứng minh CBI an toàn

Safety Case là gì?

Safety Case (hồ sơ luận chứng an toàn) có thể đơn giản hóa thành ba thành phần:

• Claim (luận điểm): CBI đáp ứng mục tiêu safety.
• Argument (lập luận): Vì sao có thể tin claim đó là đúng?
• Evidence (bằng chứng): Bằng chứng cụ thể nào chứng minh lập luận đó?

Evidence có thể đến từ đâu?

Bằng chứng trong một Safety Case đến từ nhiều nguồn: hazard analysis, safety requirements, system architecture, hardware design, software development, verification, validation, testing, FMEA/FTA, configuration management (quản lý cấu hình), change management, safety analysis, và assessment report.

Điểm rất quan trọng

Safety Case không phải một báo cáo được viết ra sau khi sản phẩm đã hoàn thành, như một dạng “giấy chứng nhận xin sau”. Nó phải được xây dựng song song với toàn bộ quá trình phát triển — mỗi quyết định thiết kế, mỗi thay đổi requirement, đều cần được phản ánh và cập nhật trong Safety Case gần như đồng thời.

Independent Safety Assessment: Khi người khác bắt đầu đặt câu hỏi khó

Tại sao cần độc lập?

Nhóm phát triển không nên — và theo các tiêu chuẩn ngành, không được phép — tự mình là bên duy nhất kết luận hệ thống của chính mình an toàn. Đây là lý do independent safety assessment (đánh giá an toàn độc lập) tồn tại như một lớp kiểm soát bắt buộc.

Những câu hỏi assessor có thể đặt ra

Một independent assessor thường sẽ hỏi những câu rất cụ thể: Requirement này xuất phát từ đâu? Hazard này đã được nhận diện chưa? Tại sao architecture này đủ an toàn? Nếu module này fail thì sao? Test case này chứng minh requirement nào? Có requirement nào chưa verify không? Change này đã đánh giá safety impact (ảnh hưởng đến an toàn) chưa? Evidence cho claim này ở đâu?

Prototype và safety product khác nhau ở đây

Một prototype có thể RUN (chạy được), nhưng assessor cần thấy hệ thống được PROVEN (chứng minh được) — hai trạng thái hoàn toàn khác nhau về bản chất bằng chứng, dù kết quả vận hành trên bề mặt có thể trông giống hệt nhau.

Từ Prototype CBI đến CBI SIL4: Khoảng cách nằm ở đâu?

Có thể hình dung quá trình này như một maturity ladder (thang trưởng thành):

Simulation (mô phỏng — chứng minh logic) → Prototype (chứng minh concept) → Functional CBI (thực hiện đầy đủ chức năng) → Safety-oriented CBI (áp dụng safety engineering) → SIL4 Development (lifecycle đầy đủ + V&V + safety process) → Safety Case & Independent Safety Assessment → Assessed/accepted for the defined scope (được đánh giá và chấp nhận trong phạm vi xác định).

Điểm cần nhấn mạnh: không nên hình dung con đường này là “Prototype → Certified” như một bước nhảy — và ngay cả từ “Certified” cũng cần dùng cẩn thận. Assessment và certification phụ thuộc vào scheme, tiêu chuẩn áp dụng, phạm vi đánh giá, và cơ quan đánh giá/chứng nhận cụ thể; không có một công thức chung “được assess xong là certified” áp dụng cho mọi trường hợp. Giữa “chạy tốt” và “được chấp nhận trong phạm vi xác định” là nhiều lớp công việc — safety engineering, V&V có hệ thống, configuration management, independent assessment — mà nếu thiếu bất kỳ lớp nào, hệ thống sẽ mãi dừng lại ở mức đầu.

Vậy một CBI mới có thể đạt SIL4 không?

Câu trả lời là có. Nhưng SIL4 không phải bài toán “viết một CBI tốt hơn”. Nó là bài toán xây dựng đồng thời: CBI + Safety Engineering + Development Process + V&V + RAMS + Safety Case + Independent Assessment.

Những năng lực cần có

Để đi hết con đường này, tổ chức cần hội tụ nhiều mảng năng lực: signalling engineering, system engineering, safety engineering, hardware engineering, safety-critical software engineering, RAMS (Reliability, Availability, Maintainability, Safety — Độ tin cậy, Khả dụng, Khả năng bảo trì, An toàn), verification & validation, configuration management, quality management, và safety assessment.

Đây là bài toán tổ chức chứ không chỉ bài toán kỹ thuật

Một đội rất giỏi coding nhưng thiếu safety process, thiếu independent assessment, thiếu configuration management, thiếu traceability, vẫn rất khó xây dựng được một sản phẩm SIL4 có thể chứng minh được — bất kể chất lượng code có tốt đến đâu. Nói cách khác, việc phát triển một sản phẩm CBI hướng tới SIL4 đòi hỏi không chỉ năng lực kỹ thuật mà còn một năng lực tổ chức đủ trưởng thành để duy trì các quy trình safety, configuration management, traceability, V&V và assessment trong suốt vòng đời.

Một phép so sánh đơn giản: “CBI chạy được” vs “CBI hướng tới SIL4”

Câu hỏi cuối cùng: “Có đáng để làm SIL4 không?”

SIL4 mang lại gì?

SIL4 mang lại mức độ tin cậy safety cao, khả năng chứng minh bằng evidence, khả năng triển khai trong các hệ thống yêu cầu safety integrity cao, và tạo nền tảng cho sản phẩm có thể sử dụng rộng hơn — kể cả ở các thị trường có yêu cầu chứng nhận khắt khe.

Đổi lại là gì?

Cái giá phải trả không nhỏ: chi phí phát triển, thời gian, nhân lực chuyên môn, quy trình nghiêm ngặt, khối lượng documentation lớn, verification & validation kéo dài, assessment độc lập, và chi phí duy trì lifecycle maintenance sau khi hệ thống đã đưa vào vận hành.

Câu hỏi thực tế

Câu hỏi đáng đặt ra không phải là:

“Có làm được SIL4 không?”

mà là:

“Tổ chức có đủ năng lực, quy trình, nguồn lực và thời gian để xây dựng và duy trì toàn bộ safety evidence hay không?”

Kết luận

SIL4 không phải là một chiếc tem được dán lên CBI sau khi sản phẩm hoàn thành. Nó là kết quả của cả một chuỗi công việc liên tục:

Requirement → Hazard → Architecture → Implementation → Verification → Validation → Safety Case → Independent Assessment.

Và vì vậy: “làm được CBI” và “làm được CBI SIL4” là hai bài toán hoàn toàn khác nhau.

The difficult part of SIL4 is not making the system work. It is building enough evidence to prove that it is safe.

Hay nói theo ngôn ngữ của người làm signalling: A CBI can be engineered to work. A SIL4 CBI must be engineered so that its safety can be demonstrated.