Os rv trong dịch vụ hàng không. Hệ điều hành thời gian thực cho hệ thống điện tử hàng không: tổng quan

Việc lựa chọn dịch vụ hàng không là vô cùng nghiêm ngặt và không chỉ liên quan đến nhân viên bay mà còn liên quan đến hệ điều hành thời gian thực (RT OS). Hãy xem xét những yêu cầu nào được đặt ra đối với hệ thống hàng không thương mại bởi các tổ chức chịu trách nhiệm về an toàn chuyến bay. Không còn nghi ngờ gì nữa, điều này sẽ giúp hiểu được các yêu cầu cần thiết cho nhiều ngành công nghiệp khác - bất cứ nơi nào cần phản ứng nhanh với các sự kiện, độ tin cậy cao, khả năng tồn tại và độ an toàn của các công cụ được sử dụng, bao gồm cả phần mềm,.

Cục Hàng không Liên bang Hoa Kỳ, một trong những tổ chức có thẩm quyền chịu trách nhiệm về an toàn chuyến bay, có các yêu cầu nghiêm ngặt đối với hệ điều hành thời gian thực thương mại được áp dụng để vận hành (đặc biệt là đối với ngành hàng không dân dụng, nơi mạng sống của hàng trăm hành khách phụ thuộc vào công việc của họ). Trong số đó:

yêu cầu thời gian thực “cứng”; hành vi xác định dưới các tải hệ thống khác nhau, được yêu cầu trong các ứng dụng quan trọng và hệ thống có tính sẵn sàng cao;
“khả năng sống sót” cao, nếu phần mềm nào bị lỗi thì phần còn lại vẫn hoạt động bình thường;
yêu cầu chất lượng nghiêm ngặt, có nghĩa là tuân thủ các tiêu chuẩn ngành, quốc gia và quốc tế khác nhau;
yêu cầu về độ tin cậy; xác suất xảy ra lỗi chương trình sẽ rất nhỏ;
yêu cầu về bảo mật, an toàn dữ liệu; Hệ thống phải cung cấp phương tiện để bảo vệ những thông tin quan trọng nhất.

Hệ thống quy định yêu cầu

Hãy liệt kê các tài liệu chính quy định các yêu cầu đối với hệ điều hành thời gian thực trong lĩnh vực hàng không.

Tiêu chuẩn DO-178 - Xem xét phần mềm trong chứng nhận thiết bị và hệ thống trên không.Được phát triển và duy trì bởi Ủy ban Kỹ thuật Vô tuyến Hàng không (RTCA, www.rtca.org). Tiêu chuẩn xác định năm mức độ nghiêm trọng của lỗi, trong đó mỗi mức độ yêu cầu phần mềm được chỉ định, được thiết kế để đảm bảo chức năng của toàn bộ hệ thống khi xảy ra lỗi ở cấp độ này:

cấp độ A- bảo vệ chống lại các hư hỏng dẫn đến hậu quả thảm khốc;

cấp độ B- bảo vệ chống lại các hư hỏng dẫn đến hậu quả nguy hiểm;

cấp độ C- bảo vệ chống lại các hư hỏng dẫn đến hậu quả lớn;

cấp D- bảo vệ chống lại các hư hỏng dẫn đến hậu quả tối thiểu;

cấp độ E- bảo vệ chống lại những hư hỏng không dẫn đến bất kỳ hậu quả nào.

Tiêu chuẩn ED-12B. Tương tự châu Âu của DO-178B. Được xác định bởi hiệp hội Tổ chức Thiết bị Hàng không Dân dụng Châu Âu (EUROCAE, www.eurocae.org).

RTCA DO-248B - Báo cáo thường niên cuối cùng để làm rõ DO-178B. Tài liệu giải thích cho DO-178B. Các chủ đề chính của nó bao gồm các chủ đề như phần mềm được phát triển trước đó, sản phẩm phần mềm thương mại, quy trình xác minh, tài liệu tham khảo lịch sử, công cụ tự động, v.v.

Tiêu chuẩn DO-254 - Hướng dẫn đảm bảo thiết kế cho phần cứng điện tử trên không.Được phát triển và duy trì bởi RTCA. Tài liệu này được thiết kế để giúp các nhà sản xuất máy bay và nhà cung cấp hệ thống điện tử hàng không đảm bảo rằng thiết bị điện tử của họ thực hiện các chức năng cần thiết một cách an toàn. Tài liệu quy định các quy trình trong vòng đời phần cứng và mô tả các cách đảm bảo các đặc tính cần thiết của sản phẩm để chứng nhận chúng phù hợp với yêu cầu.

ARINC 653 - Giao diện chuẩn của phần mềm ứng dụng điện tử hàng không.Được phát triển bởi ARINC vào năm 1997, nó xác định giao diện phần mềm APEX (Ứng dụng/Điều hành) phổ quát giữa hệ điều hành máy tính tích hợp và phần mềm ứng dụng. Các yêu cầu về giao diện được xác định để cho phép các chương trình ứng dụng kiểm soát việc gửi đi, liên lạc và trạng thái của các phần tử xử lý nội bộ. Là một trong những yêu cầu cốt lõi đối với hệ điều hành thời gian thực trong ngành hàng không, ARINC 653 giới thiệu kiến trúc máy ảo phân vùng.

Tiêu chí chung để đánh giá an ninh công nghệ thông tin. Một tập hợp các yêu cầu và điều kiện bí mật ( www.commoncriteria.org), được Cơ quan An ninh Quốc gia Hoa Kỳ và Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ cũng như các cơ quan hữu quan ở các quốc gia khác (hiện có 13 quốc gia khác ngoài Hoa Kỳ) phê duyệt. Năm 1999, “Tiêu chí chung” đã nhận được trạng thái tiêu chuẩn quốc tế ISO 15408.

MILS - Nhiều cấp độ bảo mật/an toàn độc lập. Nó đang được phát triển thông qua nỗ lực của các tổ chức quan tâm, chẳng hạn như Phòng thí nghiệm Nghiên cứu Không quân Hoa Kỳ, Lockheed Martin, Cơ quan An ninh Quốc gia Hoa Kỳ, v.v. Dự án MILS giúp xác minh về mặt toán học lõi phần mềm của hệ thống bằng cách giảm chức năng bằng cách giảm áp đặt bốn nhóm yêu cầu bắt buộc đối với hệ thống (Luồng thông tin, Cách ly dữ liệu, Xử lý theo chu kỳ, Giới hạn thiệt hại). Kiến trúc MILS là một hệ thống có các phân vùng biệt lập, mỗi phân vùng bao gồm kernel, middleware và ứng dụng (Hình 1).

Cơm. 1. Kiến trúc MILS

POSIX - Giao diện hệ điều hành di động cho uniX. Xác định giao diện hệ điều hành di động ở cấp nguồn. Thông số kỹ thuật cốt lõi được phát triển theo tiêu chuẩn IEEE 1003.1 và được áp dụng làm tiêu chuẩn quốc tế ISO/IEC 9945-1:1990. Từ quan điểm của hệ điều hành thời gian thực, ba tiêu chuẩn được quan tâm nhiều nhất: 1003.1a (Định nghĩa hệ điều hành), 1003.1b (Tiện ích mở rộng thời gian thực) và 1003.1c (Chủ đề).

Khái niệm phân vùng bị cô lập

Về nhiều mặt, các văn bản quy định chồng chéo, bổ sung cho nhau. Theo kết quả của nhiều nghiên cứu, khái niệm phân vùng biệt lập đã được áp dụng làm khái niệm chính. Sự đáp ứng các yêu cầu cách ly cứng phải được “chứng minh” bởi các nhà cung cấp giải pháp phần mềm theo phương pháp chứng nhận được nêu trong DO-178B. Có nhiều cách tiếp cận khác nhau để triển khai các phân vùng biệt lập, nhưng ngày nay kiến trúc được áp dụng là ARINC 653, xác định hỗ trợ cách ly cho hệ điều hành thời gian thực và sử dụng C và Ada-95 làm ngôn ngữ mô tả.

Từ góc độ người dùng, ARINC 653 là đặc tả giao diện APEX (Ứng dụng/Điều hành) và không xác định việc triển khai nó. Do đó, một số nhà cung cấp phần mềm triển khai việc điều phối bằng cách sử dụng bộ điều phối một cấp, một số khác sử dụng bộ điều phối hai cấp, khi cấp đầu tiên quản lý các phân vùng và cấp thứ hai quản lý các quy trình trong mỗi phân vùng. Tình huống này với sự hỗ trợ ARINC 653 gây ra khó khăn trong việc chứng nhận các sản phẩm phần mềm chỉ tuân thủ ARINC 653 - cùng một API có thể ánh xạ tới các phương pháp triển khai khác nhau. Kết quả là, nhiều hệ điều hành thời gian thực rất khác nhau đã xuất hiện nhưng vẫn tuân thủ đặc tả ARINC 653.

Trong bộ lễ phục. Hình 2 cho thấy kiến trúc của một hệ thống với một số phân vùng biệt lập, mỗi phân vùng đại diện cho một ứng dụng độc lập. Tất cả dữ liệu và mã trong mỗi phần được thu thập cùng nhau và thực thi ở chế độ người dùng. Các thành phần Hệ điều hành Mô-đun (MOS) và Gói hỗ trợ bo mạch (BSP) chạy ở chế độ giám sát. Ngoài ra, có thể có một phần đặc biệt với một số khả năng đặc biệt, chẳng hạn như cơ sở chuyển đổi chế độ đầu vào/đầu ra và chế độ.

ARINC 653 xác định chính xác giao diện trao đổi thông tin giữa các phân vùng, mỗi phân vùng đại diện cho một ứng dụng cộng với hệ điều hành phân vùng (POS). Giao diện này phải đảm bảo cách ly các thành phần sau.

ĐẬP. Mỗi phân vùng được phân bổ một không gian địa chỉ vật lý tuyến tính liền kề, ranh giới của không gian này không thể thay đổi trong quá trình vận hành hệ thống. Đối với mỗi phân vùng, việc phân bổ và giải phóng bộ nhớ được thực hiện và kiểm soát bởi MOS. Hệ điều hành thời gian thực phải cung cấp sự cách ly thông tin trong không gian địa chỉ trong một “khối” tuyến tính được phân bổ cho từng phần. Điều này áp dụng cho mã chương trình, hằng số, dữ liệu tĩnh, ngăn xếp và vùng heap (khu vực lấy bộ nhớ khi được yêu cầu).

Thời gian sử dụng CPU. Các quy trình trong một phân vùng có thể không ảnh hưởng đến hoạt động của các quy trình trong phân vùng khác hoặc chúng có thể ảnh hưởng đến chúng theo cách được xác định trước và được kiểm soát (ví dụ: bằng cách đặt một số cờ hoặc điều kiện). ARINC 653 yêu cầu thời gian của bộ xử lý được phân bổ cho từng phân vùng theo chu kỳ nghiêm ngặt và thời gian sở hữu bộ xử lý cho từng phân vùng phải được chỉ định trước trong bảng cấu hình. Trong mỗi phân vùng, các quy trình có thể cạnh tranh về thời gian CPU dựa trên mức độ ưu tiên (“ưu tiên”) bằng cách sử dụng lập lịch ưu tiên ưu tiên.

Mã chương trình.Đối với một số vùng bộ nhớ, MOS đặt thuộc tính "chỉ thực thi" ở chế độ giám sát. Điều này có nghĩa là các ứng dụng ở chế độ người dùng không thể phá hủy vùng mã.

Ngắt. Ngắt là các sự kiện không đồng bộ cần được chăm sóc đặc biệt để đảm bảo cách ly phần. Điều quan trọng là họ không “lấn sân” thời gian và trí nhớ sang phần khác. Một nguồn gây gián đoạn có thể xảy ra là bộ tính giờ kiểm soát việc gửi sự kiện cả trong POS và trong MOS.

Một số quy ước đã được thông qua để cung cấp sự cách ly ngắt. Ngắt hẹn giờ chỉ xảy ra ở chế độ giám sát; Không thể truy cập trực tiếp vào đồng hồ ở chế độ người dùng. Nếu POS và MOS ở các cấp độ bảo mật khác nhau thì phải cung cấp cơ chế để phân phối thông tin về các sự kiện tạm thời tới các phân vùng ứng dụng đang chạy ở chế độ người dùng. Tại những thời điểm khi phần này đang hoạt động (sở hữu thời gian của bộ xử lý), tất cả các sự kiện thời gian liên quan đến phần đó sẽ được truyền đến phần đó. Khi một phân vùng không hoạt động, tất cả các sự kiện tạm thời liên quan đến nó phải được lưu trữ và sau đó được chuyển sang phân vùng đó khi được kích hoạt.

Một nguồn gây ngắt khác là các thiết bị I/O bên ngoài. Theo yêu cầu của ARINC 653, nên sử dụng thuật toán thăm dò thiết bị cho các thiết bị có truyền dữ liệu đồng bộ. Tuy nhiên, một số thiết bị yêu cầu xử lý ngắt. Những ngắt này phải được MOS xử lý và sau đó được truyền đến POS khi phân vùng được kích hoạt. Rõ ràng, sự chậm trễ về thời gian và thậm chí mất thông tin có thể xảy ra và do đó người thiết kế phải tính đến điều này.

ARINC 653 xác định không chỉ các yêu cầu về cách ly các phân vùng mà còn cả các cơ chế tương tác giữa chúng. Các chức năng sau đây để tương tác giữa các phần đã được giới thiệu:

trao đổi tin nhắn bằng cách thiết lập kênh liên lạc, kênh này phải được mô tả trước trong bảng cấu hình hệ thống;

trao đổi qua bộ đệm, trong đó chỉ một phân vùng có thể ghi vào một bộ đệm cụ thể và tất cả các phân vùng khác chỉ có thể đọc; điều này cung cấp khả năng phát thông tin giữa các phân vùng.

Tiêu chuẩn DO-178B

Tiêu chuẩn DO-178B mô tả các kỹ thuật và phương pháp để đảm bảo tính toàn vẹn và độ tin cậy của phần mềm, bao gồm tất cả các giai đoạn trong vòng đời của phần mềm - lập kế hoạch, phát triển yêu cầu, thiết kế, mã hóa, tích hợp và thử nghiệm.

Việc lập kế hoạch DO-178B phải bao gồm các kế hoạch sau: kế hoạch về các khía cạnh chương trình của chứng nhận; kế hoạch dự án phần mềm; kế hoạch xác minh phần mềm; kế hoạch quản lý cấu hình phần mềm; kế hoạch đảm bảo chất lượng phần mềm. Trong toàn bộ vòng đời, việc tuân thủ tiêu chuẩn DO-178 phải được đảm bảo trong các lĩnh vực tuyên bố yêu cầu, thiết kế, mã hóa, xác minh và lập tài liệu. Yêu cầu phần mềm (yêu cầu cấp cao), thiết kế phần mềm (yêu cầu và kiến trúc), mã chương trình ở dạng nguồn và đối tượng phải được phát triển. Mỗi thành phần được phát triển phải được xác minh theo các tiêu chí khác nhau. Việc xác minh các yêu cầu phần mềm cấp cao bao gồm việc kiểm tra các điều kiện sau: các yêu cầu đáp ứng yêu cầu hệ thống và sẵn sàng để phân tích cùng với các yêu cầu hệ thống; yêu cầu chính xác và nhất quán; các yêu cầu tương thích với phần cứng và do đó phải được hỗ trợ bởi kết quả.

Xác minh thiết kế phần mềm bao gồm việc xác minh rằng các yêu cầu thiết kế đáp ứng các yêu cầu cấp cao và có thể được phân tích, chính xác và nhất quán và do đó có thể được hỗ trợ bởi các kết quả. Tương tự, kiến trúc và mã phần mềm phải được xác minh và cũng phải đáp ứng các yêu cầu đặt ra trong DO-178B. Tiêu chuẩn này xác định quy trình xác minh của giai đoạn tích hợp phần mềm, kiểm tra tính đầy đủ của chính quy trình xác minh, cung cấp quản lý cấu hình (bao gồm kiểm soát phiên bản) và các công cụ tự động đủ điều kiện.

Tiêu chuẩn xác định ba cấp độ kiểm tra mã cấu trúc:

Bao phủ câu lệnh có nghĩa là mọi câu lệnh trong một chương trình đều được gọi ít nhất một lần;
phạm vi quyết định có nghĩa là mọi điểm vào và ra trong chương trình được thực thi ít nhất một lần và mọi quyết định trong chương trình đều đảm nhận tất cả các giá trị đầu ra (Boolean) có thể có ít nhất một lần;
Bao gồm các giải pháp với một điều kiện có thể sửa đổi có nghĩa là mỗi điểm vào và ra trong chương trình được thực thi ít nhất một lần, mỗi quyết định trong chương trình lấy tất cả các giá trị đầu ra (Boolean) có thể có ít nhất một lần và mỗi điều kiện trong giải pháp đều dẫn đến trong một sự thay đổi độc lập trong ý nghĩa đầu ra.

Các cấp độ chứng nhận được xác định trong DO-178B khác nhau về số lượng yêu cầu (độ sâu xác minh) mà phần mềm phải đáp ứng. Các khía cạnh lý thuyết của việc xác minh mã được trình bày trong nhiều chuyên khảo cơ bản khác nhau, đặc biệt là trong tác phẩm.

Việc chứng nhận DO-178B phải được thực hiện bởi những người được gọi là Đại diện Kỹ thuật được chỉ định, những người được FAA chỉ định để xem xét dữ liệu được sử dụng trong chứng nhận. Nhà phát triển tìm cách đạt được chứng nhận cho phần mềm của mình theo DO-178B để được phép sử dụng phần mềm của mình (bao gồm cả hệ điều hành thời gian thực) trong ngành hàng không. Quyền này không chỉ áp dụng cho phần mềm mà còn cho toàn bộ sản phẩm (dự án) nói chung. Để bắt đầu quá trình chứng nhận, trước tiên nhà phát triển phải “mở” một dự án và lấy số dự án chính thức từ FAA hoặc tham gia một dự án hiện có với số dự án đã được cấp. Để “mở” một dự án, bạn phải có chứng chỉ loại hoặc chứng chỉ loại bổ sung. Thông thường, chứng chỉ loại được cấp cho máy bay và tất cả thiết bị trên máy bay đều có chứng chỉ đó. Chứng chỉ loại bổ sung được cấp cho các thiết bị bổ sung trên máy bay, bao gồm cả phần mềm.

“Tiêu chí chung” để đánh giá tính bí mật

Tiêu chí chung xác định Mức độ đảm bảo đánh giá (EAL) và đánh giá không chỉ tính bảo mật và độ tin cậy của sản phẩm mà còn cả quy trình phát triển và hỗ trợ của chúng để đảm bảo rằng các vấn đề được giải quyết nhanh chóng. Đối với hệ điều hành, các yêu cầu của Tiêu chí chung được trình bày chi tiết trong . Có bảy cấp độ đảm bảo quyền riêng tư:

EAL1 (đã kiểm tra chức năng)- áp dụng khi yêu cầu bảo mật tối thiểu nhưng bí mật không được coi là yêu cầu quan trọng;

EAL2 (đã được kiểm tra cấu trúc)- áp dụng trong trường hợp các nhà phát triển hoặc người dùng yêu cầu mức độ bảo mật trung bình trong trường hợp không có thông tin đầy đủ về tất cả các quy trình phát triển;

EAL3 (được kiểm tra và kiểm tra một cách có phương pháp)- áp dụng khi các nhà phát triển hoặc người dùng yêu cầu mức độ bí mật được đảm bảo ở mức trung bình và yêu cầu nghiên cứu toàn diện về hệ điều hành cũng như các giai đoạn phát triển của nó nhưng không cần phải làm lại hệ điều hành một cách đáng kể;

EAL4 (được thiết kế, kiểm tra và xem xét có phương pháp)- áp dụng trong trường hợp các nhà phát triển hoặc người dùng yêu cầu mức độ bảo mật cao được đảm bảo của hệ điều hành và yêu cầu sửa đổi đặc biệt đối với hệ điều hành hiện có để đáp ứng các yêu cầu này;

EAL5 (được thiết kế và thử nghiệm bán chính thức)- áp dụng khi các nhà phát triển hoặc người dùng yêu cầu mức độ bảo mật cao của hệ điều hành và cách tiếp cận nghiêm ngặt đối với thiết kế, sao cho các thuộc tính này đã được tích hợp ngay ở giai đoạn thiết kế, sử dụng các phương tiện đặc biệt để đảm bảo bí mật;

EAL6 (được xác minh, thiết kế và thử nghiệm bán chính thức)- áp dụng được khi có mức độ nguy hiểm cao và khi chi phí bảo vệ chống truy cập trái phép cao là hợp lý;

