Zor gerçek zamanlı, yumuşak gerçek zamanlı ve kesin gerçek zamanlı arasındaki farklar?

Farklı gerçek zamanlı kavramların tanımlarını okudum ve sert ve yumuşak gerçek zamanlı sistemler için verilen örnekler bana mantıklı geliyor. Ancak, sağlam bir gerçek zamanlı sistem için gerçek bir açıklama veya örnek yoktur. Yukarıdaki bağlantıya göre:

Firma: Sık olmayan son teslim tarihi kaçırmalar tolere edilebilir ancak sistemin hizmet kalitesini düşürebilir. Son teslim tarihinden sonra bir sonucun kullanışlılığı sıfırdır.

Firma gerçek zamanlı ile zor veya yumuşak gerçek zamanlı arasında net bir ayrım var mı ve bu ayrımı gösteren iyi bir örnek var mı?

Charles yorumlarda yeni etiketler için tag wiki'leri göndermemi istedi. Sağladığım "gerçek zamanlı kesin sistem" örneğigerçek zamanlıetiketi bir süt sunum sistemiydi. Sistem, son kullanma süresinden sonra süt veriyorsa, sütün "yararlı olmadığı" kabul edilir. Sütsüz tahıl yemeye tahammül edilebilir, ancak deneyimin kalitesi bozulur.

Bu, tanımı ilk okuduğumda kafamda oluşturduğum fikir. Çok daha iyi bir örnek arıyorum ve belki de bu fikrimi geliştirecek firma gerçek zamanının daha iyi bir tanımını arıyorum .

Zor gerçek zamanlı, kesinlikle her son teslim tarihine uymanız gerektiği anlamına gelir. Çok az sayıda sistem bu gereksinime sahiptir. Bazı örnekler nükleer sistemler, kalp pilleri gibi bazı tıbbi uygulamalar, çok sayıda savunma uygulaması, aviyonik vb.

Sert / yumuşak gerçek zamanlı sistemler bazı son teslim tarihlerini kaçırabilir, ancak çok fazla kaçırılırsa, sonunda performans düşecektir. İyi bir örnek, bilgisayarınızdaki ses sistemidir. Birkaç biti kaçırırsanız, önemli değil, ama çok fazla kaçırırsanız ve sonunda sistemi bozarsınız. Benzer sismik sensörler de olabilir. Birkaç veri noktasını kaçırırsanız, önemli değil, ancak verileri anlamlandırmak için çoğunu yakalamanız gerekir. Daha da önemlisi, düzgün çalışmazlarsa kimse ölmeyecek.

Çizgi belirsiz çünkü bir kalp pili bile hastayı öldürmeden küçük bir miktar düşebilir, ancak genel öz budur.

Sıcak ve sıcak arasındaki fark gibi. Gerçek bir bölünme yok, ama bunu hissettiğinizde anlarsınız.

Zor Gerçek Zamanlı

Sert gerçek zamanlı tanım herhangi bir sistem hatası olması son tarih cevapsız düşünüyor. Bu çizelgeleme, zamanlama kısıtlamalarına uyulmamasının can veya mal kaybına neden olduğu kritik görev sistemlerinde yaygın olarak kullanılır.

Örnekler:

• Air France Flight 447, bir sensör arızasının bir dizi sistem hatasına neden olması sonrasında okyanusa düştü. Pilotlar, güncel olmayan alet okumalarına yanıt verirken uçağı durdurdu. 12 mürettebatın tamamı ve 216 yolcu öldü.

• Mars Pathfinder uzay aracı, öncelikli bir ters çevirme sistemin yeniden başlatılmasına neden olduğunda neredeyse kayboldu. Daha düşük öncelikli bir görev tarafından engellendiği için daha yüksek öncelikli bir görev zamanında tamamlanmadı. Sorun düzeltildi ve uzay aracı başarıyla indi.

