Gömülü sistemler için hata modelleme


10

Mikrodenetleyicili kablosuz sensör devresi ve 2.4 GHz alıcı-verici modülü , I²C arayüzlü bazı entegre sensörler, bir UART portu ve gerekli ayrık bileşenler var.

Bu kart, bir LiPo pil ve bir şönt şarj cihazı ile bir güneş (PV) panelinden enerji atmak için tasarlanmıştır . Bu, sensörün kendi kendine güç almasını ve mümkün olan en az bakım gerektiren süresiz çalışmasını sağlar.

Böyle bir sistemde meydana gelebilecek ve yaşlanma, çevresel özelliklerin ihlali (sıcaklık, nem vb.) Veya yanlış bakımdan (tasarım sorunları / hatalar değil) kaynaklanabilecek olası hataları araştırmak istiyorum. çalışma ömrünü en üst düzeye çıkarmak için.

Sensör düğümünün çalıştığı ortam, tavana veya duvarlara yapıştırılmış bir binadır. Bu nedenle aşırı sıcaklıklar veya yağmur dikkate alınmaz.

Ortaya koyduğum bazı hatalar:

  • Bileşen bozuk -> açık \ kısa devre
  • Sensör arızalı -> yanlış çıkış değerleri (ama ne kadar yanlış?)
  • Toz \ su nedeniyle bozulan izolasyon -> artan sızıntı
  • Sıcaklık aralık dışında -> ???

Sensör düğümünün nasıl arızalanacağını nasıl tahmin edebilirim ve neden?


Sensörün, hayal edebileceğiniz herhangi bir arızaya neden olabilecek kim / ne olursa olsun ve mekanik olarak kırılabileceğini unutmayın.
Sharptooth

Evet, şu an da bir sınır durum olduğu için kurcalamayı da ihmal ediyordum ... ama herhangi bir öneri hoş geldiniz!
clabacchio

güneş paneli mucking ve yeterli güç üretmiyor. Eminim bazı MEMS cihazlarındaki yaşam çevreye çok duyarlıdır ... tahmin.
Kenny

Çalışmanızın amacı nedir? Örneğin, hepsi farklı yaklaşımlar gerektiren başarısızlık oranını azaltmak, başarısızlık etkisini azaltmak (yumuşak başarısız), riski azaltmak (açık bir şekilde devam etmek yerine başarısızlığı tespit etmek) vb.
Wouter van Ooijen

Yanıtlar:


7

Olası hataları “tüm” olarak anlamak için çok fazla serbestlik derecesi vardır. Bununla birlikte, hataları tasarım döngüsünün erken aşamalarında (yani geniş sürümden önce) tanımlamak ve azaltmak için teknikler vardır.

Tasarım zamanı aktiviteleri (donanım öncesi)

Akran değerlendirmesi her zaman hataları bulmak için harika bir yoldur. Bir başkasının tasarımınızı analiz ettirmesini ve sorularına karşı savunmaya hazır olmasını sağlayın (veya bir hata bulduklarını ve düzelttiklerini kabul edin!) İncelemenin yerini tutamaz ve taze gözler sık ​​sık yorgun olanlar tarafından kaçırılan şeyleri görür. Bu hem donanım hem de yazılım şemaları için geçerlidir - kaynak kodu kadar kolay incelenebilir.

Donanım için, diğerlerinin söylediği gibi, bir DFMEA ( Tasarım Hatası Modu ve Efekt Analizi ) iyi bir öneri. Her bileşen için, kendinize "bu kısa devre yaparsa ne olur" ve "açık devre giderse ne olur" sorun ve analizinizin kaydını tutun. IC'ler için, bitişik pimler birbirlerine kısa devre yaparsa ne olacağını hayal edin (lehim köprüleri, vb.)

Ürün yazılımı için, koddaki gizli hataları ortaya çıkarmak için statik kod analiz araçları (MISRA, tiftik vb.) Kullanılabilir. Kayan işaretçiler ve karşılaştırmak yerine eşitlik (= vs ==) gibi şeyler, bu araçların kaçırmayacağı yaygın 'oopsiler'.

Yazılı bir çalışma teorisi, hem donanım hem de yazılım için çok yararlıdır. Bir operasyon teorisi, sistemin nasıl çalıştığını, korumaların nasıl çalıştığını, sıralamayı vb. Oldukça yüksek bir seviyede tanımlamalıdır. Basitçe mantığın nasıl akması gerektiği kelimelerine yer vermek, bazı vakaların kaçırılmış olabileceğini fark etmeye neden olur ("Um, waitasec, bu durum ne olacak? ")

Prototip seviye testi

Donanımı elinize aldıktan sonra, "işe" gitme zamanı.

Tüm teorik analizler yapıldıktan sonra, cihazın spesifikasyonlar içinde nasıl çalıştığını doğru bir şekilde karakterize etmek çok önemlidir . Buna yaygın olarak geçerlilik testi veya yeterlilik denir. İzin verilen tüm uçların test edilmesi gerekir.

Bir diğer önemli yeterlilik faaliyeti bileşen stres analizidir. Her parça, tanımlanmış bir çalışma koşulunda maksimum voltaj / akım / sıcaklığına göre değerlendirilir. Sağlamlığı sağlamak için uygun bir değer kaybı kılavuzu uygulanmalıdır (voltajın% 80'ini, gücün% 70'ini vb. Aşmayın).

