Kritik yaşam veya ölüm sistemlerinde kullanılan yazılımlar nasıl test edilir?


51

Örneğin bir web sitesinin aksine bir uçak, belirli sistemlerdeki herhangi bir hatanın tamamen kabul edilemez olduğu bir sistemdir, çünkü örneğin uçuş izlemedeki hatalar otopilotun arızalanmasına ve dalış yapmasına neden olabilir. Açıkçası, Boeing ve Airbus'taki mükemmel mühendisler otopilotu bir anda bir dalışın tamamen kabul edilebilir ve güvenli bir manevra olduğuna karar vermediğinden emin olmak için kontrol ettiğinden bu olmadı. Ya da belki bilgisayar çöker ve yeni uçakla uçarken bulunan pilotlar artık uçağı uçuramazlar. Elbette, bir çökmeyi önlemek için (hem yazılım hem de uçakta) bu güvenlik sistemlerine dahil edilmiş çeşitli güvenlik prosedürleri ve fazlalıklar var.

Bununla birlikte, diğer taraftan, yazılımların mükemmel olmadığı oldukça açıktır - hem açık kaynaklı hem de kapalı kaynaklı yazılımlar düzenli olarak çöküyor ve yalnızca en basit "Merhaba Dünya" programı başarısız oluyor. Havacılık, tıp ve diğer ölüm kalım endüstrilerindeki yazılım sistemlerini tasarlayan mühendisler, yazılımlarını, başarısız olmayacak şekilde test etmeyi nasıl başarır (ve başarısız olursa, en azından incelikle başarısız olur)?

Umutsuzca hepinizin gidemeyeceğinizi umuyorum: "Ah, Boeing / Airbus / (başka bir şirket) için çalışıyorum ve değil! Bir sonraki uçuş / hastane ziyaretinizde iyi eğlenceler."


8
Therac25 ve Patriot bataryası ile meşgul olmayan, açıkça yeterince iyi olmayan durumları göz önüne alındığında.
Loren Pechtel

@Loren Peki, istisnalar olmadığından şüphem yok. Öte yandan, hiçbir zaman yakın yaralanma / yaralanma / ölümle sonuçlanan önemli bir yazılım hatasıyla karşılaşmak için Airbus A320 (uçakla uçma uçakları) okumamıştım ve 4000 den fazla yapıldı.
waiwai933,

3
"Merhaba Dünya" da başarısız olabilir. lol
xandy

1
@waiwai - aslında, bu bir yıl kadar önce oldu - hatalı bir algılayıcı uçağın çok dik ve durmak üzere olduğunu söyledi. Bilgisayarın uçuş seviyesine dönme girişimi aslında bir dalıştı. Kaza yok, ancak yolcuların yaralanmasına / hasar görmesine ve kabinin etrafına atılan gevşek eşyalara neden oldu.
Tom Clarkson,

6
Pilotlar lisanslı ölümcül mahkumlar kullanmıyorlar mı?
JeffO

Yanıtlar:


29

Endüstriyel kontrollerde çok çalıştım. Havacılık ve uzay gibi görkemli bir endüstride olmak zorunda değildir. Hemen hemen her endüstriyel makine ciddi yaralanma veya ölüme neden olacak kadar potansiyel enerjiye sahiptir. İnsanların yaralandığı zaman etraftaydım. Zamanınızın çoğunu bir ofiste bir masada geçirirseniz, fabrika işlerinin çoğunun ne kadar tehlikeli olacağına şaşıracaksınız (ve kesinlikle yakın zamana kadar). Şimdi daha iyi makine koruma yöntemlerine sahibiz. İşte pratikte nasıl çalıştığı (yetki alanından yetki alanlarına kadar değişmesine rağmen):

ABD'de OSHA standartları ve AB'de de benzer (genellikle daha katı) kurallar vardır. Bunlar genellikle, riskin bir analizini yapmanızı zorunlu kılarak başlar. Bu, tüm tehlikelerin bir listesini çıkardığınız ve daha sonra bir kişinin riske ne sıklıkta maruz kalacağı, riski önlemek için ne kadar kolay olduğu (hıza bağlı vb.) Ve ne sonucun ciddiyeti (kesim, amputasyon, ölüm vb.).

