0xFF

Концевики по определению срабатывают в конечных положениях. А пациент давится, потенциально, в любых. Да и не обязательно пациент. Может возникнуть произвольная неисправность и попытка применить силу приведёт к тому, что что-нибудь будет оторвано, помято и т.п. И "момент на валу огонь", но и давится пациент не граммами, а десятками-сотнями килограмм. И почему собственно огонь. Здесь уже есть проблема в системе управления. Рассмотрим самый примитивный вариант: асинхронный двигатель включенный через фазосдвигающий конденсатор или неуправлеяемый "частотник". Способен развить момент только на номинальной скорости, когда оно как раз не нужно (основные затраты энергии -- разгон-торможение, ведь никакую работу аппарат не выполняет). Поэтому когда начинает давиться пациент, то его давит не только инерцией тонны свинца, но и ещё всей мощью двигателя, выбранной с большим запасом (ибо ему преодолевать трение покоя в момент пуска, а график момент-обороты все видели...) В системе управления предусмотрены, допустим, только "концевики", которые ничем помочь не могут. Будет кровь, мясо и размотанные кишки... Потенциально, наверное, может быть какой-то датчик для аварийного выключения, но например отдельный условный "датчик момента" не имеет смысла без встраивания в систему управления (при разгоне там момент существенно выше, чем нужно чтоб задавить пациента). И даже если есть такой датчик, то отключение питания будет бессмысленно (ввиду значительной инерции механизма, сам же пишешь -- тонна), и даже включение торможения не поможет -- нужно иметь СУЩЕСТВЕННЫЙ, на порядок и больше, запас момента/мощности двигателя для быстрой остановки, и существенный запас механической прочности всей конструкции (т.е. скорей аварийный стоп -- последующий дорогостоящий ремонт). Что и экономически не выгодно никому кроме пострадавшего (поэтому и нужно гос. регулирование), и опять же требует более сложной системы управления. Могут быть коллекторные двигатели, им проще стартовать и тормозить, и пациента скорей будет давить больше инерцией, чем двигателем, но в остальном так же. Что предлагается: в системе управления реализуется физико-математическая модель объекта управления (вот прямо натурально: задаются физические размеры и массы...) На которую параллельно поступают все те же управляющие сигналы. И с которой снимаются условные сигналы датчиков, и сравниваются с тем что есть на самом деле. И при существенном различии формируется признак аварии. И контроллер двигателя может выдавать потребляемую мощность или измерять момент. И измеренный результат может сравниваться с мат. моделью. В итоге граммы может не почувствует, но уж килограммы-то как-нибудь сможет. Альтернативное решение -- модная сейчас тема машинного обучения. Мол мат. модель мы делать не умеем, но погоняем во всех режимах и запишем что наизмеряли. И в будущем будем выявлять существенные отклонения от записанного через, условно, нейросеть. По-моему это очень вероятностный ("сработает или нет") и сомнительный метод... Вспоминая Therac, отдельный вопрос -- правильность работы системы управления. Я уже писал здесь на эту тему: опять же нужна какая-то форма сертификации ПО на соответствие ряду требований. Например, система управления должна состоять из двух независимых подсистем: 1) основной, используемой при работе; 2) аварийной, проверяющей правильность работы основной системы, и способной перехватить управление в любой момент и осуществить безопасное выключение (например, нужно всегда перекрывать шторку изотопного источника, чтоб все вокруг не пооблучались, не знаю как оно там на самом деле, или на примере выше с двигателем -- уметь не питание отключить, но подать команду на торможение). Идея в том, что основной алгоритм управления может быть чрезвычайно сложным, трудно формализуемым и к тому же многократно изменяться по мере разработки. Поэтому формируется отдельный алгоритм, который не обладает той же полнотой, что основной алгоритм управления, но имеет жёстко заданные условия определяющие корректность работы основного алгоритма, заданные в терминах конечного автомата или в рамках темпоральной логики (допустимых и недопустимых последовательностей событий) -- строго в формализуемой форме (а не в виде запутанного программного кода на C++). Вторая подсистема не обязательно должна быть аппаратно реализована отдельно, может реализовываться на той же вычислительной машине, но должна быть изолирована от программных сбоев первой системы. Практически, может реализовываться отдельным процессом в многозадачной операционной системе. Наличие такой вот второй подсистемы просто выполняющей проверку правильности работы первой по заданным правилам (весьма ограниченному набору правил, который легко составить) могло запросто спасти жизни и здоровье убитых или покалеченных Therac'ом (28 человек, пока программисты исправляли тривиальнейшие баги). Или неизвестное число людей могло бы не пострадать от педали в Toyota, и не пришлось бы придумывать небылицы про педаль западающую за коврик. Лифты могли бы не возить по несуществующим этажам (всегда боялся, что если самого верхнего или самого нижнего концевика нет -- долбанет мало не покажется). Но следующим встанет вопрос надежности самой вычислительной машины. Ты вот пишешь, управляется айбиэмкой под столом. Из этого следует, что в эту же айбиэмку могут вставить флешку с пасьянсом (разрядить в клавиатуру статический разряд от подошедшего оператора) и в этот момент всё перестанет работать. Это опять же вопрос сертификации. Система управления должна быть реализована в приборе автономно, айбиэмка может выступать только в роли пульта управления, а не давать команды на двигатели и читать концевики (пусть и через компорт), как могут норовить сделать ради упрощения обновления ПО.