• Bir Inkjet yazıcı, doğru miktarda mürekkebi kağıdın belirli bir kısmına koymak için kontrol yazılımına sahip bir baskı kafasına sahiptir. Son teslim tarihi kaçırılırsa, yazdırma işi mahvolur.

Firma Gerçek Zamanlı

Firması gerçek zamanlı tanımı seyrek cevapsız süreler için izin verir. Bu uygulamalarda, sistem, yeterince aralıklı oldukları sürece görev başarısızlıklarından kurtulabilir, ancak görevin tamamlanma değeri sıfıra düşer veya imkansız hale gelir.

Örnekler:

• Son teslim tarihinin eksik olduğu robot montaj hatlarına sahip üretim sistemleri, bir parçanın yanlış bir şekilde birleştirilmesine neden olur. Bozulan parçalar, kalite kontrol tarafından yakalanacak kadar seyrek olduğu ve çok maliyetli olmadığı sürece, üretim devam eder.

• Dijital kablo set üstü kutusu, çerçevelerin ekranda görünmesi gereken zaman damgalarının kodunu çözer. Çerçeveler zaman sırasına duyarlı olduğundan, kaçırılan bir son tarih titremeye neden olarak hizmet kalitesini düşürür. Kaçırılan çerçeve daha sonra kullanılabilir hale gelirse, yalnızca daha fazla titreşimin görüntülenmesine neden olur, bu nedenle işe yaramaz. Jitter çok sık meydana gelmezse, izleyici programın tadını çıkarmaya devam edebilir.

Yumuşak Gerçek Zamanlı

Yumuşak gerçek zamanlı tanıma çoğunlukla cevapsız süreler için izin verir ve sürece görevleri zamanında yürütülür olarak sonuçları değerine sahip olmaya devam. Tamamlanan görevler, son tarihe kadar artan değere sahip olabilir ve geçtikten sonra azalan değere sahip olabilir.

Örnekler:

• Hava istasyonlarında sıcaklık, nem, rüzgar hızı vb. Okumak için birçok sensör bulunur. Okumalar düzenli aralıklarla alınmalı ve iletilmelidir, ancak sensörler senkronize değildir. Bir sensör okuması diğerlerine kıyasla erken veya geç olsa da, yeterince yakın olduğu sürece yine de alakalı olabilir.

• Bir video oyun konsolu, bir oyun motoru için yazılım çalıştırır. Görevleri arasında paylaşılması gereken birçok kaynak vardır. Aynı zamanda oyunun doğru bir şekilde oynanması için görevlerin programa göre tamamlanması gerekir. Görevler tamamen zamanında olduğu sürece oyun eğlenceli olacaktır ve değilse biraz gecikebilir.

^{Siewert: Gerçek Zamanlı Gömülü Sistemler ve Bileşenler.
Liu & Layland: Zor Gerçek Zamanlı Bir Ortamda Çoklu Programlama için Planlama Algoritmaları.
Marchand & Silly-Chetto: Yumuşak Atiyodik Görevlerin ve Atlamalı Periyodik Görevlerin Dinamik Zamanlaması.}

Wikipedia sayfasını ve diğer sayfaları gerçek zamanlı bilgi işlemle okuduktan sonra. Şu çıkarımları yaptım:

1> Sabit bir gerçek zamanlı sistem için , sistem Başarısız olduğu kabul edilse bile sistem son teslim tarihini karşılayamazsa.

2> Firma gerçek zamanlı bir sistem için , sistem son teslim tarihini karşılayamasa bile, muhtemelen birden fazla kez (yani birden fazla talep için), sistemin başarısız olduğu kabul edilmez. Ayrıca, taleplere verilen yanıtlar (bir sorguya verilen yanıtlar, bir görevin sonucu, vb.), Söz konusu istek için son tarih geçtikten sonra değersizdir ( Son teslim tarihinden sonra bir sonucun faydası sıfırdır. ). Varsayımsal bir örnek, bir fırtına tahmin sistemi olabilir (eğer bir fırtına gelmeden önce tahmin edilirse, sistem işini yapmıştır, olay meydana geldikten sonra veya gerçekleştiği zaman tahmininin hiçbir değeri yoktur).

