Bạn đã xử lý cứng không gian?

Tôi rất háo hức nghiên cứu các thực hành tốt nhất khi nói đến việc làm cứng không gian. Chẳng hạn, tôi đã đọc (mặc dù tôi không thể tìm thấy bài báo nữa) rằng một số phần cốt lõi của máy bay sao Hỏa không sử dụng cấp phát bộ nhớ động, thực tế nó đã bị cấm. Tôi cũng đã đọc rằng bộ nhớ lõi kiểu cũ có thể thích hợp hơn trong không gian.

Tôi đã xem xét một số dự án liên quan đến Thử thách âm lịch của Google và tự hỏi cảm giác sẽ như thế nào khi nhận được mã trên mặt trăng, hoặc thậm chí chỉ vào không gian. Tôi biết rằng các bảng cứng không gian mang lại sự tỉnh táo trong một môi trường khắc nghiệt như vậy, tuy nhiên tôi đang tự hỏi (với tư cách là một lập trình viên C), tôi sẽ cần điều chỉnh suy nghĩ và mã như thế nào nếu tôi viết thứ gì đó sẽ chạy trong không gian?

Tôi nghĩ rằng vài năm tới có thể cho thấy sự tăng trưởng nhiều hơn trong các công ty không gian tư nhân, tôi thực sự muốn ít nhất là hiểu biết về các thực tiễn tốt nhất.

Điều gì xảy ra với một chương trình nếu bức xạ, lạnh hoặc nhiệt bắn phá một tấm ván gây thiệt hại cho lớp cách nhiệt của nó? Tôi nghĩ mục tiêu là giữ con người bên trong một tàu vũ trụ (miễn là sửa chữa hoặc tráo đổi công cụ) và tránh các nhiệm vụ để sửa chữa mọi thứ.

Hơn nữa, nếu hội đồng quản trị duy trì một số hệ thống quan trọng, cảnh báo sớm dường như là tối quan trọng.

Làm thế nào để một người có được kinh nghiệm trong việc này thông qua thử nghiệm và dùng thử & lỗi (chặn việc phóng vệ tinh cá nhân của riêng bạn?)

Phần mềm không gian không phải là ma thuật phức tạp. Bạn vẫn đang sử dụng 0 và 1, không phải 1 và 3. Vì vậy, có lẽ không có yếu tố wow liên quan đến việc mô tả những gì phát triển phần mềm.

Một số khác biệt nhỏ xuất hiện trong tâm trí hiện tại là:

• Quá trình định hướng.
• Phần mềm không gian sẽ luôn có cả bộ định thời giám sát phần mềm và phần cứng.
• Mọi hệ thống không gian tôi từng làm việc là một hệ thống thời gian thực cứng.
• Bạn mô phỏng (với độ chính xác cao) mọi tác nhân bên ngoài vào hệ thống. Điều này thường liên quan đến việc xây dựng (đôi khi thực sự tốn kém) phần cứng tùy chỉnh chỉ được sử dụng để thử nghiệm.
• Bạn dành nỗ lực lớn và chi phí làm thử nghiệm chính thức.
• Khách hàng (thường là JPL) cực kỳ tham gia vào quá trình thử nghiệm.
• Bạn thường sử dụng các trình biên dịch và môi trường phát triển cũ và đã biết, thay vì các trình biên dịch mới.
• Mã đánh giá, mã đánh giá và mã đánh giá.
• Tốt hơn hết là bạn nên thoải mái chuyển đổi giữa thế giới phần cứng và phần mềm. Bạn không cần phải biết cách thiết kế phần cứng nhưng bạn phải biết nó hoạt động như thế nào.
• Sử dụng rộng rãi các thiết bị thử nghiệm, như máy hiện sóng, máy phân tích logic, máy tổng hợp và máy phân tích phổ.
• Ít nhất 3 vị trí để lưu trữ chương trình ứng dụng. Mặc định được ghi trong ROM. Điều này sẽ không bao giờ thay đổi. 2 cái còn lại dành cho phiên bản hiện tại và phiên bản tiếp theo / cuối cùng.
• Phân tích thất bại (MTBF) là thực sự quan trọng.
• Hệ thống dự phòng và kế hoạch chuyển đổi dự phòng cho các thành phần quan trọng.

