Có thể truyền tin nhắn cho dự phòng CPU và cấu trúc cân bằng tải


8

Trong các hệ thống nhúng loại kim loại trần hoặc tối thiểu RTOS có nhiều bộ xử lý, liệu có thể có một chương trình giống hệt nhau chạy trên mỗi bộ xử lý sử dụng Giao diện chuyển thông điệp (MPI) để cung cấp cân bằng tải và dự phòng trong trường hợp lỗi bộ xử lý không? Chẳng hạn như một máy trạng thái thay đổi những hành động mà các CPU khác thực hiện dựa trên các thông báo đã truyền, ví dụ như yêu cầu bộ xử lý khác đảm nhận một phần của vòng lặp hệ thống để cân bằng tải hoặc gửi tin nhắn sống định kỳ và ghi nhớ mỗi CPU chịu trách nhiệm gì Dự phòng CPU.

Trong sơ đồ ví dụ này, các phần thực tế của vòng lặp hệ thống đầy đủ "mở" có thể là bất kỳ hệ thống riêng biệt nào. Không thể có sự hợp tác chỉ là khả năng mở và đóng các phần của vòng lặp hệ thống đầy đủ chạy trên mỗi CPU trong một loại đa xử lý không đối xứng rất nguyên thủy. "Quá trình di chuyển" sang CPU khác sẽ được kích hoạt bởi một yêu cầu cho CPU khác mở phần đó của vòng lặp hệ thống, sau đó CPU yêu cầu đóng phần của nó hoặc thiếu phản hồi từ CPU khác khi được truy vấn nếu còn tồn tại trong một khoảng thời gian .

nhập mô tả hình ảnh ở đây

Nó đã được đề xuất như là một giải pháp cho sự thất bại của bộ xử lý tiềm năng và giải pháp để cân bằng tải vì chúng ta không thể chuyển một hệ điều hành nhúng để thực sự xử lý đa đối xứng hoặc bất đối xứng trên bảng tùy chỉnh, và nghe có vẻ như về mặt lý thuyết là có thể, nhưng thiết kế cực kỳ kém ý tưởng. Ngoài ra, tôi không thể tìm thấy bất kỳ mẫu thiết kế hoặc thuật toán nào để sử dụng thông điệp truyền theo cách này.

Một số nền tảng quan trọng đối với các quyết định kỹ thuật phần mềm: Một dự án CubeSat của sinh viên (không được phân loại hoặc cho một lớp học), chúng tôi có một nhóm phát triển phần mềm nhỏ với hầu hết các sinh viên cơ sở ít có kiến ​​thức về thiết kế hệ điều hành. Vì nhiều lý do, chúng tôi không thể thực hiện bất kỳ giải pháp nào trong thế giới thực mà tôi đã đọc. Điều này nghe có vẻ như có vẻ như nó sẽ gây ra quá nhiều phức tạp cho nhóm để giải quyết, và ngay cả khi nó có thể được thực hiện sẽ gây ra một thiết kế khủng khiếp sẽ dẫn đến một số vấn đề biến CubeSat thành một hòn đá quay quanh.

Tôi thậm chí không chắc chắn chúng ta có thể thực hiện chuyển tin nhắn theo cách đủ tin cậy để khai thác không gian, tôi thậm chí không thể tìm thấy bất kỳ giao thức giao tiếp sẵn sàng sản xuất nào có thể được sử dụng để truyền tin nhắn trên xe buýt với một hệ điều hành nhỏ hoặc trần kim loại như chúng ta cần. Nhưng tôi cũng tò mò muốn biết liệu giải pháp được đề xuất này cho quá trình di chuyển, dự phòng CPU và cân bằng tải thậm chí có khả thi đối với một hệ thống quan trọng an toàn hay không. Có vẻ như nó có thể dẫn đến trạng thái hai CPU đang chạy cùng một "Quá trình" hoặc một phần của vòng lặp chương trình nếu một lần thức dậy khó phát hiện.


Một số câu hỏi: (1) dữ liệu được thông qua như thế nào? Có một mạng hoặc dữ liệu liên bộ xử lý đi qua xe buýt? Không chắc là tất cả các bộ xử lý có thể chia sẻ quyền truy cập vào cùng một ngân hàng bộ nhớ cùng lúc, không giống như các bộ xử lý có mục đích chung (máy tính để bàn / máy chủ). (2) làm thế nào để đối phó với thiết bị (cảm biến và cơ cấu chấp hành) được nối cứng với một bộ xử lý?
rwong

1
Dữ liệu sẽ phải được truyền bằng UART hoặc I2C, nếu chúng ta sử dụng bộ nhớ dùng chung, chúng ta cũng có thể làm SMP, nhưng những điều tôi đọc về việc thực hiện điều đó (tốt nhất là qua SPI) thậm chí không được đề cập trong khóa học hệ điều hành nâng cấp của chúng ta mutex, semaphore, vv thực hiện. Đội ngũ kỹ sư điện và máy tính đã đảm bảo với tôi mọi CPU sẽ được kết nối với từng thiết bị ngoại vi, nhưng thiết kế bo mạch vẫn chưa hoàn thành.
8bit.wappen

