Pemodelan kesalahan untuk sistem tertanam

Saya memiliki rangkaian sensor nirkabel dengan mikrokontroler dan modul transceiver 2,4 GHz , beberapa sensor terintegrasi dengan antarmuka I²C, port UART, dan komponen diskrit yang diperlukan.

Papan ini dirancang untuk mencari daya dari panel surya (PV), dengan baterai LiPo dan pengisi daya shunt . Ini memungkinkan sensor untuk bekerja sendiri dan beroperasi untuk waktu yang tidak terbatas, membutuhkan perawatan seminimal mungkin.

Saya ingin menjelajahi kemungkinan kesalahan yang dapat terjadi dalam sistem seperti ini, dan itu bisa disebabkan oleh penuaan, pelanggaran spesifikasi lingkungan (suhu, kelembaban dan sebagainya) atau pemeliharaan yang salah (bukan masalah desain / bug), di Untuk memaksimalkan masa operasinya.

Lingkungan di mana simpul sensor beroperasi adalah bangunan, menempel di langit-langit atau dinding. Jadi suhu ekstrim atau hujan tidak dipertimbangkan.

Apa yang saya temukan adalah beberapa kesalahan yang saya coba simpulkan:

• Komponen rusak -> buka \ korsleting
• Sensor rusak -> nilai output salah (tapi bagaimana salah?)
• Mengisolasi isolasi karena debu \ air -> peningkatan kebocoran
• Temperatur di luar kisaran -> ???

Bagaimana saya bisa memperkirakan bagaimana simpul sensor akan gagal, dan mengapa?

Ada terlalu banyak derajat kebebasan untuk memahami "semua" kesalahan yang mungkin terjadi. Namun, ada teknik untuk mengidentifikasi dan mengurangi kesalahan pada awal siklus desain (yaitu sebelum rilis luas).

Kegiatan desain-waktu (pra-perangkat keras)

Tinjauan rekan selalu merupakan cara terbaik untuk menemukan bug. Mintalah orang lain menganalisis desain Anda, dan bersiaplah untuk bertahan terhadap pertanyaan-pertanyaan mereka (atau mengakui bahwa mereka menemukan bug, dan memperbaikinya!) Tidak ada pengganti untuk pengawasan, dan mata yang segar sering melihat hal-hal yang terlewatkan oleh yang lelah. Ini berfungsi baik untuk perangkat keras maupun perangkat lunak - skema dapat ditinjau semudah kode sumber.

Untuk perangkat keras, seperti yang dikatakan orang lain, DFMEA ( Mode Kegagalan Desain dan Analisis Efek ) adalah rekomendasi yang bagus. Untuk setiap komponen, tanyakan pada diri sendiri "apa yang terjadi jika ini keluar" dan "apa yang terjadi jika ini sirkuit terbuka", dan buat catatan analisis Anda. Untuk IC, bayangkan juga apa yang terjadi jika pin yang berdekatan disingkat satu sama lain (jembatan solder, dll.)

Untuk firmware, alat analisis kode statis (MISRA, lint, dll.) Dapat digunakan untuk mengungkap bug tersembunyi dalam kode. Hal-hal seperti pointer mengambang dan kesetaraan-alih-bandingkan (= vs ==) adalah 'oopsi' umum yang tidak akan dilewatkan oleh alat ini.

Teori operasi tertulis juga sangat membantu, baik untuk perangkat keras maupun perangkat lunak. Sebuah teori operasi harus menggambarkan dalam tingkat yang cukup tinggi bagaimana sistem bekerja, bagaimana perlindungan bekerja, pengurutan, dll. Sederhananya dengan kata-kata bagaimana logika harus mengalir sering menyebabkan seseorang menyadari bahwa beberapa kasus mungkin telah terjawab ("Um, waitasec, bagaimana dengan kondisi ini? ")

Pengujian tingkat prototipe

Setelah Anda mendapatkan perangkat keras, saatnya untuk "bekerja".

Setelah semua analisis teoritis dilakukan, penting untuk secara akurat mengkarakterisasi bagaimana perangkat beroperasi dalam spesifikasi. Ini biasanya disebut sebagai pengujian validasi atau kualifikasi. Semua ekstrem yang diijinkan perlu diuji.

Kegiatan kualifikasi penting lainnya adalah analisis tegangan komponen. Setiap bagian dievaluasi terhadap tegangan / arus / suhu maksimum, dalam kondisi operasi yang ditentukan. Untuk memastikan kekokohan, pedoman derating yang tepat harus diterapkan (jangan melebihi 80% tegangan, 70% daya, dll.)