3> Soft gerçek zamanlı bir sistem için , sistem son teslim tarihini karşılayamasa bile, muhtemelen birden fazla kez (yani birden fazla istek için), sistemin başarısız olduğu kabul edilmez. Ancak bu durumda, taleplerin sonuçları , son teslim tarihinden sonraki bir sonuç için değersiz bir değer değildir, sıfır değildir , daha ziyade son tarihten sonra zaman geçtikçe azalır. Örn .: Ses-video akışı.

İşte çok yardımcı olan bir kaynağa bağlantı.

Bazı büyük felaketleri zor gerçek zaman tanımıyla ilişkilendirmek popülerdir, ancak bu alakalı değildir. Zor bir gerçek zamanlı kısıtlamayı karşılamadaki herhangi bir başarısızlık, basitçe sistemin bozulduğu anlamına gelir. Bir şey "bozuk" olarak etiketlendiğinde ortaya çıkan sonucun ciddiyeti, tanım için önemli değildir.

Firma ve yumuşak, tek bir son teslim tarihini karşılayamadığı için otomatik olarak kırılmış ilan edilmez.

Bağlandığınız sayfadan gerçek zamanlı zorluğun adil bir örneği için:

Atari 2600 ve Cinematronics vektör grafikleri gibi erken video oyun sistemleri, grafiklerin ve zamanlama donanımının doğası nedeniyle zor gerçek zamanlı gereksinimlere sahipti.

Video oluşturma döngüsündeki bir şey yalnızca tek bir son teslim tarihini kaçırırsa, tüm ekran arızalanır ve bu, nadir olsa bile, dayanılmaz olurdu. Bu bozuk bir sistem olur ve para iadesi için mağazaya geri götürürsünüz. Bu yüzden gerçek zamanlı zor.

Açıktır ki, herhangi bir sistem üstesinden gelemeyeceği durumlara maruz kalabilir, bu nedenle tanımın beklenen çalışma koşullarıyla sınırlandırılması gerekir - güvenlik açısından kritik uygulamalarda insanların korkunç koşullar için plan yapmaları gerektiğine dikkat edin ("soğutucu buharlaştı", " frenler başarısız oldu ", ancak nadiren" güneş patladı ").

Ve unutmayalım ki bazen "herhangi biri izlerken" örtük bir çalışma koşulu vardır. Eğer kimse seni kuralları çiğnediğini görmezse (ya da yaptılarsa ama kimseye söylemeden ateşi ölürlerse) ve kimse gerçeğin ardından kuralları çiğnediğini kanıtlayamazsa, o zaman kuralları hiç çiğnememişsin gibi!

Farklı gerçek zamanlı sistem türleri arasında ayrım yapmanın en basit yolu, soruyu yanıtlamaktır:

Gecikmiş bir sistem yanıtı (son tarihten sonra) hala yararlı mı, değil mi?

Dolayısıyla, bu soru için aldığınız cevaba bağlı olarak, sisteminiz aşağıdaki kategorilerden biri olarak dahil edilebilir:

1. Zor : Hayır ve gecikmiş yanıtlar sistem hatası olarak kabul edilir

Bu, ölü hattı kaçırmanın sistemi kullanılamaz hale getireceği durumdur. Örneğin, arabanın Hava Yastığı sistemini kontrol eden sistem, kazayı algılamalı ve çantayı hızla şişirmelidir. Tüm süreç, saniyenin yirmi beşte birini alıyor. Bu nedenle, eğer sistem örneğin 1 saniyelik gecikmeyle tepki verirse, sonuçlar ölümcül olabilir ve araba çoktan düştüğünde çantanın şişirilmesinin bir faydası olmayacaktır.

2. Firma : Hayır, ancak gecikmiş cevaplar gerekli değildir bir sistem hatası