Tôi chỉ vấp vào câu hỏi thú vị của bạn.

Tôi đã ở phòng thí nghiệm thiết bị trong Apollo, và một lần nữa sau đó khi nó được gọi là Draper Lab trong "chiến tranh lạnh".

Đối với máy tính hướng dẫn Apollo, lõi được sử dụng cho RAM và lõi bện đặc biệt được sử dụng cho ROM. Bản thân cỗ máy này được chế tạo hoàn toàn từ cổng NOR và có tốc độ khá chậm, cho độ tin cậy.

Tôi đã không làm việc trực tiếp với tên lửa Minuteman, nhưng tôi đã nhận thức được một số vấn đề. Nếu một đầu đạn hạt nhân phát ra trong vùng lân cận của một số thiết bị điện tử, về cơ bản nó sẽ rút ngắn nó ra. Máy tính hướng dẫn có một cảm biến bức xạ sẽ tắt Vc ngay lập tức để không có gì bị cháy. Sau đó, máy tính sẽ khởi động lại, đã xóa các thanh ghi của nó.

Để xử lý việc này, máy tính sẽ định kỳ chụp các thanh ghi của nó vào lõi và khi khởi động lại, nó sẽ khởi động từ điểm kiểm tra đó. Để thực hiện công việc này, phần mềm (tất cả trong ASM) phải được phân tích để thấy rằng nó có thể nhận bất kỳ số lần truy cập nào như vậy, ở bất kỳ tần suất nào, mà không nhận được câu trả lời sai. Điều đó được gọi là "khởi động lại được bảo vệ". Vấn đề rất thú vị, cho rằng (cảm ơn lòng tốt) nó không bao giờ phải được sử dụng.

Để có được độ tin cậy môi trường khắc nghiệt cụ thể trong C, đây là một số điều thực sự cụ thể mà tôi đã thấy.

MISRA-C: Tập hợp con Ô tô C. Một chút giống như Ravenscar ADA / Java.

cơ quan giám sát: đảm bảo chương trình không bị khóa

bộ nhớ ecc (đôi khi)

tổng kiểm tra: tìm kiếm các bit lật. Tôi đã thấy cả ba thứ này trong một hệ thống:

1) kiểm tra chương trình liên tục (trong EPROM nhưng vẫn bị lật bit).

2) tổng kiểm tra cấu trúc dữ liệu nhất định theo định kỳ.

3) Kiểm tra vệ sinh CPU định kỳ.

4) kiểm tra các thanh ghi IO có những gì chúng được cho là có trong chúng.

4b) đọc lại đầu ra vào đầu vào độc lập và xác minh.

Quan trọng hơn nhiều so với ngôn ngữ lập trình là các yêu cầu trên hệ thống cơ bản (HĐH và Phần cứng). Về cơ bản, bạn cần đảm bảo (và chứng minh) hành vi xác định và dự đoán của toàn bộ hệ thống. Nhiều nghiên cứu liên quan đã được thực hiện trong cộng đồng thời gian thực. Tôi thực sự khuyên bạn nên đọc hai cuốn sách nếu bạn thực sự muốn học môn này: Hệ thống thời gian thực của Jane Liu và một cuốn sách có cùng tên của Hermann Kopetz . Cái trước bao gồm việc lên lịch theo kiểu rất lý thuyết trong khi cái sau đưa chân bạn trở lại mặt đất và khá nhiều bao gồm tất cả các khía cạnh liên quan của thiết kế hệ thống (thời gian thực), ví dụ như khả năng chịu lỗi.

Hơn nữa, hai sự cố sau đây minh họa độc đáo chất lượng của các vấn đề mà các kỹ sư phần mềm phải đối mặt khi gửi thứ gì đó vào không gian:

• Ariane 5 (Tái sử dụng phần mềm đã được chứng minh dưới các ràng buộc khác nhau)
• Mars Rover Pathfinder Reboot (Ưu tiên đảo ngược)

Tôi đã tìm thấy tài liệu này (khoảng năm 2009) cho Tiêu chuẩn mã hóa thể chế JPL cho ngôn ngữ lập trình C trên Phòng thí nghiệm phần mềm đáng tin cậy (LaRS) tại trang web của Phòng thí nghiệm sức đẩy phản lực .