Hanya sekali Anda tahu bagaimana keadaannya dalam kondisi normal Anda dapat mulai berspekulasi tentang kelainan eksternal, atau beberapa kelainan seperti yang Anda gambarkan. Sekali lagi, model DFMEA (apa yang terjadi jika X terjadi) adalah pendekatan yang baik. Pikirkan hal-hal yang mungkin dilakukan pengguna terhadap unit - output pendek, mengikat sinyal bersama, menumpahkan air di atasnya - cobalah, dan lihat apa yang terjadi.

Tes HALT (uji kehidupan yang sangat dipercepat ) juga berguna untuk jenis sistem ini. Unit ini dimasukkan ke dalam ruang lingkungan dan dilaksanakan dari suhu minimum hingga maksimum, input dan output minimum dan maksimum, dengan getaran. Ini akan menemukan segala macam masalah, baik listrik dan mekanik.

Ini juga saat yang tepat untuk melakukan beberapa pengujian fuzz tertanam - gunakan semua input jauh di luar rentang yang diharapkan, kirim omong kosong melalui UARTs / I2C, dll. Untuk menemukan lubang dalam logika. (Rutinitas I2C bit-banged terkenal karena mengunci bus, misalnya.)

Tes perselisihan adalah cara yang baik untuk menunjukkan ketahanan. Nonaktifkan semua fitur perlindungan seperti suhu berlebih, kelebihan beban, dll. Dan berikan tekanan hingga ada yang rusak. Ambil unit setinggi suhu yang dapat pergi sampai sesuatu gagal atau perilaku tidak menentu terjadi. Kelebihan unit sampai powertrain gagal. Jika beberapa parameter gagal hanya sedikit di atas kondisi terburuk, ini merupakan indikasi marginalitas dan beberapa pertimbangan desain mungkin harus ditinjau kembali.

Anda juga dapat mengambil pendekatan tingkat berikutnya dan menguji secara fisik beberapa kesimpulan DFMEA Anda - lakukan celana pendek dan buka dan jepit celana pendek dan lihat apa yang meledak.

Bacaan lebih lanjut

Latar belakang saya adalah konversi daya. Kami memiliki standar industri yang disebut IPC-9592A yang merupakan upaya untuk menstandarisasi bagaimana produk harus memenuhi syarat dalam hal tes apa dan bagaimana mereka harus dilakukan. Banyak jenis tes dan metodologi yang dirujuk oleh dokumen ini dapat dengan mudah digunakan dalam disiplin listrik lainnya.

Dengan beberapa perangkat pada antarmuka I2C Anda memiliki kemungkinan masalah "mengoceh" di mana satu perangkat gagal, babi I2C, dan membunuh semua transmisi I2C lainnya.

Pengujian rendam dikombinasikan dengan pengujian lingkungan akan memberikan bentuk analisis kegagalan yang berbeda. Menggunakan komponen marginal, suhu maksimum / minimum / berfluktuasi, kelembaban yang berbeda, catu daya kotor, lingkungan rf yang bising, dll. Selama periode waktu mensimulasikan periode penggunaan normal yang jauh lebih lama. Sistem akan mengalami kegagalan nyata dan tingkat kegagalan dapat dihitung.

Kesalahan yang paling mungkin adalah bug firmware. Semua yang saya lakukan memiliki beberapa.

Pastikan Anda mengaktifkan pengawas waktu, dan minta semua fungsi berulang yang kritis terjadi sebelum "membelai anjing." Saya suka mengatur bendera di penghitung waktu dan menggunakannya untuk menghapus pengawas di loop utama.

Tes pemulihan firmware Anda melalui siklus reset juga.

Karena startup adalah ketika banyak kegagalan terjadi, saya suka menyalakan melalui relay, kemudian menulis skrip cepat ke siklus daya, tunggu radio untuk menunjukkan bangun, ulangi. Kemudian lakukan ini selama 10.000 siklus atau lebih.

Beberapa yang jelas:

• Kegagalan baterai. Mungkin kehilangan elektrolit yang menyebabkan kontaminasi elektronik
• Tegangan lebih dari sistem PV
• Apakah bergerak atau dekat mesin? Kemudian goncangan / getaran
• Kehilangan komunikasi karena lingkungan eksternal (hujan / salju menyerap sinyal, dll).

Jika Anda melakukan FMEA, Anda harus terlebih dahulu mempertimbangkan seberapa penting sistem itu sebelum Anda dapat memutuskan apa yang merupakan kesalahan.

Saya terkejut bahwa tidak ada yang menyebutkan Pengujian Kehidupan Dipercepat dan Pengujian Kehidupan Sangat Dipercepat .

Salah satu alat penting yang Anda miliki adalah bahwa untuk setiap kenaikan suhu 10 derajat Celcius, keandalan rata-rata berkurang hingga 50 persen. Anda bisa mengetahui kehidupan produk Anda dengan mengujinya pada suhu yang sangat meningkat. Anda tidak perlu menguji komponen di luar suhu terukurnya untuk memanfaatkan ini.