Bu, son teslim tarihini kaçırmanın tolere edilebilir olduğu durumdur, ancak hizmetin kalitesini etkileyecektir. Basit bir örnek olarak bir video şifreleme sistemini düşünün. Normalde şifreleme parolası , şifrelenmiş video karelerini almaya başlamadan önce oluşturulur . Bu durumda bir gecikme video arızalarına neden olabilir çünkü set üstü kutu henüz şifreyi almadığı için çerçevelerin kodunu çözemez. Bu durumda hizmet (film, ilginç bir futbol maçı vb.) Son teslim tarihine uyulmamasından etkilenebilir. Bu durumda parolayı gecikmeli olarak almak kullanışlı değildir, çünkü aynı şekilde şifrelenen çerçeveler zaten hatalara neden olmuştur. sunucuda (video Head end) oluşturulur ve müşterinin alıcı kutusuna gönderilir. Bu işlem senkronize edilmelidir, böylece normal olarak set üstü kutu şifreyi

3. Yumuşak : Evet, ancak sistem hizmeti düşürüldü

Wikipedia tanımından da anlaşılacağı gibi , bir sonucun kullanışlılığı son teslim tarihinden sonra azalır . Bu, sistemden son teslim tarihinden sonra yanıt almanın son kullanıcı için hala yararlı olduğu, ancak son tarihe ulaştıktan sonra kullanışlılığının azaldığı anlamına gelir. Bu duruma basit bir örnek, bir odanın (veya bir binanın) sıcaklığını otomatik olarak kontrol eden bir yazılımdır. Bu durumda, sistemin sıcaklık sensörlerini okumada bazı gecikmeleri varsa, ani sıcaklık değişikliklerine tepki vermesi biraz yavaş olacaktır. Bununla birlikte, sonunda değişime tepki gösterecek ve örneğin sabit tutmak için sıcaklığı buna göre ayarlayacaktır. Dolayısıyla bu durumda gecikmiş tepki yararlıdır, ancak sistemin hizmet kalitesini düşürür.

Bir yumuşak gerçek zamanlı sonuç başvuru tarihinden sonra elde olsa bile hangi sonuçlar geçerli olarak kabul edilir, anlamak kolay yoldur.

Örnek: Web tarayıcısı- Belirli URL talep ediyoruz, sayfanın yüklenmesi biraz zaman alıyor. Sistemin bize sayfayı sağlaması beklenenden daha uzun sürerse, elde edilen sayfa geçersiz sayılmaz, sadece sistemin performansının yetersiz olduğunu söyleriz (sistem düşük performans verdi!).

İçinde sert gerçek zamanlı sonuç başvuru tarihinden sonra elde edilmesi halinde sistemin, sistem tamamen başarısız olmuş sayılır.

Misal: Bir robotun çizgi izleme vb. Gibi bazı işler yapması durumunda Yolunda bir engel varsa ve robot bu bilgiyi programlanmış bir süre içinde (neredeyse anında!) İşlemezse, robotun başarısız olduğu söylenir. görevinde (robot sistemi de tamamen tahrip olabilir!).

Gelen firma gerçek zamanlı işlem yürütme sonucu başvuru tarihinden sonra gelirse sistemi, biz bu sonuca atmak, ancak sistem başarısız edilmiş olarak adlandırılan değildir.

Örnek: Düşman konumunu izleme veya başka bir görev için uydu iletişimi. Uyduların periyodik olarak çerçeveleri gönderdiği yer bilgisayar istasyonu aşırı yüklenmişse ve mevcut çerçeve (paket) zamanında işlenmemişse ve bir sonraki çerçeve ortaya çıkıyorsa, mevcut paket (son tarihi kaçıran) önemli değil işlemin yapılıp yapılmadığı (veya yarısı tamamlanmış veya neredeyse tamamlanmış) bırakılır / atılır. Ancak yer bilgisayarının tamamen başarısız olduğu söylenmez.

