Средства и методы разработки

Классика! 8) И у меня есть ответы. 

Первое:

Если система спроектированна таким образом, что в нештатной ситуации человеку нужно ПОЛНОСТЬЮ перехватить управление - это не система, а чья-то персональная месть.

От человека должно ожидаться принятие решения по ЧАСТНОМУ вопросу управления. Какой-то сокращенный режим.

В большинстве случаев - принятие решения о повторном пуске. Из заведомо безопасного состояния. Без спешки.

Из этого следует второе:

Роль человека, в системах АСМУ это не участие в управлении, а ПРИНЯТИЕ ОТВЕТСТВЕННОСТИ.

И чем меньше второе, в спроектированной вами системе, похоже на первое - тем лучше спроектированна система.

А из второго третье:

Современная АСМУ это не столько инструмент оператора, сколько инструмент ЭКСПЕРТА.

Того, кто прийдет на развалины вашего порохового цеха разбираться что-же пошло не так, и как лечить.

Архивы. И удаленный доступ (рабочее время экспертов всегда дорого!) - ключевая функция,

которая принесет (или съэкономит) вам очень-много-денег.

Сильно больше, чем замена оператора, который все равно останется на месте (см. пункт 2)

И "золотой пункт", с которым я на 200% согласен - человек не может выполнять НЕЛОГИЧНЫЙ набор функций эффективно!

Иногда лучше оставить ему какую-то легко автоматизируемую функцию, чтобы получить целостную и непротиворечивую зону ответственности (пункт 2).

На одном ОЧЕНЬ большом объекте, я добавил программное вычисление наибольшей положительной и отрицательной ошибки на интервале. По каждому регулятору отдельно. С ручным сбросом. Сброс должен был выполнять оператор АСМУ.

Прижилось просто охуенно!

Время между сбросами всем было похуй отдавалось на откуп оператору.

В результате, сидящий четыре часа за монитором оператор действительно просматривал что где как.

Появилась визуальная память.

Появилась компетенция "что-то мне не нравится как оно сегодня регулирует" (тм)

Давно это было :)