Sự khác biệt giữa thời gian thực cứng, thời gian thực mềm và thời gian thực chắc chắn?

Tôi đã đọc các định nghĩa cho các khái niệm khác nhau về thời gian thực và các ví dụ được cung cấp cho các hệ thống thời gian thực cứng và mềm có ý nghĩa đối với tôi. Tuy nhiên, không có lời giải thích hoặc ví dụ thực sự nào về hệ thống thời gian thực vững chắc. Theo liên kết trên:

Công ty: Việc bỏ lỡ thời hạn không thường xuyên là có thể chấp nhận được, nhưng có thể làm giảm chất lượng dịch vụ của hệ thống. Tính hữu ích của một kết quả bằng 0 sau thời hạn của nó.

Có sự phân biệt rõ ràng giữa thời gian thực công ty so với thời gian thực cứng hay mềm, và có một ví dụ điển hình nào minh họa cho sự phân biệt đó không?

Trong nhận xét, Charles yêu cầu tôi gửi wiki gắn thẻ cho các thẻ mới. Ví dụ về "hệ thống thời gian thực công ty" mà tôi đã cung cấp chocông ty thời gian thựcthẻ là một hệ thống phục vụ sữa. Nếu hệ thống phân phối sữa sau thời gian hết hạn, thì sữa đó được coi là "không hữu ích". Người ta có thể chịu được việc ăn ngũ cốc mà không có sữa, nhưng chất lượng của trải nghiệm bị giảm sút.

Đây chỉ là ý tưởng tôi hình thành trong đầu khi tôi đọc định nghĩa ban đầu. Tôi đang tìm kiếm một ví dụ tốt hơn nhiều và có lẽ một định nghĩa tốt hơn về thời gian thực công ty sẽ cải thiện quan niệm của tôi về nó.

Thời gian thực khó có nghĩa là bạn phải hoàn thành mọi thời hạn. Rất ít hệ thống có yêu cầu này. Một số ví dụ là hệ thống hạt nhân, một số ứng dụng y tế như máy điều hòa nhịp tim, một số lượng lớn các ứng dụng quốc phòng, hệ thống điện tử hàng không, v.v.

Các hệ thống thời gian thực cứng / mềm có thể bỏ lỡ một số thời hạn, nhưng cuối cùng hiệu suất sẽ suy giảm nếu bỏ lỡ quá nhiều. Một ví dụ điển hình là hệ thống âm thanh trong máy tính của bạn. Nếu bạn bỏ lỡ một vài bit, không có vấn đề gì lớn, nhưng bỏ lỡ quá nhiều và cuối cùng bạn sẽ làm suy giảm hệ thống. Tương tự sẽ là cảm biến địa chấn. Nếu bạn bỏ lỡ một vài điểm dữ liệu, không có vấn đề gì lớn, nhưng bạn phải nắm bắt hầu hết chúng để hiểu dữ liệu. Quan trọng hơn, không ai sẽ chết nếu chúng không hoạt động chính xác.

Đường này mờ, vì ngay cả máy điều hòa nhịp tim cũng có thể tắt một lượng nhỏ mà không làm bệnh nhân tử vong, nhưng đó là ý chính chung.

Nó giống như sự khác biệt giữa nóng và ấm. Không có sự phân chia thực sự, nhưng bạn biết nó khi bạn cảm thấy nó.

Thời gian thực khó

Các khó khăn thời gian thực nghĩa xem xét bất kỳ bỏ lỡ hạn chót là một lỗi hệ thống. Việc lập kế hoạch này được sử dụng rộng rãi trong các hệ thống quan trọng của sứ mệnh mà việc không tuân theo các ràng buộc về thời gian dẫn đến thiệt hại về nhân mạng hoặc tài sản.

Ví dụ:

• Chuyến bay 447 của Air France đã lao xuống đại dương sau khi trục trặc cảm biến gây ra hàng loạt lỗi hệ thống. Các phi công đã làm máy bay bị đình trệ trong khi phản ứng với các kết quả đọc trên thiết bị lỗi thời. Toàn bộ phi hành đoàn 12 người và 216 hành khách thiệt mạng.