EAL7 (được xác minh, thiết kế và thử nghiệm chính thức)- nên được sử dụng trong các ứng dụng có chi phí rất cao trong trường hợp truy cập trái phép.

Cấp độ EAL được xác nhận bởi một phòng thí nghiệm đặc biệt, Phòng thí nghiệm kiểm tra tiêu chí chung.

Bảng hiển thị danh sách các yêu cầu đảm bảo bảo mật tối đa mà hệ thống phải đáp ứng ở cấp độ EAL7.

Hệ thống LynxOS-178

LynxOS-178 dựa trên hệ điều hành thời gian thực LynxOS v.3, chạy trong một phân vùng biệt lập. LynxOS v.3 được chứng nhận POSIX 1003.1-1996 trên nền tảng Intel và PowerPC.

Tính năng chính của LynxOS-178 là hỗ trợ nhiều phân vùng được phân tách hoàn toàn về thời gian, bộ nhớ và tài nguyên theo yêu cầu của ARINC 653. LynxOS-178 (phiên bản 2.0) hỗ trợ: tối đa 16 phân vùng (máy ảo), bao gồm phân vùng gốc; lên tới 64 quy trình; tối đa 51 luồng trong mỗi quy trình; gửi các luồng trong một phân vùng theo thời gian thực; chức năng giao tiếp giữa các tiến trình trong một phân vùng.

Mỗi phân vùng được cách ly hoàn toàn, khiến lỗi không thể lan truyền giữa các phân vùng.

Với LynxOS-178, các phân vùng cố định được dùng làm máy ảo LynxOS. Mỗi tiến trình ứng dụng hoạt động trong môi trường hệ điều hành riêng của nó như thể nó đang chạy trên bộ xử lý của chính nó. Điều này áp dụng cho tất cả các tài nguyên CPU và không gian được đặt tên. Sự trừu tượng hóa này bảo vệ nhà phát triển ứng dụng khỏi nỗ lực bổ sung khi lập trình một hệ thống phức tạp. Quản lý phân vùng được kiểm soát thông qua Bảng cấu hình máy ảo (VCT) và là bắt buộc trong môi trường LynxOS-178, cho phép nhà phát triển ứng dụng tập trung phát triển ứng dụng thay vì phân vùng hệ thống. Ngoài ra, LynxOS-178 hỗ trợ phân vùng các hệ thống tuân thủ RTCA DO-255, cho phép phần mềm có mức bảo mật DO-178B khác nhau chạy trên các phân vùng khác nhau (máy ảo). Điều này có nghĩa là hệ điều hành có thể chạy ứng dụng Cấp A (DO-178B) trên một máy ảo và ứng dụng Cấp C trên máy khác, với cả hai ứng dụng chạy trên cùng một bộ xử lý trong cùng một hệ thống.

Phiên bản LynxOS-178 có trong nhiều sản phẩm khác nhau (ví dụ: máy bay Bombardier Challenger 300 của Rockwell Collins) được chứng nhận theo tiêu chuẩn DO-178B và kiến trúc của chính hệ điều hành ( cơm. 3) đáp ứng yêu cầu ARINC 653.

LynxOS-178 cung cấp các nhóm dịch vụ hệ thống sau theo ARINC 653: Quản lý phân vùng - quản lý phân vùng, Quản lý quy trình - quản lý quy trình, Quản lý thời gian - quản lý thời gian, Giao tiếp giữa các phân vùng - tương tác của các quy trình trong các phần khác nhau (Dịch vụ cổng lấy mẫu và Cổng xếp hàng Dịch vụ), Giao tiếp nội bộ - tương tác của các quy trình trong một phân vùng (Dịch vụ đệm, Dịch vụ bảng đen, Dịch vụ Semaphore, Dịch vụ sự kiện), Giám sát tình trạng - theo dõi tình trạng của hệ điều hành hoặc thiết bị.

Một hệ điều hành nguyên mẫu đáp ứng EAL7 sẽ được phát hành vào năm 2006; Một hạt nhân LynxSecure mới tuân thủ MILS đang được phát triển, hạt nhân này sẽ chỉ chứa 8 nghìn dòng mã nguồn và sẽ tuân thủ các yêu cầu EAL7.

Không còn nghi ngờ gì nữa, các yêu cầu được xem xét đối với hệ điều hành thời gian thực là rất quan trọng đối với nhiều ngành công nghiệp khác, chẳng hạn như hệ thống hải quân, quân sự và vũ trụ, hệ thống thông tin liên lạc, hỗ trợ sự sống, hệ thống nhằm sử dụng trong các tình huống khẩn cấp - bất cứ nơi nào phản ứng nhanh với các sự kiện , độ tin cậy, độ bền và độ an toàn cao của các công cụ được sử dụng, bao gồm cả phần mềm.

Văn học

Hệ điều hành thời gian thực thương mại tự hoạt động và việc xem xét kiến trúc. Báo cáo cuối cùng, Hoa Kỳ Cục Hàng không Liên bang, DOT/FAA/AR-03/77, tháng 2 năm 2004.
Phân vùng trong hệ thống điện tử hàng không. Kiến trúc: Yêu cầu, Cơ chế và Sự đảm bảo. Báo cáo cuối cùng, Cơ quan Hàng không và Vũ trụ Quốc gia, DOT/FAA/AR-99/58, NASA/CR-1999-209347, tháng 3 năm 2000.
Nghiên cứu Hệ điều hành thời gian thực (RTOS) thương mại tự chế (COTS) trong ứng dụng hàng không. Báo cáo cuối cùng, Hoa Kỳ Cục Hàng không Liên bang, DOT/FAA/AR-02/118, tháng 12 năm 2002.
Đánh giá hệ điều hành thời gian thực - vai trò của tiêu chuẩn. Ủy ban Tiêu chuẩn hóa Hệ thống Điện tử (ASSC), Tài liệu số: ASSC/330/2/141, tháng 3 năm 1997.
G. Mayers, Nghệ thuật kiểm thử phần mềm. John Wiley & Sons, 1979.
Hồ sơ bảo vệ an ninh COTS - Hệ điều hành (CSPP-OS), NISTIR 6985, tháng 4 năm 2003.
Tiêu chí chung để đánh giá an ninh công nghệ thông tin. Phần 3: Yêu cầu đảm bảo an ninh. Tháng 8 năm 1999, Phiên bản 2.1, CCIMB-99-033.

Serge Zolotarev ( [email được bảo vệ]) - nhân viên của công ty RTSoft (Moscow).

Người ta đã quyết định hiện đại hóa máy bay tiếp nhiên liệu cho máy bay ném bom chiến lược tầm xa KC-135 Stratotanker để đảm bảo tuân thủ các quy định Quản lý không lưu toàn cầu quốc tế và các yêu cầu của tiêu chuẩn DO-178B. Phần cứng của Trung tâm Xử lý Tích hợp do Rockwell Collins phát triển, cung cấp khả năng tính toán và kết nối mạng có thể được sử dụng để thực hiện nhiều nhiệm vụ khác nhau (hỗ trợ nhiệm vụ, điều khiển chuyến bay, hỗ trợ hiển thị). Chức năng cơ bản được mở rộng để cho phép triển khai các ứng dụng bổ sung. Việc trao đổi dữ liệu với các thiết bị khác được thực hiện thông qua phiên bản “hàng không” của mạng Ethernet. Có một số Mô-đun có thể thay thế dòng có sẵn bên trong Trung tâm xử lý tích hợp. Hệ điều hành thời gian thực được chứng nhận LynxOS-178 chạy trên Mô-đun điện toán chung và Mô-đun tập trung đầu vào/đầu ra.

Máy bay chở dầu KC-767, cũng chạy hệ điều hành LynxOS-178, đã sẵn sàng đưa khả năng tiếp nhiên liệu trên không của Lực lượng Không quân Hoa Kỳ lên một tầm cao mới và cho các máy bay tiếp dầu KC-135E truyền thống đã hoạt động trong hơn bốn thập kỷ ngừng hoạt động. Tàu mới không chỉ rộng rãi hơn mà còn đáng tin cậy hơn, khiến nó phù hợp với phạm vi hoạt động rộng hơn. Trên thực tế, KC-767 là bốn loại máy bay khác nhau trong một. Boong nơi đặt cabin thủy thủ đoàn có thể được trang bị dễ dàng để chở hành khách hoặc hàng hóa mà không ảnh hưởng đến chức năng của tàu chở dầu. Hơn nữa, tùy theo tình huống mà tàu có thể là hành khách, hàng hóa hoặc tàu chở hỗn hợp.

Trong tài liệu tiếng Anh, hai thuật ngữ được sử dụng - an toàn và bảo mật, có thể được dịch tương tự sang tiếng Nga. Tuy nhiên, chúng có ý nghĩa khác nhau và trong bài viết này, chúng tôi sẽ sử dụng an toàn như một từ đồng nghĩa với bảo mật và bảo mật như một từ đồng nghĩa với bí mật. - Ghi chú tự động

Gửi công việc tốt của bạn trong cơ sở kiến thức rất đơn giản. Sử dụng mẫu dưới đây

Các sinh viên, nghiên cứu sinh, các nhà khoa học trẻ sử dụng nền tảng kiến thức trong học tập và công việc sẽ rất biết ơn các bạn.

Cơ quan Giáo dục Liên bang

Khoa Hệ thống điều khiển tự động

Hệ thống thời gian thực

Giới thiệu

1. Hệ điều hành thời gian thực

1.1 Các loại RTOS

1.2 Cấu trúc của RTOS

1.3 Quy trình, luồng, tác vụ

1.4 Lập kế hoạch, ưu tiên

1.5 Bộ nhớ

1.6 Ngắt

1.7 Đồng hồ và bộ hẹn giờ

2. Tiêu chuẩn cho hệ điều hành thời gian thực

2.1 Tiêu chuẩn POSIX

2.2 Tiêu chuẩn DO-178B

2.3 Tiêu chuẩn ARINC-653

2.4 Tiêu chuẩn OSEK

2.5 Tiêu chuẩn an toàn

3. Sơ lược đặc điểm các hệ điều hành thời gian thực thông dụng

3.2 QNX Neutrino RTOS

3.5 RTX (Mở rộng thời gian thực cho Windows NT)

3.6 INtime (Phần mở rộng thời gian thực của Windows NT)

3.8 MicroWare OS-9

3.11 RTOS hạt nhân

Phần kết luận

Thư mục

Giới thiệu

Các khái niệm cơ bản của hầu hết các hệ điều hành thời gian thực ngày nay đều có từ cuối những năm 1970 và đầu những năm 1980.

Hệ điều hành thời gian thực và hệ thống nhúng hoạt động trong môi trường "hạn chế", nơi sức mạnh bộ nhớ và bộ xử lý bị hạn chế. Họ phải cung cấp dịch vụ cho người dùng và thế giới mà họ tương tác trong các khung thời gian nghiêm ngặt.

Các hệ thống thời gian thực được phân biệt bởi khả năng giao diện người dùng rất khiêm tốn, vì hệ thống được chuyển sang vận hành là một “hộp đen”. Một phần rất quan trọng và tính năng chính của hệ điều hành thời gian thực là quản lý tài nguyên của máy tính theo cách mà một thao tác nhất định được thực hiện trong cùng một khoảng thời gian mỗi khi nó phải được thực hiện và không thể thực hiện được. vượt quá.

Trong một máy phức tạp, việc di chuyển một bộ phận nhanh hơn mức cần thiết chỉ vì tài nguyên hệ thống cho phép có thể dẫn đến kết quả thảm khốc, cũng như không thể di chuyển bộ phận này do hệ thống đang bận.

Thông thường, khi thiết kế một hệ thống thời gian thực, thành phần của các chương trình (nhiệm vụ) mà nó thực thi đã được biết trước. Nhiều tham số của chúng cũng đã được biết, phải được tính đến khi phân bổ tài nguyên (ví dụ: dung lượng bộ nhớ, mức độ ưu tiên, thời gian thực hiện trung bình, tệp đã mở, thiết bị được sử dụng, v.v.). Do đó, các bộ mô tả nhiệm vụ được tạo trước cho họ để sau này không lãng phí thời gian quý báu để tổ chức bộ mô tả và tìm kiếm các tài nguyên cần thiết cho nó.

Để thực hiện theo thời gian thực thực sự, cần phải có nhiều chương trình. Đa chương trình là phương tiện chính để tăng hiệu suất của hệ thống máy tính và để giải quyết các vấn đề thời gian thực, hiệu suất trở thành yếu tố quan trọng nhất.

Đặc tính hiệu suất tốt nhất cho hệ thống thời gian thực được cung cấp bởi hệ điều hành thời gian thực một thiết bị đầu cuối.

1. Hệ điều hành thời gian thực

Hệ điều hành thời gian thực là một loại hệ điều hành.

Có rất nhiều định nghĩa về thuật ngữ này. Phổ biến nhất trong số họ:

*Một hệ điều hành trong đó sự thành công của bất kỳ chương trình nào không chỉ phụ thuộc vào tính đúng đắn về mặt logic của nó mà còn phụ thuộc vào thời gian cần thiết để đạt được kết quả này. Nếu hệ thống không thể đáp ứng các ràng buộc về thời gian thì lỗi phải được ghi lại;

*Tiêu chuẩn POSIX 1003.1 định nghĩa: “Thời gian thực trong hệ điều hành là khả năng hệ điều hành cung cấp mức dịch vụ được yêu cầu trong một khoảng thời gian nhất định”;

*Một hệ điều hành phản hồi vào những thời điểm có thể dự đoán trước các sự kiện bên ngoài không thể đoán trước;

* Hệ thống tương tác sẵn sàng liên tục. Chúng được phân loại vào danh mục RTOS dựa trên các cân nhắc tiếp thị và nếu một chương trình tương tác được gọi là “thời gian thực”, thì điều này chỉ có nghĩa là các yêu cầu từ người dùng được xử lý với độ trễ mà con người không thể nhận ra.

Hệ điều hành thời gian thực (RTOS) được thiết kế để cung cấp giao diện cho tài nguyên của các hệ thống thời gian thực quan trọng về mặt thời gian. Nhiệm vụ chính trong các hệ thống như vậy là tính kịp thời của việc xử lý dữ liệu.

Yêu cầu chính đối với RTOS là đảm bảo khả năng dự đoán hoặc xác định hành vi của hệ thống trong các điều kiện bên ngoài tồi tệ nhất, khác hẳn với các yêu cầu về hiệu suất và tốc độ của các hệ điều hành phổ thông. Một RTOS tốt có hành vi có thể dự đoán được trong mọi tình huống tải hệ thống (ngắt đồng thời và thực thi luồng).

Có một số khác biệt giữa hệ thống thời gian thực và hệ thống nhúng. Một hệ thống nhúng không phải lúc nào cũng được yêu cầu phải có hành vi có thể dự đoán được, trong trường hợp đó nó không phải là hệ thống thời gian thực. Tuy nhiên, ngay cả việc xem xét nhanh các hệ thống nhúng có thể cũng cho thấy rằng hầu hết các hệ thống nhúng đều yêu cầu hành vi có thể dự đoán được đối với ít nhất một số chức năng và do đó các hệ thống này có thể được phân loại là hệ thống thời gian thực.

Martin Timmerman (giám đốc Tổ chức Tư vấn thời gian thực và Hỗ trợ người dùng thời gian thực quốc tế (RTUSI), cung cấp hỗ trợ phần cứng và phần mềm cũng như phát triển các dự án hệ thống thời gian thực) đã đưa ra các yêu cầu cần thiết sau đây đối với RTOS:

*hệ điều hành phải đa nhiệm và có khả năng ưu tiên;

*hệ điều hành phải có khái niệm về mức độ ưu tiên của các luồng;

*hệ điều hành phải hỗ trợ các cơ chế đồng bộ hóa có thể dự đoán được;

*hệ điều hành phải cung cấp cơ chế kế thừa các ưu tiên;

*hành vi của hệ điều hành phải được biết và có thể dự đoán được (độ trễ xử lý ngắt, độ trễ chuyển đổi tác vụ, độ trễ của trình điều khiển, v.v.).

Điều này có nghĩa là trong tất cả các kịch bản khối lượng công việc của hệ thống, phải xác định thời gian phản hồi tối đa.

1.1 Các loại RTOS

Người ta thường phân biệt giữa hệ thống thời gian thực mềm và cứng.

Trong các hệ thống thời gian thực cứng, việc không thể đưa ra phản hồi cho bất kỳ sự kiện nào tại một thời điểm nhất định sẽ dẫn đến lỗi và không thể hoàn thành nhiệm vụ được giao. Trong hầu hết các tài liệu tiếng Nga, những hệ thống như vậy được gọi là hệ thống có thời gian xác định. Trong các ứng dụng thực tế, thời gian phản ứng phải ở mức tối thiểu.

Hệ thống thời gian thực mềm là hệ thống không nằm trong định nghĩa “cứng”, bởi vì Vẫn chưa có định nghĩa rõ ràng cho chúng trong tài liệu. Các hệ thống thời gian thực mềm có thể không có thời gian để giải quyết vấn đề, nhưng điều này không dẫn đến sự cố của toàn bộ hệ thống.

Trong các hệ thống thời gian thực, cần phải đưa ra một thời hạn nhất định (trong tài liệu tiếng Anh - thời hạn), trước khi hết thời hạn đó, nhiệm vụ nhất thiết phải được hoàn thành (đối với hệ thống thời gian thực mềm - tốt nhất là). Thời hạn này được người lập lịch tác vụ sử dụng để chỉ định mức độ ưu tiên cho một tác vụ khi nó được khởi chạy và khi chọn một tác vụ để thực thi.

1.2 Cấu trúc của RTOS

Trong 25-30 năm qua, cấu trúc của hệ điều hành (OS) đã phát triển từ cấu trúc hệ điều hành nguyên khối sang nhiều lớp sang kiến trúc client-server.

Trong cấu trúc nguyên khối, HĐH bao gồm một tập hợp các mô-đun và những thay đổi đối với một mô-đun sẽ ảnh hưởng đến các mô-đun khác. Càng nhiều mô-đun thì càng có nhiều hỗn loạn trong quá trình vận hành một hệ thống như vậy. Ngoài ra, không thể phân phối HĐH trên hệ thống đa bộ xử lý.

Trong cấu trúc nhiều lớp, những thay đổi trong một lớp sẽ ảnh hưởng đến các lớp liền kề và ngoài ra, việc đảo ngược qua một lớp là không thể.

Đối với các hệ thống thời gian thực, phải cung cấp quyền truy cập trực tiếp vào từng lớp của HĐH và đôi khi trực tiếp vào phần cứng.

Ý tưởng chính của công nghệ máy khách-máy chủ trong một hệ điều hành là giảm thiểu cơ sở hệ điều hành (các nguyên tắc lập lịch và đồng bộ hóa). Tất cả chức năng khác được chuyển sang cấp độ khác và được triển khai thông qua các luồng hoặc tác vụ. Một tập hợp các tác vụ máy chủ như vậy chịu trách nhiệm thực hiện các cuộc gọi hệ thống. Ứng dụng là các máy khách yêu cầu dịch vụ thông qua các cuộc gọi hệ thống.

Công nghệ máy khách-máy chủ cho phép tạo ra các hệ điều hành có thể mở rộng và đơn giản hóa việc phân phối trong hệ thống đa bộ xử lý. Khi vận hành hệ thống, việc thay thế một mô-đun không gây ra hiệu ứng “quả cầu tuyết”; ngoài ra, lỗi của một mô-đun không phải lúc nào cũng kéo theo lỗi của toàn bộ hệ thống. Hiện tại có khả năng tải và dỡ tải mô-đun một cách linh hoạt. Vấn đề chính trong mô hình này là bảo vệ bộ nhớ vì các tiến trình của máy chủ phải được bảo vệ. Mỗi khi yêu cầu dịch vụ được thực hiện, hệ thống phải chuyển từ bối cảnh ứng dụng sang bối cảnh máy chủ. Với sự hỗ trợ bảo vệ bộ nhớ, thời gian chuyển đổi từ quy trình này sang quy trình khác sẽ tăng lên.

Theo quy định, hầu hết các RTOS hiện đại đều được xây dựng trên cơ sở vi nhân (hạt nhân hoặc hạt nhân), cung cấp khả năng lập lịch và điều phối các nhiệm vụ cũng như sự tương tác của chúng. Mặc dù kernel giảm thiểu sự trừu tượng hóa của hệ điều hành, nhưng microkernel vẫn cần có hiểu biết về sự trừu tượng hóa quy trình. Tất cả các khái niệm trừu tượng khác của hệ điều hành đều được chuyển ra ngoài kernel, được gọi theo yêu cầu và được thực thi dưới dạng ứng dụng.