Analizin birçoğunun korunma tehlikeleri ile ilgisi var. Makinenizin etrafına büyük bir kafes yerleştirir ve sıkıca cıvatalarsanız, makinenin bileşenleri korumayı kıramadığında makineniz güvenli kabul edilir. İçeri girmek için bir araca ihtiyacınız varsa, bu bir bakım görevi olarak kabul edilir ve bakım personelinin bir makinede güvenli bir şekilde nasıl çalışacakları konusunda eğitilmiş olmaları gerekir. Ancak gerçekte, çoğu makinenin operatörlerle düzenli etkileşime ihtiyacı vardır, bu nedenle koruma kapılarına veya ışık perdelerine vb. Erişim kapıları koymak zorundayız. Bu kapılar ve ışık perdelerinin izlenmesi ve operatörün kendilerine maruz kaldığı tehlikelere karşı güç sağlama "güvenilir kontrol" şeklinde kapatılmalıdır.

Bu analize dayanarak, risk çeşitli kategorilere ayrılır. Yaygın bir sınıflandırma ölçeği, Kategori 1 ila Kategori 4'tür (EN 954-1 standardına göre). Bu kategorilere dayanarak, yasal olarak belirli bir düzeyde makine koruması ve güvenliği sağlamanız gerekir.

Kategori 4, örneğin, şunu gerektirir:

Bu parçaların her birinde tek bir arıza güvenlik fonksiyonunun kaybına neden olmaz.

Tek hata, güvenlik fonksiyonuna bir sonraki istekte veya ondan önce tespit edilir veya bu mümkün değilse, hataların birikmesi güvenlik fonksiyonunun kaybına neden olmayabilir.

Uygulamada bunu başarmak zor olabilir, ancak Kategori 4'e göre onaylanmış standart bileşenlerin mevcudiyeti ile daha da kolaylaştırılmıştır. Örneğin, bu sistemlerdeki ortak bir bileşen bir Güvenlik Rölesidir. Bunlar sadece mekanik rölelerden daha fazlası:

  • İkili yedekli giriş kanallarını izlemek için tasarlanmıştır, bu nedenle bir arıza durumunu algılayan bir sensöre sahipseniz (koruma kapısı açık gibi), genellikle yedekli devrelerle iki teması vardır. Röle her iki kanalı da izler ve eğer biri açılırsa, aktüatörlerinizin gücünü keser, ancak ikisi de aynı anda düşmezse, o zaman bir hata durumuna girer ve makine onarılana kadar yeniden başlatılamaz .
  • Röle ayrıca bu hatlarda elektriksel darbeler kullanır ve bu sinyalleri çapraz veya kısa devre telleri izlemek için kullanır, böylece bir kablolama hatasını tespit edebilir.
  • Çıkış tarafında, çıkış bobinlerini sürmek için bir çift devre seti kullanır, bu nedenle biri "açık" duruma geçerse, diğeri çıkışın enerjilendirilmesini önler. Ayrıca bunlar izlenir ve bir hata tespit edilirse çalışmayı önler. Bobinlerin kendisi aslında çıkış üzerinde yedekli fiziksel röleler anlamına gelen çift kuvvet kılavuzlu rölelerdir, ayrıca her bir rölenin üzerindeki kontakların fiziksel olarak birbirine bağlanmasını garanti eder; Bunlar da izlenir.
  • Ayrıca, kontrol ettiğiniz yükün dışında normal olarak kapalı bir yardımcı kontağı izlemek için bir girdi içerir. Çıkışı kapatırsa, normalde kapalı kontağı kavramasını görmesi gerekir, yani tekrar açık duruma geçmesine izin vermeden önce motor kontaktörünü kapattığını veya ne olduysa onu doğruladığını doğrulamalıdır.

Anlatabileceğiniz gibi, bunlar karmaşık cihazlardır. Her bir emniyet rölesi için tipik maliyetler 200 ile 600 $ arasındadır. Açıkçası bu cihazlarda yazılım var. Güvenlik rölenizi sertifikalı hale getirmek için, genellikle aşağıdaki gibi bir tasarım uygulamanız gerekir:

  • Farklı tasarımlara dayanarak, genellikle farklı satıcılardan kaynaklanan iki yedek işlemci.
  • Her bir işlemcide çalışan kod, yalıtılmış koşullarda çalışan iki ekip tarafından geliştirilmelidir. Bu, tek bir yazılım hatasının tek bir hata noktası olmasını önler.
  • Her iki işlemcinin çıktısı, güvenlik rölesi arızalarını onaylamak zorundadır.