• Tàu vũ trụ Mars Pathfinder gần như bị mất khi một đảo ngược ưu tiên khiến hệ thống khởi động lại. Nhiệm vụ có mức độ ưu tiên cao hơn đã không được hoàn thành đúng hạn do bị chặn bởi một nhiệm vụ có mức độ ưu tiên thấp hơn. Sự cố đã được khắc phục và tàu vũ trụ đã hạ cánh thành công.

• Máy in phun có đầu in với phần mềm điều khiển để đổ lượng mực chính xác vào một phần cụ thể của giấy. Nếu bị trễ thời hạn thì lệnh in sẽ bị hủy.

Thời gian thực vững chắc

Các công ty theo thời gian thực nghĩa cho phép thời hạn không thường xuyên bỏ qua. Trong các ứng dụng này, hệ thống có thể tồn tại các lỗi tác vụ miễn là chúng được đặt cách nhau thích hợp, tuy nhiên giá trị của việc hoàn thành tác vụ giảm xuống 0 hoặc không thể thực hiện được.

Ví dụ:

• Các hệ thống sản xuất với dây chuyền lắp ráp rô bốt thiếu thời hạn dẫn đến việc lắp ráp một bộ phận không đúng cách. Miễn là các bộ phận bị hỏng không đủ thường xuyên để được kiểm tra chất lượng và không quá tốn kém, thì việc sản xuất tiếp tục.

• Hộp giải mã cáp kỹ thuật số giải mã các dấu thời gian cho thời điểm các khung hình phải xuất hiện trên màn hình. Vì các khung giờ nhạy cảm với thứ tự thời gian nên việc trễ thời hạn sẽ gây ra tình trạng chập chờn, làm giảm chất lượng dịch vụ. Nếu khung hình bị nhỡ sau đó có sẵn, nó sẽ chỉ khiến hiển thị nó nhiều rung hơn, vì vậy nó vô dụng. Người xem vẫn có thể thưởng thức chương trình nếu tình trạng giật hình không xảy ra quá thường xuyên.

Thời gian thực mềm

Các thời gian thực mềm định nghĩa cho phép thời hạn thường xuyên bỏ lỡ, và chừng nào nhiệm vụ được thực hiện kịp thời kết quả của họ tiếp tục có giá trị. Các nhiệm vụ đã hoàn thành có thể có giá trị tăng dần theo thời hạn và giảm giá trị sau thời hạn đó.

Ví dụ:

• Các trạm thời tiết có nhiều cảm biến để đọc nhiệt độ, độ ẩm, tốc độ gió, ... Các kết quả đọc phải được thực hiện và truyền đi đều đặn, tuy nhiên các cảm biến không đồng bộ. Mặc dù việc đọc cảm biến có thể sớm hoặc muộn so với các chỉ số khác, nó vẫn có thể phù hợp miễn là nó đủ gần.

• Bảng điều khiển trò chơi điện tử chạy phần mềm cho công cụ trò chơi. Có nhiều tài nguyên phải được chia sẻ giữa các nhiệm vụ của nó. Đồng thời các nhiệm vụ cần được hoàn thành theo đúng tiến độ để trò chơi có thể chơi chính xác. Miễn là các nhiệm vụ được hoàn thành tương đối đúng thời gian, trò chơi sẽ thú vị, và nếu không, nó có thể chỉ bị lag một chút.

^{Siewert: Hệ thống và thành phần nhúng thời gian thực.
Liu & Layland: Lập lịch các thuật toán cho đa chương trình trong môi trường thời gian thực khó.
Marchand & Silly-Chetto: Lập lịch động cho các Nhiệm vụ theo chu kỳ mềm và Nhiệm vụ định kỳ có Bỏ qua.}

Sau khi đọc trang Wikipedia và các trang khác trên máy tính thời gian thực. Tôi đã suy luận sau:

1> Đối với hệ thống thời gian thực Khó , nếu hệ thống không đáp ứng được thời hạn ngay cả khi hệ thống được coi là Không thành công.

2> Đối với hệ thống thời gian thực Firm , ngay cả khi hệ thống không đáp ứng thời hạn, có thể nhiều hơn một lần (tức là cho nhiều yêu cầu), hệ thống không được coi là đã thất bại. Ngoài ra, các phản hồi cho các yêu cầu (trả lời cho một truy vấn, kết quả của một nhiệm vụ, v.v.) là vô giá trị khi thời hạn cho yêu cầu cụ thể đó đã trôi qua ( Tính hữu ích của kết quả bằng 0 sau thời hạn của nó ). Một ví dụ giả định có thể là một hệ thống dự báo bão (nếu một cơn bão được dự báo trước khi đến thì hệ thống đã thực hiện công việc của nó, dự đoán sau khi sự kiện đã xảy ra hoặc khi nó đang xảy ra không có giá trị).