"Yumuşak gerçek zamanlı" tanımlamak için, onu "zor gerçek zamanlı" ile karşılaştırmak en kolayıdır. Aşağıda, "gerçek zamanlı firma" teriminin, "yumuşak gerçek zamanlı" hakkında bir yanlış anlama oluşturduğunu göreceğiz.

Günlük konuşursak, çoğu insan, bilgiyi veya bir olayı "gerçek zamanlı" olarak gören resmi olmayan bir zihinsel modele sahiptir.

• Algılanan para birimiyle ilgili olabilecek bir gecikme (gecikme) ile onlara görünürse veya bu ölçüde

• yani, bilgi veya olayın kendileri için kabul edilebilir derecede tatmin edici değere sahip olduğu bir zaman çerçevesinde.

"Zor gerçek zaman" ın çok sayıda farklı geçici tanımı vardır, ancak bu zihinsel modelde, zor gerçek zamanlı "eğer" terimi ile temsil edilir. Spesifik olarak, gerçek zamanlı eylemlerin (görevler gibi) tamamlanma sürelerine sahip olduğunu varsayarsak, tüm görevlerin tamamlandığı olayın kabul edilebilir tatmin edici değeri, tüm görevlerin son tarihlerini karşıladığı özel durumla sınırlıdır.

Zor gerçek zamanlı sistemler, uygulama, sistem ve ortamla ilgili her şeyin statik olduğu ve önceden bilindiği konusunda çok güçlü varsayımlar yapar - örneğin, hangi görevler, periyodik oldukları, varış süreleri, süreleri, son tarihleri, kazandıkları Kaynak çatışmaları ve genel olarak sistemin zaman evrimi yok. Bir uçak uçuş kontrol sisteminde veya otomotiv fren sisteminde ve diğer birçok durumda, bu varsayımlar genellikle tüm son teslim tarihlerinin karşılanması için karşılanabilir.

Bu zihinsel model kasıtlı olarak ve çok yararlı bir şekilde hem sert hem de yumuşak gerçek zamanı kapsayacak kadar geneldir - yumuşak, "olduğu ölçüde" cümlesiyle uyumludur. Örneğin, görev tamamlamaları olayının yetersiz ancak kabul edilebilir bir değere sahip olduğunu varsayalım.

• görevlerin% 10'undan fazlası son teslim tarihlerini kaçırmaz
• veya hiçbir görev% 20'den fazla gecikmiyor
• veya tüm görevlerin ortalama gecikmesi% 15'ten fazla değildir
• veya tüm görevler arasında maksimum gecikme% 10'dan az

Bunların tümü, pek çok uygulamadaki yumuşak gerçek zamanlı vakaların yaygın örnekleridir.

Çocuğunuzu okuldan sonra tek görevli bir şekilde kucaklamayı düşünün. Muhtemelen bunun gerçek bir son tarihi yoktur, bunun yerine, o olayın ne zaman gerçekleştiğine bağlı olarak siz ve çocuğunuz için bir değer vardır. Çok erken, kaynakları (zamanınız gibi) boşa harcar ve çok geç, çocuğunuz yalnız bırakılabilir ve potansiyel olarak zarar görmesine neden olabilir (veya en azından rahatsız olabilir).

Statik zor gerçek zamanlı özel durumun aksine, yumuşak gerçek zamanlı, yalnızca görevler ve sistem hakkında gerekli minimum uygulamaya özgü varsayımları yapar ve belirsizlikler beklenir. Çocuğunuzu almak için, okula gitmeniz gerekir ve bunu yapmak için gereken zaman, hava durumuna, trafik koşullarına, vb. Bağlı olarak dinamiktir. en kötü durumda sürüş süresi) ama yine de kaynakları boşa harcamaktır (zamanınız ve aile aracını işgal etmek, muhtemelen diğer aile üyelerinin kullanımını reddetmek).