1.3 Quy trình, luồng, tác vụ

Khái niệm đa nhiệm (giả song song) là cần thiết cho hệ thống thời gian thực một bộ xử lý mà các ứng dụng của nó phải có khả năng xử lý nhiều sự kiện bên ngoài xảy ra gần như đồng thời.

Khái niệm về một quy trình, xuất phát từ thế giới UNIX, được triển khai kém trong hệ thống đa nhiệm vì quy trình này có ngữ cảnh nặng nề. Khái niệm thread nảy sinh, được hiểu là một subprocess, hay một tiến trình nhẹ. Các luồng tồn tại trong cùng một ngữ cảnh tiến trình, do đó việc chuyển đổi giữa các luồng diễn ra rất nhanh và các vấn đề bảo mật không được tính đến. Các luồng rất nhẹ vì bối cảnh đăng ký của chúng nhỏ hơn, tức là. bộ điều khiển của họ nhỏ gọn hơn nhiều. Chi phí do việc lưu và khôi phục các khối điều khiển của các luồng bị gián đoạn gây ra sẽ giảm. Kích thước của khối điều khiển phụ thuộc vào cấu hình bộ nhớ. Nếu các luồng đang chạy trong các không gian địa chỉ khác nhau, hệ thống phải hỗ trợ ánh xạ bộ nhớ cho từng bộ luồng.

Vì vậy, trong các hệ thống thời gian thực, quy trình được chia thành các tác vụ hoặc luồng. Trong cả hai trường hợp, mỗi quy trình đều được coi là một ứng dụng. Không nên có quá nhiều tương tác giữa các ứng dụng này và trong hầu hết các trường hợp, chúng có bản chất khác nhau - thời gian thực cứng, thời gian thực mềm, phi thời gian thực.

1.4 Lập kế hoạch, ưu tiên

Vấn đề chính trong RTOS là lập lịch tác vụ, điều này sẽ đảm bảo hoạt động của hệ thống có thể dự đoán được trong mọi trường hợp. Liên quan đến các vấn đề lập lịch trong RTOS, hai phương pháp được nghiên cứu và phát triển - thuật toán lập lịch tĩnh (RMS - Lập kế hoạch đơn điệu tốc độ) và thuật toán lập lịch động (EDF - Thời hạn sớm nhất trước tiên).

RMS được sử dụng để chứng minh chính thức các điều kiện có thể dự đoán được của một hệ thống. Để thực hiện lý thuyết này, cần phải lập kế hoạch ưu tiên trước. Trong lý thuyết RMS, mức độ ưu tiên được chỉ định trước cho từng quy trình. Các quy trình phải đáp ứng các điều kiện sau:

*quá trình này phải được hoàn thành trong khoảng thời gian của nó;

*các quy trình không phụ thuộc vào nhau;

*mỗi quy trình yêu cầu cùng thời gian CPU ở mỗi khoảng thời gian;

*quy trình không định kỳ không có thời hạn nghiêm ngặt;

*sự gián đoạn của quá trình xảy ra trong một thời gian giới hạn.

Các tiến trình được thực hiện theo thứ tự ưu tiên. Khi lập lịch RMS, ưu tiên dành cho các nhiệm vụ có thời gian hoàn thành ngắn nhất.

Trong EDF, mức độ ưu tiên được chỉ định động và mức ưu tiên cao nhất được chỉ định cho quy trình còn lại thời gian thực hiện ngắn nhất. Ở mức tải hệ thống cao, EDF có lợi thế hơn RMS.

Tất cả các hệ thống thời gian thực đều yêu cầu chính sách lập lịch theo thời hạn. Tuy nhiên, cách tiếp cận này đang được phát triển.

RTOS thường sử dụng lập lịch ưu tiên gián đoạn dịch vụ dựa trên RMS. Ưu tiên gián đoạn dịch vụ (ưu tiên) là một thành phần không thể thiếu của RTOS, bởi vì Trong hệ thống thời gian thực, phải có sự đảm bảo rằng sự kiện có mức độ ưu tiên cao sẽ được xử lý trước sự kiện có mức độ ưu tiên thấp hơn. Tất cả điều này dẫn đến thực tế là RTOS không chỉ cần cơ chế lập lịch dựa trên mức độ ưu tiên gián đoạn mà còn cần một cơ chế thích hợp để quản lý các gián đoạn. Hơn nữa, RTOS phải có khả năng vô hiệu hóa các ngắt khi mã quan trọng cần được thực thi mà không thể bị gián đoạn. Thời gian xử lý ngắt phải được giữ ở mức tối thiểu.

RTOS phải có một hệ thống ưu tiên được phát triển. Đầu tiên, điều này là bắt buộc vì bản thân hệ thống có thể được xem như một tập hợp các ứng dụng máy chủ được chia thành các luồng và một số mức độ ưu tiên cao phải được phân bổ cho các tiến trình và luồng của hệ thống. Thứ hai, trong các ứng dụng phức tạp, tất cả các luồng thời gian thực phải được đặt ở các mức ưu tiên khác nhau và các luồng không phải thời gian thực phải được đặt ở cùng cấp (thấp hơn bất kỳ luồng thời gian thực nào). Trong trường hợp này, các luồng không theo thời gian thực có thể được xử lý ở chế độ lập lịch vòng tròn (RRS), trong đó mỗi tiến trình được cấp một lát thời gian của bộ xử lý và khi lát cắt kết thúc, bối cảnh quy trình sẽ được lưu và nó được đặt vào vị trí. ở cuối hàng đợi. Nhiều RTOS sử dụng RRS để lên lịch các tác vụ ở một cấp độ. Mức độ ưu tiên 0 thường được sử dụng cho chế độ không tải.

Khi lập kế hoạch dựa trên các ưu tiên, có hai vấn đề cấp thiết cần được giải quyết:

*đảm bảo việc thực hiện quy trình với mức độ ưu tiên cao nhất,

*ngăn chặn sự đảo ngược mức độ ưu tiên, khi các tác vụ có mức độ ưu tiên cao chờ tài nguyên được chiếm bởi các tác vụ có mức độ ưu tiên thấp hơn.

Để chống đảo ngược mức độ ưu tiên, RTOS thường sử dụng cơ chế kế thừa mức độ ưu tiên, nhưng điều này giúp loại bỏ việc lập lịch dựa trên RMS vì các mức độ ưu tiên trở nên động.

1.5 Bộ nhớ

Như đã đề cập ở trên, độ trễ chuyển ngữ cảnh luồng trực tiếp phụ thuộc vào cấu hình bộ nhớ, tức là. từ mô hình bảo vệ bộ nhớ. Có bốn mô hình bảo vệ bộ nhớ phổ biến nhất trong RTOS:

*Mô hình không có bảo vệ - không gian địa chỉ hệ thống và người dùng không được bảo vệ lẫn nhau, hai phân đoạn bộ nhớ được sử dụng: cho mã và cho dữ liệu, trong khi hệ thống không yêu cầu bất kỳ quản lý bộ nhớ nào, không yêu cầu MMU (đơn vị quản lý bộ nhớ - một thiết bị phần cứng đặc biệt hỗ trợ quản lý bộ nhớ ảo);

*Mô hình bảo mật hệ thống/người dùng - không gian địa chỉ hệ thống được bảo vệ khỏi không gian địa chỉ người dùng, các quy trình hệ thống và người dùng chạy trong không gian địa chỉ ảo chung và cần có MMU. Bảo vệ được cung cấp bởi cơ chế bảo vệ trang. Có các trang hệ thống và người dùng. Các ứng dụng của người dùng không được bảo vệ lẫn nhau dưới bất kỳ hình thức nào. Bộ xử lý ở chế độ giám sát nếu phân đoạn hiện tại ở cấp 0, 1 hoặc 2. Nếu cấp phân đoạn là 3 thì bộ xử lý ở chế độ người dùng. Trong mô hình này, cần có bốn phân đoạn - hai phân đoạn ở cấp 0 (dành cho mã và dữ liệu) và hai phân đoạn ở cấp 3. Cơ chế bảo vệ trang không thêm chi phí vì bảo mật được kiểm tra đồng thời với việc dịch địa chỉ do MMU thực hiện; trong trường hợp này, HĐH không cần quản lý bộ nhớ.

*Mô hình bảo mật người dùng/người dùng - bổ sung bảo mật giữa các tiến trình của người dùng vào mô hình hệ thống/người dùng, yêu cầu MMU. Như trong mô hình trước, cơ chế bảo vệ trang được sử dụng. Tất cả các trang được đánh dấu là đặc quyền, ngoại trừ các trang của quy trình hiện tại được đánh dấu là trang người dùng. Do đó, luồng thực thi không thể truy cập vào giới hạn không gian địa chỉ của nó. Hệ điều hành chịu trách nhiệm cập nhật cờ đặc quyền cho một trang cụ thể trong bảng trang khi một tiến trình chuyển đổi. Như trong mô hình trước, bốn phân đoạn được sử dụng.

*Mô hình bảo vệ bộ nhớ ảo - mỗi tiến trình chạy trong bộ nhớ ảo riêng, yêu cầu MMU. Mỗi tiến trình có các phân đoạn riêng và do đó có bảng mô tả riêng. Hệ điều hành chịu trách nhiệm duy trì các bảng xử lý. Không gian có thể định địa chỉ có thể vượt quá kích thước của bộ nhớ vật lý nếu bộ nhớ phân trang được sử dụng cùng với phân trang. Tuy nhiên, các hệ thống thời gian thực thường không sử dụng phân trang vì tính khó dự đoán của nó. Để giải quyết vấn đề này, bộ nhớ khả dụng được chia thành một số không gian địa chỉ logic cố định có kích thước bằng nhau. Số lượng tiến trình chạy đồng thời trong hệ thống trở nên hạn chế.

Yêu cầu cơ bản đối với bộ nhớ trong hệ thống thời gian thực là thời gian truy cập phải được giới hạn (hay nói cách khác là có thể dự đoán được). Hậu quả trực tiếp là lệnh cấm sử dụng các kỹ thuật gọi trang theo yêu cầu (phân trang đĩa) cho các quy trình thời gian thực. Do đó, các hệ thống cung cấp cơ chế bộ nhớ ảo phải có khả năng khóa một tiến trình trong RAM, ngăn chặn việc hoán đổi. Vì vậy, việc hoán đổi không được phép trong RTOS vì nó không thể đoán trước được.

Nếu phân trang được hỗ trợ, việc ánh xạ thích hợp các trang tới địa chỉ vật lý phải là một phần của ngữ cảnh quy trình. Nếu không, khả năng không thể đoán trước lại xuất hiện, điều này không thể chấp nhận được đối với RTOS.

Đối với các quy trình không phải là quy trình thời gian thực cứng, có thể sử dụng cơ chế cấp phát bộ nhớ động, nhưng RTOS phải hỗ trợ xử lý hết thời gian chờ cho các yêu cầu bộ nhớ, tức là. hạn chế về thời gian chờ đợi có thể dự đoán được.

Trong các hệ điều hành thông thường, khi sử dụng cơ chế phân đoạn bộ nhớ, việc nén sau khi thu gom rác được sử dụng để chống phân mảnh. Tuy nhiên, cách tiếp cận này không thể áp dụng trong môi trường thời gian thực, bởi vì Trong quá trình nén, các tác vụ đã di chuyển không thể được thực thi, dẫn đến hệ thống không thể đoán trước được. Đây là vấn đề chính về khả năng áp dụng cách tiếp cận hướng đối tượng vào các hệ thống thời gian thực. Cho đến khi vấn đề nén được giải quyết, C++ và JAVA sẽ vẫn là những lựa chọn kém cho các hệ thống thời gian thực cứng.

Các hệ thống thời gian thực cứng thường sử dụng cấp phát bộ nhớ tĩnh. Trong các hệ thống thời gian thực mềm, có thể cấp phát bộ nhớ động mà không cần bộ nhớ ảo và không cần nén.

1.6 Ngắt

Khi mô tả quản lý ngắt, hai thủ tục thường được phân biệt, đó là:

*ngắt dịch vụ thường xuyên (ISR) - một chương trình cấp thấp trong kernel với các lệnh gọi hệ thống hạn chế,

*luồng phục vụ ngắt (IST - luồng phục vụ ngắt) - luồng cấp ứng dụng quản lý sự gián đoạn, có quyền truy cập vào tất cả các cuộc gọi hệ thống.

Thông thường, ISR được nhà sản xuất phần cứng triển khai và trình điều khiển thiết bị thực hiện quản lý ngắt bằng IST. Các luồng ngắt hoạt động giống như bất kỳ luồng nào khác và sử dụng cùng một hệ thống ưu tiên. Điều này có nghĩa là người thiết kế hệ thống có thể ưu tiên IST thấp hơn luồng ứng dụng.

1.7 Đồng hồ và bộ hẹn giờ

RTOS sử dụng nhiều dịch vụ thời gian khác nhau. Hệ điều hành theo dõi thời gian hiện tại, bắt đầu các tác vụ và luồng vào những thời điểm nhất định và tạm dừng chúng trong những khoảng thời gian nhất định. Dịch vụ thời gian RTOS sử dụng đồng hồ thời gian thực. Thông thường, đồng hồ phần cứng có độ chính xác cao được sử dụng. Bộ hẹn giờ được tạo ra để đếm các khoảng thời gian dựa trên đồng hồ thời gian thực.

Mỗi tiến trình và luồng được gán một đồng hồ CPU. Những đồng hồ này được sử dụng để tạo bộ đếm thời gian đo xem một tiến trình hoặc luồng có đang chạy theo thời gian hay không, cho phép nó tự động phát hiện các lỗi hoặc lỗi phần mềm trong việc tính toán thời gian thực hiện tối đa có thể.

Trong các hệ thống có độ tin cậy cao, quan trọng về thời gian, điều quan trọng là xác định các tình huống trong đó một tác vụ vượt quá thời gian thực hiện tối đa có thể, bởi vì trong trường hợp này, hoạt động của hệ thống có thể vượt quá thời gian phản hồi có thể chấp nhận được. Đồng hồ thời gian chạy cho phép bạn xác định thời điểm xảy ra tình trạng vượt thời gian và bắt đầu các hành động xử lý lỗi thích hợp.

Hầu hết RTOS hoạt động với thời gian tương đối. Một điều gì đó xảy ra “trước” và “sau” một sự kiện nào đó khác. Trong một hệ thống hoàn toàn hướng sự kiện, cần có cơ chế đồng hồ (ticker), bởi vì không có sự cắt lát thời gian. Tuy nhiên, nếu cần dấu thời gian cho một số sự kiện nhất định hoặc lệnh gọi hệ thống như “đợi một giây” thì cần có đồng hồ và/hoặc bộ hẹn giờ.

Đồng bộ hóa trong RTOS được thực hiện bằng cơ chế chặn (hoặc chờ) cho đến khi một sự kiện nhất định xảy ra. Thời gian tuyệt đối không được sử dụng.

Việc triển khai RTOS của các khái niệm trừu tượng khác cũng tương tự như việc triển khai chúng trong các hệ điều hành truyền thống.

2. Tiêu chuẩn cho hệ điều hành thời gian thực

2.1 Tiêu chuẩn POSIX

Sự khác biệt lớn về thông số kỹ thuật RTOS và số lượng lớn các bộ vi điều khiển hiện có dẫn đến vấn đề tiêu chuẩn hóa trong lĩnh vực hệ thống thời gian thực.

Tiêu chuẩn RTOS sớm nhất và phổ biến nhất là tiêu chuẩn POSIX (Giao diện hệ điều hành di động IEEE cho môi trường máy tính, IEEE 1003.1). Phiên bản gốc của tiêu chuẩn POSIX xuất hiện vào năm 1990 và dành cho các hệ thống UNIX, phiên bản đầu tiên xuất hiện vào những năm 70 của thế kỷ trước. Các thông số kỹ thuật POSIX xác định một cơ chế tiêu chuẩn cho sự tương tác giữa chương trình ứng dụng và hệ điều hành và hiện bao gồm một bộ gồm hơn 30 tiêu chuẩn. Đối với RTOS, bảy trong số đó là quan trọng nhất (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), nhưng chỉ có ba cái đầu tiên được hỗ trợ rộng rãi trong các hệ điều hành thương mại.

Bất chấp các điều khoản rõ ràng đã lỗi thời của tiêu chuẩn POSIX và nhu cầu lớn về cập nhật tiêu chuẩn hóa cho RTOS, vẫn chưa có tiến bộ đáng chú ý nào theo hướng này.

Tiêu chuẩn POSIX được tạo ra như một giao diện tiêu chuẩn cho các dịch vụ hệ điều hành. Tiêu chuẩn này cho phép tạo ra các ứng dụng di động. Tiêu chuẩn này sau đó đã được mở rộng để bao gồm các tính năng thời gian thực.

Thông số kỹ thuật POSIX xác định cơ chế tiêu chuẩn cho sự tương tác giữa ứng dụng và HĐH. Cần lưu ý rằng tiêu chuẩn POSIX có liên quan chặt chẽ với hệ điều hành Unix, tuy nhiên, các nhà phát triển của nhiều RTOS cố gắng tuân thủ tiêu chuẩn này.

Việc tuân thủ tiêu chuẩn POSIX cho hệ điều hành và nền tảng phần cứng phải được chứng nhận bằng cách chạy các trường hợp thử nghiệm trên chúng. Tuy nhiên, nếu hệ điều hành không giống Unix thì việc đáp ứng yêu cầu này sẽ trở thành một thách thức. Bộ thử nghiệm chỉ tồn tại cho POSIX 1003.1a. Vì cấu trúc POSIX là tập hợp các tính năng tùy chọn nên các nhà cung cấp hệ điều hành chỉ có thể triển khai một phần của giao diện chuẩn và vẫn tuyên bố rằng hệ thống của họ tuân thủ POSIX.

Mặc dù tiêu chuẩn POSIX phát triển từ Unix, nhưng nó giải quyết các khái niệm trừu tượng cơ bản của hệ điều hành và các tiện ích mở rộng thời gian thực áp dụng cho tất cả các RTOS.

Hiện tại, tiêu chuẩn POSIX được xem như một nhóm các tiêu chuẩn liên quan: IEEE Std 1003.n (trong đó n là một số).

2.2 Tiêu chuẩn DO-178B

Tiêu chuẩn DO-178B được Ủy ban Kỹ thuật Vô tuyến Hàng không (RTCA) tạo ra để phát triển phần mềm cho các hệ thống trên máy bay.

Phiên bản đầu tiên của nó được áp dụng vào năm 1982, phiên bản thứ hai (DO-178A) - vào năm 1985, DO-178B hiện tại - vào năm 1992. Việc áp dụng phiên bản mới, DO-178C, đang được chuẩn bị. Tiêu chuẩn này cung cấp năm mức độ nghiêm trọng của lỗi và đối với mỗi mức độ đó, một bộ yêu cầu phần mềm được xác định phải đảm bảo chức năng của toàn bộ hệ thống khi xảy ra lỗi ở mức độ nghiêm trọng này.

Tiêu chuẩn này xác định các cấp độ chứng nhận sau:

*A (thảm họa),

*B (nguy hiểm),

*С (đáng kể),

*D (không đáng kể)

*E (không ảnh hưởng).

Cho đến khi tất cả các yêu cầu nghiêm ngặt của tiêu chuẩn này được đáp ứng, các hệ thống máy tính nhạy cảm về bảo mật sẽ không bao giờ cất cánh được.

2.3 Tiêu chuẩn ARINC-653

Tiêu chuẩn ARINC-653 (Giao diện tiêu chuẩn phần mềm ứng dụng điện tử hàng không) được ARINC phát triển vào năm 1997. Tiêu chuẩn này xác định giao diện phần mềm APEX (Ứng dụng/Điều hành) phổ quát giữa hệ điều hành máy tính của máy bay và phần mềm ứng dụng.

Các yêu cầu về giao diện giữa phần mềm ứng dụng và dịch vụ hệ điều hành được xác định để cho phép phần mềm ứng dụng kiểm soát việc điều phối, liên lạc và trạng thái của các phần tử xử lý nội bộ. Năm 2003, phiên bản mới của tiêu chuẩn này đã được thông qua. ARINC-653 giới thiệu kiến trúc của các máy ảo được phân vùng là một trong những yêu cầu chính đối với RTOS trong ngành hàng không.

2.4 Tiêu chuẩn OSEK

