SciFi (09.02.2026 19:37, просмотров: 73) ответил _Илья на Видел как-то плату вычислительного модуля импортного ПЛК для
ответственных применений.ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้
-
- Это если глюк заложен в прошивку. А если глюком является
"залипание" бита в ячейке памяти или на шине - т.е дефект/сбой
чипа? Программа должна это безопасно обработать. Такой подход
кладут в основу написания кода. - pavel2000(09.02.2026 20:22)
- Сначала надо определиться со списком угроз, потом думать как
минимизировать вероятность ущерба, исходя из имеющихся
возможностей. Универсального рецепта я думаю что нет. В простейшем
случае ограничиваются CRC флэша. Более продвинутые добавляют
контроль осцилляторов. Еще добавляют контроль ошибочных состояний
(туда попадают и аппаратные и алгоритмические ошибки). А вообще
список возможных угроз огромен, даже не выходя за границы м/к. Еще
есть внешняя схема, источники питания, AlexBi(80 знак., 10.02.2026 08:39)
- +1. Я бы даже сказал, оценить разные риски количественно. Пока ни одной цифры не было, как обычно. Так-то легко можно
направить все свои усилия на борьбу с самым маленьким риском просто
потому, что это прикольно. Условно, боролись со сбойным железом, а
в итоге заглючил софт, написанный мизинцем левой ноги. - SciFi(10.02.2026 08:45)
- Полагаю цифр нет и не может быть, т.к. они индивидуальны для
каждого изделия и появляются только после набора статистики.
Поэтому борьба с глюками плохо поддается количественной оценке.
Известна только уязвимость флэша, и та без цифр. Все остальное
плотно покрыто мраком тайны. AlexBi(147 знак., 10.02.2026 09:26)
- Цифры есть. Для МК, как я понимаю, они берутся как % количества гейтов конкретной периферии, ядра, памяти и пр. Условно, есть FIT конкретного МК, АЦП занимает 5%, то FIT для АЦП будет 5% от общего (может не совсем так и у производителя есть методика расчета, но она есть). Соответственно, тест АЦП может выявить проблему АЦП и "программа примет надлежащие меры". Покрыв тестави критические для безопасности блоки можно увеличить метрику надежности системы. Цифры для FuSa-ready Илья(246 знак., 12.02.2026 18:09)
- "Цифр нет" ... "на порядок". Это цифра 10 вообще-то. Уже хорошее
начало. - SciFi(10.02.2026 09:42, +1)
- 10 - в нашем колхозе это ДВЕ цифры! - Kpoк(12.02.2026 19:39)
- Полагаю цифр нет и не может быть, т.к. они индивидуальны для
каждого изделия и появляются только после набора статистики.
Поэтому борьба с глюками плохо поддается количественной оценке.
Известна только уязвимость флэша, и та без цифр. Все остальное
плотно покрыто мраком тайны. AlexBi(147 знак., 10.02.2026 09:26)
- +1. Я бы даже сказал, оценить разные риски количественно. Пока ни одной цифры не было, как обычно. Так-то легко можно
направить все свои усилия на борьбу с самым маленьким риском просто
потому, что это прикольно. Условно, боролись со сбойным железом, а
в итоге заглючил софт, написанный мизинцем левой ноги. - SciFi(10.02.2026 08:45)
- Сначала надо определиться со списком угроз, потом думать как
минимизировать вероятность ущерба, исходя из имеющихся
возможностей. Универсального рецепта я думаю что нет. В простейшем
случае ограничиваются CRC флэша. Более продвинутые добавляют
контроль осцилляторов. Еще добавляют контроль ошибочных состояний
(туда попадают и аппаратные и алгоритмические ошибки). А вообще
список возможных угроз огромен, даже не выходя за границы м/к. Еще
есть внешняя схема, источники питания, AlexBi(80 знак., 10.02.2026 08:39)
- Это если глюк заложен в прошивку. А если глюком является
"залипание" бита в ячейке памяти или на шине - т.е дефект/сбой
чипа? Программа должна это безопасно обработать. Такой подход
кладут в основу написания кода. - pavel2000(09.02.2026 20:22)