-
- Отчасти [это таки анализ, а не синтез] эти вопросы рассматриваются в FMEA, но, как понимаете, это все же работа с вероятностями, а там 100% гарантии просто не может быть. Вероятность она и есть вероятность. Вопрос только в количестве девяток в конечном результате анализа. akz(1 знак., 13.12.2022 17:53, ссылка)
- В продолжении моего поста про безопасные объекты, викторина. Химический реактор, реакция при низких температурах (<200С) эндотермическая, при превышении порога экзотермическая . Причем настолько, что может ёбнуть. Температуру надо поддерживать на границе эндотермической реакции. - IBAH(13.12.2022 17:41)
- Если уж "котёл" вспомнили, то... :-) Costic(673 знак., 13.12.2022 16:39, ссылка)
- Это не к алгоритмам. У объекта управления должны быть какие-то
граничные условия. Которые должны (пере)проверяться где-то за
пределами основного алгоритма. Ну и разумеется максимально простая
пошаговая стратегия безопасного аварийного отключения. Для
безопасности этого достаточно. Надёжное и безаварийное
функционирование - это другоетм. - =AlexD=(13.12.2022 10:31)
- "должны (пере)проверяться где-то за пределами основного алгоритма", +++ Больше скажу, сам объект должен исключать возможность управления приводящего к аварии. Простейший пример - реверсивный пускатель с механической блокировкой. - IBAH(13.12.2022 17:50)
- А касательно безаварийного функционирования - нужно строить полную и достоверную математическую модель как объекта управления, так и внешней среды (реакция и воздействие) + добавить хаос человеческого кретинизма. Слишком сложно и не востребовано в большинстве случаев. Ограничиваются частичными моделями + защита. - =AlexD=(13.12.2022 10:41)
- Evgeny, Вы конечно читали скучный и нудный ГОСТ Р МЭК 61508-хх, который в "61508-3" "Требования к программному обеспечению" доходит таки до приложения "Руководство по выбору и методу средств". При этом первые две части вообще начинаются со слова "Общие...". В этом смысле он (ГОСТ) как КО прав, сначала системы, а потом алгоритмы. По ссылке - цикл статей по функциональной безопасности на "Хабре" Chum_A(1 знак., 13.12.2022 10:22, ссылка)
- надо курить "теорию надёжности и построения отказоустойчивых систем (нам читали основы в институте, было очень интересно (специальность "конструирование и производство радиоэлектронных средств (индекс специальности не помню точно, то ли 2301, то ли 2303 :(( Adept(813 знак., 13.12.2022 03:45)
- Это к вопросу об IoT. О вопросах безопасности в этом бизнесе вообще
никто не думает. Это меня просто бесит. Ладно, о компьютерной
безопасности иногда думают. Но о комплексной безопасности никто и
никогда. - Evgeny_CD(13.12.2022 02:56)
- У Adafruit или Sparkfun было компромиссное решение между защищённостью и легковесностью для работы с их облаком: каждая транзакция сопровождалась hexstring-параметром, который представлял собой хэш от остальной посылки и соли. Принимающая сторона тоже выполняла преобразование и обрабатывала только при совпадении. Вроде Гудвин или General показывали свои весы, состыкованные с облаком; я малость покопался(не в проекте, в сервисе). Это как частный элемент затрагиваемый вопросом. Dingo(17 знак., 13.12.2022 04:52, ссылка)
- ничего предосудительного. Это просто дилетантский подход. Одни не
знают как надо делать (те, кто делают), другие (те, кто покупает)
не знают как должно быть :)) на самом деле это всё прокатывает до
точки, когда начнутся массовые отказы с жертвами (были уже вроде
прецеденты, когда при пожарах умные дома не выпускали владельцев)
Это своего рода "естественный отбор" :)) А отсутствие широкого
инженерногол кругозора и навыков системного подхода и анализа,
приводит к тому, что Adept(230 знак., 13.12.2022 03:31 - 03:34)
- Херовый отбор. Сдох тупой юзер - сдохла частичка моего cash flow. Я против. - Evgeny_CD(13.12.2022 03:34)