Tiêu chuẩn OSEK/VDX là sự kết hợp của các tiêu chuẩn ban đầu được phát triển ở hai tập đoàn riêng biệt sau đó được hợp nhất. OSEK lấy tên từ từ viết tắt tiếng Đức của một tập đoàn bao gồm các nhà sản xuất ô tô hàng đầu của Đức BMW, Bosch, Daimler Benz (nay là Daimler Chrysler), Opel, Siemens và Volkswagen, cũng như Đại học Karlsruhe (Đức). Dự án VDX (Vehicle Distributed eXecutive) được phát triển bởi các công ty PSA và Renault của Pháp. Nhóm OSEK và VDX hợp nhất vào năm 1994.

Dự án OSEK/VDX ban đầu được dự định phát triển kiến trúc hệ điều hành mở và tiêu chuẩn API cho các hệ thống được sử dụng trong ngành công nghiệp ô tô. Tuy nhiên, tiêu chuẩn được phát triển hóa ra lại trừu tượng hơn và không chỉ giới hạn sử dụng trong ngành công nghiệp ô tô.

Tiêu chuẩn OSEK/VDX bao gồm ba phần - tiêu chuẩn hệ điều hành (OS), tiêu chuẩn truyền thông (COM) và tiêu chuẩn trình quản lý mạng (NM). Ngoài các tiêu chuẩn này, ngôn ngữ triển khai (OIL) cũng được xác định. Thành phần đầu tiên của tiêu chuẩn OSEK là tiêu chuẩn hệ điều hành, đó là lý do tại sao tiêu chuẩn OSEK thường bị hiểu nhầm là tiêu chuẩn RTOS. Mặc dù HĐH là một phần lớn của tiêu chuẩn này nhưng sức mạnh của nó nằm ở sự tích hợp tất cả các thành phần của nó.

2.5 Tiêu chuẩn an toàn

Liên quan đến các tiêu chuẩn cho RTOS, cần lưu ý tiêu chuẩn nổi tiếng về tiêu chí đánh giá sự phù hợp của hệ thống máy tính (Tiêu chí đánh giá hệ thống máy tính đáng tin cậy - TCSEC). Tiêu chuẩn này được Bộ Quốc phòng Mỹ phát triển và còn được gọi là Sách Cam vì màu bìa.

Một số quốc gia khác cũng đã xây dựng các tiêu chí tương tự, trên cơ sở đó xây dựng tiêu chuẩn quốc tế “Tiêu chí chung để đánh giá bảo mật CNTT” (ISO/IEC 15408).

Sách Cam liệt kê bảy cấp độ bảo vệ:

*A1 - sự phát triển đã được xác minh. Cấp độ này yêu cầu việc bảo vệ thông tin mật và thông tin nhạy cảm khác bằng các biện pháp kiểm soát an ninh phải được đảm bảo bằng các phương pháp xác minh chính thức.

*B3 - miền bảo mật. Cấp độ này nhằm bảo vệ hệ thống khỏi các lập trình viên có kinh nghiệm.

*B2 - bảo vệ có cấu trúc. Một hệ thống có mức độ bảo vệ này không thể bị tin tặc xâm nhập.

*B1 - kiểm soát truy cập bắt buộc. Một hacker có kinh nghiệm có thể vượt qua được mức độ bảo vệ này, nhưng người dùng bình thường thì không.

*C2 - kiểm soát truy cập tùy ý. Cấp độ C2 cung cấp bảo mật cho quy trình đăng nhập, cho phép giám sát các sự kiện liên quan đến bảo mật và cách ly tài nguyên.

*C1 - bảo vệ có chọn lọc. Cấp độ này cung cấp cho người dùng khả năng bảo vệ dữ liệu cá nhân hoặc thông tin dự án bằng cách đặt các biện pháp kiểm soát quyền truy cập.

*D - mức bảo vệ tối thiểu. Mức độ bảo vệ thấp hơn này được dành riêng cho các hệ thống đã được thử nghiệm nhưng không thể đáp ứng các yêu cầu của loại cao hơn.

3. Đặc điểm tóm tắt của các hệ điều hành thời gian thực phổ biến nhất

3.1 VxWorks

Hệ điều hành thời gian thực thuộc dòng VxWorks của WindRiver Systems Corporation được thiết kế để phát triển phần mềm cho các máy tính nhúng hoạt động trong hệ thống thời gian thực cứng.

Hệ điều hành VxWorks có kiến trúc client-server và được xây dựng theo công nghệ vi nhân, tức là. lớp hạt nhân không bị gián đoạn thấp nhất (WIND Microkernel) chỉ xử lý việc lập lịch tác vụ và quản lý đồng bộ hóa/giao tiếp tác vụ. Tất cả chức năng khác của nhân điều hành - quản lý bộ nhớ, đầu vào/đầu ra, v.v. - được cung cấp ở mức cao hơn và được triển khai thông qua các quy trình. Điều này đảm bảo hiệu suất và tính xác định của hạt nhân cũng như khả năng mở rộng hệ thống.

VxWorks có thể được cấu hình cho các hệ thống nhúng nhỏ có hạn chế về bộ nhớ cho đến các hệ thống phức tạp, giàu tính năng.

Mặc dù hệ thống VxWorks có thể cấu hình được, tức là. Các mô-đun riêng lẻ có thể được tải tĩnh hoặc động; không thể nói là sử dụng cách tiếp cận dựa trên thành phần. Tất cả các mô-đun đều được xây dựng trên hạt nhân cơ sở và được thiết kế theo cách mà chúng không thể được sử dụng trong các môi trường khác.

3.2 QNX Neutrino RTOS

Hệ điều hành thời gian thực QNX Neutrino (RTOS) từ Hệ thống phần mềm QNX là hệ điều hành vi nhân cung cấp khả năng đa nhiệm được ưu tiên.

QNX Neutrino RTOS có kiến trúc máy khách-máy chủ. Trong môi trường QNX Neutrino, mọi trình điều khiển, ứng dụng, giao thức và hệ thống tệp đều chạy bên ngoài kernel, trong một không gian địa chỉ được bảo vệ. Nếu bất kỳ thành phần nào bị lỗi, nó có thể tự động khởi động lại mà không ảnh hưởng đến các thành phần khác hoặc kernel. Mặc dù hệ thống QNX có thể cấu hình được, tức là. Mặc dù các mô-đun riêng lẻ có thể được tải tĩnh hoặc động, nhưng không thể nói là sử dụng cách tiếp cận dựa trên thành phần. Tất cả các mô-đun đều dựa vào nhân cơ sở và được thiết kế sao cho chúng không thể sử dụng được trong các môi trường khác.

QNX Neutrino RTOS bao gồm kernel, trình quản lý quy trình và các dịch vụ cấp độ người dùng nâng cao. Là một hệ điều hành vi nhân thực sự, QNX Neutrino RTOS chỉ triển khai các dịch vụ cơ bản nhất trong nhân hệ điều hành, chẳng hạn như truyền tin nhắn, tín hiệu, bộ hẹn giờ, lập lịch luồng và các đối tượng đồng bộ hóa. Tất cả các dịch vụ, trình điều khiển và ứng dụng hệ điều hành khác chạy dưới dạng các quy trình riêng biệt giao tiếp thông qua việc truyền tin nhắn đồng bộ.

QNX Neutrino RTOS có thời gian xử lý ngắt ngắn và chuyển đổi ngữ cảnh nhanh. Sự đảo ngược ưu tiên được khắc phục bằng cách sử dụng kế thừa ưu tiên phân tán. Mô hình hóa đơn giản hóa các hoạt động thời gian thực được thực hiện thông qua việc truyền tin nhắn đồng bộ. Các ngắt lồng nhau và giới hạn trên cố định về thời gian xử lý ngắt đảm bảo rằng các ngắt có mức ưu tiên cao được xử lý nhanh chóng với thời gian có thể dự đoán được.

3.3 REMS

RTEMS (Điều hành thời gian thực cho hệ thống đa bộ xử lý) là một hệ điều hành thời gian thực phi thương mại dành cho các hệ thống nhúng sâu.

Nhà phát triển hệ thống là OAR (Tập đoàn nghiên cứu ứng dụng trực tuyến, Hoa Kỳ). Hệ thống này được tạo ra theo lệnh của Bộ Quốc phòng Hoa Kỳ để sử dụng trong các hệ thống điều khiển hệ thống tên lửa. Hệ thống này đang được phát triển cho các hệ thống đa bộ xử lý dựa trên mã nguồn mở, trái ngược với các hệ thống nguồn đóng tương tự. Hệ thống này được thiết kế cho nền tảng MS-Windows và Unix (GNU/Linux, FreeBSD, Solaris, MacOS X).

Lõi RTEMS cung cấp chức năng cơ bản của hệ thống thời gian thực. Những tính năng này bao gồm

*xử lý đa nhiệm;

*làm việc trong các hệ thống đồng nhất và không đồng nhất;

*lập kế hoạch theo hướng sự kiện dựa trên mức độ ưu tiên;

*lập kế hoạch với tốc độ đơn điệu;

*tương tác và đồng bộ hóa nhiệm vụ;

*ưu tiên kế thừa;

*điều khiển ngắt phản hồi;

*phân bổ bộ nhớ động;

*cấu hình hệ thống cho người dùng được ủy quyền;

* di động tới nhiều nền tảng mục tiêu.

RTOS được liên kết với phần cứng bằng thư viện đặc biệt gồm các chương trình con BSP (gói hỗ trợ bo mạch) và các chương trình con chuyên dụng cho các kiến trúc khác nhau.

RTEMS không hỗ trợ tải động các ứng dụng và mô-đun, vì vậy phạm vi ứng dụng của nó là các hệ thống nhúng trong đó không cần phải sửa đổi phần mềm thường xuyên.

RTOS RTEMS cung cấp hỗ trợ khá yếu cho các hệ thống tệp, điều này giới hạn phạm vi ứng dụng có thể có của nó trong lĩnh vực hệ thống lưu trữ và thu thập dữ liệu tập trung đối với các công cụ cấp cao tiêu chuẩn.

3.4 Hợp xướng

Hệ điều hành ChorusOS là một hệ điều hành nhúng có khả năng mở rộng được sử dụng rộng rãi trong ngành viễn thông. Hiện nay, thương hiệu này được phát triển và phân phối bởi Tập đoàn Sun Microsystems.

Để xây dựng và triển khai ChorusOS trên các nền tảng viễn thông cụ thể, Sun Microsystems cung cấp việc sử dụng môi trường phát triển Sun Embedded Workshop. Sun Microsystems đang giới thiệu ChorusOS làm nền tảng nhúng cho Mạng hướng dịch vụ của Sun. Kết hợp với nhiều dịch vụ, tích hợp phần mềm và phần cứng liền mạch, quản trị và hỗ trợ dễ dàng cho công nghệ Java dành riêng cho nhu cầu viễn thông, ChorusOS cho phép bạn triển khai hiệu quả các tính năng và ứng dụng mới, duy trì độ tin cậy và chức năng của mạng hiện đại.

ChorusOS hỗ trợ nhiều giao thức viễn thông, ứng dụng cũ, ứng dụng thời gian thực và công nghệ Java trên một nền tảng phần cứng duy nhất.

ChorusOS mô hình ba loại ứng dụng:

*Quy trình POSIX chiếm phần lớn các ứng dụng ChorusOS, các ứng dụng này có quyền truy cập vào API POSIX, một số API mở rộng giống POSIX và một số lượng nhỏ lệnh gọi hệ thống vi nhân hạn chế;

*Các tác nhân ChorusOS - các ứng dụng này chạy trên vi nhân và bị giới hạn bởi API vi nhân, các tác nhân bao gồm trình điều khiển, sự kiện hệ thống con và ngăn xếp giao thức;

*Các ứng dụng ChorusOS cũ được hỗ trợ để tương thích với các ứng dụng được phát triển cho các phiên bản ChorusOS cũ hơn.

Kiến trúc của Hệ điều hành ChorusOS là nhiều lớp, dựa trên thành phần. Microkernel chứa tập hợp các thành phần tối thiểu cần thiết cho hoạt động của HĐH. Kích thước của phần cư trú của kernel là 10Kb.

Khái niệm “tác nhân” trong ChorusOS được định nghĩa là đơn vị tải cho một ứng dụng. Nó cũng đóng vai trò như một đơn vị đóng gói để ánh xạ tất cả các tài nguyên hệ thống được ứng dụng sử dụng và các luồng chạy bên trong tác nhân. Ví dụ về các tài nguyên như vậy là các luồng, vùng bộ nhớ và điểm cuối giao tiếp.

ChorusOS 5.0 hỗ trợ môi trường vận hành Solaris và hỗ trợ các nền tảng mục tiêu sau:

*UltraSPARC II (CP1500 và CP20x0);

*Intel x86, Pentium;

*Dòng bộ xử lý Motorola PowerPC 750 và 74x0 (mpc7xx);

*Motorola PowerQUICC I (mpc8xx) và PowerQUICC II (mpc8260) (vi điều khiển).

3.5 RTX (Mở rộng thời gian thực cho Windows NT)

Windows NT được thiết kế và sử dụng chủ yếu như một hệ điều hành đa năng. Tuy nhiên, trên thị trường hệ thống thời gian thực đang có xu hướng rõ ràng là sử dụng Windows NT và các phần mở rộng của nó trong các hệ thống chuyên dụng. Cái này có một vài nguyên nhân:

*Windows NT được thiết kế theo công nghệ hệ điều hành hiện đại,

*giao diện lập trình ứng dụng (API) cho Win32 đã trở thành tiêu chuẩn thực tế cho các lập trình viên,

*giao diện người dùng đồ họa (GUI) đã trở nên phổ biến đến mức các hệ điều hành khác đang cố gắng cung cấp giao diện tương tự,

*có sẵn một số lượng lớn trình điều khiển thiết bị,

*Có sẵn nhiều môi trường phát triển tích hợp mạnh mẽ.

Bản thân Windows NT không phù hợp để sử dụng trong các hệ thống thời gian thực, vì nó có quá ít mức độ ưu tiên và không có cơ chế kế thừa các mức độ ưu tiên. Để giảm thiểu thời gian dịch vụ gián đoạn (ISR), Windows NT đã đưa ra khái niệm cuộc gọi thủ tục trì hoãn (DPC), mức ưu tiên của nó cao hơn mức ưu tiên của các luồng hệ thống và người dùng, trong khi tất cả các DPC đều có cùng mức ưu tiên. Điều này khiến tất cả các DPC được xếp hàng vào hàng đợi FIFO và một DPC có ngắt cấp cao sẽ chỉ có thể thực thi sau khi tất cả các DPC khác được xếp hàng trước khi nó hoàn thành. Những tình huống như vậy dẫn đến thời gian phản hồi không thể đoán trước, không tương thích với các yêu cầu RTOS. Quản lý bộ nhớ trong Windows NT dựa trên cơ chế bộ nhớ ảo. Điều này đòi hỏi phải bảo vệ bộ nhớ, dịch địa chỉ và hoán đổi, điều này không thể chấp nhận được trong RTOS.

RTX (Tiện ích mở rộng thời gian thực) dành cho Windows NT (được phát triển bởi VenturCom Corporation) cho phép bạn tạo các ứng dụng điều khiển tốc độ cao với thời gian phản hồi xác định đối với các sự kiện bên ngoài.

RTX được tích hợp sâu vào nhân Windows NT và sử dụng dịch vụ Windows NT cũng như API WIN32 để cung cấp các chức năng cần thiết. Hạt nhân thời gian thực (hạt nhân) được tích hợp vào hạt nhân (kernel) NT. Mỗi quy trình RTX chạy dưới dạng trình điều khiển thiết bị hạt nhân NT và các quy trình không được bảo vệ lẫn nhau. Việc triển khai này dẫn đến chuyển đổi ngữ cảnh nhanh chóng nhưng không an toàn từ góc độ quyền riêng tư.

3.6 INtime (Phần mở rộng thời gian thực của Windows NT)

INtime là tiện ích mở rộng thời gian thực của Windows được phát triển bởi Radisys Corporation và hiện được TenAsys Corporation duy trì.

INtime kết hợp các khả năng của RTOS thời gian thực cứng với các hệ điều hành Windows tiêu chuẩn, bao gồm Windows XP, Windows XP Embedded, Windows 2000, Windows NT và Windows NT Embedded mà không yêu cầu phần cứng bổ sung. INtime được thiết kế đặc biệt cho kiến trúc bộ xử lý x86.

INtime, không giống như RTX, có liên quan yếu đến NT. Kiến trúc INtime dựa trên cơ chế tác vụ phần cứng do bộ xử lý Intel cung cấp. Hóa ra hai lõi đang chạy trên cùng một phần cứng. Vì chúng dùng chung phần cứng nên cần phải có một số sửa đổi đối với NT HAL. Cách tiếp cận này cho phép bạn bảo vệ và tách biệt vùng thời gian chạy và bộ nhớ khỏi Windows. Trong INtime, mỗi quy trình ứng dụng có không gian địa chỉ riêng. Ngoài ra, kernel và các ứng dụng chạy ở các mức độ ưu tiên khác nhau, giúp bảo vệ chúng khỏi nhau.

INtime thể hiện hành vi có thể dự đoán được nhưng kiến trúc phức tạp của nó không cho phép hệ thống đạt được hiệu suất tốt. Do hạn chế về phân đoạn, INtime không phù hợp với tất cả các hệ thống thời gian thực.

3.7 LynxOS

Hệ điều hành LynxOS RTOS (LynuxWorks, Inc.) là hệ điều hành cứng thời gian thực được thiết kế cho các thiết bị viễn thông và chuyên dụng. Hệ điều hành này hoàn toàn mang tính quyết định và có khả năng tương thích POSIX, UNIX và Linux. Các lĩnh vực ứng dụng của LynxOS cũng là các hệ thống bảo mật phức tạp.

Phiên bản phát hành mới nhất của thương hiệu này, LynxOS-178 2.0, được nhà sản xuất mô tả là một hệ điều hành thương mại cung cấp độ tin cậy và khả năng phản hồi cao cần thiết cho các ứng dụng nhúng có yêu cầu bảo mật đặc biệt. LynxOS-178 2.0 triển khai hỗ trợ cho giao diện APEX (Ứng dụng/EXecutive - giao diện chương trình ứng dụng/điều khiển) của thông số ARINC-653. Điều này có nghĩa là hệ điều hành này đáp ứng các yêu cầu khắt khe nhất về tính bảo mật và độ tin cậy của hệ thống điện tử dành cho hàng không quân sự và dân dụng. LynxOS-178 2.0 hoàn toàn tuân thủ Cấp A của thông số kỹ thuật DO-178B.

RTOS LynxOS-178 2.0 tuân thủ các yêu cầu của tiêu chuẩn POSIX và ARINC-653, cũng như DO-178B, có nghĩa là đảm bảo tính di động của mã ứng dụng của hệ thống nhúng, tái sử dụng các chương trình đã tạo cũng như tuân thủ hầu hết các tiêu chuẩn tiêu chuẩn hệ điều hành nghiêm ngặt với yêu cầu bảo mật ngày càng tăng. Sử dụng LynxOS-178 2.0 cho phép bạn sử dụng mọi chương trình và sự phát triển đã được chứng nhận trước đó.

3.8 MicroWare OS-9

Hệ điều hành thời gian thực OS-9 của Microsoft System là hệ điều hành đa nhiệm, nhiều người dùng dành cho các ứng dụng nhúng thời gian thực. Hệ thống này được thiết kế để hoạt động trong các hệ thống như thiết bị viễn thông di động, thiết bị đầu cuối truy cập Internet nhúng và hộp giải mã truyền hình kỹ thuật số tương tác.

OS-9 chạy trên các bộ xử lý như Motorola 68K, ARM/StrongARM, Bộ xử lý mạng Intel IXP1200, MIPS, PowerPC, Hitachi SuperH, x86 hoặc Intel Pentium, Intel IXC1100 XScale.

Nhân OS-9 có khả năng mở rộng, hoàn toàn có thể ưu tiên, hỗ trợ tới 65.535 quy trình, cung cấp 65.535 mức độ ưu tiên và hỗ trợ tới 255 người dùng. Nhân OS-9 chứa hơn 90 lệnh gọi hệ thống giúp kiểm soát việc lập lịch động, phân bổ bộ nhớ, giao tiếp giữa các bộ xử lý, v.v. - quản lý chế độ tiết kiệm năng lượng được tích hợp trong nhân hệ điều hành.

Microware là một trong những công ty đầu tiên cấp phép Java cho các ứng dụng nhúng và là công ty đi đầu trong việc cung cấp nhiều công cụ và ứng dụng OS-9 cho nhiều loại thiết bị khác nhau.

Là môi trường phát triển ứng dụng chéo tích hợp cho OS-9, Microware đã phát triển môi trường Hawk, chạy trên nền tảng MS Windows NT.

3.9 OSE RTOS