Sadece normal koşullar altında işlerin nasıl olduğunu öğrendikten sonra harici anormaller veya tanımladığınız gibi birden fazla anormal hakkında spekülasyon yapmaya başlayabilirsiniz. Yine, DFMEA modeli (X olursa ne olur) iyi bir yaklaşımdır. Kullanıcının birime yapabileceği her şeyi düşünün - kısa çıkışlar, sinyalleri birbirine bağlayın, üzerine su dökün - deneyin ve neler olduğunu görün.

HALT testi ( yüksek hızlandırılmış ömür testi ) de bu tip sistemler için yararlıdır. Ünite bir çevre odasına konur ve titreşim ile minimumdan maksimum sıcaklığa, minimum ve maksimum giriş ve çıkışa uygulanır. Bu, hem elektrikli hem de mekanik her türlü sorunu bulacaktır.

Bu aynı zamanda bazı gömülü fuzz testleri yapmak için iyi bir zamandır - tüm girişleri beklenen aralıkların ötesinde kullanın, mantıktaki delikleri bulmak için UART / I2C vb. Aracılığıyla anlamsızca gönderin. (Örneğin, Bit-Bang I2C rutinleri veri yolunu kilitlemekle meşhurdur.)

Strife testi sağlamlığı göstermenin iyi bir yoludur. Aşırı sıcaklık, aşırı yük vb. Koruma özelliklerini devre dışı bırakın ve bir şey kırılıncaya kadar stres uygulayın. Üniteyi, bir şey başarısız oluncaya veya bazı düzensiz davranışlar oluşana kadar gidebileceği kadar yüksek sıcaklıkta alın. Güç aktarma organı arızalanana kadar üniteyi aşırı yükleyin. Bazı parametreler en kötü durum koşullarının biraz üzerinde başarısız olursa, marjinallik göstergesi ve bazı tasarım unsurlarının yeniden gözden geçirilmesi gerekebilir.

Ayrıca, bir sonraki seviye yaklaşımı benimseyebilir ve bazı DFMEA sonuçlarınızı fiziksel olarak test edebilirsiniz - aslında şort ve açıklıkları ve pin şortlarını yapın ve neyin patladığını görün.

daha fazla okuma

Geçmişim güç dönüşümünde. IPC-9592A adlı bir endüstri standardımız var; bu, ürünlerin hangi testler ve nasıl yapılması gerektiğine göre nasıl nitelikli hale getirileceğini standartlaştırma çabasıdır. Bu dokümanda atıfta bulunulan test ve metodolojilerin çoğu, diğer elektriksel disiplinlerde kolayca kullanılabilir.


6

I2C arabirimindeki birden fazla cihazla, bir cihazın arızalandığı, I2C'yi domuzladığı ve diğer tüm I2C yayınlarını öldürdüğü "gevezelik salak" problemine sahip olabilirsiniz.

Islanma testi, çevresel testlerle birleştirildiğinde farklı bir arıza analizi şekli sağlar. Belirli bir süre boyunca marjinal bileşenler, maksimum / minimum / dalgalanma sıcaklıkları, farklı nemlilikler, kirli güç kaynakları, gürültülü ortamlar vb. Kullanılması normal kullanımın çok daha uzun bir dönemini simüle eder. Sistemde gerçek arızalar olacaktır ve arıza oranları hesaplanabilir.


3

Büyük olasılıkla yazılım hatalarıdır. Yaptığım her şeyin birkaç tane var.

Bir bekçi zamanlayıcısının etkin olduğundan emin olun ve "köpeği sevmeden" önce tüm kritik tekrarlanan işlevlerin gerçekleşmesini gerektirir. Zamanlayıcı kesintisinde bir bayrak ayarlamayı ve ana döngüdeki bekçi köpeğini temizlemek için kullanmayı seviyorum.

Ürün yazılımı kurtarma işleminizi sıfırlama döngüleri üzerinde de test edin.

Başlangıç ​​çok fazla hata oluştuğu için, bir röleden güç almayı seviyorum, sonra güç döngüsüne hızlı bir komut dosyası yazıyorum, radyonun uyandırmayı göstermesini bekleyin, tekrarlayın. Sonra bunu 10000 döngü kadar yapın.


Testte çok ilginç bir güç. Son şirketimin aptal bir vericiyle senkronize halde kalması için birkaç yıl boyunca çalışması gereken bir proje vardı ve bu süre zarfında hata veremedi, ürün yazılımı hatalarını kaldırmak muhtemelen en zor kısımdı.
Kortuk

2

Birkaç bariz:

  • Pil arızası. Elektroniğin kirlenmesine yol açan elektrolitin kaybı
  • PV sisteminden aşırı gerilim
  • Hareket ediyor mu yoksa makinelerin yakınında mı? Sonra şok / titreşim
  • Dış ortam nedeniyle iletişim kaybı (sinyali emen yağmur / kar, vb.).

Bir FMEA yapıyorsanız, neyin hata oluşturduğuna karar vermeden önce sistemin ne kadar kritik olduğunu düşünmeniz gerekir.


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.