Dưới đây là một bản tóm tắt các quy tắc được ghi lại:

1. Tuân thủ ngôn ngữ

   • Đừng đi lạc ngoài định nghĩa ngôn ngữ.
   • Biên dịch với tất cả các cảnh báo được kích hoạt; sử dụng máy phân tích mã nguồn tĩnh.

2. Dự đoán thực hiện

   • Sử dụng giới hạn vòng lặp có thể kiểm chứng cho tất cả các vòng lặp có nghĩa là chấm dứt.
   • Không sử dụng đệ quy trực tiếp hoặc gián tiếp.
   • Không sử dụng cấp phát bộ nhớ động sau khi khởi tạo tác vụ.
   • * Sử dụng tin nhắn IPC để liên lạc nhiệm vụ.
   • Không sử dụng độ trễ của tác vụ để đồng bộ hóa tác vụ.
   • * Hoàn toàn chuyển quyền ghi (quyền sở hữu) cho các đối tượng dữ liệu được chia sẻ.
   • Đặt các hạn chế về việc sử dụng semaphores và khóa.
   • Sử dụng bảo vệ bộ nhớ, lề an toàn, mô hình rào cản.
   • Không sử dụng goto, setjmp hoặc longjmp.
   • Không sử dụng các phép gán giá trị chọn lọc cho các thành phần của danh sách enum.

3. Mã hóa phòng thủ

   • Khai báo các đối tượng dữ liệu ở mức phạm vi nhỏ nhất có thể.
   • Kiểm tra giá trị trả về của các hàm không trống hoặc được truyền rõ ràng tới (void).
   • Kiểm tra tính hợp lệ của các giá trị được truyền cho các hàm.
   • Sử dụng các xác nhận tĩnh và động như kiểm tra độ tỉnh táo.
   • * Sử dụng U32, I16, v.v. thay vì các loại dữ liệu C được xác định trước như int, short, v.v.
   • Làm cho thứ tự đánh giá trong các biểu thức ghép rõ ràng.
   • Không sử dụng biểu thức với tác dụng phụ.

4. Mã rõ ràng

   • Chỉ sử dụng rất hạn chế bộ xử lý trước C.
   • Không xác định các macro trong một hàm hoặc một khối.
   • Không xác định hoặc xác định lại các macro.
   • Đặt #else, #elif và #endif trong cùng một tệp với #if hoặc #ifdef phù hợp.
   • * Đặt không quá một tuyên bố hoặc tuyên bố trên mỗi dòng văn bản.
   • * Sử dụng các hàm ngắn với số lượng tham số hạn chế.
   • * Sử dụng không quá hai cấp độ của mỗi lần khai báo.
   • * Sử dụng không quá hai cấp độ hội nghị cho mỗi tham chiếu đối tượng.
   • * Không ẩn các hoạt động hủy đăng ký bên trong các macro hoặc typedefs.
   • * Không sử dụng con trỏ hàm không liên tục.
   • Không chuyển con trỏ hàm thành các loại khác.
   • Không đặt mã hoặc khai báo trước một lệnh #incoide.

*) Tất cả các quy định là có trách nhiệm quy định, trừ những phần đánh dấu.

Hệ thống máy tính chống không gian là tất cả về độ tin cậy. Một giới thiệu sâu sắc về lĩnh vực này có thể được tìm thấy trong các khái niệm cơ bản về độ tin cậy của Algirdas Avižienis, Jean-Claude Laprie & Brian Randell.

Thời gian thực cũng là một khái niệm quan trọng cho điện toán không gian. Là Pankrat, tôi muốn giới thiệu Hệ thống thời gian thực của Hermann Kopetz.

Để đưa ra ý nghĩa thực tế về những thách thức của điện toán không gian, hãy nghĩ đến:

• điều kiện khắc nghiệt trong không gian: rất nóng khi hướng về phía mặt trời, phía bên kia rất lạnh, nhiều tia vũ trụ có thể đảo ngược các bit trong bộ nhớ, gia tốc và rung động lớn khi được giặt, ... Phần cứng cho không gian phải mạnh hơn nhiều so với phần cứng cho quân đội.

