- Máy tính bay của Orion, tàu vũ trụ có người lái lên Mặt Trăng, có kiến trúc cải thiện đáng kể về khả năng phục hồi và điều khiển tự động so với các hệ thống thời Apollo, quản lý toàn bộ các chức năng cốt lõi như duy trì sự sống, điện năng và liên lạc
- Để vận hành liên tục ngay cả ở khoảng cách 250.000 dặm trong quỹ đạo Mặt Trăng, hệ thống được thiết kế để chịu được lỗi phần cứng và ảnh hưởng của bức xạ thông qua cấu trúc dự phòng vật lý, logic và nhiều máy tính bay
- Mỗi Flight Control Module (FCM) gồm một cặp bộ xử lý tự kiểm chứng, tổng cộng 8 CPU chạy song song, cô lập lỗi bằng thiết kế fail-silent và thuật toán chọn đầu ra dựa trên mức ưu tiên
- Hệ thống duy trì trạng thái đồng bộ hoàn toàn bằng Ethernet kích hoạt theo thời gian và kiến trúc tất định, đồng thời tự động sửa cả lỗi một bit nhờ mạng và bộ nhớ được nhân ba
- Để phòng trường hợp toàn bộ hệ thống chính đều thất bại, Backup Flight Software dựa trên phần cứng và hệ điều hành độc lập sẽ tiếp quản quyền điều khiển; cấu trúc này được đánh giá là mô hình phục hồi luôn hoạt động cho các hệ thống tự trị trong tương lai
Thiết kế máy tính chịu lỗi của NASA cho Artemis II
- Máy tính bay của Artemis II có kiến trúc cải thiện đáng kể về khả năng phục hồi và điều khiển tự động so với máy tính dẫn đường thời Apollo
- Máy tính Apollo dùng bộ xử lý 1MHz và khoảng 4KB bộ nhớ, còn điều khiển chính dựa nhiều vào công tắc thủ công hoặc rơ-le
- Capsule Orion của Artemis II để máy tính trực tiếp quản lý mọi chức năng cốt lõi như duy trì sự sống, điện năng và liên lạc
- Vì thất bại nhiệm vụ ở khoảng cách 250.000 dặm trong quỹ đạo Mặt Trăng gần như không thể khắc phục, hệ thống phải hoạt động không gián đoạn ngay cả khi gặp bức xạ vũ trụ, lật bit và lỗi phần cứng
- NASA chuẩn bị cho lỗi phần cứng bằng cách dùng dây dẫn dự phòng vật lý, các mặt phẳng mạng dự phòng về mặt logic và nhiều máy tính bay
-
Sức mạnh của tám
- Orion áp dụng cấu trúc vượt ra ngoài dự phòng ba (triple redundancy) truyền thống
- Hai Vehicle Management Computer (VMC), mỗi máy gắn hai Flight Control Module (FCM), tạo thành tổng cộng 4 FCM
- Mỗi FCM gồm một cặp bộ xử lý tự kiểm chứng (self-checking), tạo thành tổng cộng 8 CPU chạy song song phần mềm bay
- Hệ thống dựa trên thiết kế fail-silent; khi phát sinh lỗi, CPU gặp sự cố sẽ ngay lập tức chuyển sang trạng thái im lặng thay vì phát ra đầu ra sai
- Thay vì bỏ phiếu đa số, hệ thống dùng thuật toán chọn nguồn dựa trên mức ưu tiên để chọn đầu ra từ kênh đang hoạt động bình thường
- NASA dự kiến lỗi tạm thời khi đi qua vành đai bức xạ Van Allen; ngay cả khi mất 3 FCM trong tối đa 22 giây, nhiệm vụ vẫn có thể tiếp tục với FCM cuối cùng
- FCM ở trạng thái im lặng có thể được đặt lại, đồng bộ lại với các mô-đun khác và tham gia trở lại ngay trong chuyến bay
-
Duy trì hoạt động tất định
- Để giữ nhiều máy tính độc lập ở trạng thái đồng bộ hoàn toàn (lockstep), hệ thống áp dụng kiến trúc tất định (deterministic architecture)
- Orion dùng mạng Ethernet kích hoạt theo thời gian (time-triggered Ethernet) để phân phối thời gian cho toàn bộ hệ thống
- Phần mềm bay chạy trong major frame và minor frame do bộ lập lịch ARINC653 quản lý
- Việc phân chia theo thời gian và không gian bảo đảm đầu vào và đầu ra được căn chỉnh hoàn toàn với lịch mạng
- Mỗi FCM nhận cùng một đầu vào, chạy cùng một đoạn mã và tạo ra cùng một đầu ra
- Mỗi giây, độ trôi đồng hồ của FCM được đo và hiệu chỉnh lại theo thời gian chuẩn của mạng
- Ứng dụng không đáp ứng được deadline sẽ tự động chuyển sang trạng thái im lặng rồi đồng bộ lại
- Phần cứng dùng bộ nhớ dự phòng mô-đun ba (TMR) để tự động sửa lỗi một bit, còn card giao tiếp mạng cũng so sánh hai đường truyền lưu lượng để xử lý fail-silent khi có lỗi
- Mạng được nhân ba thành ba mặt phẳng độc lập, và mọi switch đều có chức năng tự kiểm chứng
-
Hệ thống dự phòng cuối cùng
- NASA cũng chuẩn bị cho lỗi common mode failure, có thể ảnh hưởng đồng thời tới mọi kênh chính
- Vì vậy, họ trang bị riêng hệ thống Backup Flight Software (BFS)
- BFS gồm phần cứng khác, hệ điều hành khác và phần mềm bay đơn giản hóa được phát triển độc lập
- Nếu hệ thống chính thất bại, BFS sẽ tự động tiếp nhận quyền điều khiển để hoàn tất các giai đoạn động của nhiệm vụ
- Sau đó phi hành đoàn có thể thử khôi phục FCM chính
- Logic fail-silent là bắt buộc, nhưng cũng cần bộ định thời giám sát và cơ chế giám sát nhiều lớp để bảo đảm không có lỗi nào tồn tại mà không bị phát hiện
- Hệ thống cũng được thiết kế để sống sót ngay cả khi mất điện hoàn toàn (“dead bus”)
- Khi nguồn điện được khôi phục, hệ thống sẽ tự động vào chế độ an toàn (safe mode)
- Tấm pin mặt trời được xoay về phía Mặt Trời để khôi phục điện năng, sau đó tàu được xoay để phần đuôi hướng về phía Mặt Trời nhằm ổn định nhiệt
- Tiếp theo, hệ thống sẽ cố gắng tái lập liên lạc với Trái Đất; khi cần, phi hành đoàn có thể tự điều chỉnh thủ công thiết bị duy trì sự sống
-
Tương lai của độ tin cậy
- Sự chuyển đổi từ Apollo sang Artemis cho thấy độ phức tạp phần mềm đã tăng vọt
- Apollo còn có các phương án dự phòng cơ khí, nhưng ở Artemis, phần mềm đảm nhiệm toàn bộ điều khiển
- NASA sử dụng quy trình kiểm chứng hiện đại bao gồm mô phỏng toàn bộ môi trường, kiểm thử sức ép Monte Carlo và fault injection quy mô lớn
- Họ dùng siêu máy tính để mô phỏng toàn bộ dòng thời gian của chuyến bay và xác minh liệu phần mềm có thể phục hồi theo kiểu fail-silent ngay cả trong tình huống lỗi phần cứng hay không
- Kiến trúc zero-tolerance của Orion được đánh giá là mô hình về khả năng phục hồi luôn hoạt động (always-on) có thể áp dụng cho các hệ thống như xe tự lái và mạng điều khiển công nghiệp trong tương lai
1 bình luận
Ý kiến trên Hacker News
Từ năm 1989 đến 1995, tôi đã làm ở Stratus về VOS và hiệu năng cơ sở dữ liệu
Stratus là công ty làm hệ thống chịu lỗi (fault-tolerant) dựa trên phần cứng, còn đối thủ Tandem theo hướng dựa trên phần mềm
Kiến trúc của Stratus là “pair and spare”, trong đó mọi board đều được nhân đôi và đầu ra của từng chân được so sánh ở mỗi tick
Khi chuyển từ Motorola 68K sang Intel, đội phần cứng đã rất vất vả vì một số chân không dùng tới của lệnh bị để trôi nổi
Tôi rất ấn tượng với nhận định của một nhà nghiên cứu CMU rằng “Agile và DevOps đã làm suy yếu tính kỷ luật về kiến trúc”
Có cảm giác như ngày nay chúng ta đã quên cách xây dựng hệ thống xác định
Việc lập lịch khung cực kỳ nghiêm ngặt của Time-triggered Ethernet khiến nó giống như một thế giới hoàn toàn khác với cách phát triển phần mềm hiện nay
Một số thực hành phát triển hiện đại (unit test, CI, v.v.) vẫn có tác động tích cực ngay cả trong môi trường này
Giờ đây trọng tâm đã chuyển sang thị trường thương mại nên đầu tư giảm đi, nhưng vẫn còn rất nhiều thuật toán thú vị
Có thể tham khảo nghiên cứu của Frank Mueller hoặc Johann Blieberger
Trong môi trường có đầu vào/đầu ra bị giới hạn như máy bay, thiết kế xác định là cực kỳ phù hợp
Trên thực tế, nó gần với một bus phần cứng chuyên dụng hơn là Ethernet
Khi xem thử thách ‘radiation hardening’ trên Code Golf, tôi đã tự hỏi
liệu cách tiếp cận kiểu này có thực sự hữu ích ngoài đời không
Thực tế thì có quá nhiều tầng vấn đề đan xen nên rất khó, nhưng dù vậy đây vẫn là một ý tưởng thú vị
Thiết kế “fail-silent” được mô tả trong bài khá thú vị
Nhưng tôi tự hỏi làm sao phát hiện được nếu hai CPU cùng lúc tính sai và cho ra kết quả giống nhau
Xác suất cả hai CPU cùng tạo ra một lỗi giống nhau thấp hơn rất nhiều so với FIT của một CPU đơn lẻ
Dù vậy, trong không gian thì định luật Murphy vẫn luôn hiện hữu nên cũng không dám chắc
kết quả sai vẫn có thể được chọn theo kiểu “đa số 25%”
Tôi muốn biết thông tin cụ thể hơn về CPU, RAM, OS, ngôn ngữ của hệ thống này
Tôi cũng muốn biết FCM bị “fail-silent” với tần suất bao nhiêu
Nó thường chạy trên FreeRTOS hoặc RTEMS
Cá nhân tôi thấy cấu trúc dự án quá phức tạp nên khá khó làm việc cùng
Phần lớn mã cốt lõi của NASA không công khai, nhưng cFS là tài liệu rất tốt để học về thiết kế phần mềm bay cổ điển
Bài viết không đi vào chi tiết về RTOS và kiến trúc thực tế
Điều khiển bay chính của Orion là kiến trúc dự phòng bốn lần dựa trên Green Hills INTEGRITY RTOS và bộ xử lý BAE RAD750
BFS chạy trên phần cứng hoàn toàn khác là LEON3 + VxWorks, và dùng framework cFS của NASA
Đây là kiến trúc mô-đun có thể tái sử dụng cũng được dùng trong kính viễn vọng James Webb và Mars Rover
Cấu trúc này không chỉ đơn giản là “hệ thống chính + dự phòng”, mà là khái niệm dự phòng khác loại (dissimilar redundancy)
Có thể xem thêm ở tài liệu kỹ thuật NASA 1, tài liệu 2
Việc chế tạo thực tế do Lockheed Martin và các nhà thầu phụ đảm nhiệm
Cách báo chí diễn đạt như thể NASA tự tay làm mọi thứ dễ gây hiểu lầm
Khi còn làm lập trình viên web 25 năm trước, tôi từng hỏi một người bạn xuất thân từ NASA rằng “các anh xử lý bug thế nào?” thì
anh ấy cười và trả lời: “không có bug”
Các lập trình viên ngày nay đã quen làm việc trong môi trường mà thất bại không gắn với sinh mạng con người
Với dịch vụ web thì cùng lắm là mất doanh thu, còn tàu vũ trụ thì liên quan đến mạng người
Tôi từng phát triển một máy tính chống bức xạ,
và ngoài việc nhân bản đơn thuần còn dùng cả kỹ thuật phát hiện lỗi không dư thừa
Hơi tiếc là tôi không thấy cách tiếp cận đó trong hệ thống lần này
tăng cường chống chịu về mặt vật lý bằng cách phân tán tiết diện va chạm bức xạ
Các kiến trúc dự phòng khác nhau đều rất ấn tượng, nhưng tôi vẫn tự hỏi liệu chức năng điều khiển thủ công (Manual Override) còn khả dụng hay không
Liệu khi cần có thể điều khiển trực tiếp như Apollo 11 và 13 không
Vì các phi hành gia vẫn là những người có xuất thân phi công thử nghiệm, tôi đoán là có thể