Lộ trình làm chủ công nghệ CBI SIL4: Một quốc gia mới bắt đầu cần làm gì trong 3 năm đầu?
Hãy hình dung một cuộc họp quyết định chuyển sang hệ thống liên khóa máy tính (Computer-Based Interlocking, CBI). Câu hỏi đầu tiên gần như luôn là: mua của ai, giá bao nhiêu, bao lâu thì có? Đó là những câu hỏi cần thiết. Nhưng có một câu hỏi thứ hai ít khi được đặt ra đủ sớm: ba năm, năm năm sau khi hệ thống đã chạy, khi cần thay đổi một dữ liệu, sửa một giao diện hay xử lý một sự cố liên quan đến an toàn, ai sẽ là người chịu trách nhiệm và đủ năng lực để làm việc đó?
Bài viết này là một nỗ lực trả lời câu hỏi thứ hai. Cần nói rõ ngay từ đầu: 3 năm mà bài nhắc đến là thời gian để một quốc gia xây năng lực và chứng minh được ở tầng ứng dụng, chứ không phải lời hứa rằng sau 3 năm ta tự phát triển xong một sản phẩm CBI SIL4. Vì sao ranh giới này quan trọng, phần sau sẽ nói rõ.
Vì sao một quốc gia mới bắt đầu cần một lộ trình riêng?
Có một cách nghĩ rất tự nhiên: chưa có CBI thì thiếu một sản phẩm, cứ mua về là xong. Nhưng hãy so sánh với việc sở hữu một chiếc xe. Mua xe về, ta có phương tiện. Nhưng nếu ta không có xưởng, không có thợ, không có quy trình bảo dưỡng và không ai hiểu vì sao phanh được thiết kế như vậy, thì mỗi lần trục trặc ta đều phải gọi người khác đến. Với xe cá nhân, điều đó chỉ tốn tiền. Với hệ thống liên khóa, một thay đổi không được phân tích an toàn đúng cách có thể ảnh hưởng trực tiếp đến an toàn chạy tàu.
Cái mà một quốc gia mới bắt đầu thường thiếu không phải là source code, mà là cả một hệ sinh thái xung quanh nó: quy trình quản lý vòng đời an toàn, hazard log, quản lý thay đổi và cấu hình đủ chặt để chịu được đánh giá độc lập, năng lực verification & validation (V&V), và kinh nghiệm đứng ở cả hai phía của một đợt independent safety assessment. Những thứ này không mua được bằng một hợp đồng. Chúng chỉ hình thành qua việc làm thật, làm đủ lâu và làm có kiểm soát. Đó là lý do một lộ trình riêng là cần thiết.
“Đạt SIL4” thực ra có nghĩa là gì?
Trước khi bàn đến lộ trình, cần tách hai đối tượng thường bị gộp lẫn làm một.
Đối tượng thứ nhất là generic product, tức nền tảng CBI, gồm phần cứng, phần mềm nền và bộ công cụ, được phát triển và đánh giá an toàn như một sản phẩm dùng được cho nhiều ứng dụng. Đối tượng thứ hai là specific application, tức việc cấu hình nền tảng đó cho một ga hay một tuyến cụ thể: dữ liệu ứng dụng, giao diện với thiết bị hiện trường, và các điều kiện an toàn mà ứng dụng bắt buộc phải tuân thủ (thường gọi là SRAC). Theo cách tiếp cận của họ tiêu chuẩn CENELEC, an toàn của hai đối tượng này được lập luận ở những phần hồ sơ khác nhau.
Ví von cho dễ nhớ: generic product giống một loại động cơ đã được thiết kế và kiểm định, còn specific application giống việc lắp động cơ đó vào một chiếc xe cụ thể, với hộp số, hệ thống phanh và điều kiện vận hành riêng. Động cơ tốt chưa đảm bảo chiếc xe an toàn nếu việc lắp ráp sai.
Từ đây có một hệ quả rất quan trọng: một quốc gia hoàn toàn có thể triển khai và chịu trách nhiệm về một ứng dụng CBI theo yêu cầu SIL4 mà không cần tự phát triển sản phẩm generic, miễn là sản phẩm được chọn đã được đánh giá phù hợp và quốc gia đó làm đúng phần việc của tầng ứng dụng. Ngược lại, muốn sở hữu và tiến hóa chính sản phẩm generic thì đó là một năng lực khác hẳn, đòi hỏi thời gian dài hơn nhiều. Nếu bạn cần đọc kỹ hơn về khái niệm SIL, hãy xem SIL trong đường sắt ở phần RAMS & SIL.
SIL4 khó ở đâu?
Phần này đã có một bài riêng (SIL4 đối với CBI: Tại sao đạt được lại khó đến vậy?), nên ở đây chỉ tóm tắt. Cái khó của SIL4 nằm ở chỗ nó là bài toán chứng minh chứ không chỉ là bài toán xây dựng. Yêu cầu an toàn phải đúng, đủ và truy xuất được, vì một lỗi ở đây sẽ lan xuống mọi khâu sau. Kiến trúc phải chứng minh được tính độc lập và cơ chế phát hiện lỗi, chứ có hai bộ xử lý chưa tự động là SIL4. Lỗi ngẫu nhiên của phần cứng được kiểm soát bằng chỉ tiêu định lượng, còn lỗi hệ thống của quá trình phát triển được kiểm soát bằng quy trình. Việc kiểm thử phải truy xuất được về từng hazard và từng yêu cầu. Và cuối cùng, tất cả phải hội tụ trong một Safety Case đứng vững trước một bên đánh giá độc lập.
Điều cần mang theo khi đọc phần lộ trình phía dưới là: năm mảng công việc này không thể dồn về cuối dự án. Chúng phải được xây song song ngay từ đầu.
Ba tầng làm chủ công nghệ CBI
“Làm chủ CBI” không phải một trạng thái duy nhất mà là một chuỗi các mức độ. Cách dễ hiểu nhất để phân chia là hỏi: ai chịu trách nhiệm về an toàn ở mức nào?
Ở tầng thứ nhất, năng lực ứng dụng, ta chịu trách nhiệm an toàn cho một ứng dụng cụ thể. Ta biết thiết kế dữ liệu ứng dụng, cấu hình liên khóa, kiểm soát giao diện với thiết bị hiện trường, kiểm thử, đưa vào vận hành, bảo trì và xử lý sự cố. Điều quan trọng nhất mà bài viết nào về chủ đề này cũng dễ bỏ sót là: ta còn phải tự xây được Safety Case cho ứng dụng đó, không chỉ vận hành nó.
Ở tầng thứ hai, năng lực nền tảng, ta hiểu sâu bên trong: kiến trúc phần cứng và phần mềm, giao diện vital và non-vital, I/O, truyền thông, chẩn đoán, công cụ engineering. Ta đủ hiểu để phân tích tác động an toàn khi có thay đổi hoặc khi nội địa hóa một phần của nền tảng.
Ở tầng thứ ba, năng lực sản phẩm generic, ta sở hữu Safety Case của cả sản phẩm. Ta xác định generic requirements, phát triển nền tảng, vận hành đầy đủ vòng đời an toàn, làm việc trực tiếp với assessor và đưa sản phẩm qua nhiều phiên bản.
Luận điểm quan trọng nhất của bài viết này là không nên nhảy thẳng từ tầng một lên tầng ba. Một đội ngũ chưa từng chịu trách nhiệm an toàn cho một ứng dụng thực, chưa từng bị assessor đặt câu hỏi khó về từng dòng bằng chứng, sẽ rất khó tự xây được cả một Safety Case cho nền tảng. Tầng hai chính là cầu nối: nó chuyển ta từ chỗ “dùng đúng” sang chỗ “hiểu đủ sâu để thay đổi có kiểm soát”.
Mua, chuyển giao hay tự phát triển: chọn theo từng thành phần
Khi nói đến việc tiếp cận công nghệ, người ta thường nghĩ đến ba con đường: mua, chuyển giao công nghệ, hoặc tự phát triển. Cách đặt vấn đề này dễ khiến ta phải chọn một trong ba cho toàn bộ chương trình. Thực tế hợp lý hơn nhiều là chọn con đường khác nhau cho từng thành phần, và luôn nhớ một điều: mua một sản phẩm và làm chủ một công nghệ là hai mục tiêu khác nhau.
Với phần dữ liệu ứng dụng và application engineering, nên tự làm ngay từ đầu, kèm đào tạo và giám sát từ đối tác, vì đây là tầng nhanh làm chủ nhất và cũng là tầng bắt buộc phải có. Môi trường kiểm thử và mô phỏng cũng nên tự xây, bởi nếu phụ thuộc hoàn toàn vào môi trường của nhà cung cấp, ta không thể tự chứng minh điều gì. Với công cụ engineering, cách hợp lý là license, nhưng có yêu cầu rõ về việc hiểu và kiểm soát cấu hình cách sử dụng. Những phần dễ phát sinh lỗi tích hợp như I/O, giao diện hiện trường, chẩn đoán và bảo trì thì nên ưu tiên chuyển giao thực chất. Còn nền tảng phần cứng, phần mềm nền và phần mềm generic, ở giai đoạn đầu nên mua hoặc license một sản phẩm đã có đánh giá, rồi chuyển giao dần theo lộ trình, và coi việc tự phát triển là mục tiêu dài hạn cần năng lực tầng hai làm nền. Riêng safety process và Safety Case thì không có lựa chọn nào khác ngoài tự xây, có thể nhờ một assessor độc lập bên ngoài đồng hành trong giai đoạn đầu.
Khi thương lượng chuyển giao, có ba cái bẫy đáng nhớ. Thứ nhất là chuyển giao hình thức: nhận một chồng tài liệu chưa chắc đã hiểu, nên cần đào tạo, làm việc chung trên dự án thật và tiêu chí nghiệm thu kiến thức rõ ràng. Thứ hai là phạm vi sửa đổi: một sản phẩm đã được đánh giá, nếu bị sửa mà không phân tích và đánh giá lại tác động an toàn, có thể làm mất hiệu lực của chính đánh giá đó. Thứ ba là quyền truy cập và chủ quyền dữ liệu: ta cần biết rõ mình được truy cập source code và tài liệu thiết kế đến đâu, dữ liệu ứng dụng thuộc về ai, và khi nhà cung cấp không còn hỗ trợ trực tiếp thì ai bảo trì.
Lộ trình 3 năm nhìn như một câu chuyện
Thay vì một bảng công việc, có thể hình dung 3 năm như ba chương nối tiếp nhau, mỗi chương trả lời một câu hỏi khác.
Năm thứ nhất trả lời câu hỏi: “Ta chọn đi đường nào, và ta có đủ nền để bắt đầu không?” Đây là năm của những quyết định quyết định thành bại cả chương trình. Ta chọn chiến lược và đối tác, ký các thỏa thuận chuyển giao có tiêu chí nghiệm thu cụ thể. Ta chốt hệ tiêu chuẩn áp dụng và phiên bản hiện hành (chẳng hạn họ EN 50126, EN 50129, EN 50716) cùng với cơ quan có thẩm quyền về an toàn đường sắt. Ta dựng tổ chức safety với các vai trò cốt lõi: safety manager, system, hardware, software, V&V, quality, quản lý cấu hình. Và có một việc rất dễ bị dời lại nhưng nên làm ngay: chọn tổ chức đánh giá an toàn độc lập từ đầu, vì đánh giá độc lập tham gia theo vòng đời thì rẻ và hiệu quả hơn nhiều so với đến cuối mới gặp. Hazard log, cơ chế truy xuất yêu cầu và quản lý thay đổi cũng cần được khởi tạo ngay trong năm này. Kết quả mong đợi không phải là một sản phẩm, mà là một tổ chức có quy trình an toàn hoạt động được.
Năm thứ hai trả lời câu hỏi: “Ta có làm được một ứng dụng thật, dưới sự kiểm soát an toàn không?” Đây là năm chuyển từ học sang làm. Ta xây quy trình application engineering và kiểm soát lỗi dữ liệu, dựng phòng lab và môi trường mô phỏng, rồi thiết kế ứng dụng cho một ga pilot với đầy đủ giao diện thực tế: relay, track circuit hoặc axle counter, thiết bị hiện trường. Ta thực hiện V&V có hệ thống cho ứng dụng đó. Và điều quan trọng nhất của năm này là Safety Case cho ứng dụng được xây song song với thiết kế, chứ không phải đợi thiết kế xong mới viết. Cùng lúc, đội ngũ bắt đầu chạm vào tầng hai: hiểu sâu I/O, giao diện và chẩn đoán.
Năm thứ ba trả lời câu hỏi: “Ta có chứng minh và được chấp nhận không?” Ứng dụng pilot đi qua FAT, SAT và tích hợp hiện trường, rồi cutover từ hệ thống cũ sang CBI với kế hoạch bảo đảm an toàn khai thác trong suốt quá trình. Independent Safety Assessment được thực hiện, hồ sơ được hoàn thiện và đi qua quy trình chấp nhận với cơ quan có thẩm quyền. Cuối năm, đội ngũ đánh giá lại năng lực của mình và xác định phần nào của tầng hai nên được nội địa hóa tiếp theo.
Cần nói thẳng về điều kiện: kết quả của năm thứ ba phụ thuộc vào việc sản phẩm generic được chọn đã có đánh giá phù hợp, vào lịch làm việc của cơ quan thẩm định và tổ chức đánh giá độc lập, và vào khung pháp lý về chấp nhận sản phẩm. Việc “chấp nhận trong phạm vi nào” còn phụ thuộc scheme, tiêu chuẩn áp dụng và cơ quan đánh giá. Vì vậy đây là một mục tiêu có điều kiện, không phải một cam kết tuyệt đối.
Những rào cản thường gặp và cách nhìn chúng
Nhìn qua nhiều chương trình chuyển đổi công nghệ, có năm rào cản lặp đi lặp lại.
Rào cản đầu tiên là thiếu chuyên gia và văn hóa an toàn chưa trưởng thành: có những kỹ sư giỏi nhưng chưa quen làm việc theo vòng đời an toàn. Cách giảm rủi ro là dùng đối tác và assessor có kinh nghiệm trong giai đoạn đầu, đồng thời có kế hoạch rõ để chuyển giao dần năng lực. Rào cản thứ hai là phụ thuộc nhà cung cấp: có sản phẩm nhưng không hiểu nền tảng, mọi thay đổi đều phải nhờ bên ngoài. Điều này được xử lý ngay từ hợp đồng, bằng các điều khoản chuyển giao và quyền truy cập, và bằng việc theo dõi mức phụ thuộc như một chỉ số.
Rào cản thứ ba là thiếu năng lực V&V và assessment: làm được hệ thống nhưng không chứng minh được. Cách xử lý là dựng môi trường kiểm thử độc lập từ sớm và đòi hỏi truy xuất yêu cầu ngay từ ngày đầu. Rào cản thứ tư là khung pháp lý và tiêu chuẩn chấp nhận chưa quen với CBI: quy trình thẩm định có thể chưa có tiền lệ, dẫn đến kéo dài thời gian và thiếu tiêu chí rõ. Lời khuyên là làm việc sớm với cơ quan có thẩm quyền, thống nhất tiêu chuẩn và cách chấp nhận trước khi thiết kế ứng dụng, chứ không đợi đến khi nộp hồ sơ.
Rào cản cuối cùng, và có lẽ là nguy hiểm nhất vì nó xuất phát từ sự nhiệt huyết, là scope creep: muốn làm CBI, ATP, ETCS, RBC cùng lúc ngay từ đầu. Với chỉ 3 năm và nền tảng còn hạn chế, cách an toàn nhất là chỉ tập trung vào CBI ở một ứng dụng pilot.
Làm sao biết chương trình đang đi đúng hướng?
Một chương trình có thể “đúng tiến độ” trên giấy mà vẫn lệch về bản chất. Vì vậy nên theo dõi năng lực thay vì chỉ theo dõi tiến độ. Về con người, cần nhìn số kỹ sư thực sự có năng lực CBI, số người hiểu vòng đời an toàn và số người có kinh nghiệm V&V. Về engineering, cần nhìn mức độ truy xuất yêu cầu, kiểm soát cấu hình, độ phủ test và tốc độ đóng defect. Về an toàn, cần nhìn độ trưởng thành của hazard log, độ đầy đủ của safety requirements và bằng chứng, cũng như các phát hiện từ assessment. Về công nghệ, cần nhìn mức phụ thuộc nhà cung cấp, mức hiểu nền tảng, số thành phần đã nội địa hóa và năng lực công cụ engineering. Nếu những chỉ số này không tiến triển sau mỗi giai đoạn thì lộ trình đang lệch, dù dự án vẫn trông như đang chạy tốt.
Sau năm thứ ba: con đường tới sản phẩm generic
Kết thúc năm thứ ba không có nghĩa là hành trình đã hoàn tất. Nếu mục tiêu dài hạn là làm chủ cả sản phẩm generic, chuỗi công việc tiếp theo là xác định generic requirements, phát triển sản phẩm, V&V sản phẩm, xây Safety Case, đánh giá độc lập và chấp nhận trong phạm vi xác định. Đó là một chương trình khác về quy mô so với việc triển khai một ứng dụng. Bài này cố ý không gắn số năm cho giai đoạn đó, vì thời gian phụ thuộc nhiều vào năng lực đã tích lũy, mức đầu tư và phạm vi sản phẩm. Điều quan trọng là quyết định có đi tiếp hay không nên dựa vào các chỉ số năng lực ở phần trước, chứ không chỉ dựa vào việc ứng dụng pilot đã chạy được.
Kết luận
Nếu phải rút toàn bộ bài viết thành vài ý, thì đó là thế này. Đạt được một ứng dụng CBI theo yêu cầu SIL4 trong 3 năm là mục tiêu có điều kiện nhưng khả thi, nếu chọn đúng chiến lược và bắt đầu xây năng lực an toàn ngay từ năm đầu. Còn làm chủ cả sản phẩm generic là một hành trình dài hơn, và cần được đi qua từng tầng chứ không nhảy cóc. Mua một sản phẩm không đồng nghĩa với làm chủ công nghệ: làm chủ được đo bằng khả năng chịu trách nhiệm về an toàn và hiểu đủ sâu để kiểm soát thay đổi. Và trên hết, Safety Case cùng đánh giá độc lập không phải công việc cuối dự án, mà là thứ được xây cùng từng quyết định kỹ thuật từ ngày đầu.
