Моделювання несправностей для вбудованих систем

У мене є схема бездротового датчика з мікроконтролером і модулем приймача 2,4 ГГц , деякі інтегровані датчики з інтерфейсом I²C, порт UART та необхідні дискретні компоненти.

Ця плата призначена для викиду енергії з сонячної (PV) панелі, з батареєю LiPo і зарядним пристроєм для шунтування . Це дозволяє самостійно живити датчик та працювати протягом невизначеного часу, вимагаючи якнайменшого обслуговування.

Я хотів би вивчити можливі несправності, які можуть виникнути в такій системі, і які можуть бути пов’язані зі старінням, порушенням екологічних специфікацій (температура, вологість тощо) або неправильним технічним обслуговуванням (не проблемами проектування / помилками), щоб максимально збільшити термін експлуатації.

Середовище, в якому працює вузол датчика, - це будівля, приклеєна до стелі чи стін. Тож екстремальні температури чи дощ не вважаються.

Що я придумав - це деякі недоліки, які я намагаюся узагальнити:

• Компонент зламаний -> відкрите \ коротке замикання
• Несправність датчика -> неправильні вихідні значення (але як неправильно?)
• Дефект ізоляції через пил \ вода -> збільшення витоку
• Температура поза діапазоном -> ???

Як я можу оцінити, як вузол датчика виходить з ладу і чому?

Занадто багато ступенів свободи, щоб зрозуміти "всі" можливі помилки. Однак існують методи виявлення та усунення несправностей на початку циклу проектування (тобто перед широким випуском).

Активність проектування (попереднє обладнання)

Експертна оцінка - це завжди чудовий спосіб знайти помилки. Попросіть когось іншого проаналізувати ваш дизайн, і будьте готові захищатись від їх запитань (або визнайте, що знайшли помилку, і виправте її!) Немає заміни на пильну перевірку, і свіжі очі часто бачать речі, які втомилися. Це працює як для апаратного, так і програмного забезпечення - схеми можна переглянути так само легко, як і вихідний код.

Що стосується обладнання, як уже говорили інші, DFMEA ( режим відмови дизайну та аналіз ефектів ) є хорошою рекомендацією. Для кожного компонента запитайте себе: «що станеться, якщо це короткочасне» та «що станеться, якщо це вийде з відкритим контуром», і запишіть свій аналіз. Для ІМС також уявіть, що станеться, якщо сусідні штифти будуть укорочені один до одного (паяльні мости тощо)

Для вбудованого програмного забезпечення для виявлення прихованих помилок у коді можуть використовуватися інструменти аналізу статичного коду (MISRA, lint тощо). Такі речі, як плаваючі покажчики та рівність, а не порівняння (= vs ==), є загальними "новичками", які ці інструменти не пропустять.

Письмова теорія роботи також дуже корисна як для апаратного, так і для програмного забезпечення. Теорія функціонування повинна на досить високому рівні описувати, як працює система, як працюють захисні засоби, послідовні дії тощо. Просто кажучи словами, як логіка повинна діяти, часто це призводить до того, що можна зрозуміти, що деякі випадки можуть бути пропущені ("Гм, waitasec, що з цією умовою? ")

Тестування рівня прототипу

Як тільки ви отримаєте обладнання в руки, прийшов час перейти до "роботи".

Після того, як буде зроблений весь теоретичний аналіз, важливо точно охарактеризувати, як працює пристрій у межах специфікації. Це зазвичай називають перевірки перевірки або кваліфікації. Усі допустимі крайності потрібно перевірити.

Ще одна важлива кваліфікаційна діяльність - компонентний аналіз стресу. Кожна деталь оцінюється відповідно до її максимальної напруги / струму / температури у визначеному робочому стані. Щоб забезпечити надійність, слід застосовувати відповідне керівництво, що не відповідає 80% напруги, 70% потужності тощо)

Лише дізнавшись, як все відбувається в нормальних умовах, ви можете почати спекулювати на зовнішніх аномалях чи кількох аномаліях, як ви описуєте. Знову ж таки, модель DFMEA (що трапиться, якщо трапиться X) - хороший підхід. Подумайте про будь-яку можливу річ, яку користувач міг би зробити із пристроєм - короткі виходи, зв’яжіть сигнали разом, розлийте на ньому воду - спробуйте їх і подивіться, що станеться.

