У меня есть схема беспроводного датчика с микроконтроллером и приемопередающим модулем 2,4 ГГц , некоторые встроенные датчики с интерфейсом I²C, порт UART и необходимые дискретные компоненты.
Эта плата предназначена для отвода энергии от солнечной (PV) панели, с LiPo-батареей и шунтирующим зарядным устройством . Это позволяет датчику самостоятельно питаться и работать в течение неопределенного времени, что требует минимального технического обслуживания.
Я хотел бы изучить возможные неисправности, которые могут возникать в такой системе, и которые могут быть вызваны старением, нарушением спецификаций окружающей среды (температура, влажность и т. Д.) Или неправильным техническим обслуживанием (не проектными проблемами / ошибками), в Чтобы максимизировать срок его эксплуатации.
Среда, в которой работает сенсорный узел, представляет собой здание, прикрепленное к потолку или стенам. Так что экстремальные температуры или дождь не учитываются.
Я пришел к выводу о некоторых недостатках, которые я пытаюсь обобщить:
- Неисправен компонент -> разомкнут \ короткое замыкание
- Датчик неисправен -> неверные выходные значения (но как неправильно?)
- Дефектная изоляция из-за пыли \ воды -> повышенная утечка
- Температура вне диапазона -> ???
Как я могу оценить, как происходит сбой сенсорного узла и почему?
источник
Ответы:
Существует слишком много степеней свободы, чтобы понять «все» возможные ошибки. Однако существуют методы для выявления и устранения неисправностей на ранних стадиях цикла проектирования (т. Е. До широкого выпуска).
Время разработки (до аппаратного обеспечения)
Рецензирование - это всегда отличный способ найти ошибки. Попросите кого-нибудь еще проанализировать ваш дизайн и быть готовым защитить от своих вопросов (или признать, что они нашли ошибку и исправить ее!). Ничто не заменит внимательного изучения, и свежие глаза часто видят вещи, которые упустили уставшие. Это работает как для аппаратного, так и для программного обеспечения - схемы можно просматривать так же легко, как и исходный код.
Для аппаратного обеспечения, как уже говорили другие, хорошая рекомендация - DFMEA ( режим сбоев проектирования и анализ эффектов ). Для каждого компонента задайте себе вопрос: «что произойдет, если это закоротит», и «что произойдет, если это произойдет по открытой схеме», и запишите свой анализ. Для микросхем также представьте, что происходит, если соседние контакты закорочены друг на друга (паяные перемычки и т. Д.)
Для прошивки могут использоваться инструменты статического анализа кода (MISRA, lint и т. Д.) Для выявления скрытых ошибок в коде. Такие вещи, как плавающие указатели и равенство вместо сравнения (= vs ==), являются общими «упсами», которые эти инструменты не пропустят.
Письменная теория работы также очень полезна как для аппаратного, так и для программного обеспечения. Теория работы должна на довольно высоком уровне описывать, как работает система, как работают средства защиты, последовательность и т. Д. Простое изложение слов о том, как должна проходить логика, часто приводит к пониманию того, что некоторые случаи могли быть пропущены («Гм, waitasec, что насчет этого условия? ")
Тестирование на уровне прототипа
Как только вы получите аппаратное обеспечение, пришло время приступить к «работе».
После того, как весь теоретический анализ сделан, важно точно охарактеризовать, как устройство работает в пределах спецификации. Обычно это называется проверочным тестом или квалификацией. Все допустимые крайности должны быть проверены.
Другим важным квалификационным мероприятием является анализ напряжения компонентов. Каждая деталь оценивается по ее максимальному напряжению / току / температуре в определенных рабочих условиях. Чтобы обеспечить надежность, следует применять соответствующее руководство по снижению номинальных характеристик (не превышайте 80% напряжения, 70% мощности и т. Д.)
Только когда вы знаете, как обстоят дела в нормальных условиях, вы можете начать рассуждать о внешних аномалиях или множественных аномалиях, которые вы описываете. Опять же, модель DFMEA (что происходит, если X случается) является хорошим подходом. Подумайте о том, что пользователь может сделать с устройством - короткие выводы, связать вместе сигналы, пролить на него воду - попробовать и посмотреть, что получится.
HALT-тест ( высоко ускоренный жизненный тест ) также полезен для этих типов систем. Устройство помещается в камеру окружающей среды и работает при минимальной и максимальной температуре, минимальном и максимальном входе и выходе с вибрацией. Это найдет все виды проблем, как электрических, так и механических.
Это также хорошее время для проведения встроенного нечеткого тестирования - используйте все входы, выходящие далеко за ожидаемые диапазоны, отправьте тарабарщину через UART / I2C и т. Д., Чтобы найти дыры в логике. (Например, подпрограммы I2C с побитовым битом печально известны блокировкой шины.)
Страйф-тестирование - это хороший способ продемонстрировать надежность. Отключите все защитные функции, такие как перегрев, перегрузка и т. Д., И применяйте нагрузку, пока что-то не сломается. Поднимите устройство настолько высоко, насколько это возможно, до тех пор, пока что-то не выйдет из строя или не произойдет какое-то странное поведение. Перегружайте агрегат, пока не выйдет из строя силовая установка. Если какой-то параметр выходит из строя только немного выше условий наихудшего случая, его показание маржинальности и некоторые соображения дизайна, возможно, придется пересмотреть.
Вы также можете воспользоваться подходом следующего уровня и физически проверить некоторые из своих выводов DFMEA - на самом деле делайте короткие замыкания и размышления и снимайте короткие замыкания и смотрите, что взрывается.
дальнейшее чтение
Мой фон в преобразовании энергии. У нас есть отраслевой стандарт IPC-9592A, который пытается стандартизировать, как продукты должны быть квалифицированы с точки зрения того, какие тесты и как они должны быть выполнены. Многие из типов испытаний и методологий, упомянутых в этом документе, могут быть легко использованы в других электрических дисциплинах.
источник
С несколькими устройствами на интерфейсе I2C вы можете столкнуться с проблемой «болтовни идиота», когда одно устройство выходит из строя, захватывает I2C и убивает все другие передачи I2C.
Испытания на пропитку в сочетании с испытаниями на воздействие окружающей среды обеспечат другую форму анализа отказов Использование предельных компонентов, максимальных / минимальных / колеблющихся температур, различной влажности, грязных источников питания, шумовой радиочастотной среды и т. Д. В течение определенного периода времени моделирует гораздо более длительный период нормального использования. Система будет иметь реальные сбои, и их можно рассчитать.
источник
Скорее всего, ошибка в ошибках прошивки. У всего, что я сделал, было несколько.
Убедитесь, что у вас включен сторожевой таймер и что все критические повторяющиеся функции должны выполняться перед тем, как «погладить собаку». Мне нравится устанавливать флаг в прерывании таймера и использовать его для очистки сторожевого таймера в основном цикле.
Проверьте восстановление прошивки через циклы сброса тоже.
Поскольку при запуске происходит много сбоев, мне нравится включать питание через реле, затем писать быстрый сценарий для выключения питания, ждать, пока радио покажет пробуждение, повторить. Затем сделайте это за 10000 циклов или около того.
источник
Несколько очевидных:
Если вы выполняете FMEA, вам нужно сначала подумать, насколько критична система, прежде чем вы сможете решить, что является ошибкой.
источник
Я удивлен, что никто не упомянул Ускоренное жизненное испытание и Высоко ускоренное жизненное испытание .
Один из важных инструментов, которыми вы располагаете, заключается в том, что на каждые 10 градусов по Цельсию повышение температуры в среднем снижает надежность на 50 процентов. Вы можете получить представление о сроке службы вашего продукта, протестировав его при значительно повышенной температуре. Вам не нужно тестировать компоненты выше их номинальной температуры, чтобы воспользоваться этим.
источник