Application data, Safety Case và tầng ứng dụng: nơi làm chủ CBI nhanh nhất
Trong lộ trình làm chủ CBI SIL4, tầng ứng dụng là tầng đầu tiên trong ba tầng làm chủ, và cũng là tầng mà một quốc gia mới bắt đầu có thể nắm được sớm nhất. Bài này đi sâu vào tầng đó: điều gì thực sự nằm trong trách nhiệm của người triển khai một ứng dụng CBI, và vì sao dữ liệu ứng dụng cùng Safety Case của ứng dụng lại là hai thứ cần được coi trọng ngang với phần mềm.
Vì sao tầng ứng dụng là nơi làm chủ nhanh nhất?
Có ba lý do. Thứ nhất, phần việc ở tầng này gần với kiến thức tín hiệu mà một quốc gia đã có: nguyên tắc liên khóa, sơ đồ ga, quy tắc chạy tàu, cách các thiết bị hiện trường hoạt động. Ta không phải học lại từ đầu mà chuyển kiến thức đó sang một môi trường mới. Thứ hai, tầng ứng dụng không đòi hỏi phải thay đổi sản phẩm generic, nên không phải đánh giá lại nền tảng. Thứ ba, đây là nơi mỗi ứng dụng mới đều tạo ra kinh nghiệm mới: mỗi ga pilot là một vòng học có kiểm soát.
Nhưng nhanh không có nghĩa là dễ. Hai cấu phần quyết định chất lượng ở tầng này đều là những thứ dễ bị đánh giá thấp: application data và Safety Case cho ứng dụng.
Generic product, generic application, specific application
Để đọc bài này, cần nhắc lại ba khái niệm. Generic product là nền tảng CBI dùng được cho nhiều ứng dụng. Generic application là một lớp ứng dụng được xác định chung, chẳng hạn cấu hình liên khóa cho một loại ga hay một kiểu quy tắc chạy tàu, với các quy tắc thiết kế và dữ liệu dùng lại được. Specific application là một ga hoặc một tuyến cụ thể, với sơ đồ, số lượng thiết bị và điều kiện hiện trường riêng.
Theo cách tiếp cận của họ tiêu chuẩn CENELEC, an toàn của từng lớp được lập luận trong một hồ sơ riêng, và hồ sơ ở lớp trên dựa vào hồ sơ ở lớp dưới. Nói cách khác, Safety Case của một ga cụ thể không viết lại toàn bộ lập luận về nền tảng. Nó viện dẫn Safety Case của sản phẩm generic và chứng minh rằng ứng dụng này sử dụng sản phẩm đúng như điều kiện đã quy định. Đây chính là lý do tầng ứng dụng khả thi cho một quốc gia mới: ta chịu trách nhiệm phần của mình mà không phải gánh cả nền tảng.
Từ hazard analysis đến safety requirements cho một ứng dụng
Một ứng dụng cụ thể không bắt đầu từ việc vẽ sơ đồ, mà từ câu hỏi: ở ga này, với thiết bị và cách khai thác này, những trạng thái nguy hiểm nào có thể xảy ra? Ví dụ điển hình là hai tuyến xung đột cùng được thiết lập, ghi chuyển khi tàu còn đang ở trên, hoặc tín hiệu mở khi tuyến chưa được chứng minh đã an toàn. Mỗi mối nguy đó được ghi vào hazard log, đánh giá mức rủi ro, rồi chuyển thành các safety requirement gắn với từng chức năng liên khóa.
Điểm cần lưu ý là hazard analysis ở cấp ứng dụng không làm lại phân tích của nhà cung cấp cho sản phẩm generic. Nó bổ sung những mối nguy phát sinh từ chính ứng dụng này: bố trí ga, giao diện với thiết bị cũ, các đặc thù khai thác. Nếu hazard log của ứng dụng chỉ sao chép lại từ hồ sơ sản phẩm, ta đã bỏ qua đúng những chỗ mà nhà cung cấp không thể biết thay ta.
Application data và cách kiểm soát lỗi dữ liệu
Hãy nghĩ về application data như “bản đồ” mà nền tảng dùng để hiểu ga: vị trí tín hiệu, ghi, đoạn đường ray, các tuyến hợp lệ và điều kiện liên khóa của từng tuyến. Nền tảng có thể hoàn toàn đúng, nhưng nếu bản đồ sai một chi tiết thì hệ thống vẫn hành xử sai, và sai theo cách trông rất bình thường.
Vì vậy dữ liệu ứng dụng thường được xếp vào nhóm lỗi hệ thống (systematic failure) mà quy trình phải kiểm soát. Ở mức nguyên tắc, một quy trình data tốt thường có bốn đặc điểm. Dữ liệu được xây từ một đặc tả rõ ràng, không từ trí nhớ của người thiết kế. Quá trình tạo dữ liệu được kiểm soát cấu hình, có phiên bản và có dấu vết thay đổi. Dữ liệu được kiểm tra độc lập, bởi người hoặc công cụ khác với người hoặc công cụ đã tạo ra nó. Và dữ liệu được kiểm chứng bằng mô phỏng hoặc thử nghiệm trước khi đưa vào hiện trường.
Mức độ chặt chẽ cụ thể, kể cả yêu cầu về công cụ và về kiểm tra chéo, còn phụ thuộc vào tài liệu của sản phẩm generic (thường nằm trong SRAC của nó) và phiên bản tiêu chuẩn áp dụng, nên bạn cần đối chiếu với hồ sơ cụ thể chứ không thể chỉ dựa vào mô tả chung này.
Giao diện với hạ tầng hiện hữu
Với một quốc gia đang chuyển từ liên khóa rơ-le sang CBI, phần lớn thiết bị hiện trường vẫn là thiết bị cũ: mạch điện đường ray hoặc bộ đếm trục, máy chuyển ghi, đèn tín hiệu, cáp và hệ thống cấp nguồn. CBI phải đọc trạng thái từ chúng và điều khiển chúng thông qua các giao diện vào/ra.
Đây là một trong những nơi rủi ro tập trung, vì sản phẩm generic được đánh giá với những giả định về thiết bị mà nó giao tiếp: cách thiết bị báo lỗi, độ tin cậy của tín hiệu, đặc tính cách ly điện, khả năng chống nhiễu. Nếu thiết bị hiện hữu không thỏa mãn các giả định đó, lập luận an toàn của sản phẩm không còn áp dụng cho ứng dụng của ta, dù bản thân CBI vẫn chạy bình thường. Vì thế việc khảo sát hiện trạng, đối chiếu giả định của sản phẩm với thực tế thiết bị, và ghi nhận những chỗ không khớp là công việc bắt buộc chứ không phải thủ tục.
Safety Case của ứng dụng: Claim, Argument, Evidence
Safety Case của một ứng dụng cụ thể có thể đọc theo mô hình đã quen: một claim (ứng dụng này đáp ứng mục tiêu an toàn của nó), một argument (vì sao đáng tin claim đó) và evidence (bằng chứng cụ thể). Điều khác biệt là phần lập luận có cấu trúc phân tầng.
Phần đầu viện dẫn Safety Case của sản phẩm generic và chứng minh ta đang dùng sản phẩm trong phạm vi đã được đánh giá. Phần tiếp theo chứng minh mọi điều kiện áp dụng đã được đáp ứng (xem mục SRAC bên dưới). Phần thứ ba trình bày hazard log và safety requirement riêng của ứng dụng cùng bằng chứng chúng đã được thỏa mãn: thiết kế, dữ liệu, kết quả V&V. Cuối cùng là các bằng chứng về quy trình: quản lý chất lượng, quản lý an toàn, quản lý cấu hình và quản lý thay đổi.
Cấu trúc trong các tiêu chuẩn hiện hành có tên gọi và cách chia cụ thể hơn thế. Nên dựa vào bản chính thức của EN 50129 khi dựng khung hồ sơ thật, vì mình không xác nhận được chi tiết từng phiên bản từ đây. Nguyên tắc quan trọng nhất là: Safety Case của ứng dụng được xây song song với thiết kế, không phải viết bù sau khi nghiệm thu.
SRAC và điều kiện áp dụng
SRAC (Safety-Related Application Conditions) là tập hợp các điều kiện mà sản phẩm generic yêu cầu người sử dụng phải tuân thủ để lập luận an toàn của sản phẩm còn hiệu lực. Chúng có thể là quy tắc thiết kế dữ liệu, giới hạn về cấu hình, yêu cầu đối với thiết bị giao diện, điều kiện môi trường hay hạn chế vận hành.
Với người làm ứng dụng, SRAC là danh sách kiểm tra quan trọng nhất. Mỗi điều kiện phải được theo dõi qua một chuỗi: điều kiện đó là gì, áp dụng vào chỗ nào của ứng dụng, được đáp ứng bằng biện pháp nào, và bằng chứng ở đâu. Một SRAC bị bỏ sót không chỉ là một thiếu sót kỹ thuật. Nó có thể làm cho phạm vi đánh giá của sản phẩm không còn bao trùm ứng dụng của ta.
Công cụ và phòng lab cần thiết
Để làm được những việc trên, một đội ngũ cần ba nhóm năng lực hạ tầng. Nhóm thứ nhất là công cụ engineering: công cụ tạo và kiểm tra dữ liệu, cùng môi trường cấu hình. Khi dùng công cụ, cần hiểu công cụ ấy có ảnh hưởng thế nào đến an toàn và được kiểm soát cấu hình ra sao. Nhóm thứ hai là môi trường mô phỏng và thử nghiệm, cho phép kiểm chứng dữ liệu và logic mà không phải thử trên hệ thống đang khai thác, kể cả mô phỏng thiết bị hiện trường và các tình huống lỗi. Nhóm thứ ba là hạ tầng quản lý cấu hình và truy xuất: một nơi duy nhất lưu phiên bản dữ liệu, tài liệu, kết quả kiểm thử và liên kết chúng với yêu cầu. Thiếu nhóm này, ta khó chứng minh bằng chứng nào thuộc về phiên bản nào.
Khó khăn thường gặp và cách giảm rủi ro
Khó khăn đầu tiên thường thấy là lỗi dữ liệu và lỗi giao diện chỉ lộ ra ở giai đoạn muộn. Cách giảm rủi ro là đưa kiểm tra độc lập và mô phỏng vào sớm, và coi dữ liệu như một sản phẩm cần V&V riêng, không phải phụ lục của thiết kế. Khó khăn thứ hai là thiết bị hiện hữu không khớp giả định của sản phẩm, và nên được giải quyết bằng khảo sát và phân tích khoảng cách trước khi chốt thiết kế, thay vì phát hiện lúc thử nghiệm. Khó khăn thứ ba là thiếu công cụ và phòng thử nghiệm, khiến đội ngũ phải dựa hoàn toàn vào môi trường của nhà cung cấp. Đây là lý do nên đầu tư môi trường riêng từ Năm thứ hai của lộ trình.
Khó khăn thứ tư là thiếu hồ sơ lịch sử về mối nguy và sự cố của hệ thống cũ, làm cho hazard analysis thiếu dữ liệu đầu vào. Có thể bù bằng cách thu thập kinh nghiệm khai thác, phỏng vấn nhân sự vận hành và bảo trì, và làm việc với nhà cung cấp để tận dụng hazard log của họ như điểm xuất phát, không phải thay thế cho phân tích của ứng dụng. Khó khăn cuối cùng là áp lực tiến độ khiến Safety Case bị dồn về cuối, và như đã nói, đây là lỗi khó sửa nhất. Cách phòng là đặt các mốc Safety Case cùng với các mốc thiết kế ngay từ kế hoạch.
Kết luận
Tầng ứng dụng cho một quốc gia mới bắt đầu con đường làm chủ CBI thực tế nhất, nhưng thực tế không có nghĩa là đơn giản. Ta chịu trách nhiệm cho dữ liệu, cho giao diện với thiết bị hiện hữu, cho việc tuân thủ SRAC và cho Safety Case của chính ứng dụng. Làm tốt phần này là nền tảng để bước sang tầng nền tảng ở các giai đoạn sau.