Bu örnek, boşa harcanan kaynaklar açısından maliyetli görünmeyebilir, ancak diğer örnekleri düşünün. Tüm askeri savaş sistemleri yumuşak gerçek zamanlıdır. Örneğin, hedef manevralar sırasında güncellemeler ile güdümlü bir füze kullanarak düşman bir kara aracına uçak saldırısı gerçekleştirmeyi düşünün. Kurs güncelleme görevlerini tamamlamak için maksimum tatmin, hedefe doğrudan yıkıcı bir vuruşla elde edilir. Ancak bu sonuçtan emin olmak için kaynakların gereğinden fazla sağlanması girişimi genellikle çok pahalıdır ve hatta imkansız bile olabilir. Bu durumda, füze hedefe onu etkisiz hale getirecek kadar yakın vurursa daha az ama yeterince tatmin olmuş olabilirsiniz.

Açıktır ki savaş senaryoları, kaynak yönetimi tarafından barındırılması gereken pek çok olası dinamik belirsizliğe sahiptir. Yumuşak gerçek zamanlı sistemler, endüstriyel otomasyon gibi birçok sivil sistemde de çok yaygındır, ancak açıkçası askeri olanlar kabul edilebilir düzeyde tatmin edici bir değer elde etmek için en tehlikeli ve acil olanlardır.

Gerçek zamanlı sistemlerin temel taşı "öngörülebilirlik" tir. Zor gerçek zamanlı durum, yalnızca bir özel öngörülebilirlik durumu ile ilgilenir - yani, görevlerin tamamının son tarihlerini karşılayacağı ve bu olay ile mümkün olan maksimum değere ulaşılacağı. Bu özel duruma "deterministik" adı verilir.

Bir öngörülebilirlik yelpazesi var. Deterministik (determinizm), öngörülebilirlik spektrumundaki bir uç noktadır (maksimum öngörülebilirlik); diğer son nokta, minimum öngörülebilirliktir (maksimum determinizm). Spektrumun metrik ve uç noktaları, seçilen bir öngörülebilirlik modeli açısından yorumlanmalıdır; bu iki uç nokta arasındaki her şey öngörülemezlik dereceleridir (= belirlenimsizlik dereceleri).

Çoğu gerçek zamanlı sistem (yani, yumuşak olanlar), örneğin, görevlerin tamamlanma süreleri ve dolayısıyla bu olaylardan kazanılan değerlerin deterministik olmayan tahmin edilebilirliğine sahiptir.

Genel olarak (teoride), öngörülebilirlik ve dolayısıyla kabul edilebilir tatmin edici değer, deterministik son noktaya gerektiği kadar yakın yapılabilir - ancak fiziksel olarak imkansız veya aşırı pahalı olabilecek bir fiyatla (savaşta olduğu gibi veya belki de çocuğunuzu okuldan almak).

Yumuşak gerçek zamanlı, uygulamaya özgü bir olasılık modeli seçimi (yaygın sıklık modeli değil) ve dolayısıyla olay gecikmeleri ve sonuç değerleri hakkında mantık yürütmek için öngörülebilirlik modeli gerektirir.

Kabul edilebilir değer sağlayan yukarıdaki olaylar listesine geri dönersek, şimdi aşağıdaki gibi deterministik olmayan durumlar ekleyebiliriz:

• hiçbir görevin son tarihini% 5'ten fazla kaçırmama olasılığı 0,87'den fazladır. (Burada ifade edilen programlama kriterlerinin sayısını not edin.)

Bir füze savunma uygulamasında, hücumun her zaman savunmaya göre avantaja sahip olduğu gerçeği göz önüne alındığında, bu iki gerçek zamanlı hesaplama senaryosundan hangisini tercih edersiniz:

• Tüm düşman füzelerin mükemmel bir şekilde imha edilmesi çok olası veya imkansız olduğundan, en çok tehdit oluşturan (örneğin hedeflerine göre) düşman füzelerinin başarılı bir şekilde yakalanma olasılığını en üst düzeye çıkarmak için savunma kaynaklarınızı tahsis edin (yakın müdahale önemlidir, çünkü düşman füzeyi rotasının dışına hareket ettirebilir);