3> Đối với hệ thống thời gian thực Soft , ngay cả khi hệ thống không đáp ứng thời hạn, có thể nhiều hơn một lần (tức là cho nhiều yêu cầu), hệ thống không được coi là đã thất bại. Tuy nhiên, trong trường hợp này, kết quả của các yêu cầu không có giá trị vô giá trị đối với kết quả sau thời hạn của nó, không phải là 0 , đúng hơn là nó giảm dần khi thời gian trôi qua sau thời hạn. Ví dụ: Truyền âm thanh-video.

Đây là một liên kết đến một tài nguyên rất hữu ích.

Người ta thường liên tưởng một số thảm họa lớn với định nghĩa về thời gian thực khó, nhưng điều này không liên quan. Bất kỳ sự thất bại nào trong việc đáp ứng một hạn chế thời gian thực cứng chỉ có nghĩa là hệ thống bị hỏng. Mức độ nghiêm trọng của kết quả khi thứ gì đó được gắn nhãn "hỏng" không quan trọng đối với định nghĩa.

Chắc chắn và mềm chỉ đơn giản là không được tự động tuyên bố bị phá vỡ do không đáp ứng một thời hạn duy nhất.

Để có một ví dụ rõ ràng về thời gian thực khó, từ trang bạn đã liên kết:

Các hệ thống trò chơi điện tử ban đầu như Atari 2600 và đồ họa vector Cinematronics có yêu cầu khó về thời gian thực vì bản chất của đồ họa và phần cứng thời gian.

Nếu một cái gì đó trong vòng lặp tạo video chỉ trễ một thời hạn duy nhất thì toàn bộ màn hình sẽ bị trục trặc, điều này sẽ không thể chấp nhận được, ngay cả khi điều đó là hiếm. Đó sẽ là một hệ thống bị hỏng và bạn sẽ mang nó trở lại cửa hàng để được hoàn lại tiền. Vì vậy, rất khó trong thời gian thực.