Makineniz için güvenlik sisteminizi tasarladıktan sonra güvenlik dereceli bileşenleri kullanarak, tasarımı bir Uzman Mühendis tarafından incelenip damgalanmasını sağlamanız gerekir. Sonra makineyi sen yarat. Sonra P.Eng. Tezgâhın konstrüksiyonunu, tasarıma inşa edildiğinden emin olarak inceleyecektir. Belgelenecek ve beklendiği gibi çalıştığından emin olmak için bazı testler yapacaklar. Buna başlangıç ​​öncesi inceleme (PSR) denir ve her yetki alanında yapılmaz. PSR geçtikten sonra, bir operatörün makineyi çalıştırmasına izin verilir.

Son yıllarda güvenlik sistemlerinde bazı devrimler olmuştur. Bir süredir kimse ağ üzerinden güvenlik verilerini iletme konusunda güvenmedi, bu nedenle tipik olarak DeviceNET ve EtherCAT gibi "dağıtılmış I / O sistemleri" denilen şeye sistemin güvenlik kısmında izin verilmedi. Bununla birlikte, son protokoller artık güvenlik cihazlarının bu endüstriyel ağlar üzerinden çalışmasına izin veriyor. Protokoller zaman damgalı mesajlardan ve bağlantının her iki ucunda da çift gereksiz işlemden yararlanır.