• Bunun gerçek zamanlı bir hesaplama problemi olmadığından şikayet edin, çünkü statik yerine dinamiktir ve geleneksel gerçek zamanlı kavramlar ve teknikler uygulanmaz ve statik gerçek zamanlıdan daha zor göründüğünden, bununla ilgilenmezsiniz .

Gerçek zamanlı bilgi işlem topluluğundaki yumuşak gerçek zamanlıyla ilgili çeşitli yanlış anlamalara rağmen, yumuşak gerçek zamanlı, çok genel ve güçlüdür, ancak gerçek zamanlıya kıyasla potansiyel olarak karmaşıktır. Burada özetlendiği gibi yumuşak gerçek zamanlı sistemler, gerçek zamanlı bilgi işlem topluluğu dışında uzun ve başarılı bir kullanım geçmişine sahiptir .

OP sorusuna doğrudan cevap vermek için:

Zor gerçek zamanlı bir sistem belirleyici garantiler sağlayabilir - en yaygın olarak tüm görevler son teslim tarihlerini karşılayacaktır, kesinti veya sistem çağrısı yanıt süresi her zaman x'ten az olacaktır, vb. - YALNIZCA çok güçlü varsayımlar yapılırsa ve doğruysa önemli olan her şey statiktir ve a 'priori olarak bilinir (genel olarak, zor gerçek zamanlı sistemler için bu tür garantiler oldukça basit durumlar dışında açık bir araştırma problemidir)

Yumuşak gerçek zamanlı bir sistem deterministik garantiler vermez, uygulamaya özel kriterlere göre mevcut dinamik koşullar altında mümkün olan olası en iyi analitik olarak belirlenmiş ve başarılmış olasılıksal zamanlama ve zamanlama öngörülebilirliğini sağlamayı amaçlamaktadır.

Açıkçası zor gerçek zaman, yumuşak gerçek zamanın basit ve özel bir durumudur. Açıkçası yumuşak gerçek zamanlı analitik deterministik olmayan güvencelerin sağlanması çok karmaşık olabilir, ancak en yaygın gerçek zamanlı durumlarda (savaş gibi en tehlikeli güvenlik açısından kritik olanlar dahil) zorunludur çünkü çoğu gerçek zamanlı durum dinamik değildir statik.

"Gerçek zamanlı gerçek zamanlı", kötü tanımlanmış, "yumuşak gerçek zamanlı" özel bir durumdur. "Yumuşak gerçek zamanlı" terimi anlaşılır ve doğru kullanılırsa bu terime gerek yoktur.

Realtime.org web sitemde gerçek zamanlı, zor gerçek zamanlı, yumuşak gerçek zamanlı, öngörülebilirlik, belirlenimcilik ve ilgili konular hakkında çok daha ayrıntılı bir tartışmam var.

gerçek zamanlı - Hesaplama sonuçlarının harici süreci kontrol etmek, izlemek veya zamanında yanıtlamak için kullanılabilmesi için, hesaplamanın harici bir sürecin gerçekleştiği gerçek zamanda gerçekleştirildiği bir sistem veya çalışma modu ile ilgili tavır. [IEEE Standardı 610.12.1990]

Bu tanımın eski, çok eski olduğunu biliyorum. Bununla birlikte, IEEE (Elektrik ve Elektronik Mühendisleri Enstitüsü) tarafından daha yeni bir tanım bulamıyorum.

Seri bağlantı noktasından veri giren bir görev düşünün. Yeni veri geldiğinde, seri bağlantı noktası bir olayı tetikler. Yazılım bu olaya hizmet verdiğinde, yeni verileri okur ve işler. Seri bağlantı noktasında, gelen verileri depolamak için bir donanım bulunur (MSP432'de 2, TM4C123'te 16), böylece arabellek doluysa ve daha fazla veri gelirse yeni veriler kaybolur. Bu sistem zor, sağlam veya yumuşak gerçek zamanlı mı?