Tôi không thấy cách bạn có thể đạt được mức dự phòng CPU và cân bằng tải cùng một lúc. Nếu bạn phân phối các tác vụ khác nhau cho mỗi CPU, thì không có dự phòng (nếu CPU bị lỗi, nó có thể ngừng đáp ứng, nhưng rất có thể nó sẽ chỉ làm một cái gì đó ngẫu nhiên, thường là do ảnh hưởng của bức xạ, nhưng vẫn tiếp tục phản hồi). Để dự phòng, tất cả các tác vụ nên chạy trong tất cả các bộ xử lý. Nếu cân bằng tải quan trọng hơn dự phòng, thì sơ đồ của bạn có vẻ đơn giản, tôi chỉ thực hiện mỗi phần như một nhiệm vụ khác nhau thay vì các nhánh của một tác vụ (giả sử RTOS của bạn là đa nhiệm).
André Sassi

@ AndréSassi: AFAICT bạn bắt đầu với dự phòng và một số cân bằng tải, và, nếu có vấn đề với một số CPU, bạn di chuyển các tác vụ sang các CPU khác, dẫn đến tải trên mỗi CPU cao hơn và thậm chí có thể giảm thông lượng cho mức thấp hơn cho mỗi CPU. nhiệm vụ ưu tiên, hoặc tỷ lệ lỗi không quan trọng cao hơn. Điều này vẫn tốt hơn là thất bại hoàn toàn.
9000

Lợi thế của hệ thống này là gì thay vì chạy tất cả các tác vụ trên tất cả các bộ xử lý?
dùng253751

Câu trả lời:


1

Câu hỏi tuyệt vời bởi vì tôi thực sự đã làm việc một số trong số này vào giữa những năm 90. Tàu vũ trụ rất tốn kém và rất khó để sửa đổi phần mềm một lần trên quỹ đạo. Tôi đã nghĩ về một biến thể của vấn đề này khi nghĩ làm thế nào tài nguyên phần mềm tàu ​​vũ trụ có thể phân bổ lại dựa trên yêu cầu nhiệm vụ thay đổi. Theo như chúng tôi đã mang nó trong phòng thí nghiệm (VxWorks):

  1. Ước tính tải nhiệm vụ cần thiết cho mỗi bộ xử lý cho mỗi yêu cầu.
  2. Ước tính tải nhiệm vụ cho nhiệm vụ phụ được thiết lập. Đây là cấu hình mới mong muốn dựa trên việc cung cấp các tác vụ cần thiết cho mỗi bộ xử lý cần thiết để đáp ứng đầy đủ các yêu cầu nhiệm vụ quan trọng nhất. Về cơ bản những gì bạn không thể sống mà không có.
  3. Đối với mỗi bộ xử lý, chúng tôi hiện có một mô hình tác vụ nhiệm vụ chính và các biến thể của chúng dựa trên các trạng thái xử lý khác, chúng tôi có thể phải chuyển sang một cách nhanh chóng nhất có thể. Đây là kế hoạch thích ứng đơn giản. Không có gì đặc biệt, chỉ là các bộ mô hình tác vụ khác nhau cắt vào một số kích thích. Cân bằng tải trong các thí nghiệm của tôi về cơ bản được lên kế hoạch trước. Chúng tôi đã sử dụng lập kế hoạch RMA cơ bản cho hoạt động này. Về cơ bản đây là một chuyển đổi ngữ cảnh lớn ở cấp độ mô hình tác vụ toàn hệ thống.

Trên chương trình cập nhật chương trình theo RTOS. Về cơ bản cắm vào một bộ tác vụ mới, nối mạng hàng đợi và bắt đầu lại luồng dữ liệu.
Vì vậy, trong việc thực hiện đơn giản này, chúng tôi tạm dừng hoặc xóa một số tác vụ và cho phép các tác vụ khác chạy. Chúng tôi đã tiến xa hơn một chút trong kỹ thuật mà chúng tôi gọi là kỹ thuật "Ghép tim". Điều này là để cập nhật phần mềm trạm. Chúng ta có thể ngắt kết nối và định tuyến lại các mạng xếp hàng trong mô hình tác vụ. Về cơ bản ngắt kết nối tác vụ và loại bỏ nó nếu muốn, giết hàng đợi và kết nối lại nhiệm vụ mới (trái tim) và động mạch (mạng xếp hàng). Chúng tôi đã làm một chút thời gian chơi trở lại vào năm 1995/96. Tôi không chỉ muốn khả năng thêm chức năng mà còn loại bỏ những thứ không cần thiết vì bộ nhớ là một nguồn tài nguyên hạn chế. Không biết nhiều về MPI, tôi chưa bao giờ sử dụng nó. Là nó quyết định? Sử dụng lý thuyết thông tin, bạn không cần nhiều để gửi tín hiệu sống. Sử dụng các bit tối thiểu. Thông tin phổ biến nhất như "giữ mạng" chỉ mất một bit, đúng hay sai. Các sự kiện xảy ra với xác suất thấp hơn nhiều cần nhiều bit hơn để biểu diễn. Loại bỏ bất kỳ phần mềm nào bạn có thể. Thực hiện theo nguyên tắc KISS (Giữ cho nó đơn giản..Stool!).

Bây giờ bảo vệ bức xạ của một số loại. Dự án sinh viên có nghĩa là có khả năng bay CMOS. Ít nhất tôi đã đặt kiểm tra CRC vào bộ nhớ và chạy một bộ giám sát để bắt lỗi như bức xạ treo máy làm những thứ kỳ lạ đối với thiết bị điện tử. Các hiệu ứng đảo lộn sự kiện đơn lẻ có thể được giảm thiểu bằng CRC trên bộ nhớ. Latch-up yêu cầu thiết lập lại nguồn.

Tôi sẽ đề nghị thử một cái gì đó như FreeRTOS và xem những tính năng bạn có thể uốn cong theo ý muốn của bạn. Không gian là một môi trường rất thách thức. Chúc vui vẻ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.