Rõ ràng là bất kỳ hệ thống nào cũng có thể phải đối mặt với các tình huống mà nó không thể xử lý, vì vậy cần phải hạn chế định nghĩa nằm trong điều kiện hoạt động dự kiến ​​- lưu ý rằng trong các ứng dụng quan trọng về an toàn, mọi người phải lập kế hoạch cho các điều kiện khủng khiếp ("chất làm mát đã bay hơi", " phanh gấp ”, chứ hiếm khi“ nắng đã nổ ”).

Và đừng quên rằng đôi khi có một điều kiện hoạt động ngầm "trong khi có ai đó đang theo dõi". Nếu không ai thấy bạn vi phạm các quy tắc (hoặc nếu họ làm vậy nhưng họ đã chết cháy trước khi nói với bất kỳ ai), và không ai có thể chứng minh rằng bạn đã vi phạm các quy tắc sau khi thực tế, thì nó giống như thể bạn chưa bao giờ vi phạm các quy tắc!

Cách đơn giản nhất để phân biệt giữa các loại hệ thống thời gian thực khác nhau là trả lời câu hỏi:

Một phản hồi hệ thống bị trì hoãn (sau thời hạn) có còn hữu ích hay không?

Vì vậy, tùy thuộc vào câu trả lời bạn nhận được cho câu hỏi này, hệ thống của bạn có thể được đưa vào một trong các loại sau:

1. Khó : Không và câu trả lời bị trì hoãn được coi là lỗi hệ thống

Đây là trường hợp khi thiếu dead-line sẽ khiến hệ thống không sử dụng được. Ví dụ hệ thống điều khiển xe Hệ thống túi khí sẽ phát hiện ra va chạm và làm phồng túi nhanh chóng. Toàn bộ quá trình mất nhiều hơn hoặc ít hơn một phần hai mươi lăm giây. Vì vậy, ví dụ, nếu hệ thống phản ứng với 1 giây chậm trễ, hậu quả có thể rất nguy hiểm và sẽ chẳng có lợi gì nếu chiếc túi bị bung ra khi chiếc xe đã bị rơi.

2. Công ty : Không, nhưng câu trả lời chậm trễ không cần thiết là hệ thống bị lỗi

Đây là trường hợp bỏ lỡ thời hạn có thể chấp nhận được nhưng nó sẽ ảnh hưởng đến chất lượng của dịch vụ. Ví dụ đơn giản, hãy xem xét một hệ thống mã hóa video. Thông thường, mật khẩu mã hóa được tạo trong máy chủ (đầu video) và được gửi đến hộp giải mã tín hiệu của khách hàng. Quá trình này phải được đồng bộ hóa để thông thường hộp giải mã tín hiệu nhận được mật khẩutrước khi bắt đầu nhận các khung video được mã hóa. Trong trường hợp này, sự chậm trễ có thể dẫn đến video bị trục trặc vì hộp giải mã tín hiệu không thể giải mã các khung hình vì nó chưa nhận được mật khẩu. Trong trường hợp này, dịch vụ (phim, một trận bóng đá thú vị, v.v.) có thể bị ảnh hưởng do không đáp ứng thời hạn. Việc nhận mật khẩu với độ trễ trong trường hợp này không hữu ích vì các khung được mã hóa với cùng một đã gây ra trục trặc.

3. Mềm : Có, nhưng dịch vụ hệ thống đã xuống cấp

Theo mô tả của wikipedia , tính hữu ích của một kết quả sẽ giảm sau thời hạn của nó . Điều đó có nghĩa là, nhận được phản hồi từ hệ thống ngoài thời hạn vẫn hữu ích cho người dùng cuối nhưng tính hữu ích của nó sẽ giảm sau khi đến thời hạn. Một ví dụ đơn giản cho trường hợp này là một phần mềm tự động điều khiển nhiệt độ của một căn phòng (hoặc một tòa nhà). Trong trường hợp này, nếu hệ thống có một số chậm trễ trong việc đọc các cảm biến nhiệt độ, nó sẽ phản ứng chậm một chút khi có sự thay đổi nhiệt độ quá lớn. Tuy nhiên, cuối cùng nó sẽ phản ứng với sự thay đổi và điều chỉnh nhiệt độ cho phù hợp để giữ cho nó không đổi. Vì vậy, trong trường hợp này, phản ứng chậm trễ là hữu ích, nhưng nó làm giảm chất lượng dịch vụ của hệ thống.

Một thời gian thực mềm là dễ nhất để hiểu, trong đó thậm chí nếu kết quả thu được sau thời hạn cuối cùng, kết quả vẫn được coi là hợp lệ.

Ví dụ: Trình duyệt web- Chúng tôi yêu cầu một số URL nhất định, việc tải trang sẽ mất một khoảng thời gian. Nếu hệ thống mất nhiều thời gian hơn dự kiến ​​để cung cấp cho chúng tôi trang đó, trang thu được không được coi là không hợp lệ, chúng tôi chỉ nói rằng hiệu suất của hệ thống không đạt mức cao (hệ thống cho hiệu suất thấp!).

Trong hệ thống thời gian thực cứng , nếu kết quả nhận được sau thời hạn, hệ thống được coi là đã thất bại hoàn toàn.

Ví dụ: Trong trường hợp rô bốt thực hiện một số công việc như dò đường, v.v. Nếu có chướng ngại vật trên đường đi của nó và rô bốt không xử lý thông tin này trong một thời hạn được lập trình nào đó (gần như ngay lập tức!), Thì rô bốt đó được cho là đã thất bại trong nhiệm vụ của nó (hệ thống robot cũng có thể bị phá hủy hoàn toàn!).

Trong hệ thống thời gian thực công ty , nếu kết quả của việc thực hiện quy trình đến sau thời hạn, chúng tôi sẽ loại bỏ kết quả đó, nhưng hệ thống không được coi là đã bị lỗi.

Ví dụ: Liên lạc vệ tinh để giám sát vị trí của đối phương hoặc một số nhiệm vụ khác. Nếu trạm máy tính mặt đất mà vệ tinh gửi các khung định kỳ đến đó bị quá tải và khung (gói) hiện tại không được xử lý kịp thời và khung tiếp theo xuất hiện, thì gói hiện tại (người bị trễ thời hạn) không thành vấn đề việc xử lý đã được thực hiện (hoặc đã hoàn thành một nửa hoặc gần như đã hoàn thành) bị loại bỏ / loại bỏ. Nhưng máy tính mặt đất không được coi là đã hoàn toàn thất bại.

Để định nghĩa "thời gian thực mềm", dễ nhất là so sánh nó với "thời gian thực cứng". Dưới đây chúng ta sẽ thấy rằng thuật ngữ "thời gian thực công ty" tạo thành sự hiểu lầm về "thời gian thực mềm".

Nói một cách ngẫu nhiên, hầu hết mọi người đều có một mô hình tinh thần không chính thức coi thông tin hoặc một sự kiện là "thời gian thực"

• nếu, hoặc trong phạm vi, nó biểu hiện với họ với độ trễ (độ trễ) có thể liên quan đến đơn vị tiền tệ được nhận thức của nó

• tức là, trong một khung thời gian mà thông tin hoặc sự kiện có giá trị thỏa đáng được chấp nhận đối với họ.

Có rất nhiều định nghĩa đặc biệt khác nhau về "thời gian thực cứng", nhưng trong mô hình tinh thần đó, thời gian thực cứng được biểu thị bằng thuật ngữ "nếu". Cụ thể, giả sử rằng các hành động trong thời gian thực (chẳng hạn như nhiệm vụ) có thời hạn hoàn thành, giá trị thỏa đáng có thể chấp nhận được của sự kiện tất cả các nhiệm vụ hoàn thành được giới hạn trong trường hợp đặc biệt mà tất cả các nhiệm vụ đều đáp ứng thời hạn của chúng.

Các hệ thống thời gian thực cứng đưa ra giả định rất mạnh mẽ rằng mọi thứ về ứng dụng, hệ thống và môi trường là tĩnh và được biết đến là 'tiên nghiệm - ví dụ: nhiệm vụ nào, chúng định kỳ, thời gian đến, thời gian, thời hạn của chúng, rằng chúng đã thắng 'không có xung đột tài nguyên và nói chung là sự phát triển theo thời gian của hệ thống. Trong hệ thống điều khiển chuyến bay của máy bay hoặc hệ thống phanh ô tô và nhiều trường hợp khác, những giả định đó thường có thể được thỏa mãn để tất cả các thời hạn sẽ được đáp ứng.

Mô hình tinh thần này đủ tổng quát một cách có chủ ý và rất hữu ích để bao gồm cả thời gian thực cứng và mềm - mềm được dùng cho cụm từ "đến mức độ đó". Ví dụ: giả sử rằng sự kiện hoàn thành nhiệm vụ có giá trị dưới mức tối ưu nhưng có thể chấp nhận được nếu

• không quá 10% nhiệm vụ bị bỏ lỡ thời hạn của chúng
• hoặc không có nhiệm vụ nào bị trễ hơn 20%
• hoặc mức độ trễ trung bình của tất cả các nhiệm vụ không quá 15%
• hoặc sự chậm trễ tối đa trong số tất cả các nhiệm vụ là dưới 10%

Đây là tất cả các ví dụ phổ biến về các trường hợp thời gian thực mềm trong rất nhiều ứng dụng.

Hãy xem xét ứng dụng một nhiệm vụ đưa đón con bạn sau giờ học. Điều đó có thể không có thời hạn thực tế, thay vào đó có một số giá trị đối với bạn và con bạn dựa trên thời điểm sự kiện đó diễn ra. Quá sớm sẽ lãng phí tài nguyên (chẳng hạn như thời gian của bạn) và quá muộn có một số giá trị tiêu cực vì con bạn có thể bị bỏ lại một mình và có khả năng gây hại (hoặc ít nhất là bất tiện).

Không giống như trường hợp đặc biệt thời gian thực cứng tĩnh, thời gian thực mềm chỉ tạo ra các giả định tối thiểu cần thiết cho các ứng dụng cụ thể về các nhiệm vụ và hệ thống, đồng thời dự kiến ​​sẽ có sự không chắc chắn. Để đưa đón con bạn, bạn phải lái xe đến trường và thời gian để làm điều đó tùy thuộc vào thời tiết, điều kiện giao thông, v.v. Bạn có thể bị cám dỗ để cung cấp quá mức hệ thống của mình (nghĩa là cho phép những gì bạn hy vọng là trường hợp xấu nhất là thời gian lái xe) nhưng điều này lại gây lãng phí tài nguyên (thời gian của bạn và chiếm dụng xe của gia đình, có thể từ chối sử dụng bởi các thành viên khác trong gia đình).

Ví dụ đó có vẻ không tốn kém về tài nguyên bị lãng phí, nhưng hãy xem xét các ví dụ khác. Tất cả các hệ thống chiến đấu quân sự đều là thời gian thực mềm. Ví dụ: hãy xem xét thực hiện một cuộc tấn công của máy bay vào một phương tiện mặt đất thù địch bằng cách sử dụng tên lửa được dẫn đường với các bản cập nhật cho nó làm mục tiêu diễn tập. Sự hài lòng tối đa để hoàn thành các nhiệm vụ cập nhật khóa học đạt được bằng một cuộc tấn công hủy diệt trực tiếp vào mục tiêu. Nhưng nỗ lực cung cấp quá mức các nguồn lực để đảm bảo kết quả này thường là quá đắt và thậm chí có thể là không thể. Trong trường hợp này, bạn có thể ít hơn nhưng đủ hài lòng nếu tên lửa tấn công đủ gần mục tiêu để vô hiệu hóa nó.

Rõ ràng là các kịch bản chiến đấu có rất nhiều bất ổn động lực có thể xảy ra mà ban quản lý tài nguyên phải giải quyết. Các hệ thống thời gian thực mềm cũng rất phổ biến trong nhiều hệ thống dân sự, chẳng hạn như tự động hóa công nghiệp, mặc dù rõ ràng các hệ thống quân sự là những hệ thống cấp bách và nguy hiểm nhất để đạt được giá trị thỏa đáng có thể chấp nhận được.

Nền tảng của các hệ thống thời gian thực là "khả năng dự đoán". Trường hợp thời gian thực khó chỉ quan tâm đến một trường hợp đặc biệt có thể dự đoán được - tức là tất cả các nhiệm vụ sẽ đáp ứng thời hạn của chúng và giá trị tối đa có thể đạt được nhờ sự kiện đó. Trường hợp đặc biệt đó được đặt tên là "xác định".

Có một phổ khả năng dự đoán. Tính xác định (thuyết xác định) là một điểm cuối (khả năng dự đoán tối đa) trên phổ khả năng dự đoán; điểm cuối còn lại là khả năng dự đoán tối thiểu (tính không xác định tối đa). Số liệu và điểm cuối của phổ phải được giải thích theo mô hình khả năng dự đoán đã chọn; mọi thứ giữa hai điểm cuối đó là mức độ không thể đoán trước (= mức độ không xác định).

Hầu hết các hệ thống thời gian thực (cụ thể là các hệ thống mềm) có khả năng dự đoán không xác định, ví dụ, về thời gian hoàn thành nhiệm vụ và do đó các giá trị thu được từ các sự kiện đó.

Nói chung (về lý thuyết), khả năng dự đoán, và do đó giá trị thỏa đáng có thể chấp nhận được, có thể đạt được càng gần điểm cuối xác định càng tốt - nhưng ở một mức giá có thể là không thể thực hiện được hoặc quá đắt (như trong chiến đấu hoặc thậm chí có thể trong đón con đi học về).

Thời gian thực mềm yêu cầu lựa chọn mô hình xác suất dành riêng cho ứng dụng (không phải mô hình thường xuyên phổ biến) và do đó mô hình khả năng dự đoán để suy luận về độ trễ sự kiện và giá trị kết quả.

Quay lại danh sách các sự kiện cung cấp giá trị có thể chấp nhận ở trên, bây giờ chúng ta có thể thêm các trường hợp không xác định, chẳng hạn như

• xác suất để không có nhiệm vụ nào bị trễ thời hạn trên 5% là lớn hơn 0,87. (Lưu ý số lượng các tiêu chí lập lịch biểu được thể hiện trong đó.)

Trong ứng dụng phòng thủ tên lửa, với thực tế là trong chiến đấu tấn công luôn có lợi thế hơn phòng thủ, bạn sẽ thích tình huống nào trong hai kịch bản tính toán thời gian thực này:

• bởi vì việc tiêu diệt hoàn hảo tất cả các tên lửa thù địch là rất khó hoặc không thể, hãy chỉ định các nguồn lực phòng thủ của bạn để tối đa hóa xác suất rằng nhiều tên lửa thù địch nhất (ví dụ: dựa trên mục tiêu của chúng) sẽ bị đánh chặn thành công (đánh chặn gần được tính vì nó có thể di chuyển tên lửa thù địch chệch hướng);

• phàn nàn rằng đây không phải là vấn đề tính toán thời gian thực vì nó là động thay vì tĩnh, các khái niệm và kỹ thuật thời gian thực truyền thống không được áp dụng và nó nghe có vẻ khó hơn thời gian thực tĩnh cứng, vì vậy bạn không quan tâm đến nó .

Bất chấp những hiểu lầm khác nhau về thời gian thực mềm trong cộng đồng máy tính thời gian thực, thời gian thực mềm rất chung chung và mạnh mẽ, mặc dù có khả năng phức tạp so với thời gian thực cứng. Các hệ thống thời gian thực mềm như được tóm tắt ở đây có một lịch sử sử dụng thành công lâu dài bên ngoài cộng đồng máy tính thời gian thực .

Để trả lời trực tiếp câu hỏi OP:

Một hệ thống thời gian thực cứng có thể cung cấp các đảm bảo xác định — thông thường nhất là tất cả các tác vụ sẽ đáp ứng thời hạn của chúng, thời gian phản hồi cuộc gọi của hệ thống hoặc gián đoạn sẽ luôn nhỏ hơn x, v.v. — NẾU VÀ CHỈ NẾU các giả định rất mạnh được đưa ra và đúng rằng mọi thứ quan trọng là tĩnh và được biết đến là 'tiên nghiệm (nói chung, những đảm bảo như vậy đối với các hệ thống thời gian thực cứng là một vấn đề nghiên cứu mở ngoại trừ những trường hợp khá đơn giản)

Một hệ thống thời gian thực mềm không đưa ra các đảm bảo mang tính xác định, nó được thiết kế để cung cấp tính kịp thời xác suất hoàn thành và được xác định rõ nhất về mặt phân tích cũng như khả năng dự đoán về tính kịp thời khả thi trong các tình huống năng động hiện tại, theo các tiêu chí dành riêng cho ứng dụng.

Rõ ràng thời gian thực cứng là một trường hợp đặc biệt đơn giản của thời gian thực mềm. Rõ ràng là các đảm bảo không xác định trong phân tích thời gian thực mềm có thể rất phức tạp để cung cấp, nhưng là bắt buộc trong các trường hợp thời gian thực phổ biến nhất (bao gồm cả những trường hợp quan trọng về an toàn nguy hiểm nhất như chiến đấu) vì hầu hết các trường hợp thời gian thực là động không tĩnh.

"Thời gian thực chắc chắn" là một trường hợp đặc biệt chưa được xác định rõ của "thời gian thực mềm". Không cần thuật ngữ này nếu thuật ngữ "thời gian thực mềm" được hiểu và sử dụng đúng cách.

Tôi có một cuộc thảo luận chi tiết hơn, chính xác hơn nhiều về thời gian thực, thời gian thực cứng, thời gian thực mềm, khả năng dự đoán, thuyết xác định và các chủ đề liên quan trên trang web real-time.org của tôi.

thời gian thực - Liên quan đến hệ thống hoặc phương thức hoạt động trong đó việc tính toán được thực hiện trong thời gian thực tế mà quá trình bên ngoài xảy ra, để kết quả tính toán có thể được sử dụng để kiểm soát, giám sát hoặc phản hồi kịp thời với quá trình bên ngoài cách thức. [Tiêu chuẩn IEEE 610.12.1990]

Tôi biết định nghĩa này đã cũ, rất cũ. Tuy nhiên, tôi không thể tìm thấy một định nghĩa mới hơn của IEEE (Viện Kỹ sư Điện và Điện tử).

Hãy xem xét một tác vụ nhập dữ liệu từ cổng nối tiếp. Khi dữ liệu mới đến cổng nối tiếp sẽ kích hoạt một sự kiện. Khi phần mềm phục vụ sự kiện đó, nó sẽ đọc và xử lý dữ liệu mới. Cổng nối tiếp có phần cứng để lưu trữ dữ liệu đến (2 trên MSP432, 16 trên TM4C123) sao cho nếu bộ đệm đầy và nhiều dữ liệu đến thì dữ liệu mới sẽ bị mất. Hệ thống này là thời gian thực cứng, chắc hay mềm?

Đó là thời gian thực khó vì nếu phản hồi muộn, dữ liệu có thể bị mất.

Hãy xem xét một thiết bị trợ thính nhập âm thanh từ micrô, xử lý dữ liệu âm thanh, sau đó xuất dữ liệu ra loa. Hệ thống thường có hiện tượng chập chờn nhỏ và có giới hạn, nhưng đôi khi các tác vụ khác trong máy trợ thính khiến một số dữ liệu bị trễ, gây ra xung nhiễu trên loa. Hệ thống này cứng, chắc hay mềm theo thời gian thực?

Đây là thời gian thực chắc chắn vì nó gây ra lỗi có thể nhận thấy được nhưng ảnh hưởng là vô hại và không làm thay đổi đáng kể chất lượng trải nghiệm.

Xem xét một nhiệm vụ xuất dữ liệu ra máy in. Khi máy in không hoạt động, máy in sẽ kích hoạt một sự kiện. Khi phần mềm phục vụ sự kiện đó, nó sẽ gửi nhiều dữ liệu hơn đến máy in. Hệ thống này cứng, chắc hay mềm theo thời gian thực?

Đó là thời gian thực mềm vì nó phản hồi càng nhanh càng tốt, nhưng giá trị của hệ thống (băng thông là lượng dữ liệu được in ra mỗi giây) giảm dần theo độ trễ.

UTAustinX: Mạng Bluetooth thời gian thực UT.RTBN.12.01x

Có thể định nghĩa bị lỗi.

Từ kinh nghiệm của tôi, tôi sẽ tách biệt hai điều này là phụ thuộc vào phần cứng và phần mềm.

Nếu bạn có 200ms để xử lý ngắt do phần cứng điều khiển, đó là những gì bạn có. Bạn dán 300ms mã vào đó và hệ thống không bị hỏng, nó chưa được phát triển. Bạn sẽ được chuyển ra ngoài trước khi bạn hoàn thành. Mã của bạn không hoạt động hoặc không phù hợp với mục đích. Nhiều hệ thống có thời gian xử lý được xác định rõ ràng. Video, viễn thông, v.v.

Nếu bạn đang viết một ứng dụng theo thời gian thực, điều này có thể được coi là nhẹ nhàng . Nếu hết thời gian, bạn có thể hy vọng sẽ tải ít hơn vào lần sau, bạn có thể điều chỉnh hệ điều hành, thêm bộ nhớ hoặc thậm chí nâng cấp phần cứng. Bạn có các tùy chọn.

Nhìn nó từ góc độ UX là không hữu ích. Một chiếc Skoda có thể không bị hỏng nếu nó trục trặc, nhưng một chiếc BMW chắc chắn sẽ như vậy.

Trong những năm qua, định nghĩa này đã mở rộng đến mức gây bất lợi cho thuật ngữ này. Thời gian thực hiện được gọi là "Khó" là những gì từng được gọi đơn giản là thời gian thực. Vì vậy, các hệ thống trong đó thiếu cửa sổ thời gian (chứ không phải thời hạn một phía) sẽ dẫn đến dữ liệu không chính xác hoặc hành vi không chính xác nên được coi là thời gian thực. Các hệ thống không có đặc tính đó sẽ được coi là không theo thời gian thực.

Điều đó không có nghĩa là thời gian không được quan tâm trong các hệ thống không thời gian thực, nó chỉ có nghĩa là các yêu cầu về thời gian trong các hệ thống như vậy không dẫn đến kết quả về cơ bản là không chính xác.

Hệ thống thời gian thực cứng sử dụng phiên bản lập lịch ưu tiên trước, để các tác vụ quan trọng được lập lịch ngay lập tức, trong khi hệ thống thời gian thực mềm sử dụng phiên bản không ưu tiên của lập lịch ưu tiên, cho phép hoàn thành tác vụ hiện tại trước khi quyền điều khiển được chuyển sang ưu tiên cao hơn tác vụ, gây thêm sự chậm trễ. Do đó, thời hạn nhiệm vụ được tuân thủ nghiêm ngặt trong hệ thống thời gian thực cứng, trong khi trong hệ thống thời gian thực mềm, chúng được xử lý không nghiêm túc.