Hệ điều hành thời gian thực OSE RTOS, được phát triển bởi ENEA Corporation, có hạt nhân lập lịch ưu tiên. Hạt nhân này được tối ưu hóa cao để có hiệu suất cao và đủ nhỏ gọn để sử dụng trong các hệ thống nhúng. OSE có kiến trúc hướng thông điệp với các lệnh gọi hệ thống đơn giản. Truyền thông điệp trong OSE đóng vai trò như một cổng khái niệm trong các hệ thống nhúng đa bộ xử lý phân tán. Các tác vụ gửi tin nhắn trực tiếp cho nhau thông qua HĐH mà không hỗ trợ hàng đợi, hộp thư hoặc các cơ chế trung gian khác. OSE RTOS hỗ trợ phân trang, sao chép, cập nhật mã động và nhiều giao thức truyền thông.

Kiến trúc OSE RTOS dựa trên mô hình nhiều lớp.

Đơn vị thực hiện trong OSE RTOS là tiến trình. Các quy trình có thể được nhóm thành một khối, khối này có thể có nhóm bộ nhớ riêng. Trong nhân OSE RTOS, một không gian địa chỉ thuộc về một phân đoạn, có thể bao gồm một hoặc nhiều khối. Việc ánh xạ các khối thành các phân đoạn và nhóm ánh xạ tới các vùng giúp có thể đạt được sự bảo vệ bộ nhớ và cách ly chương trình hoàn chỉnh. Các khối và nhóm có thể được đặt trong một hoặc nhiều phân đoạn.

Trong OSE RTOS, việc phân tách tiến trình được hiểu là động và tĩnh: các tiến trình tĩnh được tạo bởi kernel khi hệ thống khởi động và tồn tại trong suốt vòng đời của hệ thống, các tiến trình động được tạo và hủy trong quá trình thực thi.

3.10 Windows CE

Windows CE RTOS có dạng mô-đun với một hạt nhân nhỏ và các mô-đun tùy chọn chạy như các tiến trình độc lập. Lập kế hoạch trong Windows CE dựa trên mức độ ưu tiên. Hỗ trợ bảo vệ kernel và các tiến trình khỏi nhau. Ngoài ra, có thể có một chế độ hoạt động khi không có sự bảo vệ giữa các tiến trình và kernel. Cần lưu ý rằng các ngắt được xử lý dưới dạng luồng và có mức độ ưu tiên của luồng. Windows CE cũng hỗ trợ các luồng, là các luồng mà kernel không quản lý. Mỗi luồng chạy trong ngữ cảnh của luồng đã tạo ra nó; chúng có thể được sử dụng để tạo bộ lập lịch trong một luồng. Những luồng như vậy rất hữu ích trong các ứng dụng mới hoặc cũ, nhưng chúng không phù hợp với các hệ thống thời gian thực.

Windows CE có giới hạn bộ nhớ vật lý là 512 MB. Microsoft đã đưa ra hạn chế này để Windows CE có thể chạy trên nhiều loại bộ xử lý nhúng mà không gặp vấn đề về tương thích, vì một số bộ xử lý này có khả năng quản lý bộ nhớ vật lý 512MB. Windows CE thực hiện phân trang bộ nhớ ảo. Kích thước trang thay đổi tùy theo nền tảng, nhưng 4KB được sử dụng bất cứ khi nào có thể. Có thể cấm phân trang, điều này rất quan trọng đối với các hệ thống thời gian thực. Ở chế độ này, mô-đun được tải hoàn toàn vào bộ nhớ trước khi thực thi. Khi đó việc phân trang sẽ không ảnh hưởng đến việc thực thi ứng dụng.

Không giống như các RTOS khác, Windows CE hỗ trợ các chức năng chờ chung cho nhiều loại đối tượng khác nhau (mutexes, semaphores, sự kiện, tiến trình và luồng). Ưu điểm của các chức năng như vậy là có thể mong đợi nhiều đối tượng cùng một lúc cho đến khi một trong số chúng đưa ra tín hiệu. Các phần quan trọng chỉ có thể được sử dụng trong một quy trình duy nhất. Các ẩn dụ tính toán và mutexes tính toán có thể được sử dụng cả trong một quy trình và giữa các quy trình. Windows CE sử dụng tính kế thừa ưu tiên để tránh vấn đề đảo ngược mức độ ưu tiên.

3.11 hạt nhân RTOS

Hệ điều hành Nucleus do Accelerated Technology Corporation phát triển, được thiết kế cho các ứng dụng nhúng.

Hạt nhân là một hệ thống chéo, tức là một sản phẩm phần mềm được tạo ra trên một nền tảng phần mềm và phần cứng và được thực thi trên nền tảng khác.

Nucleus RTOS đi kèm với mã nguồn mở.

Cốt lõi của Nucleus RTOS, Nucleus PLUS, cung cấp khả năng đa nhiệm, tính di động và khả năng mở rộng. Hạt nhân được triển khai như một thư viện các hàm trong C.

Nucleus PLUS cung cấp các tính năng như quản lý tương tác tác vụ (hộp thư, hàng đợi, đường ống, ngữ nghĩa, sự kiện, tín hiệu), cũng như quản lý bộ nhớ, bộ hẹn giờ, ngắt. Việc lập lịch tác vụ được thực hiện dựa trên mức độ ưu tiên cũng như sử dụng thuật toán FIFO.

Khi một lệnh gọi hệ thống được thực thi, việc thực thi một tác vụ có thể bị tạm dừng vô thời hạn, trong một khoảng thời gian nhất định hoặc không bị tạm dừng. Tất cả các đối tượng trong hệ thống có thể được tạo và xóa một cách linh hoạt.

Phần kết luận

Trong nhiều năm, các ứng dụng dựa trên hệ điều hành thời gian thực đã được sử dụng trong các hệ thống nhúng đặc biệt và gần đây chúng đã tìm được đường vào mọi thứ, từ hệ thống điều khiển trên máy bay đến các thiết bị gia dụng.

Thuộc tính quan trọng nhất của hệ thống thời gian thực là khả năng dự đoán được phản ứng theo thời gian của hệ thống đối với các sự kiện bên ngoài. Chỉ dựa trên đặc tính này, chúng ta mới có thể nói về tính nhất quán và tính hợp lệ của các giải pháp được nhúng trong một hệ điều hành thời gian thực cụ thể.

Hệ thống thời gian thực phải đáp ứng các tham số đầu vào bên ngoài và tạo ra kết quả đầu ra mới trong một khoảng thời gian giới hạn. Thời gian đáp ứng nên được giới hạn. Thời gian phản hồi quá dài có thể khiến hệ thống thời gian thực bị lỗi.

Không còn nghi ngờ gì nữa, hầu hết các hệ điều hành thời gian thực truyền thống đều được thiết kế với một CPU duy nhất trên một bo mạch. Ngày nay, việc hỗ trợ cho các hệ thống đa bộ xử lý ngày càng được yêu cầu nhiều hơn.

Rõ ràng là các hệ điều hành có kiến trúc nguyên khối, do tập trung vào các nền tảng bộ xử lý cụ thể và tính chất tương tác với nhân, khó có thể được sử dụng làm hệ điều hành thời gian thực tương đối phổ biến cho các hệ thống có tính sẵn sàng cao.

Các hệ điều hành thời gian thực hiện đại dựa trên các phương pháp kiến trúc mới, được bổ sung bởi các công cụ phát triển hệ thống ứng dụng cho phép chúng được tạo ra trong thời gian ngắn với các đặc tính tốt nhất; Ngoài ra, các hệ điều hành được tạo trên cơ sở vi nhân có một số những lợi thế so với kiến trúc nguyên khối và kết hợp với cách tiếp cận hướng đối tượng, cho phép hệ thống trở nên độc lập với phần cứng và cung cấp phản hồi nhanh chóng với các sự kiện bên ngoài.

Do khả năng dự đoán theo thời gian nên RTOS phải được thiết kế cẩn thận để hỗ trợ các ứng dụng thời gian thực.

Thư mục

1. Burdonov I.B., Kosachev A.S., Ponomarenko V.N. Hệ điều hành thời gian thực. Bản in trước: Viện lập trình hệ thống RAS. Irkutsk, 2006.

2. Olifer V.G., Olife N.A. Hệ điều hành mạng: Sách giáo khoa cho trường đại học. Tái bản lần thứ 2 - St. Petersburg: Peter, 2008. - 669 trang.: bệnh.

3. www.ru.wikipedia.org

4. www.intuit.ru

Tài liệu tương tự

Đặc điểm chính của hệ thống thời gian thực, các loại kiến trúc. Hệ thống ưu tiên xử lý (nhiệm vụ) và các thuật toán điều phối. Khái niệm về khả năng chịu lỗi, nguyên nhân gây ra lỗi. Khả năng chịu lỗi trong các hệ thống thời gian thực hiện có (QNX Neutrino).

kiểm tra, thêm vào ngày 09/03/2013

Phân loại hệ thống thời gian thực Hạt nhân và hệ điều hành thời gian thực. Nhiệm vụ, quy trình, chủ đề. Ưu điểm và nhược điểm của thread. Thuộc tính, lập kế hoạch, đồng bộ hóa nhiệm vụ. Nhiệm vụ liên quan. Đồng bộ hóa với các sự kiện bên ngoài.

tóm tắt, thêm vào ngày 28/12/2007

Đặc điểm, cơ sở ứng dụng, kiến trúc của hệ điều hành cứng và thời gian thực. Lập trình tuần tự các nhiệm vụ thời gian thực. Cấu trúc và ngôn ngữ lập trình song song, đa chương trình và đa nhiệm.

bài tập khóa học, được thêm vào ngày 17/12/2015

Hệ điều hành xử lý hàng loạt, chia sẻ thời gian, thời gian thực. Đặc điểm của thuật toán quản lý tài nguyên. Hỗ trợ chế độ nhiều người dùng. Đa nhiệm ưu tiên và không ưu tiên. Hệ điều hành và mạng toàn cầu.

tóm tắt, thêm vào ngày 11/12/2011

Xem xét các yêu cầu về miền có vấn đề. Các tính năng của quản lý công việc. Hệ thống thực thi thời gian thực. Lập trình ở cấp độ vi xử lý. Mô hình và phương pháp miền. Triển khai nguyên mẫu hệ thống thời gian thực.

bài tập khóa học, được thêm vào ngày 15/02/2005

Lập lịch các tác vụ trong hệ điều hành thời gian thực. Các loại lập kế hoạch cơ bản liên quan đến các nhiệm vụ thời gian thực. Lựa chọn thuật toán lập lịch có thể chấp nhận được khi thiết kế RTS. Dự báo tĩnh bằng cách sử dụng bảng.

kiểm tra, thêm 28/05/2014

Xem xét các nguyên tắc cơ bản và phương pháp thiết kế hệ thống thời gian thực. Mô tả thiết kế và các đặc điểm chức năng của đối tượng điều khiển, xây dựng sơ đồ nhiệm vụ. Lựa chọn kiến trúc phần cứng, mô hình tiến trình-luồng, giao diện.

bài tập khóa học, được thêm vào ngày 19/01/2015

Đặc điểm chung của nhiệm vụ ghi lại thời gian thực hiện chương trình: thực thi các quy trình thời gian thực, lập hồ sơ. Bộ đếm thời gian có thể lập trình như một hệ thống rất phức tạp. Phân tích các chức năng chính trả về thời gian chuẩn của Windows.

bài tập khóa học, được thêm vào ngày 18/05/2014

Khái niệm và chức năng của hệ điều hành. Tính năng chính của hệ điều hành thời gian thực. Làm việc với bảng tính. Lọc các bản ghi trong bảng MS Excel. Cài đặt bộ lọc tự động tùy chỉnh trong bảng doanh thu chuyển động hàng hóa.

kiểm tra, thêm vào ngày 21/11/2013

Bản chất và nguyên tắc hoạt động của hệ điều hành, các quy tắc và lợi ích của việc sử dụng nó. Khả năng của các hệ điều hành khác nhau, điểm mạnh và điểm yếu của chúng. Đặc điểm so sánh của hệ thống Unix và Windows NT, tiềm năng và nhiệm vụ của chúng.

Tổng quan về các đặc điểm so sánh của HĐH RT hiện có trên thị trường Nga liên quan đến việc sử dụng trong các hệ thống điều khiển hàng không.

05/05/2008, Thứ Hai, 23:56, giờ Mátxcơva

Nhờ sự phát triển của công nghệ máy tính, gần đây người ta có thể gán các nhiệm vụ cho một mô-đun trước đây được thực hiện bởi một số mô-đun bộ xử lý, đồng thời cải thiện các đặc tính về trọng lượng và kích thước của hệ thống điều khiển và giảm chi phí. Xu hướng này trong công nghệ hàng không đã dẫn đến sự xuất hiện của khái niệm hệ thống điện tử hàng không mô-đun tích hợp - IMA (Integrated module Avionics, IMA).

Vấn đề của việc tích hợp các chức năng điều khiển vào một mô-đun duy nhất là cần phải chia sẻ các tài nguyên chung hiện nay (thời gian xử lý, bộ nhớ, kênh liên lạc) giữa các tác vụ khác nhau, đồng thời đảm bảo mức độ tin cậy và độc lập của các chức năng như trước. Hệ điều hành thời gian thực đóng vai trò then chốt trong việc giải quyết vấn đề này.

Hiện nay, có một số RTOS thương mại dành cho các ứng dụng quan trọng trên thị trường thế giới (Bảng 1). Bài viết này cung cấp cái nhìn tổng quan về RTOS hiện có trên thị trường Nga, dựa trên thông tin từ các nguồn mở và kinh nghiệm cá nhân của các tác giả.

Văn bản quy định yêu cầu đối với RTOS

Tiêu chuẩn DO-178 (Cân nhắc phần mềm trong chứng nhận hệ thống và thiết bị trên không) xác định các yêu cầu đối với quy trình phát triển phần mềm và tính kỹ lưỡng của việc xác minh tùy thuộc vào mức độ quan trọng của nó. Mức độ quan trọng của phần mềm được xác định dựa trên phân tích về mức độ nghiêm trọng của hậu quả do lỗi phần mềm. Tổng cộng có năm mức độ quan trọng của phần mềm (từ A đến E).

MILS (Nhiều cấp độ bảo mật độc lập) là một cách tiếp cận đặc biệt đối với thiết kế hệ điều hành nhằm ngăn chặn việc lan truyền các lỗi phần mềm ứng dụng trong thời gian chạy và cũng đơn giản hóa việc xác minh chương trình do tính mô-đun của phần mềm. Tất cả các ứng dụng được đặt trong cái gọi là phần (phân vùng). Các phân vùng đã phân bổ tài nguyên (vùng bộ nhớ, thời gian xử lý trong mỗi chu kỳ hệ thống, quyền truy cập vào các kênh liên lạc, v.v.). Quyền truy cập vào các tài nguyên được phân bổ được đảm bảo bởi hệ điều hành đang chạy ở chế độ giám sát. Do đó, phần mềm ứng dụng có mức độ quan trọng khác nhau có thể chạy trên một mô-đun bộ xử lý chạy một hệ điều hành - nếu lỗi xảy ra ở phần mềm ít quan trọng hơn (và theo đó, ít được kiểm tra hơn), điều này sẽ không ảnh hưởng đến hoạt động của các phần khác theo bất kỳ cách nào, vì những nỗ lực “chiếm đoạt” tài nguyên của người khác sẽ bị hệ điều hành chặn. Ý tưởng của MILS lặp lại ý tưởng của IMA và DO-178B.

Lỗi 404: Không tìm thấy trang.

Điều này có thể đã xảy ra vì một trong những lý do sau:

– lỗi khi gõ địa chỉ trang (URL)
– theo liên kết “bị hỏng” (không hoạt động, không chính xác)
– trang được yêu cầu chưa bao giờ có trên trang web hoặc nó đã bị xóa

Bạn có thể:

– quay lại bằng nút Quay lại của trình duyệt
– kiểm tra chính tả địa chỉ trang (URL)
– sử dụng bản đồ trang web hoặc đi đến trang chính

Tiêu chuẩn ARINC-653 (Giao diện tiêu chuẩn phần mềm ứng dụng điện tử) chỉ định giao diện phần mềm ứng dụng APEX hỗ trợ khái niệm phân vùng kiểu MILS. Giao diện này bao gồm các chức năng quản lý phân vùng, quy trình, chia sẻ thời gian, liên lạc giữa và trong các phân vùng cũng như giám sát trạng thái hệ thống. Cần lưu ý rằng tiêu chuẩn ARINC-653 mô tả cách tiếp cận được chấp nhận chung để triển khai các ý tưởng MILS cho IMA, mặc dù có thể có các cách triển khai khác. RTOS hàng không tuân thủ ARINC-653 có lợi thế vì tiêu chuẩn này được các tổ chức chứng nhận quốc tế biết đến và hiểu rõ, do đó, việc đạt được chứng chỉ tuân thủ DO-178B cho một hệ thống được xây dựng theo tiêu chuẩn này sẽ dễ dàng hơn.

Tiêu chuẩn về các thành phần phần mềm có thể tái sử dụng. Theo DO-178B, phần mềm của một hệ thống ứng dụng hàng không cụ thể phải trải qua toàn bộ quy trình chứng nhận, ngay cả khi nó sử dụng các mô-đun (thành phần) đã được chứng nhận trước đó như một phần của hệ thống khác. Một trong những sáng kiến mới nhất của FAA (Cơ quan Chứng nhận Hàng không Liên bang, Hoa Kỳ) là xác định tiêu chí về khả năng sử dụng lại phần mềm mà không cần chứng nhận lại. Các thành phần có thể không được chứng nhận lại được gọi là RSC (Thành phần phần mềm có thể tái sử dụng). Phải nỗ lực nhiều hơn để được chứng nhận RSC, nhưng khi đó RSC sẽ tiết kiệm đáng kể.

Tài liệu tiếng Nga xác định yêu cầu phần mềm (bao gồm RTOS):

GOST R ISO/IEC 51904-2002 (“Phần mềm hệ thống nhúng. Yêu cầu chung về phát triển và lập tài liệu”) - tương tự DO-178B dành cho hàng không quân sự;
KT-178A ("Yêu cầu về trình độ phần 178A") - tương tự DO-178B dành cho hàng không dân dụng;
GOST R ISO/IEC 12207-99 ("Công nghệ thông tin. Quy trình vòng đời phần mềm").

Việc so sánh hệ điều hành RT được thực hiện theo 13 thông số, có tính đến các tiêu chí kỹ thuật, tính dễ phát triển và các thông số kinh tế.

Thông số thời gian của hệ điều hành

Một trong những yêu cầu chính đối với RT OS là thời gian trễ tối thiểu để xử lý một sự kiện. Trong thực tế, điều này có nghĩa là các tham số sau phải nhỏ:

thời gian phản hồi ngắt - thời gian từ khi xảy ra ngắt thực tế đến khi bắt đầu xử lý lệnh đầu tiên của trình xử lý ngắt;
kiểm soát thời gian chuyển luồng - thời gian chuyển đổi giữa hai luồng trong một tiến trình;
thời gian chuyển đổi bối cảnh quy trình (chỉ dành cho các hệ điều hành hỗ trợ mô hình quy trình) - thời gian chuyển đổi giữa hai luồng điều khiển thuộc hai quy trình khác nhau.

Thật không may, không dễ để so sánh một cách khách quan các thông số này của các hệ điều hành RT khác nhau, bởi vì những thông số này không chỉ phụ thuộc vào chất lượng của hệ điều hành mà còn phụ thuộc vào khả năng của nền tảng phần cứng được sử dụng. Lý tưởng nhất là tất cả các hệ điều hành được so sánh nên được cài đặt trên cùng một nền tảng phần cứng, sau đó sẽ thực hiện các phép đo thích hợp. Nhưng ngay cả những phép đo này cũng sẽ không đưa ra kết quả khách quan, bởi vì các hệ điều hành khác nhau ít nhiều có thể thích ứng với phần cứng cụ thể.

Để so sánh các thông số thời gian, bài viết này sử dụng dữ liệu phân mảnh tìm thấy trên Internet, dữ liệu này thường thu được khi thử nghiệm hệ điều hành trên nhiều thiết bị khác nhau, trong khi thành phần và bản chất của các thử nghiệm không phải lúc nào cũng rõ ràng.