Öyle sert gerçek zamanlı tepki gecikirse, veri kaybolmuş olabilir çünkü.

Bir mikrofondan ses girişi yapan, ses verilerini işleyen ve ardından verileri bir hoparlöre veren bir işitme cihazı düşünün. Sistem genellikle küçük ve sınırlı bir titreşime sahiptir, ancak bazen işitme cihazındaki diğer görevler bazı verilerin gecikmesine neden olarak hoparlörde gürültü darbesine neden olur. Bu sistem zor, sağlam mı yoksa yumuşak gerçek zamanlı mı?

Kesin gerçek zamanlıdır çünkü algılanabilen bir hataya neden olur, ancak etkisi zararsızdır ve deneyimin kalitesini önemli ölçüde değiştirmez.

Verileri bir yazıcıya gönderen bir görev düşünün. Yazıcı boştayken bir olay tetikler. Yazılım bu olaya hizmet verdiğinde, yazıcıya daha fazla veri gönderir. Bu sistem zor, sağlam mı yoksa yumuşak gerçek zamanlı mı?

Bu ise , yumuşak gerçek zamanlı daha hızlı tepkileri daha iyi, ama sistemin değeri (bant genişliği saniyede baskılı veri miktarını) gecikmeyle azalır, çünkü.

UTAustinX: UT.RTBN.12.01x Gerçek Zamanlı Bluetooth Ağları

Belki tanım hatalı.

Deneyimlerime göre, ikisini donanım ve yazılıma bağlı olarak ayırırdım.

Donanım odaklı bir kesintiye hizmet etmek için 200 ms'niz varsa, sahip olduğunuz şey budur. Oraya 300ms kod yapıştırıyorsunuz ve sistem bozulmamış, geliştirilmemiştir. Bitirmeden değiştirileceksin. Kodunuz çalışmıyor veya amaca uygun değil. Pek çok sistemin katı tanımlanmış işlem süreleri vardır. Video, telekom vb.

Gerçek zamanlı bir uygulama yazıyorsanız , bu yumuşak kabul edilebilir . Zamanınız tükenirse, bir dahaki sefere daha az yük almayı umabilirsiniz, işletim sistemini ayarlayabilir, biraz bellek ekleyebilir ve hatta donanımı yükseltebilirsiniz. Seçenekleriniz var.

Buna UX perspektifinden bakmak yardımcı olmaz. Bir Skoda arızalanırsa kırılmayabilir, ancak bir BMW kesinlikle olacaktır.

Tanım, yıllar içinde terimin aleyhine genişledi. Şimdi "Zor" gerçek zamanlı olarak adlandırılan şey, eskiden basitçe gerçek zamanlı olarak adlandırılan şeydi. Bu nedenle, eksik zamanlama pencerelerinin (tek taraflı son tarihler yerine) yanlış verilere veya yanlış davranışlara neden olacağı sistemler gerçek zamanlı olarak değerlendirilmelidir. Bu özelliği olmayan sistemler gerçek zamanlı olmayan sistemler olarak kabul edilir.

Bu, zamanın gerçek zamanlı olmayan sistemlerle ilgilenmediği anlamına gelmez, sadece bu tür sistemlerdeki zamanlama gereksinimlerinin temelde yanlış sonuçlarla sonuçlanmadığı anlamına gelir.

Sabit gerçek zamanlı sistemler, öncelikli zamanlamanın önleyici sürümünü kullanır, böylece kritik görevler hemen planlanır, oysa yumuşak gerçek zamanlı sistemler, kontrol daha yüksek önceliğe aktarılmadan önce mevcut görevin tamamlanmasına izin veren öncelikli zamanlamanın önleyici olmayan sürümünü kullanır. görev, ek gecikmelere neden olur. Bu nedenle, görev son tarihleri ​​Hard gerçek zamanlı sistemlerde kritik bir şekilde takip edilirken, yumuşak gerçek zamanlı sistemlerde o kadar ciddi bir şekilde ele alınmaz.