Дмитрий Дагаев писал(а):
Микродат по крайней мере похож на контроллер, забудьте по компьютер с Линуксом. У меня как диск в информационной системе на объекте сбойнул, и RAID не помог, питанием вырубали. Так там система мягкого реального времени. А в автоматическое управление на ОС со свопингом - боже упаси...
Ну вот, допустим, класс машин, который назывался УВМ - СМ, Днепр - это к чему ближе?
Аппаратно и по софту.
Имхо, к универсальным ЭВМ. Другой вопрос, что это не безумный Intel с макроконвейрами, суперскалярами, кэшем и проч.
Бортовые СУ тоже, как правило, опираются на некий центральный узел, который по идеологии ближе к универсальной машине.
А по архитектуре ПО они, как правило, ближе к программированию, чем к АСУТП-шному конфигурированию.
Для меня естественно мыслить и описывать управление так, как, допустим, это делается в управляющем софте на Ada.
А не так, как это обычно делает инженер-автоматизатор.
Нужна возможность вводить набор модулей, абстракций, интерфейсов, которые будут многократно применяться.
А не в режиме "копипасты", как я насмотрелся в немецких проектах в сельхозке (разработки крутых контор типа Шульц Автомайшн): когда берут существующий файл предыдущего проекта и начинают напильником приводить его в соответствие новому объекту.
Для инженеров это естественно - это как взять Автокадовский проект похожего объекта и переделать под новый.
Но это абсолютно дико с точки зрения принципов программирования.
В принципе, понятно, что ПЛК эволюционировали на замену релейной логике.
Но есть уровень интеллектуальности системы, который неестественно реализовывать на этом уровне.
Базовая защита и поддержание режимов - да.
Допустим, уже какая-либо графовая математика для расчёта маршрутов в поточных производствах и т.п. - не на ПЛК же это реализовывать.
Сложная математика управления техпроцессами.
И т.п.
Управление любой боевой системой - от А135 до С400 - это тоже подобно отнюдь не контроллеру и "пром-автоматизационному" подходу.
Там ЭВМ универсального характера и ПО соответствующего вида.