Số liệu khá khách quan có thể coi là kết quả thu được từ các chuyên gia của tạp chí Hệ thống chuyên dụng, người đã tiến hành thử nghiệm và so sánh thực tế QNX RTOS 6.1, VxWorks AE 1.1 và Windows CE.NET trên nền tảng x86. Mặc dù dữ liệu này hiện đã lỗi thời nhưng các tác giả của bài viết này không thể tìm thấy tài liệu mới hơn. Trong bảng Hình 2 thể hiện dữ liệu so sánh hiệu suất được chọn giữa QNX Neutrino 6.1 và VxWorks AE 1.1. Báo cáo Hệ thống chuyên dụng đã ưu tiên QNX về mặt hiệu suất, với tỷ lệ điểm được đặt ở mức 9:5 (QNX:VxWorks), vì trong quá trình thử nghiệm, hai lỗi đã được phát hiện trong VxWorks, do đó cần phải liên hệ với bộ phận hỗ trợ để khắc phục. họ.

Trong bảng Hình 3 hiển thị dữ liệu về các đặc điểm của LynxOS. Thành phần của các bài kiểm tra được sử dụng không được chỉ định. Đối với dữ liệu về các đặc điểm của LynxOS, cột thứ tư (thử nghiệm trên nền tảng x86) rất thú vị. So với VxWorks và QNX, LynxOS RT OS có độ trễ rất lớn trong việc phản hồi khi bị gián đoạn (hơn 5 lần). Thời gian chuyển ngữ cảnh (nghĩa là thời gian chuyển đổi giữa hai luồng trong một tiến trình) bằng QNX và ít hơn VxWorks khoảng 1,5 lần.

Độ ổn định của các thông số thời gian

Ngoài các đặc tính về thời gian, tính ổn định của các đặc tính này cũng rất quan trọng đối với RT OS. Chính tiêu chí này quyết định phần lớn đến “độ cứng” của RT OS, tức là. khả năng dự đoán về thời gian xử lý dữ liệu, thời điểm đưa ra kết quả, v.v.

Dựa trên dữ liệu từ nhật ký Hệ thống chuyên dụng, QNX dẫn trước VxWorks ở tiêu chí này cả về mức độ lan tỏa của các đặc điểm trong một loạt các thử nghiệm tương tự (tỷ lệ giữa thời gian tối đa và giá trị trung bình nhỏ hơn đáng kể) và với tải ngày càng tăng (thời gian chuyển luồng khi số lượng luồng tăng 2...128 đơn vị đối với QNX chỉ tăng 1,65 lần, trong khi đối với VxWorks - 2,24 lần).

Theo dữ liệu thu được từ RTSoft, được biết LynxOS có những đặc điểm gần giống với VxWorks.

Quản lý quyền truy cập vào tài nguyên

Hãy đánh giá chất lượng kiểm soát truy cập do hệ điều hành RT này hoặc hệ điều hành RT khác cung cấp đối với các tài nguyên quan trọng của hệ thống máy tính, chẳng hạn như thời gian bộ nhớ và bộ xử lý.

Câu hỏi đầu tiên cần được trả lời là liệu HĐH có hỗ trợ mô hình quy trình hay không. Một tiến trình là một thực thể logic sở hữu một hoặc nhiều luồng, các tài nguyên liên quan và ngữ cảnh của chúng—nội dung của các thanh ghi và bộ đếm tại bất kỳ thời điểm nào.

Nhiệm vụ của các quá trình là:

trong việc phân định quyền truy cập vào RAM giữa các chương trình khác nhau trong quá trình thực thi;
trong việc phân định phạm vi của các biến toàn cục tại thời điểm biên dịch (rất quan trọng nếu phần mềm ứng dụng được viết bằng ngôn ngữ C không hỗ trợ việc phân định đó).

Phân đoạn cũng cung cấp sự phân tách các không gian địa chỉ (theo nghĩa này, khả năng phân chia và xử lý được nhân đôi). Ngoài ra, sharding cung cấp cho mỗi phân đoạn chứa một hoặc nhiều quy trình (hoặc luồng nếu hệ điều hành không hỗ trợ mô hình quy trình) với quỹ thời gian được đảm bảo. Bằng cách này, nếu một luồng có mức độ ưu tiên cao đi vào vòng lặp và làm gián đoạn phân đoạn của nó, thì tất cả các phân đoạn khác sẽ nhận được thời gian CPU theo cài đặt thời gian thiết kế và tiếp tục hoạt động bình thường.

LynxOS và QNX hỗ trợ cả mô hình quy trình và phân mảnh. Hệ điều hành VxWorks có cơ chế sharding nhưng không hỗ trợ mô hình quy trình. Nói chung, điều này có thể chấp nhận được vì sharding cung cấp sự phân tách các không gian địa chỉ. Nhưng việc thiếu các quy trình mang lại một số bất tiện. Thông thường, việc phân chia thành các phân đoạn được thực hiện dựa trên mục đích dự định của phần mềm và mức độ quan trọng của nó. Ví dụ: một số phân đoạn có thể chứa phần mềm điều khiển cho hệ thống định vị chuyến bay có mức độ quan trọng cao. Nhưng phần mềm này cũng khá phức tạp, sẽ hợp lý nếu được chia thành các mô-đun (bộ nhớ) độc lập. Hệ điều hành VxWorks không cung cấp tính năng này, nghĩa là phân đoạn sẽ bao gồm các luồng có bộ nhớ dùng chung, điều này làm phức tạp việc tổ chức phát triển song song và cuối cùng làm giảm độ tin cậy của phần mềm.

Hỗ trợ cho hệ thống đa bộ xử lý và phân tán

Giá thành của các mô-đun đa bộ xử lý gần đây đã giảm đáng kể và do đó chúng ngày càng được sử dụng nhiều hơn trong các hệ thống nhúng. Tất nhiên, RT OS phải cung cấp hỗ trợ cho những bo mạch như vậy.

Một hướng hứa hẹn khác trong việc xây dựng hệ thống điều khiển tự động là hệ thống phân tán, trong đó các mô-đun được phân tách trong không gian và giao tiếp giữa chúng diễn ra thông qua một số môi trường mạng. Một lần nữa, hệ điều hành RT được sử dụng phải có các phương tiện thuận tiện và đáng tin cậy để tổ chức tương tác giữa các mô-đun: hỗ trợ các giao thức mạng khác nhau, các phương tiện để đảm bảo tính minh bạch của mạng.

QNX RT OS cung cấp hỗ trợ cho bo mạch đa bộ xử lý. Đối với VxWorks, sự hỗ trợ như vậy chỉ mới được công bố. Chưa có phiên bản hàng không nào của LynxOS hỗ trợ bo mạch đa bộ xử lý.

Về khả năng hỗ trợ các giao thức mạng, cần lưu ý rằng RT OS LynxOS, VxWorks và QNX có khả năng gần như ngang nhau (và rộng). Một ưu điểm nữa của QNX RT OS là kiến trúc hệ thống con mạng đặc biệt của nó, đảm bảo tính “minh bạch” mạng của các chương trình ứng dụng: bất kỳ quy trình nào cũng có thể gọi một quy trình khác trên mô-đun từ xa giống như quy trình trên mô-đun cục bộ.

Hỗ trợ hệ thống tập tin

Khả năng lưu trữ thông tin dưới dạng tập tin rất tiện lợi và truyền thống. Ngược lại, việc thiếu khả năng như vậy sẽ tạo ra khó khăn khi lưu trữ dữ liệu hiếm khi được thay đổi và tạo ra các hệ thống phân tán.

Trong bảng Hình 4 cho thấy sự hỗ trợ của hệ thống tệp cho từng hệ điều hành đang được xem xét.

QNX có sự hỗ trợ rộng rãi nhất cho các hệ thống tệp. Ngoài ra, hệ thống tập tin flash của nó có khả năng chịu lỗi.

Chất lượng tài liệu

Chất lượng tài liệu cho RT OS LynxOS, VxWorks, QNX khá cao. Tuy nhiên, cũng có những phàn nàn về tài liệu:

QNX là một mô tả xuất sắc về kiến trúc và nguyên tắc thiết kế, nhưng mô tả chưa đầy đủ về giao diện lập trình ứng dụng (không phải tất cả các tham số đều được mô tả, có sự mâu thuẫn);
VxWorks - không có giải thích về nguyên tắc hoạt động và mô tả không đầy đủ về quá trình cấu hình hệ điều hành phức tạp.

Tuy nhiên, các công ty đang nghiên cứu về chất lượng của vật liệu. Tài liệu dành cho phiên bản hiện tại của QNX (6.3.2) đã được mở rộng đáng kể và một số phần đã được làm lại.

Chất lượng hỗ trợ kỹ thuật

Về chất lượng hỗ trợ kỹ thuật chính thức, người dẫn đầu chắc chắn là LynxOS. LynuxWorks hứa sẽ trả lời mọi câu hỏi kỹ thuật trong vòng 4 giờ kể từ khi yêu cầu được đăng. LynxOS được phân phối tại Nga bởi RTSoft, nơi có đội ngũ nhân viên đông đảo có khả năng cung cấp hỗ trợ có trình độ. Nhược điểm của LynxOS là hệ điều hành này chưa phổ biến ở Nga, do đó, không có cộng đồng người dùng được thành lập và thậm chí không có diễn đàn tiếng Nga.

QSS (nhà sản xuất QNX) cũng cung cấp hỗ trợ kỹ thuật tốt nhưng thời gian phản hồi nhanh không được đảm bảo. Không giống như LynxOS, QNX RT OS có cộng đồng người dùng được tổ chức tốt cả ở nước ngoài và ở Nga. Câu trả lời cho hầu hết các câu hỏi có thể được tìm thấy trên các diễn đàn này. QNX ở nước ta được phân phối bởi Hệ thống nhúng SVD, nhân viên của họ có thể cung cấp hỗ trợ kỹ thuật thành thạo và thực hiện công việc điều chỉnh HĐH cho các bo mạch xử lý cụ thể. Ngoài ra, công ty còn liên hệ trực tiếp với QSS và có thể nhận được lời khuyên về các vấn đề phức tạp từ nhà phát triển hệ điều hành QNX RT.

WindRiver, nhà phát triển VxWorks, theo truyền thống tuân thủ chính sách kỹ thuật khép kín, nghĩa là khá khó để có được thông tin về nguyên tắc hoạt động của HĐH. Hệ điều hành này cũng không có diễn đàn tiếng Nga. Hệ điều hành VxWorks RT được phân phối ở nước ta bởi công ty AVD Systems, công ty chủ yếu kinh doanh các giải pháp phần mềm và phần cứng làm sẵn có nguồn gốc nước ngoài.

Mã nguồn mở

Một hệ điều hành RT mở có ít nhất ba ưu điểm:

các nhà phát triển phần mềm ứng dụng có thể hiểu các vấn đề phức tạp mà không cần hỗ trợ kỹ thuật;
dễ dàng chứng nhận hơn (không có dấu trang, v.v.);
phát triển năng động hơn, vì công ty phát triển RT OS thường nhận được không chỉ các yêu cầu sửa lỗi mà còn cả các đề xuất để loại bỏ lỗi và cải thiện hệ thống. Theo quy luật, cộng đồng các nhà phát triển RTOS nguồn mở phát triển nhanh hơn nhiều và được tổ chức tốt hơn. Các chuyên gia độc lập xuất hiện để giúp giải quyết các vấn đề của dịch vụ hỗ trợ kỹ thuật và tham gia vào việc phát triển, gỡ lỗi và thử nghiệm hệ thống.

Kể từ tháng 9 năm 2007, QSS đã mở nguồn lõi QNX (bao gồm gói Phân vùng thích ứng, gói Tính sẵn sàng cao). Một lát sau, mã nguồn của hệ thống con mạng đã được mở. Hiện tại, phiên bản beta 6.4.0 đã có sẵn để tải xuống trên trang web chính thức.

Cần lưu ý rằng ngày nay không phải tất cả các mô-đun QNX đều mở (ví dụ: không có mã cho đồ họa và hệ thống tệp) và giấy phép áp đặt hạn chế sử dụng “mã nguồn”: chỉ dành cho mục đích phi thương mại. Tuy nhiên, người dùng QNX được hưởng các lợi ích trên miễn phí.

Mã nguồn LynxOS và VxWorks có sẵn trên thị trường. Giá cho một sản phẩm như vậy có thể thương lượng.

Công cụ

Sự sẵn có của các công cụ tốt quyết định phần lớn chất lượng và tốc độ phát triển các chương trình ứng dụng cho một hệ điều hành cụ thể. Cần lưu ý rằng LynxOS, VxWorks và QNX hiện cung cấp các công cụ chất lượng tốt bao gồm môi trường phát triển tích hợp (IDE) và gỡ lỗi phần mềm ứng dụng, các công cụ định hình chương trình (để phát hiện các tắc nghẽn về hiệu suất, bộ nhớ, v.v.). Tính công thái học của ISD dành cho các HĐH RT này nhìn chung không thua kém các công cụ phát triển đã phát triển dành cho các HĐH thông thường (ví dụ: MS Windows).

Tính di động của phần mềm ứng dụng

Tính di động của phần mềm ứng dụng giúp bạn có thể sử dụng nó trong các hệ điều hành khác (bao gồm cả hệ điều hành không phải RT). Tính di động mang lại cho nhà phát triển phần mềm ứng dụng sự độc lập nhất định với HĐH RT: nếu cần, bạn có thể chuyển sang HĐH khác với chi phí thấp.

Khả năng viết phần mềm di động hiện được xác định bằng việc tuân thủ tiêu chuẩn POSIX. Tất cả các hệ điều hành RT được coi là đều hỗ trợ tiêu chuẩn POSIX 1003.1. LynxOS có một lợi thế - HĐH này tương thích nhị phân với Linux. Nghĩa là, các ứng dụng Linux có thể chạy trên LynxOS mà không cần biên dịch lại. Ngược lại, các ứng dụng LynxOS có thể chạy trên Linux (phiên bản 2.4.x với thư viện ngôn ngữ glibs C phiên bản 2.2.2).

Phần còn lại của hệ điều hành RT yêu cầu biên dịch lại để chạy các ứng dụng Linux. Trong trường hợp này, quá trình chuyển ngay cả các ứng dụng tuân thủ POSIX thường có thể trở nên khá tốn công sức do sự khác biệt trong việc triển khai thư viện và trình biên dịch.

Hỗ trợ kiến trúc bộ xử lý

Các nhà phát triển hệ thống điều khiển hàng không trong nước trong giai đoạn chuyển đổi từ hệ điều hành nội bộ sang hệ thống thương mại ngày nay thường rơi vào tình huống cần phải lựa chọn và điều chỉnh RTOS cho phù hợp với bo mạch xử lý hiện có. Trong trường hợp này, một trong những lập luận chính khi chọn HĐH là hỗ trợ kiến trúc bộ xử lý được sử dụng trên bo mạch.

Tuân thủ các tiêu chuẩn hàng không

Theo thông lệ nước ngoài, phần mềm cho hệ thống điện tử hàng không phải có chứng chỉ phù hợp tiêu chuẩn DO-178B. Nếu phần mềm có mức độ quan trọng khác nhau được thực thi trên cùng một mô-đun bộ xử lý thì RTOS được sử dụng phải hỗ trợ khái niệm phân vùng. (Nếu không thì gần như không thể chứng minh được lỗi không lan truyền). Như đã đề cập, sẽ tốt hơn nếu giao diện lập trình RTOS tuân thủ tiêu chuẩn ARINC-653, vì tiêu chuẩn này đã được các tổ chức chứng nhận nước ngoài biết đến.

LynxOS dẫn đầu về việc tuân thủ các tiêu chuẩn. Nó hỗ trợ ARINC-653 và có rất nhiều ví dụ về hệ thống được chứng nhận DO-178B được xây dựng trên nó. Điểm mấu chốt là LynuxWorks cung cấp một bộ RSC (mặc dù tác giả bài viết không biết gì về giá cả).

VxWorks tuân thủ tiêu chuẩn ARINC-653 và các hệ thống được xây dựng dựa trên tiêu chuẩn này có thể được chứng nhận DO-178B (có nhiều ví dụ).

QNX không tuân thủ ARINC-653 và chưa có hệ thống nào được chứng nhận DO-178B dựa trên ARINC-653.

Cần lưu ý rằng về nguyên tắc, hệ thống QNX có thể được sử dụng để xây dựng IMA, vì QNX hỗ trợ phương pháp riêng của nó để cung cấp khái niệm phân vùng, đây là một giải pháp thay thế rất tốt cho ARINC-653 và ngoài ra, cho phép bạn tiết kiệm thời gian xử lý .

Về các tiêu chuẩn tương tự của Nga dành cho hàng không quân sự (GOST R ISO/IEC 51904-2002), vẫn chưa có một ví dụ nào về hệ thống được chứng nhận, mặc dù về nguyên tắc, hệ thống như vậy có thể được phát triển dựa trên bất kỳ hệ điều hành nào đang được xem xét. Đối với Hệ điều hành QNX RT, công việc hiện đang được tiến hành để chuẩn bị các mô-đun hệ điều hành chính cho chứng nhận.

Phát triển hệ thống đào tạo chuyên môn

Tốc độ và chất lượng đào tạo nhân viên làm việc với Hệ điều hành RT cũng như các công cụ gỡ lỗi và phát triển phần mềm khác nhau có liên quan trực tiếp đến tốc độ phát triển phần mềm và chất lượng của nó. Các công ty hàng đầu trong lĩnh vực phần mềm hệ thống và nhúng, như WindRiver, LynuxWorks, QSS, thực hiện một chương trình khóa học và đào tạo quy mô lớn để nghiên cứu cách sử dụng các sản phẩm của công ty, bao gồm cả RT OS.

Kết quả so sánh

QNX Neutrino RTOS là hệ điều hành tiên tiến nhất xét theo quan điểm kỹ thuật, có bộ công cụ tốt và có mức giá tương đối thấp. Kiến trúc vi nhân đảm bảo độ tin cậy cao và tính mô đun hóa của các hệ thống được phát triển. Một lợi thế nữa là mã nguồn mở. Nhưng cũng có một điều đáng lo ngại: hiện tại QNX thực tế không được sử dụng ở bất kỳ đâu trong ngành hàng không và về mặt này, hệ điều hành này thua các đối thủ cạnh tranh (LynxOS và VxWorks). Một nhược điểm nữa của QNX: không tuân thủ tiêu chuẩn ARINC-653.

Cần lưu ý rằng, về nguyên tắc, QNX Neutrino có tất cả các cơ chế cần thiết để hoạt động trong hệ thống điện tử hàng không. Ngoài ra, độ tin cậy và tính sẵn sàng cao của các hệ thống dựa trên QNX đã được chứng minh trong các ngành công nghiệp khác, nơi chi phí sai sót thậm chí còn cao hơn cả trong ngành hàng không (điều khiển lò phản ứng hạt nhân).

Công việc chuẩn bị cho việc chứng nhận QNX Neutrino theo yêu cầu của tiêu chuẩn hàng không trong nước hiện đang được SWD Software thực hiện.

Ngược lại, RTOS LynxOS-178 có tất cả các chứng chỉ cần thiết ở nước ngoài, mặc dù theo nhiều tiêu chí khác, nó có vẻ kém ưu tiên hơn QNX Neutrino. Lưu ý rằng để sử dụng trong ngành hàng không Nga, LynxOS-178 RTOS cũng phải được chứng nhận theo GOST trong nước.

Hệ điều hành VxWorks có lịch sử sử dụng lâu dài trong các ứng dụng quan trọng ở nước ngoài. Tuy nhiên, phân tích của chúng tôi cho thấy nó có vẻ ít được ưa chuộng hơn so với hai hệ điều hành đầu tiên theo nhiều tiêu chí. Ngoài ra, uy tín của VxWorks còn bị suy giảm bởi chiến lược phát triển khép kín.

Nhóm chuyên gia / R&D.CNews

Tổng quan về các đặc điểm so sánh của HĐH RT hiện có trên thị trường Nga liên quan đến việc sử dụng trong các hệ thống điều khiển hàng không.

Văn bản quy định yêu cầu đối với RTOS

