Системные требования SCADA
Хорошо документирование системных требований SCADA, вероятно, является самым важным фактором успеха проекта SCADA. Это может показаться очевидным, но скажем так: написание функциональной спецификации должно происходить до начала проектной работы в системе SCADA.
Почему функциональные спецификации необходимы для успеха проекта SCADA (фото-кредит: ABB)
Крупнейшему убийцу по расписанию и расписанию по проекту приходится переделывать часть или весь дизайн. Это связано с тем, что каждая фаза проекта строится на основе данных и работы, выполненных на предыдущем этапе.
Если какая-либо функция оборудования или точка ввода / вывода или формат сигнала пропущены или опущены, работа по добавлению или исправлению его позже в проекте может оказать серьезное негативное воздействие.
Еще одна причина, подчеркивающая важность функциональной спецификации, заключается в том, что на этапе проектирования и реализации проекта принимается множество решений и компромиссов, чтобы сохранить проект в рамках бюджета и по графику. Только имея четкое представление о функциональных требованиях системы, можно принимать объективные решения о том, что можно вырезать из проекта.
Функциональная спецификация проекта SCADA
Самая известная среда для построения понимания системных требований представлена в виде функциональной спецификации. В документе тщательно излагаются структурированным образом, как работает этот процесс и как система SCADA будет взаимодействовать с этим процессом.
Кажется, что нет установленного стандарта для функциональной спецификации. Но вполне нормально полагать, что любое определение функциональности системы должно выполняться с помощью подхода «сверху вниз», т. Е. Сначала работать над функциями перестройки, задачами и коммуникациями, а затем работать с более конкретными задачами и функции.
Независимо от формата функциональная спецификация должна содержать следующие элементы:
- Опишите процесс
- Опишите физическую схему процесса
- Оценить критическую критичность системы SCADA
- Опишите, как информация будет проходить через систему
- Определение стратегии безопасности
- Документировать стратегию сигнализации
- Определение критериев тестирования и принятия системы
1. Опишите процесс
Включите входы материалов, выходы, этапы обработки, время цикла, периоды работы, полную детализацию нормальных рабочих условий, а также любые ненормальные условия, которые могут существовать во время рутинных операций.
Включите в этот раздел, какие стратегии и алгоритмы управления должны быть установлены для различных частей оборудования. Если управление замкнутым контуром запланировано для любых уровней, температур, давлений или потоков, это должно быть указано явно.
Необходимость более сложных контуров управления, таких как каскад или передача вперед или необходимость взаимодействия с частотно-регулируемыми приводами, должна быть идентифицирована спереди. Необходимо также документировать особые потребности в размещении этих петель в автоматическом или ручном управлении или из него.
Вернуться к содержанию ↑
2. Опишите физическую схему процесса
Включите любую документацию, чертежи, эскизы и т. Д., Которые обеспечивают ощущение того, где процессы и связанное с ними оборудование расположены друг относительно друга и на предполагаемые станции мониторинга / управления оператором.
Включите любые известные или предполагаемые ограничительные условия, которые могут существовать в рамках параметров проекта. Недостаток достаточной электрической мощности или экстремальных температурных или влажностных условий или вовлечение классифицированных опасных зон должны быть подняты в начале проекта, а не когда-то после того, как все уже началось.
Вернуться к содержанию ↑
3. Оценить критическую критичность системы SCADA
Каковы могут быть последствия, если отказ в системе SCADA приводит к тому, что процесс выходит из-под контроля? Незначительные неудобства или непредвиденная катастрофа? Что делать, если данные или сообщения потеряны? Является ли это просто эксплуатационной или процедурной неприятностью или будет ли нарушена безопасность общественности?
В этот момент выгодна некоторая форма анализа структурированных отказов, например, FMEA (анализ эффектов режима отказа). Этот метод учитывает вероятность возникновения сбоев, вероятность обнаружения этих сбоев и уровень серьезности последствий отказа.
Это приводит к ранжированию различных сбоев, которые могут произойти.
Анализ эффекта режима отказа (FMEA)
| ранжирование | Строгость | Вхождение | обнаруживаемость |
| 1 | Нет эффекта | Удаленный: неудача маловероятна <1 из 15 000 000 | Управление конструкцией будет определять потенциальную причину или механизм и последующий режим отказа |
| 2 | Система, работающая с минимальными помехами | Низкий: относительно небольшое количество отказов <1 в 150 000 | Очень высокая вероятность того, что управление проектами обнаружит потенциальную причину или механизм и последующий режим отказа |
| 3 | Система, работающая с некоторой деградацией производительности | Низкий: относительно мало отказов <1 в 15 000 | Высокая вероятность того, что управление проектами обнаружит потенциальную причину или механизм и последующий режим отказа |
| 4 | Система, работающая со значительным ухудшением характеристик | Умеренный: случайные сбои <1 из 2 000 | Низкая вероятность того, что управление проектами обнаружит потенциальную причину или механизм и последующий режим отказа |
| 5 | Система не работает без повреждений | Умеренный: случайные сбои <1 из 400 | Умеренная вероятность того, что управление проектом обнаружит потенциальную причину или механизм и последующий режим отказа |
| 6 | Система не работает с незначительным повреждением | Умеренный: случайные сбои <1 из 80 | Низкая вероятность того, что управление проектами обнаружит потенциальную причину или механизм и последующий режим отказа |
| 7 | Система не работает с повреждением оборудования | Высокий: повторные отказы <1 из 20 | Очень низкая вероятность того, что управление проектами обнаружит потенциальную причину или механизм и последующий режим отказа |
| 8 | Система не работает с разрушительным разрушением без ущерба для безопасности | Высокий: повторные отказы <1 в 8 | Удаленная возможность управления проектами будет определять потенциальную причину или механизм и последующий режим отказа |
| 9 | Очень высокий рейтинг серьезности, когда потенциальный режим отказа влияет на безопасную систему с предупреждением | Vey high: Отказ почти неизбежен <1 из 3 | Очень удаленная возможность управления проектами будет определять потенциальную причину или механизм и последующий режим отказа |
| 10 | Очень высокий рейтинг серьезности, когда потенциальный режим отказа влияет на безопасную систему без предупреждения | Vey high: Отказ почти неизбежен <1 из 2 | Управление конструкцией не может обнаружить потенциальную причину или механизм и последующий режим отказа |
Этот тип оценки будет принимать решения относительно выбранной аппаратной платформы и потребности в избыточности в процессорах, сетях и устройствах хранения данных.
Чрезвычайно критические процессы, которые, если они не работают правильно, могут привести к травме или существенному повреждению оборудования или имущества, должны быть идентифицированы таким образом, чтобы они принимали решения по выбору оборудования, которое может иметь реальную разницу в стоимости.
Предоставление избыточности в ЦП или вводе / выводе или в коммуникационных связях может быть достигнуто, но при значительных затратах.
Вернуться к содержанию ↑
4. Опишите, как информация будет проходить через систему
- Начните с начала с входов оператора и ведения записей, записях, которые операторы в настоящее время хранят в бумажных формах, которые они создают или снабжаются, записи, сделанные в журналах журналов и т. Д.;
- Информация, доступная через существующие измерительные приборы процесса, записи на круговой или полосовой диаграмме;
- Информация, которая будет доступна через связи с другими информационными системами, базами данных, существующими системами SCADA и т. Д.;
- Информация, которая будет поступать в систему посредством ввода / вывода SCADA, температуры, давления, потоков и т. Д.;
- и закончите с тем, что предназначено для информации SCADA.
Просто отображается на локальных рабочих станциях? Распространяется в удаленных местах по всей окружной сети? Выдвинуты ли базы данных на административный мейнфрейм? Отформатирован ли на активные серверные страницы для доступа через интрасеть или Интернет?
В этот раздел должен быть список точек ввода-вывода, которые будут настроены в системе, диапазон технических единиц для этих точек, требуемая частота обновления для каждой точки.
Вернуться к содержанию ↑
5. Определите стратегию безопасности
Как правило, в системе SCADA реализовано по меньшей мере 2 пользовательских уровня. Первый уровень для средних пользователей и, как правило, разрешает доступ ко всем рабочим экранам и позволяет модифицировать заданные значения процесса, необходимые для бесперебойной работы установки.
На втором уровне обычно предоставляется более высокий уровень доступа, доступ к экранам конфигурации и разрешение на изменение точек будильника и частот сбора данных.
Вернуться к содержанию ↑
6. Документируйте стратегию сигнализации
Сначала определите точки в системе, которые должны быть встревожены. Затем определите, хотите ли вы иметь разные уровни серьезности для различных аварийных сигналов, которые будут существовать в системе. Устойчивые отклонения между заданной точкой и переменной процесса для некритического параметра процесса обычно приводят к простому предупреждению об отклонении и простому уведомлению оператора.
Такой же тип отклонения для более критического значения процесса может сочетаться с технологическими блокировками или инструкциями по корректировке действий оператора, поэтому этот уровень тревоги должен обрабатываться по-разному в системе.
Тревоги, которые будут связаны с аварийным отключением технологического оборудования, должны получать еще более высокий приоритет в системе.
Также у вас есть стратегия для того, как будильники будут регистрироваться, подтверждаться и очищаться из системы. Это, вероятно, будет отличаться для различных типов аварийных сигналов. Общеизвестно, что файл журнала должен быть построен (и, возможно, распечатан в печатном виде), который документирует все действия и события, которые происходят в системе SCADA, включая аварийные сигналы.
Аварийные сигналы, которые являются уведомлениями оператора, часто могут быть самоочищающимися, то есть когда отклонение уходит, так же происходит и тревога. Сигналы с более высоким приоритетом должны быть зафиксированы так, что подтверждение оператора будет успокоить klaxon, но до тех пор, пока существует условие тревоги, сигнал тревоги не может быть полностью очищен.
Убедитесь, что окончательный список аварийных сигналов и стратегия предупреждения рассмотрены и одобрены инженерами-технологами, ответственными за процесс, и лицами, ответственными за контроль над процессом, и лицами, обслуживающими людей, которым придется реагировать на условия тревоги.
Мотивы и цели этих разных групп совершенно разные, поэтому будет проведено много переговоров до утверждения окончательного списка и стратегии.
Инженеры-разработчики обычно хотят более тревожных, чем практические, что приводит к возникновению множества тревожных сигналов. Они назойливы для операторов и нередко перехватываются или переопределяются вскоре после их внедрения. Гораздо лучше установить уменьшенный набор аварийных сигналов, которые имеют смысл и полезны для операторов.
Обычно люди обслуживания предпочитают сигналы тревоги, которые могут выступать в качестве предикторов неисправности оборудования, а не отклонений процесса, поэтому они будут иметь некоторые сигналы тревоги, которые могут быть упущены первыми двумя группами.
Вернуться к содержанию ↑
7. Определение критериев тестирования и принятия системы
Последнее, что следует сказать о функциональных спецификациях, - это указать их роль в тестировании и проверке системы SCADA после ввода в эксплуатацию.
Очень важно учесть понятие тестирования в момент создания функциональных спецификаций. Для каждой функции, описанной в спецификации, метод проверки или проверки должен, по крайней мере, быть задуманным и документированным.
Этот документ будет полезен позже, когда он станет основой для вашего плана тестирования приемочных испытаний. Если вы не можете представить себе тест или этап проверки для функции, которую вы описываете, то, возможно, вам действительно не нужна эта функция, или вы не понимаете ее достаточно хорошо, чтобы полностью описать ее.
Вернуться к содержанию ↑
Ссылка // Системы SCADA в очистке сточных вод Стефаном Дж. Сосиком, CEO Process-Logic, LLC