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

Хотя в основе лучших практик создания любой системы управления лежит стандартизированный подход к настройке прикладного программного обеспечения, задача проектирования системы с нуля, по общему признанию, является сложной задачей.

Как гласит известная поговорка, тремя наиболее важными факторами при продаже недвижимости являются местоположение, местоположение и местоположение. Для распределенных систем управления (РСУ), используемых для управления сложными процессами во многих отраслях, эквивалент можно так же легко охарактеризовать как «стандарты, стандарты и стандарты». Система DCS служит центром операций переработчика, а также контролирует и контролирует ключевые переменные, такие как поток, применяемая температура, давление, уровень и транспортировка/обработка материала. HMI DCS собирает все данные с производственного оборудования и представляет их оператору в максимально «человеческом» виде. Тем не менее, существует бесконечное количество переменных, связанных с типом оборудования, обрабатываемым материалом, действиями оператора и системой управления. Поэтому РСУ должна быть спроектирована так, чтобы предсказуемым образом справляться с обычными ожидаемыми помехами, а также с неожиданными аномалиями. К сожалению, разработка приложения DCS с нуля — это все равно, что смотреть на чистый лист бумаги; его можно настроить практически любым возможным способом. Это палка о двух концах, которая может привести к созданию надежной системы, обеспечивающей точный и предсказуемый контроль, если все делать осторожно, или к потере продукта, перебоям в процессе и даже к проблемам с безопасностью, если все сделано неправильно.

Любая конфигурация приложения должна начинаться с четко определенной философии проектирования. Большинство приложений DCS создаются и поддерживаются группами инженеров, поэтому все они должны двигаться в одном направлении. Наилучшие результаты могут быть достигнуты только тогда, когда все участники общего приложения управления процессом следуют одним и тем же передовым практикам и методам. В противном случае результатом становятся непреднамеренные ошибки процесса и система, которую трудно обслуживать. Каждый инженер, работающий над приложением, должен стремиться писать свою логику одинаково. Используемые стандартные методы должны быть хорошо задокументированы и преподаны всем, кто отвечает за систему контроля. Фактически, если инженеры систем управления не могут идентифицировать конкретного программиста, глядя на логику программы или наблюдая за ее выполнением, это будет подходящим признаком хорошо спроектированного приложения РСУ. Одной из конкретных областей проектирования РСУ, которая иллюстрирует преимущества устоявшейся общей философии, является управление сигналами тревоги. В автоматизации процессов сигнализация определяется как звуковое и/или видимое средство, указывающее оператору на неисправность оборудования, отклонение технологического процесса или ненормальное состояние, требующее реакции оператора. Плохо спроектированные и обслуживаемые системы управления сигнализацией могут перегружать операторов болтовней и мешающими сигналами тревоги в нормальных условиях, а также изнурительным потоком сигналов тревоги при возникновении ненормальных состояний. Когда это происходит, операторам может быть сложно выявить наиболее важные сигналы тревоги и отреагировать на них, что приводит к нештатным ситуациям, потерям производства и даже серьезным авариям. Недавно такие организации, как ANSI (Американский национальный институт стандартов) и ISA (Международное общество автоматизации), выпустили обновленные рекомендации, касающиеся управления сигналами тревоги. Стандарт ANSI/ISA 18.2 охватывает весь жизненный цикл управления сигнализацией: от проектирования и настройки до мониторинга производительности, аудита и обеспечения соблюдения требований на протяжении всего срока службы управляющего приложения. По сути, комитет ISA определил, что сигнал тревоги следует использовать только в том случае, если он требует реакции оператора, и это, вероятно, первое нарушение большинства перерабатывающих заводов. Они используют будильники для всевозможных уведомлений, оповещений и напоминаний. Ведущие компании по автоматизации процессов в большей степени применяют стандартизированный подход к разработке приложений, уделяя особое внимание различению сигналов тревоги, требующих немедленного внимания, от менее срочных уведомлений, предупреждений и сообщений. Например, РСУ Valmet D3 спроектирована так, чтобы соответствовать или превосходить требования, изложенные в ISA-18.2, хотя и с немного другой терминологией. Сюда входит ограничение сигналов тревоги, поддержка определения приоритетов сигналов тревоги, классификация сигналов тревоги и обеспечение динамического управления сигналами тревоги.