Tiêu chuẩn DO-178 (Cân nhắc phần mềm trong chứng nhận hệ thống và thiết bị trên không) xác định các yêu cầu đối với quy trình phát triển phần mềm và tính kỹ lưỡng của việc xác minh tùy thuộc vào mức độ quan trọng của nó. Mức độ quan trọng của phần mềm được xác định dựa trên phân tích về mức độ nghiêm trọng của hậu quả do lỗi phần mềm. Tổng cộng có năm mức độ quan trọng của phần mềm (từ A đến E).
MILS (Nhiều cấp độ bảo mật độc lập) là một cách tiếp cận đặc biệt đối với thiết kế hệ điều hành nhằm ngăn chặn việc lan truyền các lỗi phần mềm ứng dụng trong thời gian chạy và cũng đơn giản hóa việc xác minh chương trình do tính mô-đun của phần mềm. Tất cả các ứng dụng được đặt trong cái gọi là phần (phân vùng). Các phân vùng đã phân bổ tài nguyên (vùng bộ nhớ, thời gian xử lý trong mỗi chu kỳ hệ thống, quyền truy cập vào các kênh liên lạc, v.v.). Quyền truy cập vào các tài nguyên được phân bổ được đảm bảo bởi hệ điều hành đang chạy ở chế độ giám sát. Do đó, phần mềm ứng dụng có mức độ quan trọng khác nhau có thể chạy trên một mô-đun bộ xử lý chạy một hệ điều hành - nếu lỗi xảy ra ở phần mềm ít quan trọng hơn (và theo đó, ít được kiểm tra hơn), điều này sẽ không ảnh hưởng đến hoạt động của các phần khác theo bất kỳ cách nào, vì những nỗ lực “chiếm đoạt” tài nguyên của người khác sẽ bị hệ điều hành chặn. Ý tưởng của MILS lặp lại ý tưởng của IMA và DO-178B.
Tiêu chuẩn ARINC-653 (Giao diện tiêu chuẩn phần mềm ứng dụng điện tử) chỉ định giao diện phần mềm ứng dụng APEX hỗ trợ khái niệm phân vùng kiểu MILS. Giao diện này bao gồm các chức năng quản lý phân vùng, quy trình, chia sẻ thời gian, liên lạc giữa và trong các phân vùng cũng như giám sát trạng thái hệ thống. Cần lưu ý rằng tiêu chuẩn ARINC-653 mô tả cách tiếp cận được chấp nhận chung để triển khai các ý tưởng MILS cho IMA, mặc dù có thể có các cách triển khai khác. RTOS hàng không tuân thủ ARINC-653 có lợi thế vì tiêu chuẩn này được các tổ chức chứng nhận quốc tế biết đến và hiểu rõ, do đó, việc đạt được chứng chỉ tuân thủ DO-178B cho một hệ thống được xây dựng theo tiêu chuẩn này sẽ dễ dàng hơn.
Tiêu chuẩn về các thành phần phần mềm có thể tái sử dụng. Theo DO-178B, phần mềm của một hệ thống ứng dụng hàng không cụ thể phải trải qua toàn bộ quy trình chứng nhận, ngay cả khi nó sử dụng các mô-đun (thành phần) đã được chứng nhận trước đó như một phần của hệ thống khác. Một trong những sáng kiến mới nhất của FAA (Cơ quan Chứng nhận Hàng không Liên bang, Hoa Kỳ) là xác định tiêu chí về khả năng sử dụng lại phần mềm mà không cần chứng nhận lại. Các thành phần có thể không được chứng nhận lại được gọi là RSC (Thành phần phần mềm có thể tái sử dụng). Phải nỗ lực nhiều hơn để được chứng nhận RSC, nhưng khi đó RSC sẽ tiết kiệm đáng kể.

Tài liệu tiếng Nga xác định yêu cầu phần mềm (bao gồm RTOS):

GOST R ISO/IEC 51904-2002 (“Phần mềm hệ thống nhúng. Yêu cầu chung về phát triển và lập tài liệu”) - tương tự DO-178B dành cho hàng không quân sự;
KT-178A (“Yêu cầu về trình độ chuyên môn phần 178A”) - tương tự DO-178B dành cho hàng không dân dụng;
GOST R ISO/IEC 12207-99 (“Công nghệ thông tin. Quy trình vòng đời phần mềm”).

Việc so sánh hệ điều hành RT được thực hiện theo 13 thông số, có tính đến các tiêu chí kỹ thuật, tính dễ phát triển và các thông số kinh tế.

Thông số thời gian của hệ điều hành

thời gian phản hồi ngắt - thời gian từ khi xảy ra ngắt thực tế đến khi bắt đầu xử lý lệnh đầu tiên của trình xử lý ngắt;
kiểm soát thời gian chuyển luồng - thời gian chuyển đổi giữa hai luồng trong một tiến trình;
thời gian chuyển đổi bối cảnh quy trình (chỉ dành cho các hệ điều hành hỗ trợ mô hình quy trình) - thời gian chuyển đổi giữa hai luồng điều khiển thuộc hai quy trình khác nhau.

Trong bảng Hình 3 hiển thị dữ liệu về các đặc điểm của LynxOS. Thành phần của các bài kiểm tra được sử dụng không được chỉ định. Đối với dữ liệu về các đặc điểm của LynxOS, cột thứ tư (thử nghiệm trên nền tảng x86) rất thú vị. So với VxWorks và QNX, LynxOS RT OS có độ trễ rất lớn trong việc phản hồi khi bị gián đoạn (hơn 5 lần). Thời gian chuyển ngữ cảnh (nghĩa là thời gian chuyển giữa 2 thread trong cùng một tiến trình) bằng QNX và ít hơn VxWorks khoảng 1,5 lần.

Độ ổn định của các thông số thời gian

Dựa trên dữ liệu từ tạp chí Hệ thống chuyên dụng, QNX dẫn trước VxWorks ở tiêu chí này cả về mức độ lan tỏa của các đặc điểm trong một loạt các thử nghiệm tương tự (tỷ lệ giữa thời gian tối đa và giá trị trung bình ít hơn đáng kể) và với tải tăng dần (thời gian chuyển luồng khi số lượng luồng tăng từ 2 lên 128 đơn vị. QNX chỉ tăng 1,65 lần, trong khi VxWorks tăng 2,24 lần).

Theo dữ liệu thu được từ RTSoft, được biết LynxOS có những đặc điểm gần giống với VxWorks.

Quản lý quyền truy cập vào tài nguyên

Nhiệm vụ của các quá trình là:

trong việc phân định quyền truy cập vào RAM giữa các chương trình khác nhau trong quá trình thực thi;
trong việc phân định phạm vi của các biến toàn cục tại thời điểm biên dịch (rất quan trọng nếu phần mềm ứng dụng được viết bằng ngôn ngữ C không hỗ trợ việc phân định đó).

Hỗ trợ cho hệ thống đa bộ xử lý và phân tán

Hỗ trợ hệ thống tập tin

Trong bảng Hình 4 cho thấy sự hỗ trợ của hệ thống tệp cho từng hệ điều hành đang được xem xét.

QNX có sự hỗ trợ rộng rãi nhất cho các hệ thống tệp. Ngoài ra, hệ thống tập tin flash của nó có khả năng chịu lỗi.

Chất lượng tài liệu

Chất lượng tài liệu cho RT OS LynxOS, VxWorks, QNX khá cao. Tuy nhiên, cũng có những phàn nàn về tài liệu:

QNX là một mô tả xuất sắc về kiến trúc và nguyên tắc thiết kế, nhưng mô tả chưa đầy đủ về giao diện lập trình ứng dụng (không phải tất cả các tham số đều được mô tả, có sự mâu thuẫn);
VxWorks - không có lời giải thích về cách hoạt động và mô tả không đầy đủ về quá trình cấu hình hệ điều hành phức tạp.

Chất lượng hỗ trợ kỹ thuật

Mã nguồn mở

Một hệ điều hành RT mở có ít nhất ba ưu điểm:

các nhà phát triển phần mềm ứng dụng có thể hiểu các vấn đề phức tạp mà không cần hỗ trợ kỹ thuật;
dễ dàng chứng nhận hơn (không có dấu trang, v.v.);
phát triển năng động hơn, vì công ty phát triển RT OS thường nhận được không chỉ các yêu cầu sửa lỗi mà còn cả các đề xuất để loại bỏ lỗi và cải thiện hệ thống. Theo quy luật, cộng đồng các nhà phát triển RTOS nguồn mở phát triển nhanh hơn nhiều và được tổ chức tốt hơn. Các chuyên gia độc lập xuất hiện để giúp giải quyết các vấn đề của dịch vụ hỗ trợ kỹ thuật và tham gia vào việc phát triển, gỡ lỗi và thử nghiệm hệ thống.

Mã nguồn LynxOS và VxWorks có sẵn trên thị trường. Giá cho một sản phẩm như vậy có thể thương lượng.

Công cụ

Tính di động của phần mềm ứng dụng

Hỗ trợ kiến trúc bộ xử lý

Tuân thủ các tiêu chuẩn hàng không

LynxOS dẫn đầu về việc tuân thủ các tiêu chuẩn. Nó hỗ trợ ARINC-653 và có nhiều ví dụ về hệ thống được chứng nhận DO-178B được xây dựng trên nó. Điểm mấu chốt là LynuxWorks cung cấp một bộ RSC (mặc dù tác giả bài viết không biết gì về giá cả).

VxWorks tuân thủ tiêu chuẩn ARINC-653 và các hệ thống được xây dựng dựa trên tiêu chuẩn này có thể được chứng nhận DO-178B (có nhiều ví dụ).

QNX không tuân thủ ARINC-653 và chưa có hệ thống nào được chứng nhận DO-178B dựa trên chúng.

Về các tiêu chuẩn tương tự của Nga đối với hàng không quân sự (GOST R ISO/IEC 51904-2002), vẫn chưa có một ví dụ nào về hệ thống được chứng nhận, mặc dù về nguyên tắc, hệ thống như vậy có thể được phát triển dựa trên bất kỳ hệ điều hành nào đang được xem xét. Đối với Hệ điều hành QNX RT, công việc hiện đang được tiến hành để chuẩn bị các mô-đun hệ điều hành chính cho chứng nhận.

Phát triển hệ thống đào tạo chuyên môn

Kết quả so sánh

QNX Neutrino RTOS là hệ điều hành tiên tiến nhất xét theo quan điểm kỹ thuật, có bộ công cụ tốt và có mức giá tương đối thấp. Kiến trúc vi nhân đảm bảo độ tin cậy cao và tính mô đun hóa của các hệ thống được phát triển. Một lợi thế nữa là mã nguồn mở. Nhưng cũng có một điều đáng lo ngại: hiện tại QNX thực tế không được sử dụng ở bất kỳ đâu trong ngành hàng không và về mặt này, hệ điều hành này thua các đối thủ cạnh tranh (LynxOS và VxWorks). Nhược điểm nữa của QNX: không tuân thủ tiêu chuẩn ARINC-653.

Công việc chuẩn bị cho việc chứng nhận QNX Neutrino theo yêu cầu của tiêu chuẩn hàng không trong nước hiện đang được SWD Software thực hiện.

Bộ Giáo dục và Khoa học Liên bang Nga

Đại học Công nghệ Bang Volga

Tóm tắt về môn học

“Hệ điều hành thời gian thực: tính năng và ứng dụng”

Người hoàn thành: Sinh viên EF (nhóm PI-12)

Mikushov Yu. V.

[email được bảo vệ]

Giáo viên: Borodin A.V.

Yoshkar-Ola

●Giới thiệu

●Định nghĩa

●Phát triển hệ điều hành hiện đại

●Hiện trạng của lĩnh vực chủ đề

●Sự khác biệt so với các hệ điều hành có mục đích chung

●Kiến trúc RTOS

●Các loại tác vụ của hệ điều hành

●Năm tác vụ hệ điều hành vô hình quan trọng nhất

●Tính năng

●Ứng dụng

●Thị trường hệ điều hành

●Tương lai của RTOS

●Kết luận

●Danh sách các nguồn được sử dụng

Giới thiệu

Yêu cầu chính đối với RTOS là đảm bảo khả năng dự đoán hoặc thuyết định mệnh hành vi của hệ thống trong điều kiện bên ngoài tồi tệ nhất, khác biệt rõ rệt so với yêu cầu về hiệu suất và tốc độ của các hệ điều hành phổ thông. Một RTOS tốt có hành vi có thể dự đoán được trong mọi tình huống tải hệ thống (ngắt đồng thời và thực thi luồng).

Người ta thường phân biệt giữa hệ thống thời gian thực mềm và cứng. Trong các hệ thống thời gian thực cứng, việc không thể đưa ra phản hồi cho bất kỳ sự kiện nào tại một thời điểm nhất định sẽ dẫn đến lỗi và không thể hoàn thành nhiệm vụ được giao. Trong hầu hết các tài liệu tiếng Nga, những hệ thống như vậy được gọi là hệ thống có thời gian xác định. Trong các ứng dụng thực tế, thời gian phản ứng phải ở mức tối thiểu. Hệ thống thời gian thực mềm là hệ thống không nằm trong định nghĩa “cứng”, bởi vì Vẫn chưa có định nghĩa rõ ràng cho chúng trong tài liệu. Các hệ thống thời gian thực mềm có thể không có thời gian để giải quyết vấn đề, nhưng điều này không dẫn đến sự cố của toàn bộ hệ thống. Trong các hệ thống thời gian thực, cần phải đưa ra một thời hạn nhất định (trong tài liệu tiếng Anh - thời hạn), trước khi hết thời hạn đó, nhiệm vụ nhất thiết phải được hoàn thành (đối với hệ thống thời gian thực mềm - tốt nhất là). Thời hạn này được người lập lịch tác vụ sử dụng để chỉ định mức độ ưu tiên cho một tác vụ khi nó được khởi chạy và khi chọn một tác vụ để thực thi.

Các định nghĩa

Hệ thống thời gian thực là một loại hệ điều hành, mục đích chính của nó là cung cấp một bộ chức năng cần và đủ để đảm bảo sự phát triển phần mềm của hệ thống thời gian thực trên phần cứng cụ thể.

Một hệ thống được gọi là hệ thống thời gian thực nếu tính chính xác trong hoạt động của nó không chỉ phụ thuộc vào tính chính xác logic của các phép tính mà còn phụ thuộc vào thời gian thực hiện các phép tính này. Nghĩa là, đối với các sự kiện xảy ra trong một hệ thống như vậy, thời điểm các sự kiện này xảy ra cũng quan trọng như tính đúng đắn về mặt logic của chính các sự kiện đó.

Các thành phần của hệ thống thời gian thực

Phần mềm ứng dụng		điều phối
		Giao tiếp giữa các luồng
Hệ điều hành thời gian thực		Xử lý ngắt
	Bảo vệ đảo ngược ưu tiên	Quản lý chủ đề
		Quản lý bộ nhớ
Phần cứng			Thiết bị

Giải mã Mac OS X:

“Mac” dùng để chỉ tên công ty Macintosh.

“OS” - hệ điều hành, tức là hệ điều hành.

“X” là số mười La Mã, biểu thị số phiên bản hệ điều hành.

Phát triển hệ điều hành hiện đại

Trong sự phát triển của các hệ điều hành hiện đại, có xu hướng chuyển mã sâu hơn lên các cấp cao hơn, đồng thời loại bỏ mọi thứ có thể có khỏi chế độ kernel, để lại một vi nhân tối thiểu. Điều này thường được thực hiện bằng cách chuyển hầu hết các tác vụ của hệ điều hành sang các quy trình của người dùng.

Khi nhận được yêu cầu thực hiện một thao tác, chẳng hạn như đọc một khối tệp, quy trình người dùng (hiện được gọi là quy trình được cung cấp hoặc quy trình máy khách) sẽ gửi yêu cầu đến quy trình máy chủ (máy chủ), quy trình này sẽ xử lý yêu cầu đó và gửi lại phản hồi.

Bằng cách chia hệ điều hành thành các phần, mỗi phần chỉ quản lý một thành phần của hệ thống (hệ thống tệp, quy trình, thiết bị đầu cuối hoặc bộ nhớ), tất cả các phần đều trở nên nhỏ và có thể quản lý được.

Ngoài ra, vì tất cả các máy chủ đều chạy dưới dạng tiến trình ở chế độ người dùng thay vì tiến trình ở chế độ lõi, nên chúng không có quyền truy cập trực tiếp vào phần cứng. Do đó, nếu xảy ra lỗi trên máy chủ file, dịch vụ xử lý yêu cầu file có thể gặp sự cố nhưng điều này thường không khiến toàn bộ máy dừng lại.

Một ưu điểm khác của mô hình client-server là nó có thể dễ dàng thích ứng để sử dụng trong các hệ thống phân tán. Nếu máy khách giao tiếp với máy chủ bằng cách gửi tin nhắn, máy khách không cần biết liệu tin nhắn của nó có đang được xử lý cục bộ trên máy của nó hay nó được gửi qua mạng tới máy chủ trên máy từ xa. Từ quan điểm của khách hàng, điều tương tự xảy ra trong cả hai trường hợp: yêu cầu được gửi và nhận được phản hồi.

Câu chuyện trên về kernel quản lý việc truyền tin nhắn từ máy khách đến máy chủ và ngược lại là không hoàn toàn thực tế. Một số chức năng của hệ điều hành, chẳng hạn như tải hướng dẫn vào thanh ghi thiết bị I/O vật lý, rất khó, nếu không nói là không thể thực hiện được từ các chương trình trong không gian người dùng. Có hai cách để giải quyết vấn đề này.

Đầu tiên là một số quy trình máy chủ quan trọng (chẳng hạn như trình điều khiển thiết bị I/O) thực sự chạy ở chế độ kernel, có toàn quyền truy cập vào phần cứng nhưng giao tiếp với các quy trình khác bằng cách truyền thông báo bình thường.

Tùy chọn thứ hai là xây dựng một cơ chế xử lý thông tin tối thiểu trong kernel nhưng để lại các quyết định về chính sách cho các máy chủ trong không gian người dùng. Ví dụ: kernel có thể nhận dạng các tin nhắn được gửi đến các địa chỉ cụ thể. Đối với kernel, điều này có nghĩa là nó cần lấy nội dung của thông báo và tải nó vào một số thanh ghi I/O trên đĩa để kích hoạt thao tác đọc đĩa.

Trong ví dụ này, kernel thậm chí có thể không kiểm tra các byte thông báo xem chúng có hợp lệ hoặc có ý nghĩa hay không; nó có thể sao chép chúng một cách mù quáng vào các thanh ghi đĩa. (Rõ ràng, một số lược đồ phải được sử dụng để giới hạn phạm vi của các quy trình có quyền gửi những tin nhắn như vậy.)

Hiện trạng của lĩnh vực chủ đề

Hiệp hội, công ty và sản phẩm

Microsoft và Apple Inc. là những nhà sản xuất hệ điều hành và phần mềm phổ biến nhất cho họ trong thế giới hiện đại.

Hệ điều hành hiện đại của Microsoft:

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

Hệ điều hành hiện đại của Apple Inc:

Hệ điều hành di động hiện đại:

Hệ thống Linux (Android)

Sự khác biệt so với các hệ điều hành có mục đích chung

Sự khác biệt chính giữa các dịch vụ cốt lõi của RTOS là tính chất xác định trong công việc của chúng, dựa trên việc kiểm soát thời gian nghiêm ngặt. Trong trường hợp này, tính tất định có nghĩa là việc thực thi một dịch vụ hệ điều hành yêu cầu một khoảng thời gian trong khoảng thời gian đã biết. Về mặt lý thuyết, thời gian này có thể được tính bằng các công thức toán học, phải hoàn toàn đại số và không bao gồm bất kỳ tham số thời gian nào có tính chất ngẫu nhiên. Bất kỳ biến ngẫu nhiên nào xác định thời gian thực hiện của một tác vụ trong RTOS đều có thể gây ra độ trễ không mong muốn trong ứng dụng, khi đó tác vụ tiếp theo sẽ không đáp ứng được lượng tử thời gian của nó, điều này sẽ gây ra lỗi.

Theo nghĩa này, hệ điều hành có mục đích chung không mang tính quyết định. Các dịch vụ của họ đôi khi có thể gây ra sự chậm trễ trong hoạt động, điều này có thể dẫn đến sự chậm lại trong phản hồi của ứng dụng đối với hành động của người dùng tại một thời điểm không xác định. Khi thiết kế các hệ điều hành thông thường, các nhà phát triển không tập trung chú ý vào bộ máy toán học để tính toán thời gian thực hiện một nhiệm vụ và dịch vụ cụ thể. Điều này không quan trọng đối với loại hệ thống này

Kiến trúc RTOS

Trong lịch sử của nó, kiến trúc hệ điều hành đã trải qua sự phát triển đáng kể. Một trong những nguyên tắc xây dựng đầu tiên, được gọi là. Hệ điều hành nguyên khối (Hình 1), nhằm trình bày HĐH như một tập hợp các mô-đun tương tác với nhau theo nhiều cách khác nhau trong nhân hệ thống và cung cấp các chương trình ứng dụng với giao diện đầu vào để truy cập phần cứng. Nhược điểm chính của kiến trúc này là khả năng dự đoán hành vi của nó kém, gây ra bởi sự tương tác phức tạp của các mô-đun hệ thống với nhau.

Tuy nhiên, hầu hết các hệ điều hành hiện đại, cả thời gian thực và đa năng, đều được xây dựng chính xác theo nguyên tắc này.