Тест HALT (випробування з високим прискореним терміном експлуатації ) також корисний для цих типів систем. Пристрій поміщається в екологічну камеру і здійснюється від мінімальної до максимальної температури, мінімальної та максимальної вхідної та вихідної потужності з вібрацією. Тут знайдуться всілякі проблеми, як електричні, так і механічні.

Це також хороший час, щоб зробити деякі вбудовані тестові тести - виконувати всі входи далеко за очікувані діапазони, надсилати хитрість через UARTs / I2C тощо, щоб знайти діри в логіці. (Біт-удари I2C підпрограми відомі, наприклад, для замикання шини.)

Тестування на страйк - це хороший спосіб продемонструвати стійкість. Вимкніть будь-які функції захисту, такі як перевищення температури, перевантаження та інтенсивно застосовувати напругу, поки щось не зламається. Підніміть пристрій настільки високої температури, наскільки це може тривати, поки щось не виходить з ладу або не виникає певна поведінка. Перевантажуйте агрегат, поки силовий агрегат не вийде з ладу. Якщо якийсь параметр не відповідає лише гіршим умовам, його вказівка ​​маргінальності та певний розгляд проектування доведеться переглянути.

Ви також можете скористатись підходом наступного рівня та фізично перевірити деякі висновки DFMEA - насправді робіть шорти та відкривайте шпильки та бачите, що вибухає.

Подальше читання

У мене передумови перетворення енергії. У нас є галузевий стандарт під назвою IPC-9592A, який є прагненням стандартизувати, як продукти повинні кваліфікуватися з точки зору тестів та як їх робити. Багато видів випробувань та методологій, на які посилається цей документ, легко можуть бути використані в інших електричних дисциплінах.

З декількома пристроями в інтерфейсі I2C у вас є можливість виникнення проблеми "лепетання ідіотів", коли один пристрій виходить з ладу, зависає I2C і вбиває всі інші передачі I2C.

Випробування намоканням у поєднанні з тестуванням навколишнього середовища забезпечують іншу форму аналізу відмов. Використання граничних компонентів, максимальних / мінімальних / коливальних температур, різної вологості, брудних джерел живлення, галасливих середовищ і т.д. тощо протягом певного періоду часу імітує набагато довший період нормального використання. У системі будуть реальні збої, і рівень відмов може бути розрахований.

Найімовірніше, виною є помилки з прошивкою. Все, що я зробив, було декілька.

Переконайтеся, що увімкнено таймер сторожового собаки, і вимагайте, щоб усі критичні повторювані функції відбувалися перед тим, як "погладити собаку". Мені подобається встановлювати прапор у таймері переривання і використовувати його для очищення сторожової собаки в основному циклі.

Перевірте також відновлення прошивки протягом циклів скидання.

Оскільки запуск - це коли відбувається багато відмов, я люблю живитись через реле, потім написати швидкий сценарій циклу живлення, зачекати, коли радіо вкаже пробудження, повторіть. Потім зробіть це протягом 10000 циклів або близько того.

Кілька очевидних:

• Збій акумулятора. Можливо втрата електроліту, що призводить до забруднення електроніки
• Перенапруга від PV-системи
• Він рухається чи знаходиться поблизу техніки? Потім удар / вібрація
• Втрата зв'язку через зовнішнє середовище (дощ / сніг, що поглинає сигнал тощо).

Якщо ви робите FMEA, вам потрібно спершу розглянути, наскільки критична система, перш ніж ви зможете вирішити, що є несправністю.

Я здивований, що ніхто не згадав про тестування прискореного життя та тестування з високим прискореним життям .

Одним з важливих інструментів, якими Ви користуєтесь, є те, що на кожні 10 градусів Цельсія підвищення температури середня надійність знижується на 50 відсотків. Ви можете отримати деяке уявлення про термін служби вашого продукту, випробувавши його при сильно підвищеній температурі. Вам не доведеться тестувати компоненти, які перевищують їх номінальну температуру, щоб скористатися цим.