|
|
1) Особенно настораживает, что это проявляется "Только на протоколе с интенсивным обменом". Извините за банальность, возможно все-таки ошибка в программе, например, переполнение буферов. У Заказчика было установлено устройство, поведение было похожее. Долго искали в аппаратной части, анализировали цепи питания, кивали на то, что у Заказчика в помещении фон. В общем, как это обычно бывает "искали блох". Почему проявлялось только у Заказчика, т.к. у него была реальная среда обитания "железки"-реальные потоки данных, а у нас только имитаторы, в результате портилась одна неприметная на первый взгляд переменная, которая при многократном искажении приводила к переполнению буфера на 1 байт раз примерно сутки.
2) "Проявляется только у заказчика" - помимо того, что было в предыдущем примере, другое устройство всегда ночью давало сбой. Ночью на территории Заказчика находиться было запрещено. Подозрения были на первичное питание и местные каналы связи. Устанваливали UPS - не помогло. Тогда сделали регистратор потока данных (питание общее), чтобы проверить источник данных. Позже, изменив процедуру инициализации, умощнив алгоритм восстановления и запись в логи, выяснилось, что все-таки один раз ночью происходит скачок напряжения, который влияет на БП. UPS при этом не помогал, т.к. нужно было ставить Smart, а у нас был обычный UPS и скачки не выдерживал. А скачок был из-за того, что ночью что-то выключали на территории опытного завода, это чувствовалось во всем районе.
Извините за многословность, но это реальные истории. После такого опыта стараюсь все приложения делать с логами в энергонезависимой памяти, даже очень компактные. Стараюсь всегда проводить анализ при запуске (фиксировать причину ресета), всегда использовать монитор питания и watchdog (если нет внутреннего использую внешний). При этом предупреждаю Заказчика, что есть логи, которые в случае сбоя можно посмотреть, чтобы он знал за ранее об этом, а не после появления проблемы.
E-mail: 
info@telesys.ru