Trong các tác vụ tự động hóa, hệ điều hành cấp độ được sử dụng rộng rãi dưới dạng RTOS (Hình 2). Một ví dụ về hệ điều hành như vậy là hệ thống MS-DOS nổi tiếng. Trong các hệ thống thuộc lớp này, các ứng dụng ứng dụng có thể truy cập phần cứng không chỉ thông qua nhân hệ thống hoặc các dịch vụ thường trú của nó mà còn có thể truy cập trực tiếp. RTOS đã được xây dựng dựa trên nguyên tắc này trong nhiều năm. So với các hệ điều hành nguyên khối, kiến trúc này cung cấp mức độ dự đoán phản ứng hệ thống cao hơn đáng kể và cũng cho phép các ứng dụng ứng dụng truy cập nhanh vào phần cứng. Nhược điểm của các hệ thống như vậy là thiếu đa nhiệm. Trong kiến trúc này, vấn đề xử lý các sự kiện không đồng bộ được giảm xuống còn các thông báo lưu vào bộ đệm, sau đó thăm dò tuần tự các bộ đệm và xử lý chúng. Đồng thời, việc tuân thủ thời hạn dịch vụ quan trọng được đảm bảo nhờ hiệu suất cao của tổ hợp máy tính so với tốc độ của các quy trình bên ngoài.

Một trong những kiến trúc hiệu quả nhất để xây dựng hệ điều hành thời gian thực là kiến trúc client-server. Sơ đồ chung của một hệ điều hành hoạt động sử dụng công nghệ này được trình bày trong Hình 3. Nguyên tắc chính của kiến trúc này là chuyển các dịch vụ hệ điều hành dưới dạng máy chủ đến cấp độ người dùng và vi nhân thực hiện các chức năng của trình quản lý tin nhắn giữa các máy khách. chương trình người dùng và máy chủ - dịch vụ hệ thống. Kiến trúc này cung cấp rất nhiều lợi thế về yêu cầu đối với RTOS và các hệ thống nhúng. Trong số những lợi thế này là:

1. Độ tin cậy của hệ điều hành tăng lên vì Trên thực tế, mỗi dịch vụ là một ứng dụng độc lập và dễ dàng gỡ lỗi cũng như theo dõi lỗi hơn.

2. Hệ thống như vậy có quy mô tốt hơn vì các dịch vụ không cần thiết có thể được loại trừ khỏi hệ thống mà không ảnh hưởng đến hiệu suất của hệ thống.

3. Khả năng chịu lỗi của hệ thống tăng lên vì Dịch vụ bị đóng băng có thể được khởi động lại mà không cần khởi động lại hệ thống.

Thật không may, ngày nay không có nhiều hệ điều hành được triển khai theo nguyên tắc máy khách-máy chủ. Trong số các RTOS nổi tiếng triển khai kiến trúc vi nhân là OS9 và QNX.

Các loại nhiệm vụ

Mỗi tiến trình bao gồm một hoặc nhiều nhiệm vụ. Hệ điều hành cho phép một tác vụ sinh ra các tác vụ mới. Nhiệm vụ có thể được chia thành 3 loại dựa trên cách thức hành động của chúng.

1. Nhiệm vụ mang tính chu kỳ. Đặc điểm của quá trình kiểm soát và quá trình tương tác.

2. Nhiệm vụ định kỳ. Điển hình cho nhiều quy trình công nghệ và nhiệm vụ đồng bộ hóa.

3. Nhiệm vụ xung lực. Điển hình cho các vấn đề về tín hiệu và quy trình công nghệ không đồng bộ.

Năm nhiệm vụ vô hình quan trọng nhất của hệ điều hành

1. Cung cấp “khớp nối” phần cứng-phần mềm

Hệ điều hành đóng vai trò như một loại “trình dịch” giữa phần cứng máy tính và phần mềm của nó. Nếu bạn mở vỏ máy tính, bạn có thể thấy nhiều bo mạch, chip, dây cáp và các thành phần khác. Đây là cơ sở vật lý giúp cho việc thực hiện chương trình có thể thực hiện được. Nhưng một chương trình không thể đơn giản lấy và sử dụng tài nguyên phần cứng của máy tính. Nó thực hiện điều này thông qua hệ điều hành.

Gần đây, hệ điều hành ngày càng được gọi là “nền tảng”. Và cái tên này phản ánh rất chính xác bản chất. Hệ điều hành là nền tảng chứa các chương trình. Hoặc, như người ta nói bây giờ, các ứng dụng cho hệ điều hành. Đây là hệ điều hành cho phép phần mềm “nói chuyện” với phần cứng. Điều này cũng áp dụng cho các thiết bị đầu vào và đầu ra. Ví dụ đơn giản nhất về thiết bị đầu vào là bàn phím và thiết bị đầu ra là màn hình.

Đây là công việc rất quan trọng. Về lý thuyết, hàng trăm thiết bị đầu vào và đầu ra khác nhau có thể được kết nối với một máy tính. Hãy lấy một con chuột thông thường. Nhưng “chuột” là một khái niệm chung. Có hàng chục mô hình khác nhau của bộ điều khiển này. Sẽ là một nhiệm vụ nặng nề khi cung cấp phần mềm hỗ trợ riêng cho từng loại chuột để nó giao tiếp trực tiếp với tài nguyên của máy tính. Nhưng giải pháp là cơ sở dữ liệu trình điều khiển có trong hệ điều hành. Đối với người dùng, có vẻ như anh ta chỉ cần kết nối bất kỳ con chuột nào với máy tính của mình và nó ngay lập tức bắt đầu hoạt động.

2. Buộc cùng một ứng dụng hoạt động trên các phần cứng khác nhau

Đây là hệ điều hành cho phép phần mềm chạy trên các máy tính khác nhau chứ không chỉ trên một cấu hình cụ thể. Ngày xửa ngày xưa, các chương trình được viết cho một kiểu máy tính cụ thể. Ngôn ngữ lập trình thực sự đóng vai trò là hệ điều hành của tiền thân của PC hiện đại, máy vi tính vào cuối những năm bảy mươi của thế kỷ trước.

Nhưng ngày nay, HĐH đã đảm nhận vai trò như một loại “bộ chuyển đổi” giữa các chương trình và phần cứng máy tính. Nếu bạn lấy bất kỳ hai kiểu máy tính nào, bộ linh kiện mà chúng được lắp ráp sẽ khác nhau. Điều này áp dụng ngay cả với những chiếc Macintosh nổi tiếng vì sự giống nhau của chúng, chưa kể đến tất cả sự đa dạng khổng lồ có thể tìm thấy trên thị trường PC hiện đại.

Môi trường hoạt động tạo ra cái gọi là môi trường trừu tượng cho chương trình. Điều này có thể được biểu diễn dưới dạng cuộc đối thoại giữa HĐH và chương trình. Trong “cuộc trò chuyện” mà con người không thể hiểu được này, chương trình “nói” với nền tảng về nhu cầu của nó và hệ điều hành phải “suy nghĩ” về cách thỏa mãn chúng một cách hợp lý. Vấn đề là bạn cần phải suy nghĩ rất nhanh chóng. Game thủ hiện đại không sẵn sàng đợi một hoặc hai giờ để tải trò chơi yêu thích của mình.

Vì vậy, chương trình “cho” hệ điều hành biết chính xác những gì nó cần để hoạt động chính xác. Rốt cuộc, ứng dụng không quen thuộc trực tiếp với tài nguyên máy tính. Và hệ điều hành lần lượt phân phối các nhiệm vụ được chương trình giao cho nó giữa các tài nguyên của thiết bị kỹ thuật số. Và loại phần cứng không quan trọng đối với chương trình. Nền tảng sẽ đảm nhiệm mọi thứ! Hệ điều hành có thể “nói”, nếu không phải với tất cả thì với nhiều thiết bị và mô-đun phần cứng.

Nếu không có kỹ năng điều hành quý giá này, các lập trình viên sẽ phải viết lại chương trình của mình cho từng cấu hình máy tính cụ thể, cho từng bộ linh kiện. Và, nếu không có hệ điều hành, chương trình có thể không hoạt động trên một máy tính có các đặc điểm khác với những đặc điểm mà người lập trình dự tính khi tạo chương trình.

Ngày nay, các nhà phát triển tạo ứng dụng của họ cho các nền tảng chứ không phải cho một số cấu hình phần cứng đã biết. Nói một cách đơn giản, không phải dành cho một máy tính cụ thể mà dành cho một hệ điều hành cụ thể. Tất nhiên, điều này dễ dàng hơn nhiều. Hàng triệu thiết bị có thể chạy cùng một hệ điều hành. Do đó, hàng chục, thậm chí hàng trăm nghìn ứng dụng đã trở nên khả thi, có sẵn cho người dùng hiện đại của từng nền tảng phổ biến.

3. Tìm kiếm file mà ứng dụng yêu cầu

Chỉ riêng tài nguyên vật lý của máy tính sẽ không đủ để các chương trình có thể thực hiện chính xác các nhiệm vụ của chúng. Tất cả thông tin được lưu trữ trong các tệp và các tệp này phải tuân theo các quy tắc nhất định. Các quy tắc này bao gồm cách đặt tên và lưu trữ tệp. Chúng tôi gọi bộ quy tắc chung này là “hệ thống quản lý tệp” hoặc đơn giản là “trình quản lý tệp”.

Các hệ điều hành khác nhau thực hiện các cách tiếp cận khác nhau để quản lý tập tin. Ngoài ra, người dùng có thể cài đặt phần mềm bổ sung cho phép quản lý tệp hiệu quả hơn. Hệ điều hành có nhiệm vụ “ghi nhớ” các tập tin được lưu trữ trên máy tính. Khi một ứng dụng muốn truy cập vào một tệp cụ thể, hệ điều hành sẽ chỉ cho chương trình đường dẫn đến tệp đó.

Nếu không có hệ thống quản lý tập tin, thông tin số trên máy tính chỉ đơn giản là một tập hợp dữ liệu vô nghĩa. Sự hỗn loạn, trong đó không có gì có thể được tìm thấy. Và hơn thế nữa, hãy tìm thấy nó trong khoảng thời gian ngắn nhất của một giây.

Hệ điều hành tuân theo các quy tắc riêng của nó một cách vô hình đối với chúng tôi, vì vậy bạn không cần phải truy cập thủ công vào các ô nhớ nơi tệp bạn cần được lưu trữ vật lý. Tuy nhiên, quan trọng nhất, người dùng hệ điều hành hiện đại không nhất thiết phải biết những quy tắc này để làm việc trên máy tính.

4. Phân bổ hiệu quả RAM khả dụng

Vì chúng ta đang nói về bộ nhớ nên việc nhớ về bộ nhớ truy cập ngẫu nhiên (RAM) là điều hợp lý. Về chính bộ lưu trữ luôn “trong tầm tay” của bộ xử lý.

Cần phải nhấn mạnh rằng tài nguyên máy tính quan trọng nhất này cũng được quản lý bởi hệ điều hành. RAM là tài nguyên được nhiều người dùng đánh giá rất thấp. Làm thế nào để máy tính của bạn chạy nhanh hơn? Nhiều người cho rằng họ rất cần một bộ xử lý mạnh hơn. Nhưng trên thực tế, thường chỉ cần tăng dung lượng RAM là đủ để hiệu suất máy tính tăng đáng kể.

Trong RAM, máy tính lưu trữ thông tin mà bộ xử lý có thể yêu cầu thực hiện các phép tính. Hãy coi loại bộ nhớ này đơn giản như một thiết bị lưu trữ tạm thời cho những thông tin cần “gần với bộ xử lý hơn”.

Khi làm việc với máy tính, đôi khi chúng ta có nhiều chương trình chạy cùng lúc. Hệ điều hành phân bổ một lượng bộ nhớ nhất định cho mỗi tác vụ. Nếu bộ xử lý cần thông tin mà nó không tìm thấy trong RAM, nó sẽ phải tìm thông tin đó ở nơi khác. Đặc biệt, trên ổ cứng của máy tính. Việc này sẽ mất nhiều thời gian hơn việc lấy dữ liệu từ RAM. Đối với người dùng, tình huống này sẽ giống như tình trạng ứng dụng bị "đóng băng" tạm thời. Trong những trường hợp như vậy, người ta thường nói rằng “máy tính suy nghĩ”.

Một trong những nhiệm vụ mà hệ điều hành đảm nhận một cách vô hình đối với người dùng là giảm thiểu thời gian trễ, tức là khoảng thời gian rất khó chịu khi máy tính đang bận công việc riêng và không phản hồi các cuộc gọi của bạn đến nó. Vấn đề là tại bất kỳ thời điểm nào hệ điều hành

có một lượng RAM nhất định, luôn bị giới hạn. Âm lượng này cũng phụ thuộc vào số lượng chương trình bạn đang chạy cùng lúc. Hệ điều hành phải “biết” mọi lúc nó còn bao nhiêu RAM để phân bổ kịp thời cho tiến trình cần tài nguyên quan trọng này.

Hệ điều hành "đánh giá" các yêu cầu của từng tiến trình đang chạy và quyết định cách đáp ứng chúng một cách thông minh. Lý tưởng nhất là việc này nên được thực hiện theo cách mà người dùng không gặp phải bất kỳ sự chậm trễ nào. Nhưng trên thực tế, HĐH chỉ cố gắng giảm thiểu độ trễ đó đến mức tối thiểu, phân bổ hợp lý các tài nguyên mà nó thực sự có.

Không có máy tính nào trên Trái đất có RAM không giới hạn. Do đó, hệ thống luôn phải chọn quy trình nào được coi là ưu tiên tại một thời điểm nhất định và quy trình nào là thứ yếu. Ai nên phân bổ bộ nhớ khẩn cấp và ai sẽ quản lý và kiên nhẫn trong lúc này. Người dùng không phải lúc nào cũng có thể đồng ý với các quy tắc mà hệ điều hành tuân theo khi cấp phát bộ nhớ. Nhưng việc phân bổ RAM trống một cách độc lập cho các quy trình sẽ khó khăn và tốn thời gian hơn nhiều so với việc giao phó nó cho một nền tảng phần mềm.

5. Tập trung sự chú ý của bộ xử lý vào một tác vụ cụ thể

Bộ xử lý trung tâm (CPU) là mô-đun vật lý giải quyết các tác vụ mà người dùng đặt ra cho máy tính của mình. Một điều nữa là hiếm có người dùng nào nói được ngôn ngữ mà bộ xử lý hiểu được. Hơn nữa, thậm chí không phải mọi lập trình viên đều quen thuộc với mã máy. Một người thậm chí có thể không nghĩ đến thực tế rằng bất kỳ chương trình nào cũng là một tập hợp các vấn đề toán học phức tạp.

Bộ xử lý trung tâm thực hiện các phép tính, nghĩa là nó tìm ra giải pháp cho những vấn đề này và cung cấp cho bạn các kết quả làm sẵn thậm chí không giống với các công thức trong sách giáo khoa đại số. Người dùng bình thường đơn giản là không quan tâm đến tất cả các phép toán này. Anh ta muốn nhân vật trong game của mình nhảy qua chướng ngại vật trong tích tắc hoặc muốn kiểm tra chính tả của văn bản anh ta vừa viết. Đằng sau những vấn đề tưởng chừng như không hề nhàm chán này lại là một phép toán phức tạp nhất.

Mỗi chương trình đang chạy đều yêu cầu một phần sức mạnh xử lý của bộ xử lý. Càng chạy nhiều chương trình cùng lúc, tải bộ xử lý càng gần mức tối đa. Nhiệm vụ của hệ điều hành là điều phối việc cung cấp thông tin xử lý đến bộ xử lý để mọi việc diễn ra suôn sẻ và không bị người dùng chú ý. Hệ điều hành có thể chuyển sự chú ý của bộ xử lý từ tác vụ này sang tác vụ khác.

Một trong những vai trò quan trọng của hệ điều hành là vai trò của người quản lý tài nguyên. Nếu nó đối phó tốt với nhiệm vụ này, thì chúng ta thậm chí không biết bộ xử lý tạm gác một nhiệm vụ này sang một nhiệm vụ khác và chuyển sự chú ý của nó sang nhiệm vụ khác vào thời điểm nào.

Trợ lý vô hình và không thể thay thế

Công việc khó khăn nhất của hệ điều hành là khiến bạn bỏ qua nó và tập trung vào các ứng dụng mà bạn quan tâm. Và trong khi mọi thứ đang diễn ra tốt đẹp, người dùng lại không hề nghĩ đến nền tảng này. Và chỉ khi lỗi phần mềm bắt đầu, người dùng mới nhận ra sứ mệnh của hệ điều hành quan trọng như thế nào.

Những “sự khác biệt” giữa các hệ điều hành mà hầu hết người dùng dễ nhận thấy chỉ đơn thuần là về mặt thẩm mỹ. Rất hiếm người dùng đủ hiểu lập trình để thấy đằng sau lớp vỏ giao diện đồ họa điều gì thực sự phân biệt hệ điều hành này với hệ điều hành khác. Cả vẻ ngoài của màn hình nền cũng như thiết kế của các biểu tượng ứng dụng đều không liên quan gì đến bản chất bên trong của hệ điều hành.

Các nhiệm vụ mô tả ở trên được thực hiện bằng cách này hay cách khác bởi mỗi hệ điều hành hiện đại, điều khiển bất kỳ thiết bị máy tính nào. Bất kể hệ điều hành trông như thế nào và nó được cài đặt trên thiết bị nào: trên PC, thiết bị di động hoặc bảng điều khiển trò chơi.

Đặc thù

Tính năng tích cực

Tính sẵn có của sản phẩm rộng rãi

Trong phần lớn các trường hợp, Windows được cài đặt trên máy tính. Do đó, khi đến thăm bạn bè hoặc nơi làm việc, bạn có thể dễ dàng chuyển một số hình ảnh, tệp văn bản hoặc clip từ ổ đĩa flash. Sự dễ sử dụng và hỗ trợ của HĐH Windows cho mọi phần cứng và mọi chương trình đã góp phần vào việc phân phối HĐH này trên toàn cầu.

Giao diện đẹp

Các hệ điều hành hiện đại có giao diện khá đẹp và trực quan. Điều này thúc đẩy nhận thức nhanh chóng về thông tin, dễ sử dụng máy tính và học cách làm việc với hệ điều hành nhanh chóng.

Độ ổn định của hệ điều hành

Nhìn chung, độ ổn định của hệ điều hành hiện đại có thể gọi là chấp nhận được. Tuy nhiên, từ “chấp nhận được” ở đây phải kèm theo rất nhiều dè dặt:

1. Độ ổn định của HĐH chỉ có thể chấp nhận được sau khi cấu hình đủ chất lượng và chất lượng cao của nó - chẳng ích gì khi nói về một hệ thống chưa được điều chỉnh (cũng như một cây đàn guitar chưa được điều chỉnh) ở đây.

2. Độ ổn định của hệ điều hành hiện đại phần lớn phụ thuộc vào phiên bản của sản phẩm và sự hiện diện của các gói dịch vụ và tiện ích bổ sung đã cài đặt - than ôi, nếu không có chúng, các lỗi thường xuyên xảy ra trong quá trình hoạt động của hệ điều hành.

3. Độ ổn định của HĐH cũng phụ thuộc vào các ứng dụng do người dùng cài đặt trên HĐH: chúng hoạt động càng ổn định và càng tương thích với chính vỏ phần mềm Windows thì chúng ta càng có thể quan sát thấy ít lỗi hơn trong hoạt động của hệ điều hành chính.

4. Độ ổn định của HĐH hiện đại bị ảnh hưởng rất nhiều bởi chính phần cứng, được sử dụng cùng với HĐH đang chạy.

5. Ngoài ra, trình điều khiển thiết bị cũng có ảnh hưởng đáng kể đến hoạt động ổn định của hệ điều hành hiện đại. Đây là những chương trình nhỏ chịu trách nhiệm ghép nối một số phần mềm nhất định với phần cứng nhất định.

Khả năng tương thích tốt với các sản phẩm từ các nhà phát triển khác nhau (khoảngOC các cửa sổ)

Một hệ điều hành hiện đại có khả năng hiểu chính xác bất kỳ loại tệp nào xuất hiện trong những phiên bản đầu tiên của nó. Nếu chúng ta nhớ lại các phần mở rộng tệp giống nhau, thì sẽ thấy rõ rằng trên thực tế, tổ tiên của chúng chính là hệ điều hành nguyên thủy và cổ xưa đó, từng được mua từ nhà phát triển bên thứ ba và được Microsoft - MS-DOS lưu ý đến. Tính liên tục của các định dạng tệp này chạy như một sợi dây xuyên suốt tất cả các phiên bản Windows, bản thân điều này đã thật tuyệt vời.