Güvenlik röleleri yavaş yavaş dodo kuşu yoluna gidiyor, bunun yerine daha emniyetli bir mantık fonksiyon blok şeması dilinde inşa etmenin bir yolu olan daha karmaşık Emniyet PLC'leri kullanıyor. Yine, bu güvenlik PLC'leri her şeyi gereksiz kullanır. Program onaylandığında, makine hizmete girmeden önce P.Eng. programı damgalar ve program / PLC bir şifre ile kilitlenir. Aynı zamanda, programın bir hashini alır ve hash belgelere kaydedilir (P.Eng'in gerçekten damgaladığı şey).

Artık güvenlik sisteminizi tasarladıktan sonra, makinenin kendisini kontrol etmek için yazdığınız mantık çok rahat bir koltuk olabilir. Programcılar sık ​​sık binlerce dolarlık hasara neden olan makinelere çarpıyor, ancak en azından kimse yaralanmayacak.


20

Rasgele fonksiyonel testlerden ziyade resmi doğrulamaya doğru ciddi bir hareket var.

NASA ve bazı savunma kuruluşları gibi devlet kurumları bu teknolojilere giderek daha fazla para harcamaktadır.

Hala ortalama bir programcı için bir PITA, ancak kritik sistemleri test etmede genellikle daha etkilidirler.

Ayrıca, çok iş parçacıklı kodun doğrulanması gibi şeyler için, akademi'den daha fazla teknik deneme eğilimi vardır.


6
NASA görev kontrolü için temel destek yazılımı yazmış ve eski ve yeni uçuş kodunun parçacıklarını görmüşken, böyle bir vurgu yoktur. Tamam, büyük miktardaki artış nedeniyle, belki NASA her zamankinden daha fazla QC'ye harcama yapıyor, ancak her uygulamaya odaklanan dikkat, uzay programının gençken olduğundan çok daha düşük. Güvenlik açısından kritik konulara hala dikkat çekiliyor, ancak kritik görevler sadece kapsamlı olmayan bir test odasına ihtiyaç duyuyor ve güvenlik açısından kritik bir doğrulama bile zaman içinde azalmış görünüyor.
Ben Voigt

7
Lütfen, resmi doğrulamanın çok etkili olabileceğine ve en yüksek güvenilirlik seviyesinin üretilmesi için zorunlu olacağına katılmıyorum. Yöneticilerin ne kadara mal olduğunu öğrendiler ve daha karmaşık bir yazılımla karşı karşıya kaldıklarında, artık gereklilik başına ve kod satırı başına bu kadar harcama yapmamalarının nedeni oldu. Doğru yaklaşım sistemi bölmek ve kritik kısımları küçük tutmak olacaktır, ancak yönetimin tüm resmi doğrulama sürecini son derece pahalı olarak ilan ettiği sonucu etkili bir şekilde yapıldığını görmedim.
Ben Voigt

2
@Ben Voight: Eğer bir astronot olsaydım, raporunuzdan çok endişe duyardım.
Orbling

1
@Sorbling: Astronotlar muhtemelen sorunun etrafında biraz ağırlık atmalılar, ancak başlangıçta çok fazla risk alan kişiler. Kontrol edebileceğiniz riskleri, sahip olamayacağınız miktardan daha düşük bir seviyeye düşürdüğünüz bir nokta var ve para harcamaya devam etmenin çok etkili olmadığı ve kullanımda gördüğüm yöntemlerin buna uygun olup olmadığı tartışmalı. puan. Bazı yerleştirilmiş yöneticiler kesinlikle yaptıklarına inanıyordu.
Ben Voigt

1
Ve 1960'lardan bu yana resmi doğrulama konusunda devam eden ve devam etmekte olan Dijkstra'yı dinlemediğini düşünmek üzücü. Nietzsche söylediği gibi, “Bazı erkekler ölümünden sonra doğarlar.”
veryfoolish

12

Yazılımın ne olduğuna bağlı. Örneğin, düzlemlerde kritik sistemler için genellikle çift yedekli işlem vardır; Aşırı durumda, kullanılan 2 farklı donanım tasarımı olabilir ve her biri üzerinde çalışacak, birbirinden bağımsız iki adet s / w parçası olabilir. Her ikisi de birbirlerini hesaplar ve kontrol ederler. Bu kusursuz değildir ve oldukça pahalıdır.

Uçak sistemlerinin testi gibi şeylere gelince, bir dizi test yapılır - uçuşla ilgili sistemlerin testi aylar alır ve herhangi bir değişiklik yaparsanız bütün bir dizi yeniden testin yapılması gerekir. Bu genellikle, simüle edilmiş bir motor veya benzeri bir araçla gerçek uçak parçalarıyla (örneğin kokpit) dolu olabilecek bir simülatörde yapılır. Tahmin edebileceğiniz gibi, bu da inşa etmek için aşırı derecede pahalıdır. Değişiklikler resmi bir test programına göre değerlendirilir ve ardından test uçuşlarında gerçek bir uçakta gerçekleştirilir. “Rahatsız edici fonksiyonel” testleri gibi şeyler yapılırken, değiştirilen öğenin normal işlerini yapmasına izin verilir ve zararlı etki olmadığını görmek için her şey kontrol edilir / test edilir. Bu da çok paraya mal olur ve haftalar sürebilir.

Bir uçuş sisteminde çok basit bir değişikliğin gerekli olduğu bir örneği biliyorum - ne kadar küçük olduğuna şaşırmanız çok basit. Ancak bunun yeniden denenmesi> 3 ay sürdü ve 1 milyon dolar gibi bir maliyete mal olacaktı.

Tıbbi yardım aldığınızda, sadece testle değil, geliştirme süreçleriyle ve dokümantasyonla ilgili atlamak için bir dizi yasal engel de vardır.

Tüm bu alanlar, bir web sitesi için biraz PHP kodu hazırlayan yerlerden gelen büyük bir adımdır. Yavaş, özenli, zor, sıkıcı, sıkıcı, titiz ve çok pahalı. Normal gelişim / test maliyetlerinizi alın ve yaklaşık 100 ile çarpın ve işarete yaklaşın.


"Kullanılan 2 farklı donanım tasarımı ve iki ayrı ayrı s / w parça, her biri üzerinde çalışacak" örneği, ilginç olabilir. Katılmıyorum, sadece merak ediyorum.
Brian Carlton

1
@Brian: Örneğin, kilitlenme önleyici fren sistemi kontrol ünitesinde 2 farklı HW, 2 bağımsız olarak geliştirilen SW için bilinen bir örnek bulunabilir. Örneğin, bakınız infineon.com/cms/jp/product/applications/automotive/safety/... tek bir IC iki farklı işlemci mimarisi (8-bit ve 16 bit) kullanır.
Zamanlayıcı,

4
Üç daha iyi. İki kişiyle, sadece bir tanesinin yanlış olduğunu biliyorsun. Üçte bir oy kullanabilirsin. AFAIK, Airbus A380'de iki üreticiden üç uçuş bilgisayarı var.
Jörg W Mittag

Yıllar önce, bu şekilde tasarlanan bazı askeri head-up ekranlarına rastladım. GUESS'im maliyeti nedeniyle bu tekniklerin birçoğunun eskisi kadar kullanılmamasıdır.
Çabuk_aksı


3

Zaten yeterince harika ve bilgilendirici cevaplar aldığınızdan, işte benim düşüncem.

Çok basit - ilk test daima programcılar üzerinde yapılır. Böcek sayısını düşük tutmaya meyillidir ve yalnızca kaliteli programcıların bordroda tutulmasını sağlar.


3

Hayatı kritik olan yazılım, her yerde olduğu gibi "iş gibi görünüyor" yazılımından başka bir standarda test edilmemiştir .

Tüm yatırımlar, programcı olmayanların daha iyi yazılımlar üretmelerine izin verecek projeler için daha önce işe yarayacak gibi görünüyor .

ps İlk yorum yok -1, ancak -1beyanımı sayar her referans için almaktan mutluluk duyarım .

İyi tasarlanmayan veya test edilmeyen kritik yazılımlar için bulduğum her referans için + 1 alabilir miyim? Simson Garfinkel WIRED ile ilgili bir makalede on vakayı belgeliyor .


Bu, ne yazık ki, hepsi çok doğru.
Ben Voigt

Tabii, seni -1 teklifinde bulundum.
Brian Carlton

@Brian Carlton Referans
vermediniz

Peki ya DO-178, GPS için MOPS ... En azından bir yıldan uzun bir süredir test çalışmaları alabilirmiydim. Testin, kodun hatasız olduğundan ve mümkün olan her durumda şartnameye uygun olduğundan emin olmadığına dikkat edin.
jinawee

2

Tüm durumlar için tek bir cevap yok. Yazılımlarının nasıl tasarlanıp test edileceğine karar vermek bireysel üreticiye kalmıştır. Ancak, tüm yazılım geliştirme süreci resmi şartnamelere uygun olmalıdır.

Örneğin tıbbi cihazlar için yazılım oluştururken, tıbbi cihazlar için yazılım IEC 62304 standardına uymalısınız . (Ne yazık ki, sadece ücretsiz olmadığı için wikipedia'ya bağlantı verebilirim). Neredeyse dünyadaki her ülke bu standardın izlenmesini gerektiriyor.

Bu gereksinimlerin ne kadar katı olduğu, zarar riskine bağlıdır. Örneğin, bir yaşam destek cihazı en büyük zarar riskine sahip olacaktır (sistemde başarısız olduğu kesin ölüm), hastalık teşhisi ile çalışan bir sistem daha düşük risk taşır (eğer bir sistem hastalığında kesin olarak teşhis edilmezse olası ölüm).

Ancak bunun temelde söylediği şey, gereksinimlerden yazılıma kadar izlenebilirlik olması gerektiğidir. Yazılım birimi doğrulamaları yapmalısınız. Bu doğrulamanın ne olduğunu belirtmez. Birim testleri olabilir, kod incelemesi olabilir. Daha yüksek riskli cihazlar için, yazılım birimleri arasındaki arayüzleri manuel olarak gözden geçirmelisiniz (anladığım ve hatırladığım kadarıyla). Ve elbette pek çok başka kurallar var. İşinizi belgelemek için çok fazla belge yazmalısınız.

Standart, çevik kalkınmayı yasaklamıyor, ancak okurken şelale gelişimi ile yazılmış gibi görünüyor.

Havacılık, tren, araba vb. Gibi diğer yazılım geliştirme alanları hakkında bir bilgim yok. Ancak benzer diğer kuralların da var olduğunu kabul ediyorum.


1

Bunlarla sınırlı olmamak üzere birçok teknik kullanılmaktadır:

  • resmi tasarım ve / veya doğrulama
  • Dinamik bellek tahsisi gibi süslü programlardan kaçınan katı kodlama standartları
  • çok zorlu kaliteli mühendisler
  • kod inceleme, hata ağaçları, FMECA, ... gibi statik analiz tekniklerini yönetir.

Ancak bir numaralı teknik:

  • TEST YAPMAK

Bir uzay aracının yazılımı, test etmek için ilk etapta tasarlamak ve kodlamaktan daha fazla çaba gerektirir.

Uçaklar, uçağın aşırı duruma getirildiği birkaç yıl süren uçuş testlerinden geçirilir. Bu sadece fiziksel yapıyı değil, yazılımı da test eder.


1

Jack Ganssle tarafından 3/1/2009 12:00 EST tarihlerinde EETimes dergisinde yayınlanan "Perfect software" isimli bir makale bulunmaktadır. Oradan birkaç nokta:

  • "Teorik olarak, Yazılım mükemmel olabilecek tek bileşendir ve bu her zaman başlangıç ​​noktamız olmalıdır." - Jesse Poore tarafından söyleniyor. Web sayfasını takip ederek, normal yazılımdan çok daha ucuza bir yazılımın nasıl mükemmel bir şekilde yapılabileceğini öğreneceksiniz.
  • Çok güvenilir işletim sistemleri sunan endüstriyel sağlayıcılar var. Makale, Mircrium ve Green Hills'ten bahsetti. Micrium'un web sayfasından sonra sertifikalar için standartların bir listesi vardır. Bunlar endüstrinin takip ettiği süreçler ve kurallar olmalıdır. Bu resmi doğrulamaya dayanıyor, ancak teoriden çok sapmış.

İlginç bir şekilde, ticari yazılımla ilgili olarak, Capers Jones tarafından toplanan veriler, "genel olarak yazılımın,% 87'lik bir hata giderme verimliliğine (nakliye öncesi kaldırılan hata yüzdesi) sahip olduğunu gösteriyor. Firmware,% 94 daha iyi bir puan aldı." Bana göre, bunların hiçbiri mükemmel değil. Daha önce bahsedilen bir cevabın yazdığı makale NASA uzay mekiği ekibinin% 99 hata giderme oranına ulaştığını, ancak yaklaşık 400k kod satırı için maliyetin yıllık 35 milyon olduğunu belirtti.

11/1/2009 tarihinde aynı yazarın "Güvenilir sistemler için yazılım" adlı daha ilginç bir makalesi daha alakalı görünmektedir. Bu şekilde özetlenebilir:

  • Gelişme sürecinde, endüstri DO-178B veya IEC61508'i izlemiştir. En geniş kapsama alanı olan testler üzerinde durur Ancak bunun etkinliği hakkında çok az kanıt bulunabilir.
  • Bir sertifika yetkilisi, Sertifikalı Güvenilir Yazılım Sistemleri Komitesi, "Güvenilir Sistemler için Yazılım - Yeterli Kanıtlar" adlı bir kitap yayımladı. Bu iyi bir referans.
  • Kitap temel olarak üç şey ister: [1] Güvenilirlik testleri için açık kurallar koyun. [2] Kurallara aykırı testler, ancak testlerin geliştiriciler tarafından harcanan zamandan daha az zaman alan normal müşteriler veya düzenleyiciler tarafından anlaşılabilir olduğundan emin olun. [3] Yazılım mühendisliği konusunda uzman olduğundan ve problem alanında geliştirme ve test yaptıklarından emin olun.
  • Yazılım tedarikçisi, herhangi bir yazılım arızası için bir garanti veya başka bir çözüm sunmalıdır.
  • Güvenli bir dil kullanın, özellikle C. SPARK değil.
  • Sözleşme yaklaşımı için tasarım SPARK'ın gücünden biridir. Kontrat için tasarım, testleri her işlev / yöntem çağrısına dahil etmek ve her zaman çalışma zamanında yürütmek için önemli bir teknolojidir. Eski günlerde yapılan basit bir iddiadan () daha fazlası, sözleşme aynı zamanda yapısal niyete karşı testler de dahil edebilir ve orijinal geliştiriciler çoğunlukla başka projelere geçtiklerinde, bakım döngüsünün sonraki dönemlerinde ihlalin düşmemesini sağlayamaz. Sözleşmeye yönelik tasarımın çok güvenilir yazılım ürünleri ürettiğine dair kanıtlar var. SPARK ve araçları, sertifikasyon sürecini kolaylaştırmak için sertifikasyon test senaryoları oluşturulmasına yardımcı olmak için kullanılabilir.

Hafızama göre, HP neredeyse on yıl önce sözleşme için tasarım yaptı. Küçük bir ekiple, 500k kod satırı, teslimattan sonra sadece 2 hata bildirildi. Çok etkileyici.

Benim görüşüme göre, güvenilir veya mükemmel bir yazılım ancak maliyetin çok yüksek olmaması durumunda elde edilebilir. Altyapıları veya otomasyonları bir zorunluluktur.


0

Genellikle arıza emniyetli olarak kullanılan bir donanım kilidine sahiptirler.

Örneğin katil robotlar için standart kötü metin kutusu tasarımları her zaman bir kill-switch ile gelir: P


0

Her endüstri, güvenlikle ilgili donanım ve yazılım için test ve dokümantasyon gereksinimlerine sahip kendi düzenleyici kurumlar kümesine sahiptir. Bu PDF'yi UL 1998 standardını tanıtan Underwriters Laboratory (UL) firmasından edinebilirsiniz : http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

Bu belgede UL, CSA ve IEC'den birçok ilgili kişiye referanslar var.

Tipik olarak, emniyetle ilgili yazılım yedek donanım devrelerine sahip olacak veya güvenli çalışma ve emniyetli arıza modları için diğer yedek kontrol özelliklerine sahip olması gerekecektir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.