• Khi xảy ra lỗi, ngoại trừ trong Trạm vũ trụ quốc tế hoặc Kính thiên văn vũ trụ Hubble, không ai đến và thay thế hệ thống bị lỗi. Mọi thứ phải được cố định từ mặt đất thông qua khả năng quan sát và chỉ huy tối đa và thông qua các hệ thống dự phòng để chuyển sang. Điều này là dễ dàng cho các vệ tinh Trái đất. Điều này là khó khăn hơn với các thăm dò không gian mà sự chậm trễ giao tiếp có thể kéo dài một giờ. Thật vậy, mọi thứ phải đáng tin cậy nhất có thể ngay từ đầu.

Những gì tôi học được từ một dự án mà tôi đã tham gia với tư cách là một thực tập sinh:

Thông số kỹ thuật phần cứng của bạn sẽ thay đổi, thường là tồi tệ hơn!

Ví dụ, CPU cứng không gian đang được sử dụng trong thiết kế đã được hứa hẹn, hứa với bạn, rằng nó sẽ chạy ở 20 MHz.

Kết quả cuối cùng chạy ở 12 MHz. Lập trình viên cao cấp của dự án đã dành nhiều thời gian để thiết kế lại các thuật toán để đáp ứng các yêu cầu khó khăn về thời gian thực của các hệ thống điều khiển và phần lớn phần mềm từ xa đã được chuyển sang hệ thống thứ hai thay vì chạy trên CPU chính.

Vì vậy, hãy cố gắng để lại một số tài nguyên bổ sung có sẵn trong thiết kế ban đầu và cố gắng không sử dụng tất cả CPU và bộ nhớ có sẵn.

Đối với phối cảnh phần mềm, hãy viết một tác vụ đặc quyền đôi khi, ngẫu nhiên, lật các bit trong mã của bạn và xem cách nó xử lý vấn đề đó. Đó là giả lập của bạn.

Thông minh về phần cứng, các bộ phận sẽ cũ, vì phải mất một thời gian dài để có được thứ gì đó được xếp hạng không gian. Ngoài ra, các bộ phận mới liên tục bị thu hẹp kích thước và tính năng càng nhỏ (nghĩ là tế bào bộ nhớ trên IC) thì càng dễ bị tham nhũng từ sự kiện bức xạ.

Tôi đã làm việc trên một thiết bị quan trọng an toàn và chúng tôi đã phải trải qua một số vòng tương tự.

Chúng tôi đã có các biến số an toàn quan trọng. Có một bản sao của nghịch đảo của biến. Sau mỗi vòng lặp, biến được kiểm tra ngược lại.

Chúng tôi đã có một bài kiểm tra đi bộ và số không của tất cả các thanh ghi. Điều đó bao gồm Bộ đếm Chương trình!

Chúng tôi đã có một bài kiểm tra tất cả các opcodes của tập lệnh vi mô. Chúng tôi phải chắc chắn rằng nếu bạn thêm 2 thanh ghi, các thanh ghi đã được thêm vào.

Một số điều này có thể không liên quan đến các chương trình trong không gian, nhưng nó mang lại cho bạn cảm giác về mức độ kiểm tra có thể xảy ra.

Tôi tin rằng một môi trường tồi tệ hơn là sử dụng nhiều Mã sửa lỗi hơn và có những bộ nhớ ECC có thể được sử dụng ở một mức độ nào đó.

Nếu người ta có thể ước tính mức độ lỗi, người ta có thể xây dựng mã sửa lỗi có thể xử lý các lỗi được giới thiệu.

• Vâng, bộ nhớ cốt lõi là trên bảng nghiên cứu.
• Bộ nhớ động không tốt cho các hệ thống nhúng. Vấn đề độ tin cậy.

Tôi đoán rằng phần mềm ECC của dữ liệu và sử dụng lý thuyết thông tin và bộ mã hóa tùy chỉnh để truyền bá dữ liệu xung quanh hệ thống để quản lý các lỗi bộ nhớ sẽ là một sự khởi đầu. Nhưng, tôi không nghiên cứu phần mềm rad-hard nên tôi không quen với nó, đó chỉ là dự đoán.