История изменений
Исправление KivApple, (текущая версия) :
Часто в таких системах есть несколько уровней надёжности.
То, что вот прямо управляет исполнительными механизмами и любой лаг == бабах, программируется на всяких МК с валидацией каждой строчки кода по различным стандартам и жёсткими ограничениям. Никаких линуксов там обычно нет. Максимум, сертифицированная RTOS, либо вообще кооперативная многозадачность (с заранее просчитанным worst case execution time для каждой задачи, чтобы ничего не поехало по таймингам). Отдельные штуки могут вообще на жёсткой логике или даже механике (например, ограничитель угла поворота сервопривода) быть реализованы.
Если хочется ещё больше надёжности, то контроллеров делают несколько и каждое управляющее воздействие выбирается путём голосования, а отбившийся от коллектива инстанс принудительно перезагружают.
Если хочется ещё больше надёжности, то каждый МК из голосующих должен быть от разных вендоров, запрограммирован на разных языках и компиляторах никак не связанными между собой командами программистов.
Однако сверху над этим часто один или даже несколько слоёв user-friendly абстракций, вплоть до системы управления на обычном десктопном/ноутбучном/планшетном железе с тачскринами и большими красивыми кнопками «сделать зашибись». Вот на этом уровне сбой это всего лишь матюки юзера и ожидание, пока терминал перезагрузится (быстро поднятое упавшим не считается). Там будут совстем другие технологии и требования к надёжности.
Вон интерфейс дракона вообще на электроне написан и едва ли кто-то устраивал полную формальную верификацию движка V8. А разгадка проста - электрон рисует рюшечки, а реально жизненноважные вещи делают совсем другие процессоры и программы.
В целом железо общего назначения вполне может выполнять всякие разные задачи - марсолёт от NASA недавно это доказал. Просто вопрос в количестве девяток в числе вероятности, что оно не откажет (при этом при грамотной настройке многие отказы лечатся перезагрузкой). А у каждой подсистемы даже одного автобуса/самолёта/космического корабля эта требуемая величина может отличаться.
Исправление KivApple, :
Часто в таких системах есть несколько уровней надёжности.
То, что вот прямо управляет исполнительными механизмами и любой лаг == бабах, программируется на всяких МК с валидацией каждой строчки кода по различным стандартам и жёсткими ограничениям. Никаких линуксов там обычно нет. Максимум, сертифицированная RTOS, либо вообще кооперативная многозадачность (с заранее просчитанным worst case execution time для каждой задачи, чтобы ничего не поехало по таймингам).
Если хочется ещё больше надёжности, то контроллеров делают несколько и каждое управляющее воздействие выбирается путём голосования, а отбившийся от коллектива инстанс принудительно перезагружают.
Если хочется ещё больше надёжности, то каждый МК из голосующих должен быть от разных вендоров, запрограммирован на разных языках и компиляторах никак не связанными между собой командами программистов.
Однако сверху над этим часто один или даже несколько слоёв user-friendly абстракций, вплоть до системы управления на обычном десктопном/ноутбучном/планшетном железе с тачскринами и большими красивыми кнопками «сделать зашибись». Вот на этом уровне сбой это всего лишь матюки юзера и ожидание, пока терминал перезагрузится (быстро поднятое упавшим не считается). Там будут совстем другие технологии и требования к надёжности.
Вон интерфейс дракона вообще на электроне написан и едва ли кто-то устраивал полную формальную верификацию движка V8. А разгадка проста - электрон рисует рюшечки, а реально жизненноважные вещи делают совсем другие процессоры и программы.
В целом железо общего назначения вполне может выполнять всякие разные задачи - марсолёт от NASA недавно это доказал. Просто вопрос в количестве девяток в числе вероятности, что оно не откажет (при этом при грамотной настройке многие отказы лечатся перезагрузкой). А у каждой подсистемы даже одного автобуса/самолёта/космического корабля эта требуемая величина может отличаться.
Исправление KivApple, :
Часто в таких системах есть несколько уровней надёжности.
То, что вот прямо управляет исполнительными механизмами и любой лаг == бабах, программируется на всяких МК с валидацией каждой строчки кода по различным стандартам и жёсткими ограничениям. Никаких линуксов там обычно нет. Максимум, сертифицированная RTOS, либо вообще кооперативная многозадачность (с заранее просчитанным worst case execution time для каждой задачи, чтобы ничего не поехало по таймингам).
Если хочется ещё больше надёжности, то контроллеров делают несколько и каждое решение выбирается путём голосования, а отбившийся от коллектива инстанс принудительно перезагружают.
Если хочется ещё больше надёжности, то каждый МК из голосующих должен быть от разных вендоров, запрограммирован на разных языках и компиляторах никак не связанными между собой командами программистов.
Однако сверху над этим часто один или даже несколько слоёв user-friendly абстракций, вплоть до системы управления на обычном десктопном/ноутбучном/планшетном железе с тачскринами и большими красивыми кнопками «сделать зашибись». Вот на этом уровне сбой это всего лишь матюки юзера и ожидание, пока терминал перезагрузится (быстро поднятое упавшим не считается). Там будут совстем другие технологии и требования к надёжности.
Вон интерфейс дракона вообще на электроне написан и едва ли кто-то устраивал полную формальную верификацию движка V8. А разгадка проста - электрон рисует рюшечки, а реально жизненноважные вещи делают совсем другие процессоры и программы.
В целом железо общего назначения вполне может выполнять всякие разные задачи - марсолёт от NASA недавно это доказал. Просто вопрос в количестве девяток в числе вероятности, что оно не откажет (при этом при грамотной настройке многие отказы лечатся перезагрузкой). А у каждой подсистемы даже одного автобуса/самолёта/космического корабля эта требуемая величина может отличаться.
Исправление KivApple, :
Часто в таких системах есть несколько уровней надёжности.
То, что вот прямо управляет исполнительными механизмами и любой лаг == бабах, программируется на всяких МК с валидацией каждой строчки кода по различным стандартам и жёсткими ограничениям. Никаких линуксов там обычно нет. Максимум, сертифицированная RTOS, либо вообще кооперативная многозадачность (с заранее просчитанным worst case execution time для каждой задачи, чтобы ничего не поехало по таймингам).
Если хочется ещё больше надёжности, то контроллеров делают несколько и каждое решение выбирается путём голосования, а отбившийся от коллектива инстанс принудительно перезагружают.
Если хочется ещё больше надёжности, то каждый МК из голосующих должен быть от разных вендоров, запрограммирован на разных языках и компиляторах никак не связанными между собой командами программистов.
Однако сверху над этим часто один или даже несколько слоёв user-friendly абстракций, вплоть до системы управления на обычном десктопном/ноутбучном/планшетном железе с тачскринами и большими красивыми кнопками «сделать зашибись». Вот на этом уровне сбой это всего лишь матюки юзера и ожидание, пока терминал перезагрузится (быстро поднятое упавшим не считается). Там будут совстем другие технологии и требования к надёжности.
Вон интерфейс дракона вообще на электроне написан и едва ли кто-то устраивал полную формальную верификацию движка V8. А разгадка проста - электрон рисует рюшечки, а реально жизненноважные вещи делают совсем другие процессоры и программы.
В целом железо общего назначения вполне может выполнять всякие разные задачи - марсолёт от NASA недавно это доказал. Просто вопрос в количестве девяток в числе вероятности, что оно не откажет. А у каждой подсистемы даже одного автобуса/самолёта/космического корабля эта требуемая величина может отличаться.
Исходная версия KivApple, :
Часто в таких системах есть несколько уровней надёжности.
То, что вот прямо управляет исполнительными механизмами и любой лаг == бабах, программируется на всяких МК с валидацией каждой строчки кода по различным стандартам и жёсткими ограничениям. Никаких линуксов там обычно нет. Максимум, сертифицированная RTOS, либо вообще кооперативная многозадачность (с заранее просчитанным worst case execution time для каждой задачи, чтобы ничего не поехало по таймингам).
Если хочется ещё больше надёжности, то контроллеров делают несколько и каждое решение выбирается путём голосования, а отбившийся от коллектива инстанс принудительно перезагружают.
Если хочется ещё больше надёжности, то каждый МК из голосующих должен быть от разных вендоров, запрограммирован на разных языках и компиляторах никак не связанными между собой командами программистов.
Однако сверху над этим часто один или даже несколько слоёв user-friendly абстракций, вплоть до системы управления на обычном десктопном/ноутбучном/планшетном железе с тачскринами и большими красивыми кнопками «сделать зашибись». Вот на этом уровне сбой это всего лишь матюки юзера и ожидание, пока терминал перезагрузится (быстро поднятое упавшим не считается). Там будут совстем другие технологии и требования к надёжности.
Вон интерфейс дракона вообще на электроне написан и едва ли кто-то устраивал полную формальную верификацию движка V8. А разгадка проста - электрон рисует рюшечки, а реально жизненноважные вещи делают совсем другие процессоры и программы.